- Web Performance
- Outils
WebPageTest vs PageSpeed Insights: 완벽 비교 가이드
WebPageTest vs PageSpeed Insights: lab data vs field data, 진단 vs SEO 시그널. 항목별 비교, 활용 사례, scripting, API, 생태계 완전 정리.
동일 URL, 두 개의 진단 렌즈
저자
WebPageTest와 PageSpeed Insights는 같은 것을 측정합니다 — 페이지의 체감 속도 — 하지만 서로 다른 두 가지 질문에 답합니다. 두 도구 모두 Chrome이 데이터를 갖고 있을 때 테스트 대상 URL에 대한 CrUX field data(28일 롤링 윈도우, 75 percentile)를 보여줍니다. lab 측면에서는 PSI가 단일 Google 데이터센터에서 Lighthouse 1회 실행을 돌리는 반면, WebPageTest는 30곳 이상의 물리적 location, multi-run, waterfall, filmstrip, scripting, API를 제공합니다. PSI는 "Google이 내 사이트를 30초 안에 어떻게 보는가?"에 답하고, WPT는 "이 페이지가 Mumbai에서 왜 4.8초나 걸리는가?"에 답합니다. 둘 중 하나만 쓴다는 것은 진단의 절반만 하고 있다는 뜻입니다.
후보 1 — duo lab/field
Paris · Moto G4 · 4G에서 실행한 1회 테스트, 결정론적
Lab score (Lighthouse) + field data (CrUX, 28일), 단일 리포트로
후보 2 — 두 개의 loupe
동일 URL, 두 개의 진단 렌즈
왜 도구 선택이 모든 것을 바꾸는가
잘못된 도구로 진행한 성능 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
Mobile vs Desktop
장치 유형별 Core Web Vitals
60% 방문자의 모바일 비율 – 모바일 최적화는 우선 사항입니다
이 축이 나머지 모든 것을 결정합니다. 방법론, 측정 항목, 사용 사례 — 모두가 이 하나의 구분에서 파생됩니다.
Lab data : 페이지를 제어된 브라우저에서 고정된 네트워크 및 CPU 프로파일(예: Slow 4G, CPU 4× throttling)로 로드합니다. 한 번의 실행으로 재현 가능한 숫자가 나옵니다. WebPageTest와 Lighthouse가 만들어내는 데이터가 바로 이것입니다. 장점은 결정론적이라서 before/after 비교나 commit 단위의 regression 탐지에 이상적이라는 점이고, 단점은 단일 synthetic 시나리오라 실제 단말기·연결 환경의 다양성을 반영하지 못한다는 점입니다.
Field data : 실제 Chrome 사용자 로드(CrUX, Chrome User Experience Report)에서 수집된 측정값을 28일 롤링 윈도우로 집계하고 75 percentile로 보여줍니다. PageSpeed Insights가 "실제 사용자 데이터" 블록에 표시하는 것이 바로 이것이며, Google이 Page Experience 시그널로 사용하는 데이터이기도 합니다. 장점은 현실 그 자체라는 점이고, 단점은 28일의 지연이 있고 특정 세션 단위로 drill-down할 수 없다는 점입니다.
| 기준 | Lab data (WPT, Lighthouse) | Field data (CrUX, PSI) |
|---|---|---|
| 출처 | 제어된 브라우저 | 실제 Chrome 사용자 |
| 재현성 | 높음 (1회 실행 = 1개의 숫자) | 통계적 (28일 P75) |
| 지연 | 즉시 | 28일 롤링 |
| 진단 | Waterfall, trace, profile | 집계된 측정값만 |
| CI regression 추적 | 이상적 | 부적합 (너무 느림) |
| Google SEO 시그널 | 간접적 | 직접적 (Page Experience) |
중요한 미묘함을 기억해두세요 : Chrome이 해당 URL에서 충분한 트래픽을 갖고 있을 때 두 도구 모두 CrUX 데이터를 표시합니다. WPT를 시점 T에 실행하면 PSI와 마찬가지로 CrUX 블록이 함께 떠오르는데, 두 도구 모두 같은 Google CrUX API를 호출하기 때문입니다. 따라서 이 비교는 흔히 단순화되는 "lab vs field"가 아니라, "매우 깊은 lab + field" (WPT) 대 "빠른 lab + field, 한 번의 클릭으로" (PSI)입니다.
실무적 결론: PSI는 문제가 있는지 알려주고, WPT는 왜 그런지 알려줍니다. 성능 최적화는 field data로만 최종 검증되지만, 그 최적화는 lab data로 만들어집니다.
WebPageTest: 가장 잘하는 것
네트워크 수조
WebPageTest(WPT)는 현재 Catchpoint가 운영하는 도구로, 무엇보다도 시장에서 가장 깊은 진단 도구를 갖춘 lab data 도구입니다 — 그리고 Chrome이 데이터를 갖고 있을 때 PSI와 똑같이 테스트 대상 URL에 대한 CrUX 블록도 리포트에 함께 표시합니다. synthetic 테스트의 표준이며, 여러 층에 걸친 진단이 강점입니다.
인프라 측면에서는 무료 Starter plan이 mainland China를 포함한 전 세계 30개 location의 물리적 단말기(실제 Moto G4, iPhone, Chrome desktop profile)에 대한 접근을 제공하고, Pro plan은 큐 우선순위와 premium location을 포함해 총 35개 location을 풀어줍니다. 동일한 Moto G4로 Paris에서 1.2초에 로드되는 사이트가 Mumbai에서는 4.8초가 걸린다는 사실을 확인할 수 있는 이유가 바로 이것입니다 — 단일 location 도구로는 절대 볼 수 없는 차이입니다. 여러 지역을 서비스하는 사이트라면 협상의 여지가 없는 기능입니다.
시각적 진단 측면에서는 waterfall이 각 요청을 DNS, connect, TLS, TTFB, download로 분해해서 보여주므로, LCP를 막는 요청, 적용되지 않은 preload, 다른 critical asset을 지연시키는 third-party script를 즉시 확인할 수 있습니다. Filmstrip은 100 ms마다(최대 60 fps까지 설정 가능) 페이지의 시각적 상태를 기록하고 video도 생성합니다. hero가 언제 나타나는지, layout shift가 언제 발생하는지, "장바구니에 추가" 버튼이 몇 번째 프레임에서 클릭 가능해지는지를 정확히 짚어낼 수 있습니다. PSI는 로딩 완료 시점의 스크린샷만 제공합니다.
Core Web Vitals를 넘어, WPT는 Speed Index(2012년 Pat Meenan이 도입한 시각적 채워짐 가중 측정값), TTFB, Start Render, Total Blocking Time, 그리고 직접 정의한 User Timings를 노출합니다 — performance.mark()로 생성한 모든 마크가 리포트에 자동 표시됩니다. 표준 측정 항목이 없는 것을 측정하기 위해 custom JavaScript를 주입할 수도 있습니다(장바구니가 interactive해지기까지의 시간, 특정 시점의 DOM 크기, 특정 요소의 존재 여부 등). 네트워크 노이즈를 거르기 위한 다중 실행(기본 3회, 설정 가능)과 중앙값은 기본 운영 방식이며, 동기화된 filmstrip으로 여러 URL을 나란히 비교할 수도 있어 경쟁사 벤치마킹에 유용합니다.
WPT를 다른 카테고리에 위치시키는 두 가지 기능은 scripting과 API입니다. Scripting을 사용하면 로그인 뒤에 있는 페이지나, 홈에서 여러 번 클릭해서 도달하는 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 데이터 공급, 배포할 때마다 트리거 등. SpeedCurve나 Calibre 같은 플랫폼이 WPT를 연동할 수 있는 것도 이 API 덕분입니다.
PageSpeed Insights: 가장 잘하는 것
TTFB
LCP
CLS
Score
Google이 운영하는 PageSpeed Insights(PSI)에는 독특한 특징이 있습니다 : 같은 리포트 안에 lab data(Lighthouse run)와 field data(CrUX 블록)를 함께 제공하는 유일한 대중적 도구입니다. 두 가지 강점이 이 이중성 안에 있습니다 — 설치 없이 한 번의 클릭으로 접근 가능합니다.
Field 측면에서는, 리포트 상단의 "실제 사용자 데이터" 블록이 해당 URL을 방문한 실제 Chrome 사용자(또는 페이지에 트래픽이 충분하지 않으면 origin 전체)의 LCP, INP, CLS를 28일 75 percentile로 보여줍니다. Google이 Page Experience 시그널에 사용하는 바로 그 데이터입니다 — 어떤 lab audit도 만들어낼 수 없습니다.
Lab 측면에서는, PSI가 Google 환경에서 Lighthouse 13을 고정된 모바일 프로파일(에뮬레이트된 Moto G4, Slow 4G, CPU 4× throttling)로 실행하고, 카테고리별(Performance, Accessibility, Best Practices, SEO) 0–100 score와 실행 가능한 audit 목록을 제공합니다 — 각 audit에는 예상 개선치(절약되는 ms, KB)와 root cause 설명이 함께 붙습니다. 로컬에서 lighthouse https://example.com을 실행하는 것과 정확히 같은 결과지만, 아무것도 설치할 필요가 없습니다.
접근성은 완벽합니다. URL과 "분석" 버튼, 30초, 계정 불필요, 기술 역량 불필요. product manager나 클라이언트와 공유하는 도구가 바로 이것입니다. v5 API(무료 Google 키)는 모니터링 측면에서 이 접근성을 확장합니다. 하루 25,000 요청, 100초당 400 요청 — 수백 개 URL로 구성된 카탈로그를 매일 audit하는 데 충분합니다. WPT 무료 plan으로는 생각조차 할 수 없는 규모입니다. 그리고 API가 두 가지(Lighthouse + CrUX)를 모두 반환하므로, 단 한 번의 호출로 lab와 field를 병행 추적할 수 있습니다.
항목별 비교
| 기준 | WebPageTest | PageSpeed Insights |
|---|---|---|
| 데이터 유형 | Lab (synthetic) | Lab (Lighthouse) + Field (CrUX) |
| 방법론 | 물리 agent 기반 테스트 | Lighthouse SaaS + CrUX 집계 |
| 결과까지 걸리는 시간 | 위치와 대기열에 따라 1~3분 (Free) | ~30초, 대기열 없음 |
| Location | 30개 (무료) ~ 35개+ (Pro) | 1개 (Google datacenter) |
| 에뮬레이트 단말기 | 실제 (Moto G4, iPhone…) | 에뮬레이트 (Moto G4) |
| 네트워크 프로파일 | 설정 가능 (3G, 4G, Cable, custom) | 고정 (Slow 4G) |
| 다중 실행 / 중앙값 | 있음 (기본 3회, 설정 가능) | 없음 (1회 실행) |
| Waterfall | 상세, interactive | 기본 수준 |
| Filmstrip | 있음 (100 ms, 최대 60 fps) | 없음 (로딩 완료 시점 캡처만) |
| Video | 있음 | 없음 |
| Custom metric / JS 주입 | 있음 | 없음 |
| User Timings | 자동 표시 | 없음 |
| Journey scripting | 있음 | 없음 |
| Field data (CrUX) | 있음 (Chrome 데이터가 있으면 리포트에 CrUX 블록 표시) | 있음 (CrUX, 28일, P75) |
| API | Pro 전용 (~$18.75/월) | 무료 (25,000/일) |
| 인증된 테스트 | 가능 (scripting) | 불가능 |
| 가격 | 무료 (300 테스트/월) ~ $180+/월 | 무료 |
| 실행 가능한 권장사항 | 없음 — 측정값, 트레이스, raw waterfall을 직접 해석 | Lighthouse 목록과 예상 절감(ms, KB) — 필터링 필요, 일부 제안은 부적절함 (Ads/Analytics 스크립트 제거, YouTube embed 제거 등) |
| Google SEO 시그널 직접 영향 | 간접적 | 있음 (Page Experience) |
사용 사례: 어떤 작업에 어떤 도구를 쓸 것인가
비교 매트릭스를 그리고 나면, 판단은 도구별이 아니라 시나리오별로 내려집니다.
| 시나리오 | 도구 | 이유 |
|---|---|---|
| 랭킹을 위해 Google이 보는 것 확인 | PSI 또는 WPT | 두 도구 모두 같은 CrUX 블록(Page Experience 진실의 근원)을 표시하며, PSI가 설정 없이 공유하기에 더 빠를 뿐 |
| LCP가 왜 4초나 되는지 이해 | WPT | Waterfall + filmstrip이 5분 안에 root cause를 짚어냄 |
| 로그인이나 consent banner 뒤 PDP audit | WPT (scripting) | PSI는 단계 하나도 넘어가지 못함 ; 쿠키 동의 배너 우회하기도 참고 |
| 카탈로그 200개 URL을 매일 모니터링 | PSI (API) | 무료 일 25,000 요청 ; WPT 무료 plan은 월 300 테스트로 제한 |
| 배포에서 발생한 성능 regression 탐지 | WPT | CI에서 결정론은 협상 불가 ; CrUX의 28일 지연이 PSI를 부적합하게 만듦 |
| Tokyo, Mumbai, São Paulo에서 테스트 | WPT | PSI는 단일 Google datacenter에서만 실행 |
| 비기술 클라이언트에게 리포트 발표 | PSI | 0–100 score + 색상 + CrUX 블록을 30초만에 교육 없이 읽을 수 있음 |
| CDN 변경이나 TTFB 최적화 영향 측정 | WPT | DNS/connect/TLS/TTFB 분해가 waterfall에 표시됨 |
| 다중 페이지 journey(장바구니 → checkout → 확인) 테스트 | WPT (scripting) | PSI에는 동등 기능 없음 |
알아둬야 할 한계와 함정
어떤 도구도 진실을 모두 말해주지는 않습니다. 반복적으로 나타나는 네 가지 함정이 있습니다.
Lighthouse score는 직접적인 SEO 시그널이 아닙니다. PSI에서 95점은 랭킹에 어떤 영향도 주지 않습니다 — Google에게 중요한 것은 같은 리포트의 CrUX 블록, 즉 P75의 field data입니다. field data에 손을 대지 않고 score만 올리는 작업은 장식에 불과합니다.
WPT 단일 실행은 의미가 없습니다. 네트워크는 노이즈가 많고, 공유 agent의 CPU는 변동합니다. 항상 최소 3회 실행을 돌리고 중앙값을 취해야 합니다. 100–200 ms 단위 최적화에서는 단일 실행이 false positive(또는 false negative)를 만들어 하루를 통째로 날릴 수 있습니다.
PSI score는 저절로 흔들립니다. 같은 URL에 30초 간격으로 PSI를 세 번 실행하면 사이트를 전혀 건드리지 않아도 85, 92, 78이 나올 수 있습니다 — 변동의 원인은 테스트를 처리하는 Google 데이터센터, 내장된 Lighthouse 버전(공개 Lighthouse CLI보다 한두 사이클 뒤처지는 경우가 있음), 그리고 공유 환경입니다. 결론은 단일 score만으로는 절대 최적화를 검증할 수 없다는 것이고, 실행 가능한 권장사항도 필터링이 필요합니다 — PSI는 실제 매출에 결정적인 Google Ads, Analytics 스크립트나 YouTube embed를 제거하라고 종종 제안합니다.
마지막으로, CrUX는 비어 있을 수 있습니다. URL이 자체적인 CrUX 데이터를 갖기 위해서는 최소 Chrome 트래픽 임계값이 필요합니다. 트래픽이 적은 페이지에서는 PSI가 origin 단위 데이터(사이트 전체)로 fallback하거나, 아무 것도 표시하지 않습니다. 빠르게 훑어보면 놓치기 쉬운 점입니다.
💡 PSI를 정확하게 읽기 위한 팁 : "실제 사용자 데이터" 블록이 origin 전체가 아니라 해당 URL에 대한 것인지 항상 확인하세요(전환 토글이 있습니다). CrUX가 비어 있다면 성능이 좋다거나 나쁘다고 결론짓지 마세요 — 데이터의 부재는 데이터의 부재일 뿐입니다. 그리고 INP가 2024년 3월에 Core Web Vitals에서 FID를 대체했다는 점을 기억하세요. 내부 dashboard가 아직 FID를 추적하고 있다면, 죽은 측정값을 추적하고 있는 셈입니다. 전체 맥락은 [Core Web Vitals: INP가 FID를 대체](https://pauld.fr/ko/advices/core-web-vitals-inp-march-2024)를 참고하세요.
WPT와 PSI 주변의 생태계
성능 도구를 이 두 가지로 줄여 버린다면 풍경의 절반을 놓치는 셈입니다. 알아둬야 할 이웃 도구들과 각자의 역할:
| 도구 | 유형 | 사용 시점 |
|---|---|---|
| Lighthouse CLI | Lighthouse 엔진을 로컬에서 실행 (npm i -g lighthouse) |
PSI로 부족, WPT는 과함, pipeline 통합 |
| DebugBear | Lighthouse + historical CrUX + 예약된 테스트 상용 플랫폼 | 시계열 추적과 alerting (PSI에 없는 영역) |
| SpeedCurve | WPT + RUM + 비즈니스 지표 dashboard | 부품을 직접 조립하지 않고 perf-conversion 상관 분석 |
| Calibre | Lighthouse 기반 지속 모니터링 + user profile + perf budget | 제품 팀 |
| Treo.site | 25개월 이상의 historical CrUX dashboard | 사이트의 장기 drift 시각화 |
| Chrome DevTools (Performance) | Chrome 내장 프로파일러 (CPU flamegraph, long task, 실시간 INP) | Waterfall을 넘어 코드 한 줄씩 설명 |
| Search Console (CWV 리포트) | SEO 측면의 Google 공식 자료 | 빨강/주황 영역 URL을 우선 수정 대상으로 나열 |
| web-vitals (라이브러리) | Google open-source RUM 라이브러리 | CrUX의 28일 지연 없이 실시간 field data |
| YellowLabTools | 코드 품질 audit (DOM, JS, CSS, 폰트) | perf audit과 병행해서 코드 측면 보완 |
실무적 권장 사항
올바른 setup은 선호도보다 사용 컨텍스트에 따라 정해집니다:
| 컨텍스트 | 권장 setup |
|---|---|
| 일회성 audit | PSI를 먼저 사용해 field data baseline과 score 확인 ; 다음으로 WPT(최소 3회 실행, 오디언스 대표 location)로 심층 진단 ; YellowLabTools를 보너스로 코드 품질 점검 |
| 지속적 모니터링 | PSI API로 N개 URL 매일 추적(score나 CWV drift에 alert) + 2–3개 location에서 WPT로 주간 단위 전략 페이지(LCP, INP, filmstrip) 측정 + web-vitals RUM으로 실시간 field data |
| CI 통합 | 모든 PR에 Lighthouse CI 적용(빠르고, 결정론적이며, regression 시 blocking) + 메인 브랜치에 대해 매일 밤 여러 location에서 WPT API 테스트 |
| Black Friday / 트래픽 피크 직전 | 핵심 페이지(home, PDP, 장바구니, checkout)를 여러 location에서 WPT로 측정 + 전체 구매 journey에 scripting 적용 + 다중 실행 비교로 안정성 검증. PSI 단독으로는 부족 — 28일 지연 때문에 피크 후 최대 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에서만 사용 가능)는 전략적 페이지의 하위 집합에 더 적합합니다.
출처
업데이트 11 6월 2026