사이트 속도 점수, 도구마다 다른 이유 — 시뮬레이션과 실측

자기 사이트에 72점을 매긴 도구

성능 진단 도구를 하나 만들어 쓰고 있습니다. 어느 날 이 도구로 제 사이트를 재봤더니 성능 72점이 나왔습니다. 도구가 원인으로 지목한 항목이 있어서, 그대로 손보고 배포했습니다. 다시 쟀습니다. 점수는 그대로였습니다.

이상했습니다. 지목된 걸 고쳤는데 숫자가 1점도 안 움직인다면, 둘 중 하나입니다. 제가 엉뚱한 걸 고쳤거나, 애초에 지목이 틀렸거나. 그래서 측정 방식 자체를 바꿔서 한 번 더 재봤습니다. 이번엔 100점이 나왔습니다. LCP 1.5초. 같은 페이지, 같은 배포본인데 72점과 100점이 오갔습니다.

시뮬레이션과 실측

점수가 갈린 건 스로틀링 방식이 달랐기 때문이었습니다. 느린 회선 환경을 흉내 내는 방법이 크게 두 가지 있습니다.

첫째는 시뮬레이션입니다. 빠른 회선으로 페이지를 실제로 받아놓고, “만약 느린 회선이었다면 이 정도 걸렸겠다”를 계산으로 추정합니다. 빠르고 저렴해서 널리 쓰이는 기본값입니다. 둘째는 실측입니다. 느린 회선을 실제로 걸어놓고 잽니다. 느리지만 실제 사용자 경험에 가깝습니다.

대부분의 페이지에서는 두 값이 비슷하게 나옵니다. 그런데 어떤 페이지에서는 크게 어긋납니다. 제 사이트가 하필 그 어긋나는 쪽에 걸린 것이었습니다. 어느 방식이 절대적으로 옳다는 얘기가 아닙니다. 방식이 다르면 숫자가 다를 수 있다는, 그 당연한 사실을 그날 처음으로 몸으로 겪었습니다.

페이지를 다 꺼봤습니다

점수를 믿기 전에, 페이지 쪽에 진짜 원인이 있는지부터 지우고 싶었습니다. 원인이 될 만한 걸 하나씩 차단해보는 실험을 했습니다.

먼저 자바스크립트를 차단했습니다. First Paint 2,400ms. 다음으로 웹폰트를 차단했습니다. 여전히 2,400ms. CSS까지 차단했습니다. 그래도 2,400ms.

다 꺼진 페이지가 2.4초가 걸릴 수는 없습니다. 렌더링할 게 사실상 남지 않았는데도 숫자가 고정으로 박혀 있다면, 그건 페이지가 만들어낸 값이 아니라 측정이 만들어낸 값입니다. 여기서 얻은 규칙은 단순합니다. 다 껐는데 숫자가 안 움직이면 도구를 의심한다. 페이지를 아무리 최적화해도 안 내려가는 바닥값은, 페이지의 문제가 아닐 확률이 높습니다.

교차 검증으로 오탐만 걸러내기

그래서 진단 도구에 교차 검증을 넣었습니다. 구조는 이렇습니다.

• 1차는 빠른 시뮬레이션으로 잰다.
• 점수가 기준(60점) 미만이면, 실측으로 한 번 더 잰다.
• 둘 다 기준 미만일 때만 낮은 점수로 보고한다.
• 두 값이 엇갈리면 실측 쪽을 채택한다.

여기서 놓치기 쉬운 게 하나 있습니다. 채택하는 쪽을 바꿀 때는 점수만 바꾸면 안 됩니다. 개선 항목, 즉 발견사항도 채택한 쪽의 것으로 함께 교체해야 합니다. 점수는 실측값 100점으로 바꿔놓고 리포트 본문에는 시뮬레이션이 뽑아낸 개선 항목이 그대로 남아 있으면, 숫자와 본문이 서로 어긋난 리포트가 됩니다.

비용도 정직하게 적어둡니다. 검증이 발동하지 않으면 약 10초, 발동하면 약 31초가 걸립니다. 모든 페이지에 실측을 거는 게 아니라, 기준 미만일 때만 한 번 더 재는 조건부 설계라 평소 비용은 낮게 유지됩니다.

남겨둔 것

솔직하게 적어둘 게 있습니다. 왜 First Paint가 하필 2,400ms에 고정으로 찍히는지, 그 근본 원인은 아직 모릅니다. 교차 검증은 엇갈리는 값 중 실제에 가까운 쪽을 고르게 해줄 뿐, 왜 그 값이 나오는지를 설명해주지는 않습니다. 오탐을 막는 장치와 원인을 밝히는 일은 다른 문제입니다.

그래서 이 글의 결론은 소박합니다. 속도 점수는 하나의 숫자가 아니라 측정 방식에 딸린 숫자입니다. 점수가 안 움직이면 배포를 의심하기 전에 측정을 의심해보고, 페이지를 다 꺼도 안 내려가는 바닥값이 보이면 그때는 도구 쪽을 들여다봅니다. 판단 기준은 그 두 문장이면 충분했습니다.

---

측정 도구를 직접 만들며 겪은 이런 삽질과 판단 기준을, 뉴스레터로 이따금 정리해 보내고 있습니다. 비슷한 고민을 하는 1인 개발자라면 구독해두셔도 좋겠습니다.