필드 데이터는 이미 일어난 방문을, 실험실 데이터는 통제된 테스트를 설명합니다. PageSpeed Insights는 둘을 함께 보여 주지만 기기, 행동과 기간이 다릅니다. 실제 경험을 이해할 때는 필드를, 원인을 찾고 변경을 확인할 때는 실험실 기록을 사용합니다.
Lighthouse가 녹색이라고 실제 방문자가 Core Web Vitals를 통과한 것은 아닙니다. 느린 합성 테스트가 좋은 필드 결과를 부정하지도 않습니다. 먼저 각 숫자의 대상을 확인합니다. Core Web Vitals 입문 안내는 지표를, 이 글은 측정 차이를 설명합니다.
측정 대상과 질문부터 확인하기
CrUX는 자격 요건을 충족하는 Chrome 사용자의 경험을 집계합니다. 모든 방문자를 세는 자료가 아닙니다. 브라우저 설정, 지원 환경과 충분한 관측량이 필요합니다. Google은 포함을 보장하는 보편적인 방문자 수를 공개하지 않습니다.
페이지 요건도 있습니다. 공개적으로 발견 가능하고 색인 생성이 가능해야 하므로, 트래픽이 있다고 비공개 계정 페이지가 포함되는 것은 아닙니다. URL을 수동 제출해 강제할 수도 없습니다. 데이터 없음은 이 자료로 답할 수 없다는 뜻이지 빠르거나 느리다는 판정이 아닙니다.
Lighthouse 탐색 실행은 설정된 브라우저에서 URL을 로드합니다. 방문을 기다리지 않고 배포 전에도 진단할 수 있지만, 하나의 시나리오가 전체 방문자 분포는 아닙니다.
다음 표는 각 자료가 답하는 질문을 구분합니다.
| 항목 | PSI의 CrUX 필드 데이터 | Lighthouse 탐색 데이터 |
|---|---|---|
| 대상 | 요건을 충족하는 실제 Chrome 방문 | 통제된 페이지 로드 |
| 기간 | 이전 28일 | 현재 테스트 |
| 기기 | 실제 기기를 폼 팩터별로 집계 | 설정한 기기와 제한 프로필 |
| 행동 | 실제 페이지 이용 | 탐색과 관찰 구간 |
| 용도 | 지속적인 방문자 문제 찾기 | 원인과 구현 변경 비교 |
| 한계 | 집계와 포함 조건 | 모든 이용 경로를 대표하지 않음 |
백분위수를 평균으로 읽지 않기
필드 값은 일반적으로 75번째 백분위수인 p75입니다. LCP p75가 2.4초라면 관측 경험의 최소 75%가 2.4초 이내에 그 시점에 도달했다는 뜻입니다. 모두가 2.4초를 기다렸거나 산술평균이 그렇다는 뜻은 아닙니다. 이 숫자는 설명용 예시이며 특정 사이트 측정값이 아닙니다.
양호 기준은 LCP 2.5초 이하, INP 200밀리초 이하, CLS 0.1 이하입니다. 모바일과 데스크톱을 따로 판단합니다. 좋은 데스크톱이 모바일 문제를 상쇄하지 않으며 기준값은 같습니다.
분포도 살펴봅니다. 경계에 가까운 좋은 p75와 상당한 느린 방문이 함께 존재할 수 있습니다. 지역, 템플릿이나 상호작용에 몰리는지 확인한 뒤 작업 완료를 판단합니다.
Google의 실험실과 필드 측정 비교는 배경을 설명합니다. 숫자를 공유할 때 대상과 백분위수를 함께 적습니다.
필드 결과가 해당 URL의 것인지 확인하기
PSI는 URL 데이터를 우선 표시하고 관측량이 부족하면 출처 수준으로 전환할 수 있습니다. 출처는 스킴, 호스트 이름과 포트의 조합입니다. 전체 경로나 같은 조직의 모든 하위 도메인이 아닙니다.
출처에는 느린 상품 페이지와 빠른 글 등 서로 다른 템플릿이 섞일 수 있습니다. 필드가 전체 출처이고 실험실이 한 글이라면, 불일치 자체가 측정 오류를 뜻하지 않습니다.
요청 URL, 최종 주소, 기기, 범위와 날짜를 기록합니다. 단순히 모바일 LCP가 나쁘다고 적으면 어떤 대상이 문제인지 알 수 없습니다. 대시보드에서 출처 값을 URL 값으로 바꾸어 표시하지 않습니다.
정확한 URL 자료가 없으면 한계를 표시하고 출처 맥락을 따로 제공합니다. PageSpeed Insights 보고서 안내에서 구분 위치를 설명합니다.
제한 설정이 재현하는 범위 이해하기
Lighthouse는 CPU와 네트워크 제한을 시뮬레이션해 성능을 추정할 수 있습니다. 다른 설정에서는 다른 방식을 사용합니다. 같은 이름의 도구라도 조건이 같다고 가정하지 말고 보고서 설정을 읽습니다.
개발 컴퓨터, 확장 프로그램, 백그라운드 부하와 테스트 위치가 영향을 줍니다. 코드 변경 없이도 실행 결과는 변합니다. 브라우저와 Lighthouse 버전, 전략, 환경과 개별 값을 저장하고 같은 조건의 반복 실행을 비교합니다.
캐시 상태도 다릅니다. 실험실은 빈 브라우저 캐시를 만날 수 있고 재방문자는 자원을 재사용합니다. 반대로 실험실이 따뜻한 CDN 응답을 받지만 먼 방문자는 그렇지 않을 수 있습니다. 어떤 캐시가 비어 있는지 명시해야 합니다. 로컬 저장소 삭제는 에지 캐시를 비우지 않습니다.
시뮬레이션은 비싼 작업을 찾는 데 유용하지만 특정 휴대전화가 같은 값을 낸다고 약속하지 않습니다. 기본 프로필을 녹색이 될 때까지 반복하기보다 방문자 증거로 추가 시나리오를 고릅니다.
차이를 설명하는 지표 조사하기
LCP에서는 실제 최대 요소와 전달 경로를 비교합니다. 화면 너비가 다른 이미지나 텍스트 블록을 선택할 수 있습니다. 거리, 서버 응답, 자원 발견과 렌더링 작업에 따라 병목이 달라집니다. 데스크톱 자산이 모바일을 대표하지 않을 수 있습니다.
CLS에서는 이용을 연장합니다. 늦은 삽입물까지 스크롤하고 광고, 동의 변경과 뒤로 가기를 시험합니다. 로드만 보는 검사는 나중의 이동을 놓칠 수 있습니다. 움직인 제목은 위 컨테이너의 피해 요소일 수 있습니다.
INP는 상호작용을 시험해야 합니다. 일반 Lighthouse 탐색 실행은 CrUX의 실제 INP 분포를 제공하지 않습니다. TBT는 로드 중 메인 스레드 부담을 보여 줄 수 있지만 INP를 대체하지 않습니다. 통제된 상호작용 도구는 지연을 측정할 수 있으며 한계는 시나리오와 범위입니다.
DevTools로 메뉴 열기, 검색 입력과 상품 옵션 변경을 재현합니다. 깨끗하게 로드된 페이지도 첫 클릭에서 비싼 일을 할 수 있습니다. 다른 사람이 재현하도록 행동, 대상과 추적 기록을 남깁니다.
배포 뒤에도 이전 방문이 남는 기간 고려하기
PSI의 CrUX는 이전 28일을 다루며 매일 갱신합니다. 수정 직후에는 대부분이 이전 구현을 설명할 수 있습니다. 새 실험실 결과와 과거 필드 결과는 시간상의 질문이 다릅니다.
배포 시각을 모니터링에 표시합니다. 공개 수집 창이 새 방문으로 채워지는 동안 자체 최신 측정과 비교 가능한 테스트를 확인합니다. 특정 시간 뒤 반드시 바뀐다거나 나쁜 표시가 남았다고 실패라고 단정하지 않습니다.
방문자 구성도 바뀝니다. 느린 네트워크의 유입이 늘면 코드가 개선되어도 분포가 달라질 수 있습니다. 가능하면 집단별로 비교하고 공개 집계가 원인을 구분하지 못하면 불확실성을 남깁니다.
집계만으로 원인을 못 찾을 때 RUM 추가하기
실제 사용자 모니터링인 RUM은 템플릿, 배포 버전 같은 맥락과 함께 자체 성능을 수집할 수 있습니다. 수집, 동의, 보관과 접근을 먼저 설계합니다. 계정 정보, 폼 내용이나 민감한 쿼리를 포함한 전체 URL은 보내지 않습니다.
공식 web-vitals 라이브러리는 중요한 수명주기 처리를 제공합니다. 의존성을 설치하고 번들링하는 프로젝트에서 다음 모듈은 지원되는 측정값을 로컬에 출력하며 서버로 보내지 않습니다.
import {onCLS, onINP, onLCP} from 'web-vitals';
function reportMetric(metric) {
console.log({
name: metric.name,
value: metric.value,
id: metric.id,
rating: metric.rating,
navigationType: metric.navigationType
});
}
onCLS(reportMetric);
onINP(reportMetric);
onLCP(reportMetric);백엔드를 설계한 다음 승인된 수집 대상으로 로거를 교체합니다. 값이 바뀌면서 같은 지표가 다시 보고될 수 있으므로 갱신과 중복 방식을 정해야 합니다. 콜백 하나가 새로운 방문은 아닙니다. INP 누락은 적격 상호작용이 없었다는 의미일 수 있으며 0으로 바꾸면 안 됩니다.
RUM과 CrUX는 브라우저, 샘플링, 동의, 탐색 정의와 iframe 범위가 달라 정확히 같지 않을 수 있습니다. 추가 진단에 attribution 빌드를 사용하되 전송 전 포함 정보를 검토합니다.
각 결과가 뒷받침하는 결정에 사용하기
구현 변경은 같은 조건에서 문제 경로를 재현하고 개선을 입증합니다. 방문자 결과는 범위와 기간이 표시된 필드로 관찰합니다. 검색에서는 Core Web Vitals와 Lighthouse 점수를 구분해야 하며 후자는 순위 등급이 아닙니다.
문제 지표 하나, 대표 템플릿 하나와 반복 가능한 경로를 고릅니다. 기준을 저장하고 의심 원인을 바꾼 뒤 시간과 기능을 모두 확인합니다. 활성화된 PageSpeed 분석기와 Core Web Vitals 안내를 활용합니다. 설명된 차이가 검증된 수정으로 이어져야 합니다.
