PageSpeed 점수의 진실 — 측정할 때 알아야 할 것들
PageSpeed Insights에서 점수를 측정하고, 새로고침하면 점수가 달라집니다. 어제 88점이었는데 오늘 85점. 뭘 바꾼 것도 없는데. 이건 정상입니다.
PageSpeed 점수를 올리기 전에, 점수가 어떻게 계산되고 왜 변동하는지 이해해야 합니다. 그래야 의미 있는 최적화와 의미 없는 집착을 구분할 수 있습니다.
1같은 사이트, 다른 점수
같은 사이트를 연속으로 3번 측정하면 이런 결과가 나옵니다:
| 측정 | Mobile | Desktop | LCP |
|---|---|---|---|
| 1차 | 88 | 97 | 3.4초 |
| 2차 | 87 | 98 | 3.4초 |
| 3차 | 87 | 98 | 3.4초 |
코드를 한 줄도 바꾸지 않았는데 87점과 88점이 왔다갔다합니다. 이건 Lighthouse의 특성입니다.
점수가 변동하는 이유
- 네트워크 변동: 테스트 서버와 측정 서버 사이의 네트워크 상태가 매번 다릅니다.
- 서버 응답 시간: TTFB(Time to First Byte)가 ±50ms 달라지면 점수도 변합니다.
- CDN 캐시 상태: 첫 측정은 cold cache, 이후는 warm cache일 수 있습니다.
- JavaScript 실행 시간: 같은 코드도 실행 환경에 따라 미세하게 달라집니다.
1점 차이에 의미를 두지 마세요
87점과 88점의 차이는 측정 오차 범위 내입니다. 의미 있는 변화를 판단하려면 최소 5점 이상의 차이가 있어야 합니다. 또는 같은 시간대에 3~5회 측정한 평균을 비교하는 게 정확합니다.
2Mobile vs Desktop 차이
많은 사람들이 "Desktop은 97점인데 Mobile은 왜 88점이지?"라고 합니다. 같은 사이트인데 왜 10점 이상 차이가 날까요?
| 항목 | Mobile | Desktop |
|---|---|---|
| 시뮬레이션 기기 | Moto G Power | 일반 데스크탑 |
| CPU 쓰로틀링 | 4배 느리게 | 제한 없음 |
| 네트워크 쓰로틀링 | 4G 시뮬레이션 | 제한 없음 |
| 뷰포트 | 412 x 823 | 1350 x 940 |
Mobile 테스트는 CPU를 4배 느리게, 네트워크를 4G로 제한합니다. 실제 최신 스마트폰보다 훨씬 느린 환경입니다. Moto G Power는 2019년 출시된 보급형 기기입니다.
왜 이렇게 느린 기기를 기준으로?
Google의 의도는 "가장 느린 사용자 환경에서도 괜찮은 경험을 보장하라"입니다. 전 세계적으로 보급형 안드로이드 기기 사용자가 많기 때문입니다. 하지만 한국은 iPhone과 갤럭시 플래그십 비율이 높아 실제 사용자 경험은 Mobile 점수보다 훨씬 좋을 수 있습니다.
3Lighthouse 점수 가중치
PageSpeed Performance 점수는 5가지 지표의 가중 평균입니다. 각 지표가 점수에 얼마나 기여하는지 알아야 어디를 최적화할지 판단할 수 있습니다.
| 지표 | 가중치 | 측정 대상 | Good 기준 |
|---|---|---|---|
| TBT (Total Blocking Time) | 30% | 메인 스레드 차단 시간 | < 200ms |
| LCP (Largest Contentful Paint) | 25% | 최대 콘텐츠 렌더링 시점 | < 2.5초 |
| CLS (Cumulative Layout Shift) | 25% | 레이아웃 변동량 | < 0.1 |
| FCP (First Contentful Paint) | 10% | 첫 콘텐츠 렌더링 시점 | < 1.8초 |
| SI (Speed Index) | 10% | 콘텐츠가 시각적으로 채워지는 속도 | < 3.4초 |
가중치에서 읽히는 것
- TBT가 30%로 가장 높습니다. JavaScript 실행 시간이 점수에 가장 큰 영향을 줍니다. 하지만 Next.js 런타임 JS (~14KB)는 줄일 수 없어서 개선 여지가 제한적입니다.
- LCP + CLS = 50%. 이 두 지표를 잡으면 점수의 절반을 확보합니다. 이미지 최적화와 레이아웃 안정성이 핵심입니다.
- FCP + SI = 20%. 상대적으로 가중치가 낮아서 이 두 지표를 개선해도 점수 변화가 작습니다.
490점과 100점의 차이
PageSpeed 최적화는 점수가 올라갈수록 투자 대비 효과가 급감합니다.
| 구간 | 난이도 | 주요 작업 | 체감 차이 |
|---|---|---|---|
| 0~50점 | 쉬움 | 이미지 압축, 기본 설정 | 매우 큼 |
| 50~80점 | 보통 | CLS, 폰트, CSS 최적화 | 큼 |
| 80~90점 | 어려움 | LCP, JS 최적화, preload 전략 | 보통 |
| 90~100점 | 매우 어려움 | 마이크로 최적화, 구조 변경 | 거의 없음 |
38점에서 88점까지 올리는 데 4단계(이미지, CLS, 폰트, LCP)로 충분했습니다. 하지만 88점에서 95점으로 올리려면 JavaScript 런타임 크기, 서드파티 스크립트, 서버 응답 시간 같은 근본적으로 제어하기 어려운 영역을 건드려야 합니다.
100점은 목표가 아닙니다
Google 자체 사이트(google.com, youtube.com)도 Mobile 100점이 아닙니다. 100점을 만들려면 JavaScript를 거의 쓰지 않는 정적 HTML 사이트여야 합니다. 90점 이상이면 "매우 좋음"이고, 80점 이상이면 "충분히 좋음"입니다.
5점수보다 중요한 것
PageSpeed 점수는 실험실 데이터(Lab Data)입니다. 실제 사용자 경험은 필드 데이터(Field Data)로 확인해야 합니다.
| 구분 | Lab Data | Field Data (CrUX) |
|---|---|---|
| 데이터 출처 | Lighthouse 시뮬레이션 | 실제 Chrome 사용자 |
| 측정 시기 | 지금 (즉시) | 최근 28일 누적 |
| 디바이스 | 고정 (Moto G) | 실제 사용자 기기 다양 |
| SEO 영향 | 간접적 | Core Web Vitals 랭킹 시그널 |
Google 검색 랭킹에 영향을 주는 건 Lab Data 점수가 아니라 Field Data의 Core Web Vitals입니다. PageSpeed 상단에 표시되는 "이 URL의 실제 사용자 환경 데이터"가 바로 Field Data입니다.
Field Data가 없다면?
트래픽이 적은 사이트는 "이 URL에 대한 데이터가 충분하지 않습니다"라고 표시됩니다. 이 경우 Field Data가 수집될 때까지 Lab Data를 참고하되, Lab Data 점수에 집착하지 마세요. 트래픽이 쌓이면 Field Data가 생기고, 그때 Core Web Vitals를 기준으로 최적화하면 됩니다.
6측정 자동화
수동으로 매번 pagespeed.web.dev에 접속하는 건 번거롭습니다. PageSpeed Insights API를 사용하면 자동으로 측정하고 기록할 수 있습니다. 구체적인 구현은 API 자동화 글을 참고하세요.
# PageSpeed Insights API 호출 (무료)
# Google Cloud Console에서 API 키 발급 필요
curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed\
?url=https://example.com\
&strategy=mobile\
&key=YOUR_API_KEY"
# 응답에서 주요 지표 추출
# .lighthouseResult.categories.performance.score → 점수
# .lighthouseResult.audits.largest-contentful-paint → LCP
# .lighthouseResult.audits.cumulative-layout-shift → CLS
# .lighthouseResult.audits.total-blocking-time → TBT이걸 cron job이나 CI/CD 파이프라인에 넣으면 배포 후 자동으로 성능을 체크할 수 있습니다. 점수가 일정 기준 이하로 떨어지면 알림을 보내는 것도 가능합니다.
측정 팁
- 같은 시간대에 측정: 서버 부하가 다르면 결과도 다릅니다. 새벽과 오후의 점수가 다를 수 있습니다.
- 3~5회 측정 후 평균: 단일 측정보다 평균이 신뢰할 수 있습니다.
- 변경 전후 비교: 절대 점수보다 변경 전후 차이가 의미 있습니다.
- Mobile 기준으로 최적화: Mobile이 좋으면 Desktop은 자연히 좋습니다.
핵심 정리
이 글의 수치는 Lighthouse 12 기준이며, 버전에 따라 가중치와 측정 방식이 달라질 수 있습니다. 실측 데이터는 특정 사이트의 결과이며 일반적인 수치와 다를 수 있습니다.
댓글
(4개)로그인하면 댓글을 작성할 수 있습니다.
API로 자동 측정하는 방법이 궁금했는데 간단하네요. 매번 수동으로 측정하는 게 시간 낭비였습니다.
점수 가중치 표가 유용합니다. TBT가 30%라는 거, LCP보다 높은 거 처음 알았어요. JS 최적화가 그래서 중요한 거였군요.
Mobile이 Moto G Power 시뮬레이션이라는 걸 모르는 클라이언트가 많습니다. 실제 사용자 기기보다 훨씬 느린 환경이라는 걸 알면 Mobile 80점대도 충분히 괜찮다는 걸 이해하게 됩니다.
관련 글
© 2026 TreeRU. All rights reserved.
본 콘텐츠의 저작권은 TreeRU에 있으며, 출처를 밝히지 않은 무단 전재 및 재배포를 금합니다. 인용 시 출처(treeru.com)를 반드시 명시해 주세요.