Lighthouse 성능 점수의 계산 방식과 실행마다 달라지는 이유

Lighthouse는 보고서의 경고 개수가 아니라 각 측정항목의 점수에 가중치를 적용해 성능 점수를 계산합니다. 원시 측정값은 먼저 점수 곡선을 통과하므로 절약한 밀리초와 얻는 점수는 선형 관계가 아닙니다. 공정하게 비교하려면 Lighthouse 버전, 기기 프로필, 제한 설정, 페이지 상태를 동일하게 유지하고 여러 실행 결과를 실제 사용자 데이터와 함께 확인해야 합니다.

가중치를 읽기 전에 버전을 확인합니다

2026년 10월 17일 Lighthouse 프로젝트의 출시 목록을 확인했을 때 최신 소프트웨어 버전은 v13.5.0이었습니다. 그렇다고 특정 PageSpeed Insights 요청이나 설치된 Chrome이 그 버전을 사용했다는 뜻은 아닙니다. 배포 일정과 로컬 브라우저 설치 상태는 다를 수 있습니다. 비교에는 보고서에 기록된 버전이 중요합니다.

문서도 구분해서 읽어야 합니다. Chrome의 일반 점수 설명 페이지는 익숙한 가중치 표를 여전히 “Lighthouse 10”으로 표시합니다. 이 글을 위해 확인한 현재 main 브랜치 설정에는 동일한 다섯 개의 0이 아닌 가중치가 있습니다. v13.5.0 태그의 설정 파일은 확인하지 못했습니다. 따라서 아래 표는 확인한 main 설정과 문서화된 Lighthouse 10 모델을 설명하며, v13.5.0 설정을 별도로 검증한 표가 아닙니다. 특정 버전의 감사는 아래 예제처럼 해당 JSON에서 확인합니다.

두 출처에서 확인한 가중치는 다음과 같습니다.

확인한 설정에서 INP의 가중치는 0입니다. 따라서 일반 탐색 점수는 INP 점수가 아닙니다. TBT는 조사할 메인 스레드 작업을 찾는 데 도움이 되지만 실제 사용자 INP 대신 TBT를 사용하면 답하려는 질문 자체가 바뀝니다.

보고서 구성이 바뀌었다고 점수 계산도 자동으로 바뀌는 것은 아닙니다. Lighthouse 13은 이전 성능 감사를 인사이트로 통합했으며, 출시 안내는 이 변경이 성능 점수를 바꾸지 않는다고 명시했습니다. 예전 감사 이름이 사라졌다고 관련 문제가 중요하지 않게 된 것은 아닙니다.

측정값을 점수로 바꾼 뒤 평균을 계산합니다

LCP 원시값은 시간이고 CLS에는 단위가 없습니다. 두 값을 그대로 더하면 의미 있는 해석이 불가능합니다. Lighthouse는 각 측정값을 해당 점수로 바꾼 후 가중치에 따라 합칩니다.

Google은 HTTP Archive 데이터에 기반한 로그 정규 분포의 점수 곡선을 설명합니다. 따라서 측정값이 같은 만큼 개선되어도 점수 증가량은 다를 수 있습니다. 곡선이 가파른 곳에서는 변화가 뚜렷하지만 최상단에 가까우면 비슷한 개선으로도 표시 정수가 거의 바뀌지 않을 수 있습니다. 모바일과 데스크톱은 설정과 점수 기준이 다르므로 서로 바꿔 비교할 수 없습니다.

산술 예로만 생각해 보겠습니다. 나머지 점수는 그대로이고 0부터 100까지의 TBT 정규화 점수만 10점 올라가면, 가중치 30%에서 전체 점수에 대한 기여는 반올림 전 3점 늘어납니다. 이는 가상의 계산이며 벤치마크나 특정 코드 변경의 효과를 보장하는 수치가 아닙니다.

측정값과 해당 측정항목의 점수를 구분해야 합니다. 작업을 100밀리초 줄였다고 100점이나 일정한 점수가 추가되지 않습니다. 시작값, 곡선, 측정 구간, 다른 측정항목이 모두 영향을 줍니다. 하나의 최적화가 여러 항목을 동시에 바꾸기도 하므로 단순 예측은 더 어려워집니다.

