Chrome UX Report | Chrome for Developers

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

측정항목

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

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

첫 페인트

"First Paint는 브라우저가 탐색 후 처음 렌더링된 시간을 보고합니다. 기본 배경 페인트는 제외되지만 기본이 아닌 배경 페인트는 포함됩니다. 이는 브라우저가 페이지 렌더링을 시작하는 페이지 로드에서 개발자가 관심을 갖는 첫 번째 주요 순간입니다."

Paint Timing API

콘텐츠가 포함된 첫 페인트

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

Paint Timing API

로드된 DOM 콘텐츠

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

MDN

콘텐츠가 포함된 최대 페인트

"최대 콘텐츠 페인트 (LCP)는 인지된 로드 속도를 측정하는 데 중요한 사용자 중심 측정항목입니다. LCP는 페이지의 주요 콘텐츠가 로드될 가능성이 있는 페이지 로드 타임라인의 특정 지점을 표시하기 때문입니다. 빠른 LCP는 페이지가 유용하다고 사용자를 안심시키는 데 도움이 됩니다."

web.dev/articles/lcp

온로드

"페이지와 종속 리소스의 로드가 완료되면 로드 이벤트가 시작됩니다."

MDN

누적 레이아웃 변경

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

web.dev/articles/cls

첫 입력 지연

"첫 입력 지연 (FID)은 사용자가 응답하지 않는 페이지와 상호작용하려고 할 때 느끼는 경험을 수치화하기 때문에 로드 반응성을 측정하는 데 중요한 사용자 중심 측정항목입니다. FID가 낮으면 페이지를 사용할 수 있습니다."

web.dev/articles/fid)

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

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

web.dev/articles/inp

Interaction to Next Paint (INP)는 2022년 2월 CrUX 데이터 세트에 추가되었습니다. 이 새로운 측정항목은 개별 이벤트의 엔드 투 엔드 지연 시간을 캡처하고 페이지의 전체 기간 동안 전반적인 응답성을 보다 전체적으로 보여줍니다.

탐색 유형 측정항목은 다음 탐색의 페이지 조회수 비율에 대한 분석을 제공합니다.

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

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

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

실험 측정항목

실험용 측정항목은 BigQuery를 사용하여 CrUX 데이터 세트에서 제공되며, 일부 측정항목은 CrUX API에서도 사용할 수 있습니다. 이러한 측정항목은 사용자 의견에 따라 달라지므로 정기적으로 변경될 가능성이 높습니다. 출시 노트에서 최신 변경사항을 확인하세요.

첫 바이트까지의 시간

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

CrUX는 문서 리소스의 첫 바이트가 서버에서 수신될 때 TTFB를 측정합니다. 기존의 TTFB 뷰는 문서 응답이 시작되는 시점을 측정하는 것이지만 조기 힌트가 사용될 때는 '첫 번째 바이트'가 이보다 먼저입니다. 향후 CrUX가 조기 힌트를 무시하도록 업데이트될 수 있습니다.

TTFB는 서버 응답 시간을 직접적으로 측정하는 것은 아닙니다. TTFB는 리디렉션 시간을 비롯하여 그 전의 측정값을 포함하고 응답이 캐시 또는 CDN 또는 서버에서 제공되는지에 따라 영향을 받기 때문에 서버 응답 시간을 직접 측정할 수 없습니다. 이는 CrUX와 같은 현장 데이터에서 특히 두드러집니다. 반면에, 실험실 테스트는 최종 URL이 테스트이고 종종 캐싱 변경 사항을 반복적으로 무효화하기 때문에 이러한 요인의 영향을 덜 받습니다.

알림 권한

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

왕복 시간

최근 네트워크 연결을 기반으로 탐색 시작 시 HTTP (애플리케이션 레이어) 왕복 시간의 추정치를 제공합니다. 이 측정항목은 Network Information API의 rtt 속성이라고도 하며, 유효 연결 유형 (ECT) 측정기준을 담당하는 동일한 API입니다.

이 측정항목은 CrUX API 및 CrUX History API에서만 사용 가능하며 75번째 백분위수까지 집계됩니다. 히스토그램을 사용할 수 없습니다. BigQuery에서도 사용할 수 없습니다.