Lighthouse 속도 점수가 재는 방식마다 다른 이유와 실측으로 다시 재는 법

제가 만들어 쓰는 사이트 진단 도구가 제 사이트 성능을 72점으로 매겼습니다. 지목된 원인을 고쳐 배포했는데 점수는 1점도 안 움직였고, 같은 주소를 측정 방식만 바꿔 다시 재니 100점, LCP 1.5초가 나왔습니다. 진단 도구는 Lighthouse 를 기본 설정 그대로 쓰고 있었고, Lighthouse 의 기본 스로틀링은 실제로 회선을 느리게 거는 방식이 아니라 계산으로 추정하는 시뮬레이션입니다.

그래서 점수가 낮게 나왔을 때 고치기 전에 할 일은 두 가지입니다. 실제로 회선을 느리게 걸어 한 번 더 재보고, 두 번 다 낮을 때만 페이지를 의심합니다. 아래에 어떻게 알아냈는지, 무엇을 확인하면 되는지를 순서대로 적었습니다.

72점을 받고 고쳤는데 점수가 그대로였던 과정

처음 몇 번 잴 때 성능은 72~73점, LCP 는 5.6초였습니다. 원인은 분명해 보였습니다. 첫 화면을 프리로더가 2.3초 동안 덮고 있었고(숫자 카운터 1.5초 + 슬라이드 0.8초), 그다음 LCP 로 잡히는 배경 글자가 투명한 상태에서 1.8초에 걸쳐 나타났습니다. LCP 는 요소가 다 보여야 확정되니 계산이 딱 맞았습니다.

프리로더를 1.0초로 줄이고 페이드 효과를 없앤 뒤 배포했습니다. 다시 재보니 72~74점으로 그대로였습니다. 렌더 지연(render delay)은 2,349ms 에서 2,079ms 가 됐으니, 화면을 가리던 시간을 1.3초 줄였는데 지표는 270ms 만 줄어든 셈입니다. 이게 처음 세운 가설이 틀렸다는 신호였습니다.

페이지를 하나씩 꺼서 측정을 의심하는 법

원인을 찾으려고 의심되는 걸 하나씩 빼봤습니다. 실제 사이트에서 Cloudflare 스크립트를 막으니 2,353ms, GA 를 막으니 2,407ms, CPU 스로틀을 풀어도 2,444ms 였습니다. 전부 2.4초 근처에서 움직이지 않았습니다.

같은 상황을 로컬에서 다시 만들었습니다. 모든 응답을 300ms 씩 늦추는 서버를 띄우니 First Paint 2,389ms 로 재현됐고, 그 환경에서 하나씩 차단한 결과는 이렇습니다.

막은 것	First Paint
자바스크립트	2,403ms
웹폰트	2,397ms
CSS	2,398ms

꾸미는 파일까지 다 빠져 글자만 남은 페이지가 2.4초 걸릴 수는 없습니다. 관측값에도 이상한 점이 있었는데, 페이지 로드(Load)는 678ms 에 끝났는데 First Paint 는 2,430ms 였습니다. 다 받아놓고 1.75초 동안 아무것도 안 그린 것으로 나왔고, 필름스트립도 2.4초까지 까맸습니다.

이때부터 페이지 말고 측정을 봤습니다. 같은 주소를 실제 네트워크 스로틀링으로 재니 100점, LCP 1.5초였습니다. 실제 사이트의 HTML 을 로컬에서 그대로 재생하면 First Paint 는 107ms 였습니다. 같은 사이트의 다른 페이지(/terms/)는 시뮬레이션으로 재도 98점이 나왔으니, 시뮬레이션이 모든 페이지에서 틀리는 것도 아니었습니다.

원인이 안 좁혀질 때 이 방법이 쓸모가 있습니다. 의심되는 걸 하나씩 빼다가 전부 뺐는데도 숫자가 안 변하면, 그 숫자는 페이지가 만든 값이 아니라 재는 쪽이 만든 값일 가능성이 큽니다.

Lighthouse 시뮬레이션과 실측 스로틀링의 차이

Lighthouse 스로틀링 문서에 따르면 Lighthouse 는 기본으로 시뮬레이션 스로틀링을 씁니다. 빠른 회선으로 한 번 실제로 받은 기록을 바탕으로 느린 회선이었다면 얼마나 걸렸을지를 계산하는 방식입니다. 빠르고 결과가 매번 같은 대신, 문서에도 계산으로 예측하는 방식이라 어느 정도 부정확함이 따른다고 적혀 있습니다.

