[Performance Test Plan] Main Hero Spray CPU·GPU 병목 진단

[SubJeeLee]

상태

측정 전 진단 설계입니다. 아래 절차로 긴 드래그 상황을 재현한 뒤, 실제 trace와 수치를 추가합니다.

배경

메인 Hero의 Canvas 기반 스프레이는 긴 드래그에서 버벅임이 관찰되었습니다. 원인이 JavaScript·Canvas draw call 중심의 CPU 병목인지, 투명도 합성 및 대형 Canvas 버퍼 중심의 GPU 부담인지, 혹은 객체 생성과 GC에 의한 메모리 문제인지 분리해 확인합니다.

목표는 단순히 효과를 축소하는 것이 아니라, 디자인 의도를 유지한 채 어떤 비용이 프레임 드롭을 만드는지 근거를 확보하는 것입니다.

현재 구현 가설

후보	현재 구조에서의 근거	확인 방법
CPU scripting	스탬프마다 입자 배열을 순회하며 arc()를 반복 호출	Performance Main thread에서 Scripting·함수 self time 확인
CPU paint / raster	Hero 전체 Canvas를 매 프레임 clearRect() 후 재도포	Frames·Main thread의 Paint/Raster 시간 확인
GPU compositing	DPR 2 Canvas와 반투명 입자를 대형 Hero 이미지 위에서 알파 합성	Performance GPU track, Chrome Task Manager GPU memory 추이 확인
메모리 / GC	긴 드래그 중 스탬프·입자 객체가 반복 생성·소멸	Performance의 GC event, Memory allocation timeline, JS heap 회복 여부 확인

예상 비용 모델

현재 스탬프는 중심 타원과 주변 입자로 구성됩니다. 장시간 드래그에서는 일정 시간 안에 생성된 모든 스탬프가 매 프레임 다시 그려집니다. 따라서 활성 스탬프 수와 입자 수의 곱이 Canvas 명령 수를 결정합니다.

프레임당 draw 명령량 ≈ 활성 스탬프 수 × (중심 도포 1 + 입자 수)

개수로 경로를 강제로 자르는 방식은 시각적으로 꼬리가 잘려 보이는 문제를 만들었으므로, 성능 경계는 고정 길이 절단이 아니라 측정 결과를 바탕으로 입력 샘플링·브러시 캐싱·생명주기를 조합해 설정합니다.

재현 시나리오

공통 환경

• 브라우저: 최신 Chrome 안정 버전, 확장 프로그램 없는 시크릿 창
• URL: 로컬 production build 또는 Vercel Preview
• 화면: 1920 × 1340, DPR 2 우선
• 조건: prefers-reduced-motion 비활성화, 정밀 포인터 환경
• 대상: / 메인 Hero

시나리오 A — 기준선

1. 새로고침 직후 10초간 아무 입력 없이 관찰
2. FPS, CPU, JS heap, GPU memory 기준선 기록

시나리오 B — 일반 분사

1. 10초 동안 Hero 내부를 중간 속도로 원형·직선 드래그
2. 입력 후 3초 이상 대기해 모든 스탬프 소멸 확인
3. FPS, Long task, 입력 지연, 메모리 회복 여부 기록

시나리오 C — 최악 조건

1. 30초 동안 빠른 장거리 지그재그 드래그 반복
2. 서로 다른 색상 스트로크를 반복 시작
3. 드래그 중과 종료 뒤의 trace·memory를 각각 저장

시나리오 D — 저사양 근사

1. Performance 패널에서 CPU 4× slowdown 설정
2. 시나리오 B와 C를 반복
3. 데스크톱에서 문제 없이 보이지만 저사양 환경에서 악화되는 구간 확인

CPU throttling은 실제 모바일 칩을 완전히 재현하지는 않으므로, 상대 비교 기준으로만 사용합니다.

측정 도구와 기록 항목

1. Chrome DevTools Performance

• Record runtime performance를 시작하고 시나리오를 수행
• Screenshots, Web Vitals, Main thread, GPU track을 포함
• 확인 항목
  • FPS track의 red bar 및 60 FPS 이탈 구간
  • Main thread의 긴 task (50ms 이상)
  • Scripting / Rendering / Painting 비중
  • pointermove interaction의 input delay·processing·presentation delay
  • 200ms 이상 INP 경고 유무
  • GC event의 빈도와 시간

2. Chrome Task Manager / Performance Monitor

• Memory footprint
• JavaScript memory의 live value
• GPU memory
• CPU usage
• DOM Nodes / Layouts per second

Canvas 구현에서는 DOM Node·Layout 증가가 낮아야 하며, 문제 발생 시 CPU·GPU·JS memory가 함께 어떤 형태로 변하는지 확인합니다.

3. Memory 패널

• 분사 전 Heap Snapshot
• 30초 분사 후 Snapshot
• 분사 종료 및 생명주기 종료 후 Snapshot
• Allocation timeline으로 반복 생성 위치와 GC 이후 잔존 객체 확인

성공 기준

지표	목표	실패 신호
프레임	일반 분사 중 50~60 FPS	지속적인 FPS red bar 또는 30 FPS 근접
Main thread	반복 long task 없음	50ms 이상 task가 연속 발생
입력 반응	INP 200ms 미만	pointer interaction 경고 발생
메모리	입력 종료 후 기준선 근처 회복	JS heap/GPU memory가 반복 입력마다 누적 상승
시각	시간 순서로 자연스럽게 소멸	고정 길이에서 경로가 잘려 꼬리처럼 보임

결과에 따른 의사결정

CPU draw call이 병목이면

• 입자 수를 무작정 줄이기 전에, 스프레이 브러시를 OffscreenCanvas에 한 번 생성
• 본 Canvas에서는 스탬프당 다수의 arc() 대신 drawImage() 1회 중심으로 렌더링
• 입력 보간 간격을 성능 예산과 함께 조정

GPU 합성이 병목이면

• DPR 상한을 2에서 화면 크기별 동적 값으로 검토
• Canvas 영역을 Hero 전체가 아닌 실제 분사 가능 영역으로 축소할 수 있는지 검토
• 반투명 입자·큰 blur/filter 추가는 피함

GC / 메모리가 병목이면

• 객체·배열 재할당을 줄이고 풀링 또는 브러시 이미지 캐싱 검토
• 스탬프 생명주기 종료 후 즉시 참조 제거 여부 확인

모든 지표가 허용 범위이면

• 현 Canvas 2D 구조 유지
• 측정 trace, 환경, 수치를 포트폴리오 근거로 보관

산출물

• before/after Chrome Performance trace (.json.gz)
• 1920px DPR 2 기준 프로파일 스크린샷
• CPU 4× throttle 비교표
• 병목 판단과 선택한 개선안
• 구현 전·후 수치를 포함한 후속 Discussion 댓글

관련 기록

• Main Hero Spray Interaction #2
• 현 구현의 기술 메모와 조정 과정은 [Technical Design] Main Hero Spray Interaction #2 댓글에 누적합니다.