2024년 3월 데이터 세트부터 Chrome 사용자 환경 보고서 (CrUX)에 navigation_types
측정항목이 포함됩니다. 쿼리된 측정기준의 페이지 로드 탐색 유형에 관한 집계된 통계를 제공합니다.
탐색 유형이 다르면 실적 측정항목이 달라지므로 사이트의 실적을 확인할 때 각 유형의 상대적인 빈도를 파악하면 도움이 됩니다. 예를 들어 탐색에서 뒤로 감기 (bfcache)를 사용하면 일반적으로 거의 즉각적으로 탐색되며 이는 매우 작은 LCP 및 FCP 측정항목에 반영되고 CLS 및 INP 측정항목에는 감소합니다.
탐색 유형 분석을 노출함으로써 사이트 소유자가 사이트에서 사용되는 탐색 유형을 더 잘 알도록 권장하고 캐싱 설정, bfcache 차단기, 사전 렌더링을 확인하여 일부 더 빠른 유형을 권장하고자 합니다.
navigation_types
측정항목은 Daily CrUX API, CrUX History API (처음에는 3주간의 기록을 사용할 수 있으며 이후 6개월 동안 매주 전체 범위로 확대됨), 최신 CrUX BigQuery 데이터 세트, CrUX 대시보드에서 사용할 수 있습니다. 이 기록이 있으면 사이트 소유자가 시간 경과에 따른 탐색 유형 사용의 변경사항도 확인할 수 있습니다. 이를 통해 개선사항을 추적할 수 있습니다 (예: bfcache 차단 삭제). 또한 사이트가 변경되지 않은 경우에도 측정항목의 변경사항을 설명할 수 있습니다.
CrUX에서 사용할 수 있는 탐색 유형은 무엇인가요?
CrUX는 다음 표에서 다음과 같은 탐색 유형을 구분합니다.
유형 | 설명 |
---|---|
navigate |
다른 카테고리에 해당하지 않는 페이지 로드. |
navigate_cache |
기본 리소스 (기본 HTML 문서)가 HTTP 캐시에서 제공된 페이지 로드입니다. 사이트에서는 종종 하위 리소스에 캐싱을 사용하지만 기본 HTML 문서는 상당히 적게 캐시됩니다. 가능하다면 로컬 및 CDN에 캐시할 수 있게 됨으로써 성능이 눈에 띄게 개선될 수 있습니다. |
reload |
사용자가 새로고침 버튼을 누르거나 주소 표시줄에서 Enter 키를 누르거나 탭 닫기를 취소하여 페이지를 새로고침했습니다. 페이지를 새로고침하면 기본 페이지가 변경되었는지 확인하기 위해 서버로 유효성 재전송을 요청하는 경우가 많습니다. 페이지 새로고침 비율이 높으면 사용자가 불만을 가질 수 있습니다. |
restore |
브라우저를 다시 시작하거나 메모리 문제로 인해 탭이 삭제된 후 페이지가 다시 로드되었습니다. Android용 Chrome의 경우 대신 reload 로 보고됩니다. |
back_forward |
방문 기록 탐색: 페이지를 보고 최근에 돌아왔음을 의미합니다. 올바른 캐싱을 사용하면 이러한 작업은 상당히 빠른 경험을 할 수 있지만 여전히 페이지를 처리하고 JavaScript를 실행해야 합니다. 두 가지 모두 bfcache에서 방지됩니다. |
back_forward_cache |
bfcache에서 제공된 기록 탐색입니다. bfcache를 활용하도록 페이지를 최적화하면 더욱 빠른 경험을 제공할 수 있습니다. 사이트에서 이 카테고리의 탐색 비율을 개선하기 위해 bfcache 차단기를 제거해야 합니다. |
prerender |
페이지가 사전 렌더링되어 bfcache와 마찬가지로 페이지 로드에 거의 즉각적으로 기여할 수 있습니다. |
경우에 따라 페이지 로드는 여러 탐색 유형의 조합일 수 있습니다. 이 경우 CrUX는 이전 표의 역순으로 (아래에서 위로) 첫 번째 일치 항목을 보고합니다.
CrUX의 탐색 유형 제한사항
CrUX는 공개 데이터 세트이므로 보고의 세분화 수준이 제한적입니다. 출처와 URL의 경우 대상 트래픽이 충분하지 않아 navigation_types
측정항목을 사용할 수 없는 경우가 많습니다. 자세한 내용은 CrUX 방법론을 참고하세요.
또한 탐색 유형별로 다른 측정항목을 분류하여 제공할 수는 없습니다. 이렇게 하면 CrUX에서 사용 가능한 출처와 URL의 수가 더 줄어들기 때문입니다.
탐색 유형과 같은 기준에 따라 트래픽을 분류할 수 있도록 사이트에서 자체 Real User Monitoring (RUM)을 구현하는 것이 좋습니다. 이러한 솔루션의 탐색 유형은 보고된 유형과 포함되는 페이지 보기에 따라 다를 수 있습니다. CrUX 데이터가 내 RUM 데이터와 다른 이유는 무엇인가요? 도움말을 참조하세요.
RUM은 특정 성능 문제에 관한 보다 높은 수준의 세부정보를 제공할 수도 있습니다. 예를 들어 CrUX는 bfcache 적합성을 개선하는 것이 가치가 있을 것임을 암시할 수 있지만, bfcache notRestoredReasons API는 bfcache에서 특정 페이지 로드를 제공할 수 없는 이유를 정확하게 알려줄 수 있습니다.
CrUX API의 탐색 유형
API에서 탐색 유형을 보려면 요청에 navigation_types
측정항목을 포함하거나 모든 측정항목이 포함되도록 측정항목을 설정하지 않습니다.
export API_KEY="[YOUR_API_KEY]"
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$API_KEY" \
--header 'Content-Type: application/json' \
--data '{"origin": "https://example.com", metrics: ["navigation_types"]}'
요청 형식은 API 키를 가져오는 방법에 대한 설명 및 API 가이드를 비롯한 API 문서에 자세히 설명되어 있습니다. 그러면 다음과 같은 객체가 반환됩니다.
{
"record": {
"key": { "origin": "https://example.com" },
"metrics": {
"navigation_types": {
"fractions": {
"navigate": 0.5335,
"navigate_cache": 0.2646,
"reload": 0.0885,
"restore": 0.0023,
"back_forward": 0.0403,
"back_forward_cache": 0.0677,
"prerender": 0.0031
}
}
},
"collectionPeriod": {
"firstDate": { "year": 2024, "month": 3, "day": 6 },
"lastDate": { "year": 2024, "month": 4, "day": 2 }
}
}
}
응답에서 CrUX는 navigation_types
측정항목을 각 탐색 유형의 페이지 로드 비율이 포함된 객체로 보고합니다. 각 비율은 특정 키의 0.0
(페이지 로드의 0% 를 나타냄)과 1.0
(페이지 로드의 100% 를 나타냄) 사이의 값입니다.
이 응답에서 2024년 3월 6일부터의 수집 기간(2024년 4월 2일까지) 동안 탐색(페이지 로드)의 6.77% 가 브라우저의 bfcache에서 제공되었음을 알 수 있습니다. 마찬가지로, 다른 비율 중 일부는 페이지 로드 최적화의 기회를 식별하는 데 도움이 될 수 있습니다. 특정 키 (URL 또는 출처와 폼 팩터의 조합 포함)의 경우 navigation_types
분수의 합은 약 1.0이 됩니다.
CrUX History API의 탐색 유형
CrUX History API는 탐색 유형에 대해 분수당 최대 25개의 데이터 포인트가 포함된 시계열을 제공하여 시간 경과에 따른 분수를 시각화할 수 있게 해줍니다. CrUX API에서 CrUX History API로 요청을 변경하려면 queryRecord
대신 queryHistoryRecord
엔드포인트에 실행합니다. 예를 들어 CrUX 기록 Colab에서는 navigation_types
측정항목을 누적 막대로 표시합니다.
위의 스크린샷에서 기록은 세 번의 수집 기간 (각각 28일, 7일 간격)에 대해서만 확인할 수 있습니다. 모두 채워지면 25개의 수집 기간이 모두 적용됩니다. 이 기록을 시각화하면 최적화가 적용되었는지 또는 회귀되었는지를 확인할 수 있습니다. 특히 HTTP 캐시 구성에 관한 것으로, bfcache 및 사전 렌더링을 위한 페이지 최적화가 여기에 해당합니다.
CrUX BigQuery의 탐색 유형
이제 CrUX BigQuery 테이블에는 각 유형으로 만들어진 navigation_type
레코드가 포함되고, 요약 구체화된 뷰에는 각 유형마다 하나씩 여러 개의 navigation_types_*
열이 포함됩니다.
자세한 표
CrUX BigQuery의 자세한 테이블 스키마는 웹 성능 측정항목에 대한 자세한 히스토그램을 제공합니다. 이를 통해 이 예시 분석에서 특정 탐색 유형이 즉각적인 로드 성능 또는 우수한 로드 성능과 어떤 상관관계가 있는지 확인할 수 있습니다.
예를 들어 back_forward_cache
비율 및 페이지가 즉시 로드되는 빈도 (instant_lcp_density
가 LCP <= 200ms로 정의됨) 및 양호한 LCP가 확인되는 빈도 (good_lcp_density
가 LCP <= 2500ms로 정의됨)와의 상관관계를 살펴보았습니다. 다음 도표에 표시된 back_forward_cache
와 instant_lcp_density
간의 강력한 통계적 상관관계 (r=0.87)와 back_forward_cache
와 good_lcp_density
(r=0.29) 간의 중간 정도의 상관관계가 있었습니다.
이 분석을 위한 Colab에는 댓글이 잘 담겨 있습니다. 여기에서는 CrUX BigQuery의 상세 표에서 가장 인기 있는 출처 10, 000개의 navigation_types 비율을 추출하는 쿼리에 관해서만 설명합니다.
- 여기서
all.202403
테이블에 액세스하고 (FROM
절 참고)phone
에 대해form_factor
를 필터링하고, 가장 인기 있는 상위 10,000개 출처에 대해 인기 순위 <= 10,000인 출처를 선택합니다 (WHERE
절 참고). - BigQuery에서
navigation_types
측정항목을 쿼리할 때는navigation_types
분수의 합계로 나누어야 합니다. 출처별로만 합쳐지고 (출처, 폼 팩터) 조합당 합산되지는 않기 때문입니다. - 모든 출처에
navigation_types
가 있는 것은 아니므로SAVE_DIVIDE
를 사용하는 것이 좋습니다.
WITH tmp AS (
SELECT
origin,
SUM(navigation_types.navigate.fraction) AS navigate,
SUM(navigation_types.navigate_cache.fraction) AS navigate_cache,
SUM(navigation_types.reload.fraction) AS reload,
SUM(navigation_types.restore AS restore,
SUM(navigation_types.back_forward.fraction) AS back_forward,
SUM(navigation_types.back_forward_cache.fraction) AS back_forward_cache,
SUM(navigation_types.prerender.fraction) AS prerender,
SUM(navigation_types.navigate.fraction
+ navigation_types.navigate_cache.fraction
+ navigation_types.reload.fraction
+ navigation_types.restore.fraction
+ navigation_types.back_forward.fraction
+ navigation_types.back_forward_cache.fraction
+ navigation_types.prerender.fraction) AS total
FROM
`chrome-ux-report.all.202403`
WHERE
experimental.popularity.rank <= 10000 AND
form_factor.name = 'phone'
GROUP BY
origin
)
SELECT
origin,
ROUND(SAFE_DIVIDE(navigate, total), 4) AS navigate,
ROUND(SAFE_DIVIDE(navigate_cache, total), 4) AS navigate_cache,
ROUND(SAFE_DIVIDE(reload, total), 4) AS reload,
ROUND(SAFE_DIVIDE(restore, total), 4) AS restore,
ROUND(SAFE_DIVIDE(back_forward, total), 4) AS back_forward,
ROUND(SAFE_DIVIDE(back_forward_cache, total), 4) AS back_forward_cache,
ROUND(SAFE_DIVIDE(prerender, total), 4) AS prerender
FROM
tmp
구체화된 테이블
요약이 충분하면 구체화된 테이블을 쿼리하는 것이 더 편리하고 비용도 저렴합니다. 예를 들어 다음 쿼리는 chrome-ux-report.materialized.device_summary
테이블에서 사용 가능한 navigation_types
데이터를 추출합니다. 이 표에는 월별, 출처, 기기 유형별로 키가 지정되어 있습니다.
SELECT
yyyymm,
device,
navigation_types_navigate,
navigation_types_navigate_cache,
navigation_types_reload,
navigation_types_restore,
navigation_types_back_forward,
navigation_types_back_forward_cache,
navigation_types_prerender
FROM
chrome-ux-report.materialized.device_summary
WHERE
origin = 'https://example.com' AND
navigation_types_navigate IS NOT NULL
ORDER BY
yyyymm DESC,
device DESC
이러한 분수의 합은 행당 1.0이 되지 않으므로 각 분수를 쿼리 해석의 대상인 결과의 합으로 나누어야 합니다.
그 이유는 히스토그램 밀도와 같은 chrome-ux-report.materialized.device_summary
의 navigation_type
분수가 날짜별 출발지 및 기기당이 아니라 출발지당 최대 1.0까지 더하기 때문입니다. 이를 통해 여러 기기에서 탐색 유형 분포를 확인할 수 있습니다.
SELECT
device,
navigation_types_back_forward
FROM
chrome-ux-report.materialized.device_summary
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202403
device |
navigation_types_back_forward |
---|---|
phone |
0.0663 |
desktop |
0.0179 |
tablet |
0.0009 |
이 쿼리 결과에서 비율은 원본 https://www.google.com
의 페이지 로드 비율을 나타냅니다. 이러한 페이지 로드 중 6.63% 는 탐색 유형이 back_forward
이고 데스크톱은 1.79%, 태블릿에서는 0.09% 입니다.
phone
에서 back_forward
비율이 상당히 높은 경우 bfcache에서 제공될 수 있도록 페이지 로드를 최적화해 볼 수 있습니다.
하지만 bfcache에서 이미 제공하는 페이지 로드의 비율, 즉 bfcache 적중률도 고려해야 합니다. 다음 쿼리는 이 특정 출처가 휴대전화 및 데스크톱에서 60% 를 초과하는 적중률을 고려할 때 이미 잘 최적화되었을 수 있음을 시사합니다.
SELECT
device,
navigation_types_back_forward_cache /
(navigation_types_back_forward + navigation_types_back_forward_cache)
AS back_forward_cache_hit_rate
FROM
chrome-ux-report.materialized.device_summary
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202403
device |
back_forward_cache_hit_rate |
---|---|
phone |
0.6239 |
desktop |
0.6805 |
tablet |
0.7353 |
따라서 휴대전화에서 back_forward
비율이 높은 것은 bfcache 사용이 감소하기 때문이 아니라 사용자가 휴대전화에서 앞뒤로 이동하는 방식을 더 많이 반영하기 때문입니다.
CrUX 대시보드의 탐색 유형
탐색 유형을 확인하는 가장 쉬운 방법은 이 링크를 통해 출처에 액세스할 수 있는 CrUX 대시보드를 사용하는 것입니다. 다음 스크린샷에서 볼 수 있듯이 처음에는 1개월 치의 데이터만 사용할 수 있지만 시간이 지나면서 기록이 채워져 매월 유형의 변경사항을 확인할 수 있습니다.
또한 보시다시피 대시보드 페이지 상단에는 최적의 탐색 방법을 제공하는 더 빠른 탐색 유형이 강조표시되어 있습니다.
결론
CrUX의 탐색 유형 분류가 사이트 성능을 이해하고 최적화하는 데 도움이 되기를 바랍니다. HTTP 캐싱, bfcache, 사전 렌더링을 효율적으로 사용하여 사이트에서 서버로 다시 이동해야 하는 페이지 로드보다 훨씬 빠른 페이지 로드를 달성할 수 있습니다.
또한 다양한 CrUX 액세스 포인트에서 데이터를 이용할 수 있게 되어 기쁩니다. 따라서 사용자는 원하는 방식으로 데이터를 사용하고 CrUX API에 노출되는 항목에 대한 URL별 유형 분석을 확인할 수 있습니다.
소셜 미디어 또는 CrUX 토론 그룹에서 CrUX 추가에 대한 의견을 보내주세요.