문서
Core Web Vitals: 실제 사용자 기준 LCP, INP, CLS를 주 단위로 확인
Chrome UX Report History API에서 가져온 주간 75번째 백분위수 LCP, INP, CLS를 사이트 전체 또는 단일 페이지 기준으로 확인하고, Google의 기준에 따라 평가합니다.
Core Web Vitals 리포트(제목: Core Web Vitals History)는 실제 Chrome 사용자가 사이트를 어떻게 경험하는지 주 단위로 보여 줍니다. 이 리포트는 Chrome UX Report History API를 사용합니다. Search Console의 Core Web Vitals 리포트에 쓰이는 것과 같은 필드 데이터이며, 각 지표를 75번째 백분위수 기준으로 Google의 기준에 따라 평가합니다. 배포 이후 페이지가 빨라졌는지 느려졌는지를, 랩 테스트로 방문자의 체감을 확인하기 훨씬 전에 파악할 수 있습니다.
리포트 실행하기
- Scope: Whole site는 Chrome 사용자가 방문한 모든 페이지를 집계하는 origin(예:
https://www.example.com)을 조회합니다. Single page는 하나의 URL을 조회합니다. - Origin 또는 Page URL: 속성의 origin이 미리 입력되어 있습니다. 다른 호스트나 페이지를 확인하려면 수정하세요.
- Device: All devices, Phone, Desktop, Tablet 중에서 선택합니다. All devices를 선택하면 기기별 데이터도 각각 불러와 Summary by device 표를 추가합니다.
- Run report를 누릅니다.
데이터가 주 단위로만 바뀌므로 결과는 하루 동안 캐시됩니다. 리포트는 CrUX API 키로 API를 호출하며, AutoPSEO가 키를 제공하므로 별도로 설정할 것은 없습니다. 직접 만든 도구에서 쓸 키가 필요하다면 API Key 버튼에서 Google의 안내 페이지로 이동할 수 있습니다.
화면 구성
판정 문구는 해당 범위가 Passes Core Web Vitals인지, 즉 데이터가 있는 모든 핵심 지표가 Good으로 평가되었는지를 알려 줍니다. 그 아래에는 지표별로 카드 5개가 이어집니다. 각 카드에는 최신 75번째 백분위수 값, 평가 등급, 4주 전과 비교한 변화, 그리고 Good으로 평가된 페이지 로드의 비율이 표시됩니다.
| 지표 | 측정 대상 | Good | Poor |
|---|---|---|---|
| LCP, Largest Contentful Paint | 로딩: 화면에 보이는 가장 큰 요소가 렌더링되는 시점 | 2.5초 이하 | 4초 초과 |
| INP, Interaction to Next Paint | 응답성: 클릭, 탭, 키 입력 후의 지연 시간 | 200ms 이하 | 500ms 초과 |
| CLS, Cumulative Layout Shift | 시각적 안정성: 로딩 중 콘텐츠가 움직이는 정도 | 0.1 이하 | 0.25 초과 |
| FCP, First Contentful Paint | 첫 텍스트나 이미지가 나타나는 시점 | 1.8초 이하 | 3초 초과 |
| TTFB, Time to First Byte | 서버가 응답을 시작하기까지 걸리는 시간 | 0.8초 이하 | 1.8초 초과 |
LCP, INP, CLS가 Core Web Vitals이고, FCP와 TTFB는 LCP가 나쁜 원인을 파악하는 데 도움이 되는 보조 지표입니다. 두 기준값 사이에 있는 값은 개선이 필요한 상태(Needs improvement)입니다. Google은 모바일과 데스크톱을 따로 나누어, 페이지 로드의 75번째 백분위수에서 각 지표를 평가합니다(web.dev: Web Vitals). INP는 2024년 3월 12일에 First Input Delay를 대신해 Core Web Vitals 지표가 되었습니다.
최신 값이 4주 전보다 5% 이상 변했으면 추세를 improving 또는 worsening으로 판단합니다. 차트에는 지표별 주간 75번째 백분위수와 Good, Needs improvement, Poor 비율이 표시되고, 표에는 모든 주의 값 5개와 LCP가 Good인 경험의 비율이 나열됩니다.
히스토리 읽는 방법
각 지점은 직전 28일간의 방문을 요약한 주간 수집 기간입니다. 그래서 개선 효과는 하루 만에 나타나지 않고 약 4주에 걸쳐 서서히 반영됩니다. API는 기본적으로 주간 기간 25개, 즉 대략 최근 6개월분을 반환합니다(CrUX History API).
- 계단식 변화가 배포, 새 태그 관리자 스크립트, 테마 업데이트와 시점이 맞아떨어지는 것이 가장 흔한 패턴입니다. 해당 날짜는 주석으로 표시해 두세요.
- 데스크톱보다 휴대폰이 나쁜 경우는 흔합니다. 휴대폰은 처리 성능이 낮고 네트워크도 더 느린 경우가 많기 때문입니다. 검색 트래픽 중 모바일 비중이 얼마나 되는지를 감안해 판단하세요.
- Origin은 Good인데 페이지는 Poor인 경우: origin 값은 모든 페이지를 합산한 결과이므로, 가장 무거운 템플릿을 하나씩 확인해 보세요.
데이터가 없을 때
Chrome은 실제 Chrome 방문이 충분한 공개 origin 또는 URL에 대해서만 레코드를 게시합니다. 그렇지 않으면 리포트에 Not enough field data라고 표시됩니다(CrUX methodology). 새 페이지나 트래픽이 적은 페이지는 origin에는 레코드가 있어도 URL 단위 레코드가 없는 경우가 많습니다. 또한 CrUX API는 국가별 구분을 제공하지 않으므로, 수치는 전 세계 모든 방문자를 기준으로 합니다.
AutoPSEO가 도움이 되는 부분
AutoPSEO가 전달하는 글은 사용자의 사이트에서 직접 렌더링되므로 템플릿의 성능을 그대로 따릅니다. AutoPSEO가 섹션을 호스팅하는 경우에는 호스팅 렌더러가 글 페이지를 직접 제공합니다. 이 페이지들을 확인하려면 해당 URL 중 하나로 리포트를 실행하세요. 세 지표에 대한 자세한 설명은 LCP, INP, CLS의 의미와 나쁜 Core Web Vitals 점수를 개선하는 방법을 참고하세요.