PageSpeed Insights 보고서는 세 번 나눠 읽습니다. 먼저 필드 범위와 문제 지표를 확인하고, 현재 실험실 실행을 살핀 뒤, 문제를 설명하는 진단을 선택합니다. 실제 평가와 Lighthouse 점수는 다른 질문에 답합니다. 한 부분의 녹색 원이 다른 부분의 문제를 취소하지는 않습니다.
개선하려는 페이지를 대표하는 공개 URL로 시작합니다. 리디렉션 뒤 최종 주소를 확인하고 모바일 또는 데스크톱을 고릅니다. 변경 전에 조건을 저장해야 다음 결과를 같은 페이지와 전략으로 비교할 수 있습니다.
페이지와 테스트 조건부터 확인하기
테스트가 성공해도 다른 경험을 설명할 수 있습니다. 리디렉션, 반환 콘텐츠, 접근 제한, 봇 차단과 오류 페이지를 확인합니다. 빠른 확인용 화면은 글이 빨리 로드된다는 증거가 아닙니다.
홈페이지만 보지 말고 대표 템플릿을 시험합니다. 글, 카테고리, 상품과 검색 페이지는 자원과 스크립트가 다를 수 있습니다. 알려진 문제가 있는 페이지로 시작하고 다른 예시도 확인한 뒤 공통 수정을 완료합니다.
날짜, 전략과 최종 URL을 적고 Lighthouse 버전과 환경도 보관합니다. 인터페이스 이름과 검사 항목은 바뀔 수 있으므로 오래된 스크린샷보다 각 부분의 목적을 이해합니다.
공식 PageSpeed Insights 개요는 필드와 실험실을 함께 사용하는 방식을 설명합니다. 보고서는 진단 출발점이지 모든 제안을 무조건 적용하라는 지시가 아닙니다.
실험실 점수보다 실제 사용자 영역 먼저 읽기
CrUX는 자격을 충족하는 실제 Chrome 방문의 이전 28일 경험을 보여 주며 매일 갱신됩니다. 해당 패널이 URL인지 더 넓은 출처인지 확인합니다.
출처는 스킴, 호스트와 포트를 묶습니다. 여러 페이지 유형이 포함될 수 있으므로 정확한 글의 분포가 같다고 단정하지 않습니다. 스크린샷이나 수치를 공유할 때 범위 표시를 남깁니다.
LCP는 로드, INP는 반응성, CLS는 안정성입니다. p75에서 양호 기준은 LCP 2.5초 이하, INP 200밀리초 이하, CLS 0.1 이하입니다. CLS는 시간 단위가 없습니다. 서로 다른 단위를 더하거나 평균 내지 않습니다.
세 지표에 충분한 데이터가 있으면 모두 좋아야 통과합니다. PSI는 INP 자료가 부족할 때 LCP와 CLS로 평가할 수 있습니다. LCP나 CLS가 부족하면 집계를 평가할 수 없습니다. INP 누락은 0도, 측정된 양호 결과도 아닙니다.
분포 막대와 보조 지표 해석하기
막대는 양호, 개선 필요, 나쁨 구간에 속하는 경험 비중입니다. 검사에 통과한 페이지 자원 비율이 아닙니다. p75는 방문의 백분위수이지 산술평균이 아닙니다.
가상의 페이지는 좋은 p75와 뚜렷한 느린 꼬리를 동시에 가질 수 있습니다. 자체 모니터링에서 국가, 기기 성능이나 템플릿을 조사할 이유가 됩니다. 공개 막대만으로 원인을 알 수는 없습니다.
FCP와 TTFB는 추가 로드 측정값으로 나타날 수 있지만 새로운 Core Web Vitals는 아닙니다. 늦은 첫 바이트가 이후를 늦출 수 있어도 큰 서버 구매가 정답이라는 뜻은 아닙니다. 리디렉션, 연결, 애플리케이션과 캐시를 조사합니다.
표나 티켓으로 옮길 때 단위를 유지합니다. 밀리초를 초 항목에 넣으면 보고 실수가 큰 회귀처럼 보입니다. CLS에는 일괄적으로 ms를 붙이지 않습니다.
모바일과 데스크톱을 별도 보기로 사용하기
기기 전환은 실험실 전략과 필드 폼 팩터를 바꿉니다. 실제 모바일은 시뮬레이션과 다르지만 둘 다 강한 데스크톱에서 가려진 문제를 드러낼 수 있습니다. 두 점수를 평균해 사이트 전체 등급을 만들지 않습니다.
레이아웃 변화도 중요합니다. 다른 주요 이미지, 높은 헤더, 숨겨진 메뉴나 별도 구성요소가 생길 수 있습니다. LCP가 다르면 각 보기의 최대 요소를 확인한 뒤 이미지나 서버 수정을 선택합니다.
각 기기에서 중요한 경로를 시험합니다. 화면에 잘 맞는 반응형 페이지도 메뉴가 느리거나 광고가 움직일 수 있습니다. CSS의 반응형 표시와 INP의 반응성은 다릅니다.
Core Web Vitals 입문 안내는 이를 실제 경험에 연결합니다. 한쪽 개선이 다른 쪽 악화를 숨기지 않게 기준을 따로 보관합니다.
Lighthouse 점수를 실험실 요약으로 읽기
진단 부분은 설정된 조건에서 URL에 Lighthouse를 실행합니다. 성능 점수는 0부터 100까지이며 90 이상은 양호, 50부터 89는 개선 필요, 50 미만은 나쁨입니다. 이 구간은 필드 지표의 기준값과 다릅니다.
합성 점수는 가중 지표 점수로 계산됩니다. 권장 조치는 원인을 찾는 데 도움이 되지만 검사 하나를 고치면 정해진 점수가 지급되는 것은 아닙니다. 버전, 설정과 개별 시간을 함께 비교합니다.
작은 시간 변화가 큰 점수 변화로 보이거나 유용한 수정 뒤에도 반올림된 점수가 같을 수 있습니다. 해당 시점이 일관되게 개선되었는지와 기능이 정상인지 확인합니다.
접근성, 권장사항과 SEO 범주는 다른 제한된 검사를 다룹니다. 높은 SEO 점수는 순위 약속이 아니며 자동 접근성 점수는 완전한 접근성 감사가 아닙니다. 비개발자에게 설명할 때 범위를 명확히 합니다.
실험실 지표를 조사 목적에 연결하기
탐색 검사는 로드 및 관찰 기간의 CLS를 측정합니다. 훨씬 나중의 변경을 놓칠 수 있고 실제 INP 분포도 제공하지 않습니다. 상호작용에는 적절한 테스트가 필요합니다.
다음 표는 지표를 서로 바꾸지 않고 다음 조사를 고르는 데 사용합니다.
| 측정 | 조사에 도움이 되는 부분 | 입증하지 않는 사항 |
|---|---|---|
| LCP | 최대 콘텐츠의 전달과 렌더링 | 이후 모든 행동의 빠른 반응 |
| CLS | 테스트에서 관찰된 이동 | 방문 후반까지 완전한 안정성 |
| FCP | 첫 콘텐츠 표시 시점 | 주요 콘텐츠 준비 완료 |
| TBT | 로드 중 메인 스레드 차단 | 실제 필드 INP 값 |
| Speed Index | 시각적 완성의 진행 | 독립적인 Core Web Vitals 통과 |
TBT가 높으면 긴 작업과 스크립트 실행을 조사합니다. 필드 INP가 나쁘면 입력, 메뉴와 옵션 변경을 재현합니다. TBT는 단서일 수 있지만 INP라고 이름을 바꾸면 증거를 왜곡합니다.
필드와 실험실 CLS가 다르면 기록을 연장하고 늦은 콘텐츠를 시험합니다. 필드와 실험실 안내를 보고 어느 한쪽이 틀렸다고 단정하지 않습니다.
설명 가능한 지표 효과로 진단 우선순위 정하기
실패한 지표와 관련된 인사이트를 엽니다. 이름은 바뀌어도 질문은 같습니다. 무엇이 발견, 전송이나 렌더링을 늦추고 메인 스레드를 막거나 배치를 바꿨는지 찾습니다.
LCP 요소를 요청 워터폴에서 따라갑니다. 큰 이미지는 늦게 발견되거나 다른 우선순위 때문에 기다리거나 다운로드 후 렌더링을 기다릴 수 있습니다. 파일 크기만 보지 말고 지배적인 단계를 수정합니다.
렌더링 차단 자원은 초기 표시에 필요한 스타일과 스크립트를 구분합니다. 모두 미루면 스타일 없는 콘텐츠나 의존성 오류가 생길 수 있습니다. 렌더링 차단 리소스 안내가 판단을 돕습니다.
예상 절약 시간은 그 시나리오의 모델 결과이지 모든 방문자에게 보장되는 값이 아닙니다. 항목끼리 같은 병목을 다룰 수 있으므로 합산해 총 절약을 약속하지 않습니다. 근거 있는 한 가지 변경을 하고 다시 측정합니다.
발견 사항을 재현 가능한 작업으로 만들기
좋은 티켓은 페이지, 기기, 지표, 증거와 변경할 구성요소를 명시합니다. 전체 보고서에 녹색으로 바꾸라는 말만 붙이지 말고 관련 요청이나 스크립트를 넣습니다. 필수 기능을 제거해서 통과하지 않도록 기능 검증도 포함합니다.
예를 들어 주요 이미지를 초기 HTML에서 발견할 수 있게 하고 선택된 반응형 자원을 확인하는 작업을 만들 수 있습니다. 승인 조건은 LCP와 여러 너비에서 올바른 표시입니다. 이는 절차 예시이며 해당 사이트에 문제가 있다는 진단은 아닙니다.
증거가 있다면 공유 구성요소를 우선합니다. 여러 템플릿의 헤더 스크립트는 개별 장식보다 중요할 수 있지만 같은 색상의 보고서가 같은 원인을 증명하지는 않습니다. 렌더링이나 동작 변경에는 되돌릴 경로를 유지합니다.
데이터가 없는 여러 이유 구분하기
새 URL, 부족한 관측량이나 공개 발견 요건 때문에 필드가 없을 수 있습니다. 출처 대체값은 맥락을 주지만 URL 기록을 채우지는 않습니다. 비공개 앱은 다른 모니터링이 필요합니다.
API 응답 변경, 설정이나 서비스 오류로 통합 도구가 필드를 받지 못할 수도 있습니다. CrUX 기록 없음, 요청 실패, 필드를 제공하지 않는 통합을 구분합니다. 모두 같은 빨간 실패 배지를 사용해서는 안 됩니다.
적절한 실험실 테스트를 계속하고 필요한 경우 개인정보를 고려한 RUM을 검토합니다. 한 번의 실행으로 백분위수를 만들거나 누락을 통과로 표시하지 않습니다.
API에 전략과 오류 처리를 명시하기
PSI v5 API는 프로그래밍 방식의 Lighthouse 분석을 제공합니다. 다음 명령은 예시 공개 URL의 성능 범주를 요청하고 JSON을 저장합니다. curl이 필요하며 접근, 할당량과 프로젝트 설정은 별도로 적용됩니다.
curl --fail-with-body --get \
'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
--data-urlencode 'url=https://example.com/' \
--data-urlencode 'strategy=mobile' \
--data-urlencode 'category=performance' \
--output pagespeed-mobile.json자동화에서는 Google 문서에 따라 키와 할당량을 설정합니다. 제한 없는 자격 정보를 공개 브라우저 코드에 넣지 않습니다. lighthouseResult를 읽기 전에 HTTP와 JSON 오류를 확인하고 시각, 최종 URL, 버전과 설정을 저장합니다.
Google은 이 API의 CrUX 포함을 중단할 계획을 알리고 CrUX API 또는 CrUX History API를 권장합니다. loadingExperience와 originLoadingExperience가 계속 존재한다고 가정해 새 시스템을 만들지 않습니다. 필드와 실험실 수집을 분리하고 빠진 필드를 명시적으로 처리합니다.
API 사용은 비공개 URL을 시험할 권한을 주지 않습니다. 토큰이나 개인정보가 담긴 주소를 보내지 않습니다. 공개 분석 서비스는 서버에서 대상 검증과 남용 방지를 구현해야 합니다.
의미 있는 변경 뒤 재검사하고 추세 보기
수정 뒤 비교 가능한 실행을 반복하고 개별 값을 보관합니다. 원래 탐색뿐 아니라 영향을 받은 기능도 시험합니다. 코드 변경 없이 자주 재실행하면 주로 변동성을 보며, 필드 수집 창에 새 방문을 만드는 것은 아닙니다.
가능한 최신 사용자 측정과 새 방문이 28일 창에 들어오는 추세를 확인합니다. 배포와 방문자 변화를 기록합니다. 대표 시나리오의 안정된 결과가 우연히 좋은 한 번보다 유용합니다.
활성화된 PageSpeed 분석기로 공개 페이지를 보고 페이지 속도 안내에서 원인을 더 조사합니다. 설명 없는 경고 목록 대신 측정 가능한 조치, 담당자와 재검사 조건으로 검토를 마칩니다.
