이제 CrUX에서 탐색 유형을 사용할 수 있습니다.

Barry Pollard

Johannes Henkel

2024년 3월 데이터 세트부터 Chrome 사용자 환경 (CrUX) 보고서에 navigation_types 측정항목이 포함됩니다. 이는 쿼리된 측정기준에 대한 페이지 로드의 탐색 유형에 관한 집계된 통계를 제공합니다.

탐색 유형이 다르면 실적 측정항목도 달라집니다. 따라서 사이트의 실적을 살펴볼 때는 각 탐색 유형의 상대적인 빈도를 이해하는 것이 좋습니다. 예를 들어 내비게이션에서 백포워드 (bfcache)를 사용하는 경우 일반적으로 거의 즉각적인 탐색이 발생하고, 이는 매우 작은 LCP 및 FCP 측정항목과 줄어든 CLS 및 INP 측정항목에 반영됩니다.

탐색 유형 분석을 노출함으로써 Google은 사이트 소유자가 사이트에서 사용되는 탐색 유형을 더 잘 파악하고 캐싱 설정, bfcache 차단기 및 사전 렌더링을 살펴보며 더 빠른 유형을 장려할 수 있도록 장려하고자 합니다.

navigation_types 또한 이 기록이 있으면 사이트 소유자가 시간 경과에 따른 탐색 유형 사용의 변화를 확인할 수 있습니다. 이를 통해 개선사항을 추적할 수 있습니다 (예: bfcache 차단 제거). 또한 사이트에 변경사항이 없는 경우에도 측정항목의 변경사항을 설명하는 데 도움이 될 수 있습니다.

CrUX에서 어떤 탐색 유형을 사용할 수 있나요?

CrUX는 다음 표에서 다음과 같은 탐색 유형을 구분합니다.

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

CrUX 탐색 유형의 제한사항

CrUX는 공개 데이터 세트이므로 보고의 세밀도가 제한적입니다. 많은 출처 및 URL의 경우 요건을 충족하는 트래픽이 충분하지 않아 navigation_types 측정항목을 사용할 수 없습니다. 자세한 내용은 CrUX 방법을 참고하세요.

또한 CrUX는 CrUX에서 사용할 수 있는 출처와 URL의 수를 더 줄이기 때문에 탐색 유형별로 다른 측정항목을 분류할 수 없습니다.

사이트에서 자체 실시간 사용자 모니터링 (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 History Colab은 navigation_types 측정항목을 누적 막대로 표시합니다.

</ph>

위의 스크린샷에서 기록은 3가지 수집 기간 (각각 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의 통계적 상관관계가 밀접한 것이 나타났고 (p=0.87), back_forward_cache와 good_lcp_density 사이의 중간 상관관계가 나타났으며 (Re=0.29).

</ph>

이 분석을 위한 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

이 쿼리 결과에서 비율은 원본 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

따라서 휴대전화에서 높은 back_forward 비율은 bfcache 사용량이 적기 때문이 아니라 사용자가 휴대전화에서 앞뒤로 이동하는 방식을 반영한 것으로 보입니다.

CrUX 대시보드의 탐색 유형

탐색 유형을 확인하는 가장 쉬운 방법은 이 링크에서 출처에 액세스할 수 있는 CrUX 대시보드를 사용하는 것입니다. 다음 스크린샷에서 볼 수 있듯이 처음에는 1개월 치 데이터만 사용할 수 있지만 시간이 지나면 기록이 채워지면서 월 단위로 유형 변화를 확인할 수 있습니다.

</ph>

또한, 대시보드 페이지 상단에 빠른 탐색 유형, 즉 최적화를 추구해야 하는 탐색 유형이 강조 표시되어 있습니다.

결론

CrUX의 탐색 유형 분류가 사이트 성능을 이해하고 최적화하는 데 도움이 되기를 바랍니다. 사이트에서 HTTP 캐싱, bfcache, 사전 렌더링을 효율적으로 사용하도록 함으로써 서버로 다시 이동해야 하는 페이지 로드보다 훨씬 빠르게 페이지 로드를 달성할 수 있습니다.

또한 다양한 CrUX 액세스 포인트에서 데이터를 사용할 수 있도록 하여, 사용자가 원하는 대로 데이터를 사용하고 CrUX API에 노출된 항목에 대한 URL별 유형 분류를 확인할 수 있게 되어 기쁩니다.

소셜 미디어 또는 CrUX 토론 그룹에서 CrUX에 대한 의견을 알려주세요.