Core Web Vitals 실사용자 데이터 모니터링 5단계
- PageSpeed Insights에서 URL별 CrUX 데이터를 확인하고, URL 데이터가 부족하면 사이트 전체 데이터를 살펴봅니다.
- LCP·INP·CLS는 각각 75백분위수와 좋음 기준으로 확인합니다.
- RUM으로 페이지·기기별 지표를 직접 수집해 배포 전후 추이를 분석합니다.
Core Web Vitals 실사용자 데이터는 실제 방문자의 브라우저에서 수집한 성능 지표입니다. 먼저 PageSpeed Insights에서 페이지 URL과 사이트 전체를 나타내는 오리진 데이터를 확인하고, 더 세밀한 페이지·기기별 분석이 필요하면 RUM(Real User Monitoring, 실제 사용자 모니터링)을 구축할 수 있습니다. 현재 Core Web Vitals는 LCP·INP·CLS로 구성되며, 각 지표의 75백분위수가 기준을 충족하는지 확인합니다.
먼저 알아둘 지표와 판정 기준
LCP(최대 콘텐츠 렌더링 시간)는 주요 콘텐츠가 표시되기까지의 로딩 성능을, INP(다음 페인트와의 상호작용)는 사용자의 상호작용에 대한 반응성을, CLS(누적 레이아웃 이동)는 화면의 시각적 안정성을 측정합니다. 세 지표는 사용자 경험의 서로 다른 면을 보여주므로 각각 확인하세요.
| 지표 | 측정 내용 | 좋음 | 개선 필요 | 나쁨 |
|---|---|---|---|---|
| LCP | 주요 콘텐츠 로딩 | 2.5초 이하 | 2.5초 초과~4초 이하 | 4초 초과 |
| INP | 상호작용 반응성 | 200ms 이하 | 200ms 초과~500ms 이하 | 500ms 초과 |
| CLS | 화면의 시각적 안정성 | 0.1 이하 | 0.1 초과~0.25 이하 | 0.25 초과 |
Core Web Vitals 평가는 LCP·INP·CLS 각각의 75백분위수로 판단합니다. 예를 들어 LCP 75백분위수가 2.5초 이하면 해당 집계의 LCP가 좋음 기준을 충족합니다. 모바일과 데스크톱은 사용 환경이 다르므로 나눠 확인하면 원인을 파악하는 데 도움이 됩니다.
핵심 기준: 세 지표의 75백분위수가 모두 좋음 기준을 충족하면 Core Web Vitals 평가를 통과합니다. 좋음 기준은 LCP 2.5초 이하, INP 200ms 이하, CLS 0.1 이하입니다.
실사용자 데이터 모니터링 5단계
1단계: PageSpeed Insights에서 URL을 조회합니다
측정할 페이지의 전체 URL을 PageSpeed Insights에 입력하고 모바일과 데스크톱 결과를 각각 확인합니다. 보고서의 필드 데이터는 Chrome 사용자 경험 보고서(CrUX) 기반이며 최근 28일의 사용자 경험을 반영합니다. 페이지별 표본이 충분하면 해당 페이지 데이터가 표시되고, 부족하면 오리진 수준 데이터가 표시될 수 있습니다.
2단계: 페이지 데이터와 오리진 데이터를 구분합니다
페이지를 수정했는데 오리진 기준 수치만 보인다면 해당 페이지의 개선 효과를 직접 확인하기 어렵습니다. 새 페이지이거나 실제 사용자 표본이 적으면 페이지 데이터가 없을 수 있습니다. 데이터 없음은 성능이 좋다는 뜻이 아닙니다. 이때 오리진 데이터를 참고하되 페이지 구조나 기능이 다른 URL의 상태까지 같다고 단정하지 마세요. 오리진 데이터도 충분하지 않으면 PageSpeed Insights에 필드 데이터가 표시되지 않을 수 있습니다.
3단계: 반복 확인할 페이지와 구간을 정합니다
홈, 상품·콘텐츠 상세, 검색·목록, 결제처럼 사용자 흐름이 다른 대표 페이지를 선정합니다. 페이지 유형과 기기 등 원인 분석에 필요한 구분을 정하고, 배포 전후에 비교할 수 있도록 변경 내용과 시점을 기록하세요. 구분 항목이 지나치게 많으면 각 구간의 표본이 작아져 결과가 불안정해질 수 있습니다.
- 페이지 유형: 상세 페이지와 목록 페이지를 분리합니다.
- 기기 유형: 모바일과 데스크톱 결과를 따로 봅니다.
- 배포 시점: 배포 전후의 수집 기간과 변경 내용을 기록합니다.
4단계: RUM으로 브라우저 데이터를 수집합니다
CrUX만으로 페이지별 원인을 찾기 어렵다면 Google Chrome 팀의 web-vitals 라이브러리를 사용해 브라우저에서 지표를 수집하고 자체 분석 시스템으로 전송할 수 있습니다. 다음은 지표를 자체 수집 엔드포인트로 보내는 예시입니다. /rum은 직접 마련해야 하는 서버 경로입니다. 수집할 데이터와 보존 기간은 서비스의 개인정보 처리 기준에 맞춰 검토하세요.
import {onCLS, onINP, onLCP} from 'web-vitals';
function sendToRUM(metric) {
const body = JSON.stringify({
name: metric.name,
value: metric.value,
id: metric.id,
path: location.pathname
});
navigator.sendBeacon('/rum', body);
}
onCLS(sendToRUM);
onINP(sendToRUM);
onLCP(sendToRUM);전송 데이터에는 지표명·값·측정 식별자처럼 분석에 필요한 항목만 담으세요. URL에 이메일이나 주문번호가 들어갈 수 있다면 원문 경로를 보내지 말고 민감한 값을 제거하거나 정해진 페이지 유형으로 치환합니다. 지표는 사용자가 페이지에서 상호작용하지 않는 등 일부 상황에서 보고되지 않을 수 있습니다. 수집이 되지 않는다면 사용자 동작 여부와 전송·저장 경로를 함께 확인하세요.
5단계: 추세를 비교하고 원인을 좁힙니다
배포 날짜와 지표 추이를 함께 기록하고, 악화가 나타난 지표를 페이지 유형과 기기별로 나눠 확인합니다. LCP가 나빠졌다면 주요 이미지와 서버 응답을, INP가 나빠졌다면 상호작용 직후 실행되는 자바스크립트 작업을, CLS가 나빠졌다면 이미지·광고·동적 콘텐츠가 차지할 공간을 우선 조사합니다. 수정 후에는 같은 조건의 필드 데이터를 다시 관찰하세요. CrUX는 최근 28일의 경험을 반영하므로 배포 효과가 즉시 전체 수치에 반영되지는 않습니다. 짧은 기간의 변화는 자체 RUM과 함께 판단하세요.
CrUX와 자체 RUM, 무엇을 언제 쓰나
CrUX는 빠른 기준선 확인에 적합합니다
별도 계측 없이 공개된 실제 사용자 데이터를 확인할 수 있어 초기 진단에 편리합니다. 다만 데이터 수집 기준을 충족하는 페이지와 오리진에 한해 제공되므로 모든 URL의 데이터를 볼 수 있는 것은 아닙니다. Chrome DevTools에서 로컬 및 실제 사용자 Core Web Vitals 성능 모니터링 안내처럼 로컬 측정과 필드 데이터를 함께 보면 테스트 환경과 실제 사용자 환경의 차이를 살펴볼 수 있습니다.
RUM은 세부 원인과 배포 영향을 추적합니다
자체 수집을 활용하면 페이지 유형이나 애플리케이션 버전 등 팀이 정한 기준으로 데이터를 나눠 볼 수 있습니다. 대신 계측 코드 배포, 데이터 저장과 대시보드 운영이 필요합니다. RUM과 CrUX는 측정 대상과 수집 조건이 달라 수치가 완전히 일치하지 않을 수 있으므로 각각의 용도에 맞춰 해석하세요.
- 외부 기준 확인: PageSpeed Insights의 페이지·오리진 필드 데이터
- 로컬 재현과 디버깅: Chrome DevTools와 실험실 측정
- 세부 페이지·배포 추적: web-vitals 기반 자체 RUM
데이터 해석에서 자주 놓치는 점
첫째, 실험실 데이터와 필드 데이터는 서로 대체할 수 없습니다. 실험실 데이터는 통제된 조건에서 문제를 재현하고 수정 전후를 비교하는 데 유용하지만 실제 사용자의 기기와 네트워크 분포를 그대로 보여주지는 않습니다. 둘째, 평균만 보면 느린 사용자 구간이 감춰질 수 있으므로 75백분위수와 좋음·개선 필요·나쁨 분포를 함께 확인하세요.
셋째, 변경 직후 CrUX 수치가 그대로라고 해서 수정이 실패한 것은 아닙니다. 최근 28일의 경험이 반영되므로 개선 전 데이터가 일정 기간 포함될 수 있습니다. 넷째, 지표가 나빠진 시점에는 변경 이력, 페이지 유형, 기기별 표본 수를 함께 살펴야 합니다.
자주 묻는 질문
Q. PageSpeed Insights에 실사용자 데이터가 표시되지 않으면 어떻게 하나요?
해당 URL의 CrUX 표본이 부족할 수 있습니다. 오리진 기준 데이터가 표시되는지 확인하고, 페이지별 판단이 필요하다면 web-vitals 기반 RUM으로 데이터를 직접 수집하세요. Lighthouse 결과는 문제를 조사하는 실험실 데이터로 활용할 수 있습니다.
Q. Lighthouse 점수만으로 Core Web Vitals 통과 여부를 알 수 있나요?
아닙니다. Lighthouse는 통제된 조건에서 수집하는 실험실 데이터이고, Core Web Vitals 평가는 실제 사용자 필드 데이터의 75백분위수를 기준으로 합니다. 두 데이터를 함께 사용하면 문제 재현과 실제 사용자 영향 확인을 나눠 진행할 수 있습니다.
Q. INP 측정값이 보고되지 않는 경우도 있나요?
있습니다. 페이지에서 사용자가 상호작용하지 않으면 해당 방문에서는 INP가 보고되지 않을 수 있습니다. 수집 표본과 실제 상호작용이 있었는지 확인하고, 상호작용이 있었는데도 값이 누락된다면 브라우저 전송이나 수집 서버를 점검하세요.
Q. 수정한 날 바로 CrUX 수치에 반영되나요?
즉시 반영된다고 볼 수 없습니다. CrUX 필드 데이터는 최근 28일의 사용자 경험을 바탕으로 하므로 이전 방문 데이터가 포함될 수 있습니다. 빠른 배포 전후 비교에는 자체 RUM을 함께 사용하고, CrUX는 더 긴 기간의 추세 확인에 활용하세요.
지표와 판정 기준은 Core Web Vitals 측정항목 기준점을 정의하는 방법, PageSpeed Insights의 CrUX 데이터와 기준 설명은 PageSpeed Insights 정보를 참고했습니다.