모델은 공식 점수 설명에서 이해하고 실제 개발 작업은 자신의 보고서 값으로 선택합니다. 다른 항목이 전체 점수를 제한한다면 느린 요소가 의미 있게 개선되어도 점수 변화는 작을 수 있습니다.

경고는 원인을 알려주며 직접 감점하지 않습니다

렌더링을 차단하는 스타일시트에 항상 일정한 감점이 붙는 것은 아닙니다. 측정항목에 반영되는 콘텐츠를 실제로 늦추는지가 중요합니다. 사용하지 않은 스크립트 경고도 제거 가능한 작업을 가리키는 것이며, 경고 자체가 추가 가중 측정항목은 아닙니다.

이 구분은 두 가지 실수를 막습니다. 보이는 경고를 모두 없애는 것과 사용자 경험 개선은 같지 않습니다. 여러 인사이트의 예상 절약 시간을 더해도 신뢰할 수 있는 총 절약량이 되지 않습니다. 같은 요청 사슬을 중복 설명하거나, 함께 적용할 때 브라우저 일정이 달라질 수 있기 때문입니다.

변경하기 전에 요청 워터폴과 메인 스레드 타임라인을 확인합니다. 주요 이미지가 늦게 발견되는 문제와 빨리 발견되지만 느리게 다운로드되는 문제는 다릅니다. JavaScript가 메인 스레드를 독점한다면 이미 작은 이미지를 반복 압축하기보다 JavaScript 실행 시간 줄이기부터 시작합니다.

하나의 점수만 요청받더라도 개별 측정항목을 보관합니다. 전체 점수가 높아져도 특정 항목은 악화될 수 있습니다. 예를 들어 CLS 개선이 가중 평균에서 느려진 콘텐츠 표시를 상쇄할 수 있습니다. 그 타협이 페이지에 적합한지는 총점만으로 알 수 없습니다.

점수를 흔드는 조건을 통제합니다

Lighthouse는 실행 중인 시스템을 측정합니다. 백그라운드 CPU 작업, 확장 프로그램, 바뀌는 광고, 실험, 캐시 상태, 네트워크 경로, 백엔드 부하가 실행을 바꿉니다. 확장 프로그램이 코드를 삽입한 브라우저는 깨끗한 브라우저와 같은 작업을 관찰하지 않습니다.

제한 방식도 비교 경계를 만듭니다. 시뮬레이션 제한은 관찰한 트레이스에서 성능을 추정하고, 실제 적용 제한은 실행 자체를 제약합니다. 한 방식의 결과를 다른 방식의 정확한 반복으로 취급해서는 안 됩니다. 방식을 고정하고 기록합니다.

같은 URL에서도 다른 경험이 나타날 수 있습니다. 동의 배너, 로그인 계정, 위치별 콘텐츠, 실험은 DOM, 요청, 스크립트를 바꿉니다. URL만으로 실험을 완전히 설명한다고 가정하지 말고 테스트 상태를 남깁니다. 운영 환경에 중요한 여러 상태가 있다면 별도로 검사합니다.

캐시가 없는 첫 방문과 재방문도 분리해야 합니다. 캐시된 글꼴이나 스크립트는 중요 경로를 바꾸고 캐시된 HTML은 서버 시간을 바꿀 수 있습니다. 기준과 변경 버전의 캐시 정책을 동일하게 유지합니다. 차가운 기준 실행과 따뜻한 변경 실행의 차이를 전부 코드 개선으로 돌리지 않습니다.

로컬 비교에는 안정적이고 한가한 장비를 사용합니다. 무거운 앱을 닫고 감사를 동시에 실행하지 않으며 깨끗한 프로필을 씁니다. 전원 설정도 유지합니다. 이런 절차는 피할 수 있는 잡음을 줄일 뿐 노트북을 모든 방문자의 대표 표본으로 만들지는 않습니다.

반복 가능한 명령줄 비교를 실행합니다

CLI에서는 명령, 패키지 버전, 출력을 함께 저장할 수 있습니다. 호환되는 Node.js와 Chrome 또는 Chromium이 필요합니다. 설치 전에 선택한 패키지의 실행 환경 요구 사항을 확인합니다. 다음 명령은 조사 당시 확인한 버전을 고정하는 예시이며 이 글을 위해 example.com에 실행한 결과가 아닙니다.

고정된 패키지와 기본 모바일 설정으로 JSON 보고서 다섯 개를 저장합니다.

