정의
웹 성능을 측정하다 보면 여러 숫자가 나오는데, "이 숫자가 대체 뭘 대표하는 값인지"를 구분하는 것이 이 글의 주제다. 서로 다른 측정을 같은 것으로 착각하면 엉뚱한 곳을 최적화하게 된다.
구분해야 할 세 가지:
- Lighthouse Performance 점수(0–100): 구글의 성능 측정 도구 Lighthouse가 여러 지표를 하나로 합쳐 매긴 종합 점수.
- 카테고리 audit(A11y/SEO/BP): 같은 Lighthouse가 매기는 접근성(A11y)·검색최적화(SEO)·모범사례(Best Practices) 점수. 성능과는 별개 항목이다.
- Chrome Performance trace의 LCP·CLS: 브라우저 개발자도구로 페이지를 한 번 기록(trace)했을 때 나오는 원시 측정값. LCP(Largest Contentful Paint — 가장 큰 콘텐츠가 화면에 그려지기까지 걸린 시간, ms)와 CLS(Cumulative Layout Shift — 화면이 얼마나 밀려났는지의 정도, 무차원)를 실제 밀리초·수치로 보여준다.
이 셋은 도구도, 집계 방식도 달라서 1:1로 대응하지 않는다.
왜 필요한가
문제 상황: "audit에서 SEO 100점"과 "trace에서 LCP 900ms"를 뭉뚱그려 "성능 좋음"으로 읽으면, 최적화 우선순위가 틀어진다. SEO 점수가 높아도 실제 로딩은 느릴 수 있기 때문이다.
원리적으로 다르기 때문이다. Performance 점수는 LCP·CLS·TBT(Total Blocking Time — 메인 스레드가 입력에 응답 못 하고 막혀 있던 총 시간)·FCP(First Contentful Paint — 첫 콘텐츠가 그려진 시점)·SI(Speed Index — 화면이 얼마나 빨리 채워졌는지) 같은 여러 지표를 가중치로 합성한, 실험실(lab — 통제된 환경에서 한 대의 기기로 재현하는 측정) 점수다. 반면 trace의 ms 값은 그 한 번의 페이지 이동(navigation) 에서 관측한 단일 값이다.
게다가 환경(개발용 dev 빌드냐 실제 production 빌드냐, 네트워크 속도를 인위로 낮추는 throttle 여부, 캐시 없는 첫 실행 cold start 여부)을 고정하지 않으면, 같은 코드로도 정반대 결론이 나온다. 그래서 "무엇을 재는 숫자인지 + 어떤 환경에서 잰 숫자인지"를 항상 함께 봐야 한다.
동작 원리
| 계측 | 단위 | 의미 |
|---|---|---|
| Trace LCP/CLS/TTFB | ms / 무차원 | 이번 reload의 lab CWV |
| Lighthouse Performance | 0–100 | 여러 메트릭 log-normal mapping 후 가중 평균 |
| Lighthouse A11y/SEO/BP | 0–100 | 해당 카테고리 audit 규칙 합격률 |
LCP ms를 줄여도 TBT가 나쁘면 Performance 점수 상한이 있을 수 있다. 반대로 SEO 100이어도 LCP ms는 별도로 봐야 한다.
비교 규칙:
- 동일 URL · 동일 auth · 동일 build · 동일 throttle 고정.
- 단일 trace 금지 — lab-performance-measurement-variance처럼 N회 median.
- dev median과 production median 절대값 비교 금지 — 환경별 before/after만.
실무 적용
- 개발 중: Chrome Performance trace reload → LCP/CLS/TTFB ms, 3× median.
- 카테고리 회귀: Lighthouse A11y/SEO/BP audit.
- 릴리스 게이트:
build && start후 동일 프로토콜. - headline에 outlier run 기록하지 않기.
트레이드오프
| 선택 | 이득 | 비용 |
|---|---|---|
| trace ms 중심 | 구현 iteration에 민감 | Lighthouse 점수와 직관 불일치 가능 |
| Lighthouse Performance만 | 단일 숫자 | LCP ms 원인 분해 어려움 |
| RUM(field) | 실사용자 분포 | lab 재현·디버깅과 별도 |
사용하면 안 되는 경우
- SEO audit 점수만으로 LCP SLA 달성을 주장하는 경우.
- dev cold run 하나로 production 성능을 대표한다고 말하는 경우.
흔한 실수
- "Lighthouse 100 = LCP 최고" (카테고리에 Performance가 없을 수도 있음).
- LCP ms만 개선했는데 Performance 점수가 안 오른 이유를 TBT/CLS 미확인.
- 서로 다른 build·auth 상태의 trace를 한 타임라인에 나열해 악화/개선 단정.
관련 개념
- lab-performance-measurement-variance — N회 median·outlier
- largest-contentful-paint — LCP 구성·개선
- critical-rendering-path — TTFB·render 파이프라인