방식	재는 법	장단점
시뮬레이션 (기본값)	빠르게 받고 느린 회선을 계산	빠름 · 특정 페이지에서 어긋남
DevTools 스로틀링	요청마다 실제로 느리게 걸어 잼	느림 · 실제 경험에 가까움

모바일 기본 프리셋은 지연 150ms, 다운로드 1.6Mbps, 업로드 750Kbps 입니다(2026년 10월 문서 확인). 명령줄에서는 --throttling-method=devtools 를 붙이면 실제로 느리게 걸어서 잽니다.

npx lighthouse https://example.com --throttling-method=devtools

어느 방식이 늘 옳다는 뜻은 아닙니다. 대부분의 페이지에서는 두 값이 비슷하게 나오고, 제 사이트가 어긋나는 쪽에 걸렸을 뿐입니다. 점수 하나만 보고 고칠 곳을 정하면 이런 경우를 못 거릅니다.

점수가 낮게 나왔을 때 확인하는 순서

1. 방식을 바꿔 한 번 더 잽니다. Lighthouse 라면 --throttling-method=devtools 를 붙여 재고, 명령줄을 쓰지 않는다면 다른 속도 측정 도구로 재봅니다.
2. 시간을 달리해 한 번 더 잽니다.
3. 두 번 다 낮을 때만 페이지를 고칩니다.
4. 고쳤는데 숫자가 안 움직이면 원인 후보를 하나씩 끄고 잽니다. 다 꺼도 안 움직이면 측정을 의심합니다.

개발자가 아니어도 1~3번은 그대로 할 수 있습니다. 점수 한 번 보고 수정을 맡기면 멀쩡한 걸 고치는 데 돈이 나갑니다.

좋아 보이는 최적화를 빼는 것도 실측으로 확인해야 합니다. 같은 사이트에서 433KB 폰트의 preload 를 빼면 나아질 줄 알았는데, 실측 점수가 84점에서 76점으로, FCP 가 2.0초에서 4.1초로 나빠졌습니다. preload 가 없으면 CSS 를 읽은 뒤에야 폰트 요청이 시작돼 글자가 늦게 그려졌고, 그래서 되돌렸습니다.

진단 도구에 교차 검증을 넣은 방법

진단 도구가 남의 사이트를 이렇게 낮게 매겨 리포트로 보내면, 받은 쪽이 다른 도구로 재보는 순간 진단을 믿지 않게 됩니다. 그래서 고친 건 사이트가 아니라 진단 도구였습니다. 지금은 이렇게 잽니다.

• 1차는 시뮬레이션으로 잽니다.
• 성능이 기준(60점) 미만이면 실제 스로틀링으로 한 번 더 잽니다.
• 둘 다 기준 미만일 때만 낮은 점수로 보고합니다.
• 두 값이 엇갈리면 실측 쪽을 씁니다.
• 재측정이 실패하면 1차 결과를 그대로 씁니다.

실측 쪽을 쓸 때는 점수만 바꾸면 안 되고 개선 항목도 실측 결과로 함께 바꿔야 합니다. 점수만 바꾸면 “100점인데 LCP 5.6초” 같은 앞뒤가 안 맞는 리포트가 나갑니다.

걸리는 시간은 재측정을 안 하면 약 10초, 하면 약 31초입니다. 모든 페이지를 실측으로 다시 재는 게 아니라 기준 미만일 때만 다시 재니 평소 걸리는 시간은 크게 늘지 않습니다. 기준을 60점으로 둘지 더 올릴지는 감으로 정하지 않으려고, 잴 때마다 시뮬레이션 점수, 실측 점수, 어느 쪽을 썼는지, 엇갈렸는지를 DB 에 남기고 npm run stats --verify 로 모아 봅니다. 엇갈린 비율이 쌓이면 그때 기준을 조정합니다.

이 진단 도구는 무결(mugyeol.kr)에서 주소만 넣으면 사이트 상태를 봐주는 무료 진단에 쓰는 엔진입니다. 오진을 찾은 사이트도 무결 사이트였습니다.

아직 모르는 것

왜 First Paint 가 하필 2,400ms 근처에 고정되는지는 아직 모릅니다. 교차 검증은 엇갈리는 두 값 중 실제에 가까운 쪽을 고르게 해줄 뿐이고, 그 값이 왜 나오는지는 알려주지 않습니다.

자막 타이밍을 맞출 때도 더 정밀하다는 옵션이 정답에서 더 멀었던 적이 있는데, 그 이야기는 정밀하다는 옵션이 실제로는 590ms 더 틀렸다에 적었고, 숫자가 0으로 보일 때 정말 0인지 안 잰 건지 가르는 법은 대시보드에 없는 지표는 0이 아니라 안 잰 것입니다에 있습니다.