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

Barry Pollard
Johannes Henkel

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는 다음 표에서 다음과 같은 탐색 유형을 구분합니다.

유형 설명
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 측정항목을 누적 막대로 표시합니다.

3주 동안의 탐색 유형 기록을 보여주는 누적 막대 그래프로, 대부분의 탐색이 '탐색' 유형이며 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 간의 강력한 통계적 상관관계 (r=0.87)와 back_forward_cache와 good_lcp_density (r=0.29) 간의 중간 정도의 상관관계가 있었습니다.

인스턴트 페이지 로드 비율과 bfcache 페이지 로드 비율 간의 강력한 상관관계를 보여주는 상관관계 차트
인스턴트 페이지 로드와 bfcache 사용량의 상관관계

이 분석을 위한 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 대시보드를 사용하는 것입니다. 다음 스크린샷에서 볼 수 있듯이 처음에는 1개월 치의 데이터만 사용할 수 있지만 시간이 지나면서 기록이 채워져 매월 유형의 변경사항을 확인할 수 있습니다.

한 달 치의 데이터를 보여주는 CrUX 대시보드의 탐색 유형 배포 화면 스크린샷.
CrUX 대시보드의 탐색 유형

또한 보시다시피 대시보드 페이지 상단에는 최적의 탐색 방법을 제공하는 더 빠른 탐색 유형이 강조표시되어 있습니다.

결론

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

또한 다양한 CrUX 액세스 포인트에서 데이터를 이용할 수 있게 되어 기쁩니다. 따라서 사용자는 원하는 방식으로 데이터를 사용하고 CrUX API에 노출되는 항목에 대한 URL별 유형 분석을 확인할 수 있습니다.

소셜 미디어 또는 CrUX 토론 그룹에서 CrUX 추가에 대한 의견을 보내주세요.