Lighthouse 성능 점수(0~100)는 랩(lab) 환경에서 잰 다섯 지표를 각각 점수로 바꾼 뒤 가중 평균한 값이다. 지표별 점수는 HTTP Archive의 실제 사이트 데이터로 만든 로그 정규 곡선에서 정해진다. 90 이상 초록, 50~89 주황, 49 이하 빨강이다.
가중치 (Lighthouse 10부터 2026년 13.x까지 동일)
| 지표 | 가중치 |
|---|---|
| TBT(Total Blocking Time) | 30% |
| LCP(Largest Contentful Paint) | 25% |
| CLS(Cumulative Layout Shift) | 25% |
| FCP(First Contentful Paint) | 10% |
| SI(Speed Index) | 10% |
TBT는 FCP부터 TTI(Time to Interactive)까지 일어난 긴 작업(50ms 초과)에서 50ms를 넘긴 부분을 모두 더한 값이다. 모바일에서 600ms를 넘기면 빨강이다. 가중치가 가장 크고 곡선이 가팔라서, TBT가 무너지면 다른 지표의 개선이 점수에 거의 드러나지 않는다.
한 지표를 고쳤더니 다른 지표가 나빠지는 역설
이미지를 지연 로딩하고 품질을 낮춰 전송량을 크게 줄였더니 LCP는 좋아졌는데 점수는 오히려 떨어지는 경우가 있다. 원인이 TBT라면 이런 메커니즘을 의심해 볼 수 있다.
- 느린 망 스로틀링에서는 큰 이미지가 대역폭을 독점해 JS가 찔끔찔끔 도착한다. 서드파티 스크립트는 측정 구간 안에 실행을 다 끝내지도 못하고, 메인 스레드는 한가해 보인다
- 이미지가 비켜 주면 JS가 일찍, 몰려서 도착해 연달아 실행된다. 긴 작업이 측정 구간(FCP~TTI) 안에 빽빽하게 들어오고 TBT가 뛴다
- 즉 새로 생긴 비용이 아니라 원래 있던 JS 비용이 측정 구간 안으로 들어온 것일 수 있다. 빠른 망의 실제 사용자는 이전에도 그 JS를 다 실행하고 있었다
확인하려면 JS 전송량이 그대로인지, 같은 스크립트의 실행 시간이 트레이스 안에서 늘었는지를 본다. 다만 같은 기간에 다른 배포가 섞였다면 진짜로 실행 비용이 늘었을 가능성도 따로 확인해야 한다. 점수 하나가 아니라 지표별로 쪼개 보는 습관이 필요한 이유다. "점수를 올리는 것"이 목표가 되면 굿하트의 법칙에 빠진다.
점수는 흔들린다
같은 페이지도 실행마다 점수가 다르다. 페이지 자체의 비결정성(A/B 테스트, 광고), 네트워크·서버 응답 시간, 측정 기기의 CPU 경쟁이 원인이다. Lighthouse 문서는 5번 돌린 중앙값이 1번보다 두 배쯤 안정적이라고 말한다. 비교할 때는 같은 환경에서 여러 번 돌려 중앙값을 쓰고, 점수를 한 숫자가 아니라 분포로 본다.
랩 데이터와 필드 데이터
Lighthouse는 기기 하나, 망 하나, 빈 캐시로 잰 랩 데이터다. 실제 사용자 데이터(필드 데이터)와는 화면 크기, 캐시 상태, bfcache(뒤로·앞으로 가기 캐시) 복원, 스크롤·상호작용 여부 때문에 차이가 난다. INP(Interaction to Next Paint)는 사용자 입력이 있어야 재지므로 랩에서는 TBT가 대리 지표 역할을 한다. 우선순위는 필드 데이터(Core Web Vitals의 p75)로 정하고, Lighthouse는 원인을 찾고 변경 전후를 비교하는 도구로 쓴다.
출처: Lighthouse performance scoring · Lighthouse 기본 설정(default-config.js) · Total Blocking Time · Lighthouse — Score variability · web.dev — Why lab and field data can be different