측정값을 믿을 수 없을 때

서로 다른 입력을 넣었는데 결과가 똑같이 나온다면, 그 입력이나 로직보다 계측 도구를 먼저 의심하십시오.

어떤 씬이나 변형을 재도 프레임 타임이 전부 같게 나옵니다

무엇이 보이는가. 여러 씬, 여러 조건에서 프레임 타임을 측정했는데 값이 전부 정확히 같은 숫자로 나옵니다(예: 16.7ms 부근에 고정).

왜 그런가. 브라우저의 vsync가 프레임 타이밍을 디스플레이 주사율에 맞춰 클램프합니다. 실제 렌더링 비용이 그보다 훨씬 작아도, vsync가 켜져 있으면 측정값은 주사율 간격으로 잘려 나옵니다.

어떻게 확인하는가. 서로 다른 부하를 주는 씬을 여러 개 준비했는데도 값이 소수점까지 동일하다면 vsync 클램프를 의심하십시오.

어떻게 고치는가. 브라우저 실행 플래그에 --disable-gpu-vsync와 --disable-frame-rate-limit을 추가하십시오.

무엇이 보이는가. CPU 스로틀링을 설정했는데 성능 저하나 병목 증상이 재현되지 않습니다.

왜 그런가. 스로틀링 배율이 충분히 세지 않으면 병목이 드러나지 않습니다. 낮은 배율에서는 멀쩡해 보이던 코드가 더 높은 배율에서야 문제를 드러내는 경우가 있습니다.

어떻게 확인하는가. 배율을 단계적으로 올려 가며 재현 여부를 확인하십시오. 특정 배율 이하에서는 증상이 전혀 안 보일 수 있습니다.

어떻게 고치는가. CPU 스로틀링을 재현이 확인될 때까지 충분히 세게 거십시오. 낮은 배율에서 “문제없음”으로 결론 내리지 마십시오.

무엇이 보이는가. 정리(teardown) 단계가 본 작업보다 오래 걸리는 것처럼 측정됩니다. 직관과 반대되는 결과입니다.

왜 그런가. requestAnimationFrame 간격을 비용 측정에 쓰면, 그 값은 JS 실행 비용이 아니라 컴포지터(compositor) 부하를 반영합니다. rAF 간격은 JS 비용의 대리 지표가 아닙니다.

어떻게 확인하는가. 같은 구간을 rAF 간격과 다른 방식으로 각각 측정해 결과가 갈리는지 비교하십시오.

어떻게 고치는가. JS 비용을 귀속하려면 rAF 간격이 아니라 Profiler.start() / Profiler.stop()이 반환하는 hitCount를 쓰십시오. 프레임 예산은 프레임타임으로 재십시오.