mkdir -p lighthouse-reports
for run in 1 2 3 4 5; do
  npx --yes [email protected] https://example.com/     --only-categories=performance     --chrome-flags="--headless"     --output=json     --output-path="lighthouse-reports/mobile-${run}.json"
done

다섯 번은 실용적인 시작 표본이지 통계적 보장이나 공식 통과 요건이 아닙니다. 기준과 변경 버전에 같은 절차를 적용합니다. 결과 폭이 넓으면 작은 차이를 진전으로 판단하기 전에 변동 원인을 찾습니다.

화면 캡처로 추측하지 말고 저장된 보고서에서 버전, 0이 아닌 가중치, 점수를 읽습니다.

// inspect-lighthouse.mjs
import { readFileSync } from 'node:fs';

const file = process.argv[2];
if (!file) throw new Error('Pass a Lighthouse JSON report path.');
const report = JSON.parse(readFileSync(file, 'utf8'));
const performance = report.categories.performance;
console.log('Lighthouse version:', report.lighthouseVersion);
console.log('Performance score:', performance.score);
console.table(performance.auditRefs.filter(({ weight }) => weight > 0));

첫 번째 보고서에 스크립트를 실행합니다.

node inspect-lighthouse.mjs lighthouse-reports/mobile-1.json

JSON 점수는 정규화되어 있으므로 0.9는 표시 형식을 적용하기 전 90에 해당합니다. 점수만이 아니라 보고서 전체를 보관합니다. 나중에 차이를 설명할 설정과 항목별 값이 들어 있습니다. 데스크톱 비교는 --preset=desktop으로 별도 실행하고 모바일 결과와 섞지 않습니다.

중앙값을 쓰되 분포를 숨기지 않습니다

반복 점수를 정렬한 뒤 가운데 값을 단순 중앙값으로 제시합니다. 최솟값, 최댓값, 개별 항목도 보관합니다. 중앙값은 유난히 빠르거나 느린 한 번의 영향에 덜 민감하지만 잘못 통제된 실험을 고치지는 못합니다.

한 실행의 가장 빠른 LCP, 다른 실행의 가장 낮은 TBT, 또 다른 실행의 가장 낮은 CLS를 합쳐 가상의 “최고 보고서”를 만들지 않습니다. 그런 조합은 실제로 발생하지 않았습니다. 대표 보고서와 전체 실행을 보관해 측정값 사이의 관계를 유지합니다.

유용한 비교 기록에는 URL과 코드 리비전, 상태, 브라우저 및 Lighthouse 버전, 기기 프로필, 제한 방식, 실행 횟수, 중앙값과 관련 항목의 분포가 들어갑니다. 조사한 변경과 알려진 환경 차이도 덧붙입니다. 그러면 조건에서 떨어진 숫자가 아니라 재현 가능한 근거가 됩니다.

PageSpeed Insights, DevTools, CLI는 버전과 환경이 다를 수 있습니다. PageSpeed Insights 가이드에서 해당 보고서를 읽는 방법을 확인합니다. 결과가 다르면 먼저 설정과 상태를 비교하며, 낮은 점수를 냈다는 이유로 도구가 틀렸다고 판단하지 않습니다.

다음에 유용한 측정으로 연결합니다

100점은 특정 조건에서 반올림된 실험실 결과이지 모든 방문자의 빠른 경험을 인증하지 않습니다. 모든 경로, 상호작용, 기기, 언어, 세션 길이를 검사하지도 않습니다. 탐색 감사에는 나중의 레이아웃 이동이나 느린 상호작용이 보이지 않을 수 있습니다.

필드 데이터와 실험실 데이터를 함께 봅니다. 통제된 테스트로 변경을 빠르게 설명한 뒤 실제 사용자 측정으로 대상 이용자가 혜택을 받는지 확인합니다. 차이는 어느 한쪽을 무효로 하기보다 빠진 테스트 조건을 알려줄 수 있습니다.

다음 반복에서는 느린 항목 하나를 선택하고 요청 또는 메인 스레드 원인을 찾은 뒤 검토 가능한 변경 하나를 만듭니다. 설정된 PageSpeed 분석기나 위 CLI로 반복 가능한 기준을 저장합니다. 원인이 드러나면 해당 페이지 속도 최적화 가이드로 이어갑니다. 목표는 반복 테스트에서도 유지되고 실제 사용자에게 도달하는 입증된 개선입니다.