Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

측정항목

게시일: 2022년 6월 23일, 최종 업데이트: 2026년 10월 13일

CrUX의 측정항목은 브라우저에서 노출하는 표준 웹 플랫폼 API를 기반으로 합니다. 특히 BigQuery 데이터 세트에서 이 데이터는 출처 해상도로 집계됩니다. 사이트 성능에 관한 더 자세한 분석 및 통계 (예: URL 수준 해상도)가 필요한 사이트 소유자는 동일한 API를 사용하여 자체 출처에 관한 자세한 실제 사용자 측정 (RUM) 데이터를 수집할 수 있습니다. 모든 API는 Chrome에서 사용할 수 있지만 다른 브라우저에서는 전체 측정항목 집합을 지원하지 않을 수 있습니다.

대부분의 측정항목은 히스토그램 집계로 표시되므로 분포를 시각화하고 백분위수 값을 대략적으로 파악할 수 있습니다.

누적 레이아웃 이동

'누적 레이아웃 변경 (CLS)은 시각적 안정성을 측정하는 데 중요한 사용자 중심 측정항목입니다. 사용자가 예기치 않은 레이아웃 변경을 경험하는 빈도를 정량화하는 데 도움이 되기 때문입니다. CLS가 낮으면 페이지가 즐거움을 선사할 수 있습니다.'

web.dev/articles/cls

DOM 콘텐츠 로드됨

'DOMContentLoaded는 스타일시트, 이미지, 하위 프레임의 로드가 완료되기를 기다리지 않고 초기 HTML 문서가 완전히 로드 및 파싱된 시간을 보고합니다.'

MDN

첫 페인트

'첫 페인트는 탐색 후 브라우저가 처음 렌더링한 시간을 보고합니다. 여기에는 기본 배경 페인트는 제외되지만 기본이 아닌 배경 페인트는 포함됩니다. 이는 개발자가 페이지 로드에서 가장 중요하게 생각하는 첫 번째 순간입니다. 브라우저가 페이지 렌더링을 시작한 때입니다.'

페인트 타이밍 API

첫 콘텐츠 페인트

첫 콘텐츠 페인트 (FCP)는 브라우저가 텍스트, 이미지 (배경 이미지 포함), 흰색이 아닌 캔버스 또는 SVG를 처음 렌더링한 시간을 보고합니다. 여기에는 대기 중인 웹 글꼴이 있는 텍스트가 포함됩니다. 사용자가 페이지 콘텐츠를 사용하기 시작할 수 있는 첫 번째 시간입니다.'

페인트 타이밍 API

다음 페인트에 대한 상호작용

'다음 페인트에 대한 상호작용 (INP)은 반응성을 평가하는 필드 측정항목입니다. INP는 전체 페이지 수명 주기에서 모든 상호작용의 지연 시간을 기록합니다. 이러한 상호작용의 가장 높은 값 또는 상호작용이 많은 페이지의 경우 가장 높은 값에 가까운 값이 페이지의 INP로 기록됩니다. INP가 낮으면 페이지가 항상 안정적으로 반응할 수 있습니다.'

web.dev/articles/inp

다음 페인트에 대한 상호작용 (INP)은 2022년 2월에 CrUX 데이터 세트에 추가되었습니다. 이 새로운 측정항목은 개별 이벤트의 전체 지연 시간을 캡처하고 페이지의 전체 수명 동안 전반적인 반응성을 보다 전체적으로 파악할 수 있도록 합니다.

최대 콘텐츠 페인트

최대 콘텐츠 페인트 (LCP)는 사용자가 느끼는 로드 속도를 측정하는 데 중요한 사용자 중심 측정항목입니다. 페이지의 주요 콘텐츠가 로드되었을 가능성이 있는 페이지 로드 타임라인의 지점을 표시하기 때문입니다. LCP가 빠르면 페이지가 유용하다는 것을 사용자에게 확신시킬 수 있습니다.

web.dev/articles/lcp

최대 콘텐츠 페인트 리소스 유형

'LCP는 사용자가 페이지로 처음 이동한 시점을 기준으로 표시 영역에 표시되는 가장 큰 이미지, 텍스트 블록 또는 동영상의 렌더링 시간을 보고합니다.'

web.dev/articles/lcp - LCP에 고려되는 요소

