- Web Performance
- Outils
WebPageTest vs PageSpeed Insights: 완벽 비교 가이드
WebPageTest vs PageSpeed Insights: lab data vs field data, 진단 vs SEO 시그널. 항목별 비교, 활용 사례, scripting, API, 생태계 완전 정리.
동일 URL, 두 개의 진단 렌즈
Paul Delcloy
저자
WebPageTest와 PageSpeed Insights는 같은 것을 측정합니다 — 페이지의 체감 속도 — 하지만 서로 다른 두 가지 질문에 답합니다. PSI는 **Lighthouse run (lab data)**와 CrUX field data (28일 rolling window, 75th percentile)를 하나의 리포트에 결합합니다. WebPageTest는 순수 lab data 도구로, 30개 이상의 실제 물리적 위치에서 결정론적 측정과 waterfall, filmstrip, scripting, API를 제공합니다. PSI는 "Google이 내 사이트를 어떻게 보는가?"에 답하고, WPT는 "왜 이 페이지가 Mumbai에서 4.8초나 걸리는가?"에 답합니다. 둘 중 하나만 사용하는 것은 절반만 진단하는 것입니다.
올바른 도구가 왜 중요한가
잘못된 도구에 의존한 performance audit는 두 가지 전형적인 증상을 낳습니다. PageSpeed Insights에서 Lighthouse score가 95점인데 실제 사용자는 모바일에서 LCP 4초를 경험하는 경우, 혹은 반대로 field에서 Core Web Vitals를 통과하지만 regression이 왜 발생했는지 이해할 수 없는 경우입니다. 원인은 거의 항상 같습니다. lab data와 field data를 혼동했거나, synthetic 수치를 실제 사용자 경험의 진실처럼 해석한 것입니다.
이것이 WebPageTest vs PageSpeed Insights 논쟁의 핵심입니다 — 그리고 이 논쟁은 승자를 지정해서 끝나지 않습니다. 두 도구는 상호 보완적이며, 각각 어떤 질문에 답하는지 아는 것이 전제 조건입니다.
근본적인 차이: lab data vs field data
Paris · Moto G4 · 4G에서 실행한 1회 테스트, 결정론적
Lab score (Lighthouse) + field data (CrUX, 28일), 단일 리포트로
이것이 모든 것을 구조화하는 축입니다. 이후의 모든 내용(방법론, 지표, 활용 사례)이 여기서 비롯됩니다.
Lab data: 고정된 network 및 CPU 설정(예: Slow 4G, CPU 4× throttled)으로 제어된 브라우저에서 페이지를 로드합니다. 한 번의 실행이 재현 가능한 수치를 생성합니다. WebPageTest와 Lighthouse가 생성하는 것이 바로 이것입니다. 장점: 결정론적이며 before/after 비교나 commit의 regression 탐지에 이상적입니다. 한계: 단일 synthetic 시나리오로 실제 기기와 연결 환경의 다양성을 반영하지 못합니다.
Field data: 실제 Chrome 사용자의 실제 페이지 로드(CrUX, Chrome User Experience Report)에서 수집된 지표로, 28일 rolling window에 걸쳐 집계되어 75th percentile로 제공됩니다. PageSpeed Insights가 "실제 사용자 경험" 섹션에서 표시하는 것이 바로 이것이며 — Google이 Page Experience 시그널로 사용하는 데이터이기도 합니다. 장점: 이것이 현실입니다. 한계: 28일의 latency와 특정 세션으로의 drill-down 불가.
| 기준 | Lab data (WPT, Lighthouse) | Field data (CrUX, PSI) |
|---|---|---|
| 출처 | 제어된 브라우저 | 실제 Chrome 사용자 |
| 재현성 | 높음 (테스트 1회 = 수치 1개) | 통계적 (28일 P75) |
| Latency | 즉각적 | 28일 rolling |
| 진단 깊이 | Waterfall, traces, profiles | 집계된 지표만 |
| CI regression 추적 | 이상적 | 부적합 (너무 느림) |
| Google SEO 시그널 | 간접적 | 직접적 (Page Experience) |
중요한 뉘앙스: WPT는 lab data만 생성하는 반면, PSI는 두 가지 모두를 생성합니다 — 같은 리포트에서 Lighthouse run (lab)과 CrUX block (field). 따라서 이 비교는 흔히 단순화하는 것처럼 "lab vs field"가 아닙니다. "순수하고 매우 깊은 lab" (WPT) 대 "한 번의 클릭으로 접근 가능한 lab + field" (PSI)입니다.
실용적인 결론: PSI는 문제가 있는지를 알려주고, WPT는 왜 그런지를 알려줍니다. optimization은 field data에서만 최종적으로 검증되지만 — lab data에서 구축됩니다.
WebPageTest가 더 잘하는 것
네트워크 수조
WebPageTest (WPT)는 현재 Catchpoint가 운영하며, 순수 lab data 도구입니다 — field data는 없지만 시장에서 가장 깊은 진단 기능을 제공합니다. 여러 계층에 걸쳐 synthetic testing의 기준점이 됩니다.
인프라 측면에서 무료 Starter plan은 전 세계 30개 위치 — 중국 본토 포함 — 의 실제 물리적 기기(Moto G4, iPhone, Chrome desktop profiles)에 접근할 수 있습니다. Pro plan은 총 35개를 해제하며 queue 우선순위와 premium 위치를 제공합니다. 이를 통해 Paris에서 1.2초에 로드되는 사이트가 동일한 Moto G4로 Mumbai에서 4.8초를 기록할 수 있음을 확인할 수 있습니다 — 단일 위치 도구로는 발견할 수 없는 차이입니다. 여러 지역에 서비스하는 사이트라면 필수입니다.
시각적 진단 측면에서 waterfall은 DNS, 연결, TLS, TTFB, 다운로드별로 각 요청을 세분화합니다. LCP를 차단하는 요청, 적용되지 않은 preload, 다른 critical asset을 지연시키는 서드파티 script를 즉시 확인할 수 있습니다. filmstrip은 페이지의 시각적 상태를 100ms마다(최대 60fps까지 설정 가능) 캡처하고 동영상을 생성합니다. hero가 나타나는 시점, layout shift가 발생하는 시점, "장바구니에 추가" 버튼이 클릭 가능해지는 frame을 정확히 파악할 수 있습니다. PSI는 로드 완료 시점의 캡처만 제공합니다.
Core Web Vitals 외에도 WPT는 Speed Index (Pat Meenan이 2012년 도입한 weighted visual fill 측정값), TTFB, Start Render, Total Blocking Time, 그리고 performance.mark()로 생성된 모든 마크가 리포트에 자동으로 표시되는 User Timings를 노출합니다. 표준 지표가 없는 것(장바구니가 interactive해지기까지의 시간, 특정 시점의 DOM 크기, 특정 요소의 존재 여부)을 측정하기 위해 custom JavaScript를 주입할 수도 있습니다. 노이즈를 걸러내기 위해 median과 함께 multi-run testing (기본 3회, 설정 가능)이 표준이며, 여러 URL을 동기화된 filmstrip으로 나란히 비교할 수 있어 경쟁사 대비 benchmarking에 유용합니다.
WPT를 별개의 범주에 놓는 두 가지 기능은 scripting과 API입니다. scripting을 통해 login 뒤의 페이지나 home에서 여러 번의 클릭으로 도달한 PDP를 audit할 수 있습니다 — navigate, 폼 입력, 클릭, 대기, 그리고 타겟 페이지에서만 지표를 기록합니다:
logData 0
setCookie https://example.com session=abc123
navigate https://example.com/login
setValue id=email user@example.com
setValue id=password ***
clickAndWait id=submit
logData 1
navigate https://example.com/dashboard
logData 0은 setup 중 기록을 비활성화하고, logData 1은 실제로 측정하려는 페이지에서 재활성화합니다. PSI에서는 완전히 불가능합니다. REST API (Pro plan)는 이 모든 것을 자동화합니다. CI pipeline의 테스트, 내부 dashboard 피드, 각 deploy마다 트리거. SpeedCurve나 Calibre 같은 플랫폼과 WPT를 통합할 수 있는 것도 이 API 덕분입니다.
PageSpeed Insights가 더 잘하는 것
TTFB
LCP
CLS
Score
Google이 운영하는 PageSpeed Insights (PSI)는 고유한 특징이 있습니다. lab data (Lighthouse run)와 field data (CrUX block)를 하나의 리포트에 결합한 유일한 주류 도구입니다. 두 가지 강점은 이 이중성에 있습니다 — 설치 없이 한 번의 클릭으로 접근 가능합니다.
field 측면에서 리포트 상단의 "실제 사용자 경험" block은 28일에 걸쳐 75th percentile에서 측정된 실제 Chrome 방문의 LCP, INP, CLS를 표시합니다. 이것이 정확히 Google이 Page Experience 시그널로 사용하는 데이터입니다 — 어떤 lab audit도 이를 생성할 수 없습니다.
lab 측면에서 PSI는 고정된 mobile profile (emulated Moto G4, Slow 4G, CPU 4× throttled)로 Google 환경에서 Lighthouse 13을 실행하고, 카테고리별(Performance, Accessibility, Best Practices, SEO) 0-100 score를 actionable audit 목록과 함께 반환합니다 — 각 audit에는 이익 추정값(절약된 ms, 절약된 KB)과 root cause 설명이 포함됩니다. 이것은 로컬에서 lighthouse https://example.com이 생성하는 것과 정확히 동일하지만 아무것도 설치할 필요가 없습니다.
접근은 완전합니다: URL, "분석" 버튼, 30초, 계정 없음, 기술적 역량 불필요. product manager나 클라이언트와 공유하는 도구입니다. v5 API (무료 Google key)는 모니터링 측면에서 이 접근성을 확장합니다: 하루 25,000 요청과 100초당 400 요청 — 무료 WPT plan으로는 상상할 수 없는 수백 개 URL의 카탈로그를 매일 audit하기에 충분합니다. 그리고 API가 두 가지(Lighthouse + CrUX)를 반환하므로, 단일 호출로 lab과 field를 병렬로 추적하기에 충분합니다.
항목별 비교
| 기준 | WebPageTest | PageSpeed Insights |
|---|---|---|
| 데이터 유형 | Lab (synthetic) | Lab (Lighthouse) + Field (CrUX) |
| 방법론 | 물리적 agent에서의 테스트 | Lighthouse SaaS + CrUX 집계 |
| 위치 | 30개 (무료) ~ 35개 이상 (Pro) | 1개 (Google datacenter) |
| 에뮬레이션 기기 | 실제 (Moto G4, iPhone…) | 에뮬레이션 (Moto G4) |
| Network profiles | 설정 가능 (3G, 4G, Cable, custom) | 고정 (Slow 4G) |
| Multi-run / 중앙값 | 예 (기본 3회, 설정 가능) | 아니오 (1회 실행) |
| Waterfall | 상세, 인터랙티브 | 기본 |
| Filmstrip | 예 (100ms, 최대 60fps) | 아니오 (최종 캡처만) |
| 동영상 | 예 | 아니오 |
| Custom metrics / JS injection | 예 | 아니오 |
| User Timings | 자동 표시 | 아니오 |
| Journey scripting | 예 | 아니오 |
| Field data | 아니오 (RUM 플러그인 제외) | 예 (CrUX, 28일, P75) |
| API | Pro 전용 (~$18.75/월) | 무료 (25,000/일) |
| 인증된 테스트 | 예 (scripting) | 아니오 |
| 가격 | 무료 (300테스트/월) ~ $180+/월 | 무료 |
| Google SEO 직접 시그널 | 간접적 | 예 (Page Experience) |
활용 사례: 어떤 상황에 어떤 도구를
매트릭스가 정해지면 결론은 도구가 아니라 시나리오별로 나옵니다.
| 시나리오 | 도구 | 이유 |
|---|---|---|
| ranking을 위해 Google이 보는 것 확인 | PSI | CrUX block이 Page Experience의 진실 출처; WPT는 이 데이터 없음 |
| LCP가 4초인 이유 파악 | WPT | Waterfall + filmstrip이 5분 안에 root cause 파악 |
| login 또는 consent banner 뒤의 PDP audit | WPT (scripting) | PSI는 어떤 단계도 통과 불가; Lighthouse와 WebPageTest에서 쿠키 동의 배너 우회하기도 참조 |
| 카탈로그 200개 URL 일일 모니터링 | PSI (API) | 무료 req/일 25,000개; 무료 WPT는 300테스트/월 상한 |
| 배포 시 perf regression 탐지 | WPT | CI에서 결정론적 측정은 필수; CrUX의 28일 latency는 PSI를 부적격으로 만듦 |
| Tokyo, Mumbai, São Paulo에서 테스트 | WPT | PSI는 단일 Google datacenter에서만 실행 |
| 비기술적 클라이언트에게 리포트 발표 | PSI | 0-100 score + 색상 + CrUX block을 교육 없이 30초에 읽기 가능 |
| CDN 변경 또는 TTFB 최적화의 영향 측정 | WPT | waterfall에서 DNS/connection/TLS/TTFB breakdown 확인 |
| 멀티 페이지 여정 테스트 (장바구니 → checkout → 확인) | WPT (scripting) | PSI에는 동등한 기능 없음 |
알아야 할 한계와 함정
어떤 도구도 전체 진실을 말하지 않습니다. 세 가지 함정이 반복적으로 등장합니다.
Lighthouse score는 직접적인 SEO 시그널이 아닙니다. PSI에서 95점은 ranking에 아무 영향이 없습니다 — Google에게 중요한 것은 같은 리포트의 CrUX block, 즉 P75의 field data입니다. field data를 건드리지 않고 score를 올리기 위해 최적화하는 것은 장식적인 작업입니다.
단일 WPT run은 아무 가치가 없습니다. 네트워크는 노이즈가 많고, 공유 agent의 CPU는 변동합니다. 항상 최소 3번 실행하고 중앙값을 취해야 합니다. 100-200ms 최적화에서는 단일 run이 하루를 낭비하게 만드는 false positive (또는 false negative)를 생성할 수 있습니다.
마지막으로 CrUX는 비어 있을 수 있습니다. URL이 자체 CrUX 데이터를 갖기 위해서는 최소한의 Chrome 트래픽 임계값이 필요합니다. 트래픽이 적은 페이지에서 PSI는 origin 데이터(사이트 전체)로 폴백합니다 — 또는 아무것도 표시하지 않습니다. 빠르게 읽으면 눈에 띄지 않습니다.
💡 PSI 해석 모범 사례: "실제 사용자 경험" block이 전체 origin이 아닌 URL에 대한 데이터를 표시하는지 항상 확인하세요 (toggle이 있습니다). CrUX가 비어 있다면 performance가 좋거나 나쁘다고 결론 내리지 마세요 — 데이터 없음은 데이터 없음입니다. 그리고 [INP가 2024년 3월 Core Web Vitals에서 FID를 대체했다는 점](https://pauld.fr/ko/advices/core-web-vitals-inp-march-2024)을 기억하세요: 내부 dashboard가 아직 FID를 추적하고 있다면 더 이상 사용되지 않는 지표를 추적하고 있는 것입니다.
WPT와 PSI 주변 생태계
performance 도구를 이 두 가지로만 제한하는 것은 절반의 환경을 놓치는 것입니다. 알아야 할 주변 도구들과 각각의 역할:
| 도구 | 유형 | 언제 사용 |
|---|---|---|
| Lighthouse CLI | 로컬 Lighthouse 엔진 (npm i -g lighthouse) |
PSI로 부족하고 WPT가 너무 무거운 경우, pipeline 통합 |
| DebugBear | Lighthouse + CrUX 이력 + 예약 테스트 상업 플랫폼 | 시계열 추적 및 알림 (PSI에 없는 기능) |
| SpeedCurve | WPT + RUM + business metrics dashboard | 부품을 조립하지 않고 perf와 conversion 상관관계 파악 |
| Calibre | 지속적인 Lighthouse 모니터링 + 사용자 profiles + perf budgets | 제품 팀 |
| Treo.site | 25개월 이상의 CrUX 이력 dashboard | 장기적으로 사이트 변화 추세 시각화 |
| Chrome DevTools (Performance) | 네이티브 Chrome profiler (CPU flamegraph, long tasks, live INP) | waterfall 너머로 가서 줄 단위로 설명 |
| Search Console (CWV 리포트) | SEO 측면의 공식 Google 출처 | 우선 수정할 빨간/주황 영역의 URL 목록 확인 |
| web-vitals (라이브러리) | Google 오픈 소스 RUM | CrUX의 28일 latency 없이 실시간 field data |
| YellowLabTools | 코드 품질 audit (DOM, JS, CSS, 폰트) | perf audit과 병행하는 코드 측면 보완 |
실용적인 권장 사항
올바른 setup은 선호도보다 사용 컨텍스트에 더 의존합니다:
| 컨텍스트 | 권장 setup |
|---|---|
| 일회성 audit | 먼저 PSI로 field 현황과 score 파악, 이후 WPT (최소 3회 실행, 타겟 오디언스를 대표하는 위치)로 진단, YellowLabTools를 보너스로 코드 품질 확인 |
| 지속적인 모니터링 | N개 URL에 대한 일일 PSI API (score 또는 CWV 변화 알림) + 전략적 페이지에 대한 주간 WPT (LCP, INP, filmstrip) 2-3개 위치에서 + 실시간 field data를 위한 RUM web-vitals |
| CI 통합 | 각 PR에 Lighthouse CI (빠름, 결정론적, regression 시 차단) + 여러 위치에서 main branch에 대한 nightly WPT API |
| Black Friday / 트래픽 급증 전 | 여러 위치에서 핵심 페이지 (home, PDP, 장바구니, checkout) WPT + 전체 구매 여정을 위한 scripting + 안정성 검증을 위한 multi-run. PSI만으로는 부족합니다 — 28일 latency로 인해 급증 후 4주까지 모든 문제가 숨겨집니다 |
FAQ
SEO audit에는 WebPageTest와 PageSpeed Insights 중 무엇을 선택해야 할까요?
먼저 PageSpeed Insights입니다. Google의 Page Experience 시그널은 CrUX field data에 의존하며, PSI가 Lighthouse score 위에 표시하는 것이 바로 이것입니다 — 28일 rolling window에서 75th percentile로. WebPageTest는 이 데이터에 접근할 수 없습니다. 그러나 LCP가 왜 나쁜지 이해해야 할 때는 WPT가 waterfall과 filmstrip으로 역할을 맡습니다. 실용적인 규칙: Google이 보는 것을 측정하려면 PSI, 무엇을 수정해야 하는지 이해하려면 WPT입니다.
PageSpeed Insights score는 좋은데 실제 Core Web Vitals 수치는 왜 나쁠까요?
같은 리포트 안의 서로 다른 두 측정값이기 때문입니다. 0-100 score는 lab data에서의 Lighthouse: 단일 run, 단일 기기 (emulated Moto G4), 단일 네트워크 (Slow 4G), 단일 Google datacenter. CrUX block은 28일 동안 P75에서 실제 Chrome 사용자를 집계합니다 — 다양한 기기, 다양한 연결, 다양한 위치. field data를 신뢰하세요: Google이 ranking에 사용하는 것이 바로 그것입니다.
WebPageTest는 무료인가요?
부분적으로는 무료입니다. Starter plan은 무료이며 전 세계 30개 위치, filmstrip, waterfall, Core Web Vitals에 접근할 수 있습니다 — 월 300 테스트 한도로. Pro plan은 약 $18.75/월부터 시작하며 API, 예약 테스트, 고급 scripting, premium 위치, queue 우선순위를 해제합니다. 일회성 audit의 경우 무료 plan으로 충분합니다. 지속적인 모니터링의 경우 API는 필수입니다.
프랑스어 사이트라면 WebPageTest에서 어떤 위치를 선택해야 할까요?
오디언스가 프랑스어권이라면 Paris (EU West)가 가장 대표적입니다. 하지만 무엇보다 단일 위치에서만 테스트하지 마세요: Paris에서 1.2 초에 로드되는 사이트가 Mumbai나 São Paulo에서 4.8 초를 기록할 수 있습니다. 해외 사용자에게 서비스하거나 CDN이 여러 영역을 커버한다면 대조적인 2-3개 위치에서 체계적으로 테스트하세요. edge가 의도대로 작동하는지 검증하는 유일한 방법입니다.
PageSpeed Insights는 정말로 Lighthouse를 사용하나요?
네, 정확히 같은 엔진입니다. PSI는 고정된 mobile profile (emulated Moto G4, Slow 4G, CPU 4× throttled)로 Google 환경에서 Lighthouse 13을 실행합니다. 같은 설정으로 로컬에서 실행한 lighthouse https://example.com과 매우 유사한 결과를 얻을 수 있습니다 — 네트워크 환경을 제외하고. PSI의 주요 차별점은 CLI에는 없는 Lighthouse score 위의 CrUX block 추가입니다.
WebPageTest를 익히는 데 얼마나 걸리나요?
기본적인 waterfall과 filmstrip 읽기는 1시간, multi-run 비교·scripting·API를 진지하게 활용하려면 반나절. 학습 곡선은 PSI (30초에 사용 가능)보다 가파르지만 빠르게 보답합니다: waterfall을 잘 읽으면 추측으로 보내는 수 시간을 절약합니다. 초보자의 전형적인 실수는 단일 run에서 결론을 도출하는 것입니다 — 항상 최소 3번 실행하고 중앙값을 취하세요.
WebPageTest나 PageSpeed Insights로 login 뒤의 페이지를 audit할 수 있나요?
WebPageTest는 가능합니다. scripting 언어(navigate, setCookie, setValue, clickAndWait, logData)를 통해 보호된 페이지로 이동하고 해당 페이지에서만 지표를 기록할 수 있습니다. PageSpeed Insights는 불가능합니다: interaction 없이 GET으로 공개 URL만 로드합니다. 인증된 페이지의 경우 WPT가 유일한 선택입니다 — 아니면 PSI에서 측정하기 위해 동일한 assets를 가진 페이지의 공개 사본을 사용하세요.
PageSpeed Insights에도 API가 있나요?
네, PageSpeed Insights v5 API는 Google 키와 함께 무료로 사용할 수 있습니다. 할당량: 하루 25,000 요청 및 100초당 400건 — 매일 수백 개 URL의 카탈로그를 audit하기에 충분합니다. 이것이 대규모 모니터링의 기본 옵션인 반면, WebPageTest API (Pro plan에서만 사용 가능)는 전략적 페이지의 하위 집합에 더 적합합니다.
Sources
업데이트 04 6월 2026