이 페이지는 Cloud Translation API를 통해 번역되었습니다.

측정항목

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

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

누적 레이아웃 변경

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

web.dev/articles/cls

로드된 DOM 콘텐츠

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

MDN

첫 페인트

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

Paint Timing API

콘텐츠가 포함된 첫 페인트

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

Paint Timing 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 이미지 하위 파트는 다음과 같은 네 가지 별도의 측정항목으로 제공됩니다.

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 수치를 왜곡하므로 포함되지 않습니다. 텍스트로 구성된 사이트의 경우 전체 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에서도 사용할 수 있습니다. 이러한 측정항목은 사용자 의견에 따라 발전하므로 정기적으로 변경될 수 있습니다. 출시 노트를 확인하여 최신 변경사항을 확인하세요.

첫 바이트까지의 시간

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

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

알림 권한

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