텍스트와 이미지 (첫 번째 동영상 프레임 이미지 포함)는 로드 특성과 최적화 기술이 매우 다른 경우가 많습니다. LCP 리소스 유형의 비율을 파악하면 LCP 측정항목과 최적화 경로를 더 잘 이해할 수 있습니다.

자세한 내용은 LCP 리소스 유형 출시 블로그 게시물을 참고하세요.

최대 콘텐츠 페인트 이미지 하위 요소

'PageSpeed Insights에서 이 측정항목을 개선하는 방법을 알려주지 않는 경우 LCP 최적화가 더 복잡한 작업이 될 수 있습니다. 복잡한 작업의 경우 일반적으로 더 작고 관리하기 쉬운 작업으로 나누어 각 작업을 개별적으로 해결하는 것이 좋습니다.'

web.dev/articles/optimize-lcp - LCP를 하위 요소로 분류

이미지 LCP를 가장 중요한 하위 요소로 분류하면 각 부분을 최적화하는 방법에 관한 구체적인 권장사항과 권장사항을 활용할 수 있습니다.

LCP 이미지 하위 요소는 다음과 같은 4가지 개별 측정항목으로 제공됩니다.

largest_contentful_paint_image_time_to_first_byte
largest_contentful_paint_image_resource_load_delay
largest_contentful_paint_image_resource_load_duration
largest_contentful_paint_image_element_render_delay

하위 요소는 이미지에만 포함되며 첫 번째 동영상 프레임 이미지는 전체 다운로드 시간을 측정할 수 없으므로 포함되지 않습니다 (첫 번째 동영상 프레임은 이러한 복잡성이 관련이 없는 LCP 리소스 유형 측정항목에 포함됨).

텍스트 하위 요소는 유용성이 떨어지고 이미지 LCP 수를 왜곡하므로 포함되지 않습니다. 텍스트 LCP로 주로 구성된 사이트의 경우 전체 TTFB 및 전체 FCP 측정항목이 유용한 분류입니다. 단, 이는 모든 LCP에 적용되며 텍스트 LCP에만 적용되는 것은 아닙니다.

자세한 내용은 LCP 이미지 하위 요소 출시 블로그 게시물을 참고하세요.

탐색 유형 측정항목은 다음 탐색의 페이지 조회수 비율을 분류하여 제공합니다.

유형	설명
`navigate`	기타 카테고리에 속하지 않는 페이지 로드입니다.
`navigate_cache`	기본 리소스 (기본 HTML 문서)가 HTTP 캐시에서 제공된 페이지 로드입니다. 사이트는 하위 리소스에 캐싱을 사용하는 경우가 많지만 기본 HTML 문서는 캐시되는 경우가 훨씬 적으며 캐시할 수 있는 경우 로컬 및 CDN에서 캐시할 수 있으므로 성능이 크게 개선될 수 있습니다.
`reload`	사용자가 새로고침 버튼을 누르거나 주소 표시줄에서 Enter 키를 누르거나 탭 닫기를 실행취소하여 페이지를 새로고침했습니다. 페이지 새로고침은 기본 페이지가 변경되었는지 확인하기 위해 서버로 다시 유효성 검사를 실행하는 경우가 많습니다. 페이지 새로고침 비율이 높으면 사용자 환경에 불만이 있을 수 있습니다.
`restore`	브라우저를 다시 시작하거나 메모리상의 이유로 삭제된 탭 후에 페이지가 새로고침되었습니다. Android의 Chrome의 경우 '새로고침'으로 보고됩니다.
`back_forward`	최근에 페이지가 표시되고 다시 돌아온 기록 탐색입니다. 올바른 캐싱을 사용하면 이러한 환경이 비교적 빨라야 하지만 페이지를 처리하고 JavaScript를 실행해야 합니다. bfcache는 둘 다 방지합니다.
`back_forward_cache`	bfcache에서 제공된 기록 탐색입니다. 페이지를 최적화하여 bfcache를 활용하도록 차단기를 삭제하면 환경이 더 빨라지므로 사이트에서
`prerender`	페이지가 사전 렌더링되었습니다. bfcache와 마찬가지로 페이지 로드가 거의 즉시 이루어질 수 있습니다.

경우에 따라 페이지 로드는 여러 탐색 유형의 조합일 수 있습니다. 이 경우 CrUX는 테이블의 역순 (하단에서 상단)으로 첫 번째 일치 항목을 보고합니다.

자세한 내용은 탐색 유형 공지사항 게시물을 참고하세요.

Onload

'로드 이벤트는 페이지와 종속 리소스의 로드가 완료되면 발생합니다.'

MDN

왕복 시간

최근 네트워크 연결을 기반으로 탐색 시작 시 HTTP (애플리케이션 계층) 왕복 시간의 추정치를 제공합니다. 이 측정항목은 이전의 효과적인 연결 유형 (ECT) 측정기준을 담당하는 동일한 API인 네트워크 정보 API의 rtt 속성을 기반으로 합니다.

자세한 내용은 LCP 리소스 유형 출시 블로그 게시물을 참고하세요.

실험용 측정항목

실험용 측정항목은 BigQuery를 사용하는 CrUX 데이터 세트와 CrUX API 모두에서 사용할 수 있지만 모든 측정항목이 두 가지 모두에서 제공되는 것은 아닙니다. 이러한 측정항목은 사용자 의견을 기반으로 발전하므로 변경될 수 있습니다. 최신 변경사항을 확인하려면 출시 노트를 참고하세요.

실험용 소프트 탐색 Core Web Vitals 측정항목

2026년 10월 출시에서는 소프트 탐색을 비롯한 Core Web Vitals 측정항목의 실험용 버전이 도입되었습니다.

experimental_largest_contentful_paint_with_softnavs
experimental_interaction_to_next_paint_with_softnavs
experimental_cumulative_layout_shift_with_softnavs

이러한 측정항목에는 전체 페이지 로드와 소프트 탐색이 모두 포함됩니다.

자세한 내용은 Chrome UX 보고서에 실험용 Core Web Vitals 측정항목 도입을 참고하세요.

첫 바이트까지의 시간

CrUX의 TTFB는 뒤로/앞으로 캐시 (bfcache) 탐색 및 사전 렌더링된 페이지에서도 수집되는 다른 타이머 (예: LCP)와 달리 전체 페이지 로드에서만 수집됩니다. 따라서 TTFB의 샘플 크기는 다른 측정항목보다 작을 수 있으며 반드시 직접 비교할 필요는 없습니다. CrUX의 TTFB에는 콜드 페이지 로드, 캐시된 페이지 로드, 설정된 연결의 페이지 로드 (예: 사이트 내 페이지 로드)가 포함됩니다.

TTFB는 리디렉션 시간을 포함하여 그 이전의 측정항목을 포함하고 응답이 캐시 또는 CDN 또는 서버에서 제공되는지 여부에 영향을 받으므로 서버 응답 시간을 직접 측정하는 것은 아닙니다. 이는 CrUX와 같은 필드 데이터에서 특히 두드러지며 실험실 테스트는 최종 URL이 테스트되고 캐싱 변경사항을 반복적으로 무효화하는 경우가 많으므로 이러한 요인의 영향을 덜 받습니다.

알림 권한

사용자에게 알림을 표시할 권한을 요청하는 웹사이트의 경우 이 측정항목은 프롬프트에 대한 사용자 응답(수락, 거부, 무시 또는 닫기)의 상대적 빈도를 나타냅니다.

광고 측정항목

Chrome은 사이트 및 광고주와 같은 다른 사용자가 실제 사용자의 광고 경험과 그 영향을 더 잘 이해할 수 있도록 공개 측정항목과 도구를 제공합니다.

광고 수: 이 측정항목은 일반적인 사용자가 사이트에서 한 번에 보는 광고 수를 설명합니다.
광고 밀도: 이 측정항목은 일반적인 사용자의 콘텐츠와 광고 노출의 균형을 설명합니다.
광고 가중치: CPU: 이 측정항목은 성능에 영향을 미칠 수 있는 광고의 CPU 사용량을 설명합니다.
광고 가중치: 네트워크: 이 측정항목은 광고의 네트워크 리소스 사용량을 설명합니다.

이러한 측정항목은 웹 광고주와 광고를 게재하는 데 사용하는 서비스에 특히 유용할 것으로 예상됩니다. 광고 생태계의 다양한 이해관계자로부터 이러한 측정항목이 광고 기회를 평가하고 광고 제품 결정을 내리는 방식을 개선할 수 있다는 의견을 들었습니다.

자세한 내용은 광고 측정항목 출시 블로그 게시물 및 광고 측정 문서에서 확인하세요.