이제 CrUX에서 LCP 이미지 하위 요소 및 RTT를 사용할 수 있습니다.

Barry Pollard

Johannes Henkel

게시: 2025년 2월 11일

2025년 2월에 출시된 Chrome 사용자 환경 보고서(CrUX)에는 다음과 같은 새로운 통계와 변경된 통계가 포함되어 있습니다.

• 최대 콘텐츠 렌더링 시간 (LCP) 이미지 하위 요소 및 리소스 유형
• 왕복 시간 (RTT) 세부정보
• 효과적인 연결 유형 (ECT) 측정기준 삭제

각각 CrUX에서 제공되는 출처 및 URL의 실적 측정항목에 대한 더 많은 유용한 정보를 제공하며 이 게시물에서는 그 이유를 자세히 설명합니다.

LCP 진단 정보

Google에서는 이미지 LCP가 있는 페이지의 LCP 시간을 더 작은 구성요소로 분류하여 높은 LCP의 정확한 원인을 최적화하는 데 노력을 집중할 수 있도록 Google I/O 2022에서 LCP 하위 요소의 개념을 처음으로 도입했습니다.

이 강의에서 HTTP 보관 파일 실험실 데이터를 분석한 결과, 이미지 다운로드 시간이 LCP 시간 중 가장 짧은 경우가 많았습니다. Google의 자체 Lighthouse를 비롯한 많은 실험실 도구는 다운로드 시간을 줄이고 성능을 개선하기 위해 이미지 형식과 크기를 최적화하라는 조언에 집중했습니다. 여전히 올바르지만 분석 결과 이 조언이 과도하게 강조되었을 수 있으며 더 큰 문제는 브라우저에서 이미지를 찾아 다운로드하기 시작하기까지의 지연이라고 합니다.

실험실 데이터를 분석하는 것도 유용하지만 실제 웹 사용 방식은 종종 다를 수 있으므로 필드 데이터의 이러한 하위 부분을 확인할 수 있어야 합니다. 작년에 게시된 게시물에서 현장 데이터를 사용한 LCP 최적화 방법에 대한 일반적인 오해가 확인되었습니다.

LCP 이미지 하위 부분

이번 출시를 통해 사이트 소유자는 출처 또는 URL 수준에서 자체 사이트의 이미지 LCP 하위 부분을 확인할 수 있습니다.

하위 부분은 이미지에만 사용할 수 있으며 첫 번째 동영상 프레임 이미지는 포함되지 않습니다 (전체 다운로드 시간을 측정할 수 없어 약간 더 복잡함). 텍스트 하위 요소는 유용성이 떨어지고 이미지 LCP 숫자를 왜곡할 수 있으므로 포함되지 않습니다. 텍스트 LCP로 구성된 사이트의 경우 전반적인 TTFB 및 전반적인 FCP 측정항목이 유용합니다. 단, 이러한 측정항목은 모든 LCP에 적용되며 텍스트 LCP에만 국한되지 않습니다. 마지막으로 이미지 하위 요소는 전체 페이지 로드 시만 수집됩니다. 뒤로/앞으로 탐색 및 사전 렌더링된 페이지에서도 수집되는 LCP 측정항목 자체와는 다릅니다.

이 데이터는 2025년 2월부터 CrUX API 및 CrUX History API에 추가되었습니다 (BigQuery는 아님). CrUX History API는 출시 시 2주간의 데이터를 보유하고 있으며 시간이 지남에 따라 25주간의 전체 기록으로 늘어납니다. API는 각 하위 부분의 75번째 백분위수(밀리초 단위)로 데이터를 제공합니다.

예를 들어 PHONE 페이지 조회수의 https://web.dev/에 대한 LCP 이미지 하위 부분을 가져오려면 다음 curl 명령어를 사용하면 됩니다 (API_KEY를 자체 키로 대체).

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "formFactor": "PHONE",
            "url": "https://web.dev/",
            "metrics": [
              "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"]}'

다음과 같은 내용이 표시됩니다.

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://web.dev/"
    },
    "metrics": {
      "largest_contentful_paint_image_element_render_delay": {
        "percentiles": {
          "p75": 2088
        }
      },
      "largest_contentful_paint_image_resource_load_delay": {
        "percentiles": {
          "p75": 828
        }
      },
      "largest_contentful_paint_image_resource_load_duration": {
        "percentiles": {
          "p75": 417
        }
      },
      "largest_contentful_paint_image_time_to_first_byte": {
        "percentiles": {
          "p75": 2385
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2025,
        "month": 1,
        "day": 12
      },
      "lastDate": {
        "year": 2025,
        "month": 2,
        "day": 8
      }
    }
  }
}

이 데이터를 포함하도록 CrUX Vis 도구를 업데이트했으며 CrUX API를 사용하는 다른 서드 파티 도구에서도 이 중요한 데이터를 노출할 것으로 예상됩니다.

CrUX Vis의 LCP 이미지 하위 부분

이 예에서는 인기 있는 미디어 사이트의 경우 리소스 로드 시간이 가장 작은 구성요소임을 알 수 있습니다. 이 사이트의 실질적인 개선 기회는 TTFB 및 리소스 로드 지연에 있으며 요소 렌더링 지연에는 그다지 개선의 여지가 없습니다.

각 하위 부분의 값이 높으면 다음과 같은 다양한 문제가 있음을 나타냅니다.

• 첫 바이트 소요 시간 (TTFB)이 길면 일반적으로 TTFB 최적화에 설명된 대로 서버, 네트워크 또는 리디렉션 문제가 있는 것입니다.
• 리소스 로드 지연이 높으면 브라우저에서 LCP 이미지를 늦게 발견했음을 나타냅니다. 예를 들어 실행하는 데 시간이 걸리는 클라이언트 측 JavaScript에 의해 삽입된 LCP 이미지가 여기에 해당합니다.
• 리소스 로드 시간이 긴 경우 이미지 다운로드 크기를 줄여야 합니다.
• 요소 렌더링 지연이 높은 경우 이미지를 사용할 수 있지만 (<link rel=preload>를 통해서일 수 있음) 오랫동안 사용되지 않습니다. 이는 이미지를 표시하는 데 클라이언트 측 JavaScript가 필요하기 때문입니다.

핵심사항: 이미지 하위 요소는 여러 페이지 조회에서 집계된 데이터를 나타내므로 75번째 백분위수로 제공되므로 하위 요소의 합계가 전체 LCP 75번째 백분위수와 같을 것으로 예상되지 않습니다. LCP 이미지 하위 요소는 75번째 백분위수 LCP 값의 정확한 분류가 아닌 상대적 하위 요소 중요성을 나타내는 데 사용해야 합니다.

이 데이터를 CrUX에서 출처 및 URL 수준 (일반적인 자격 기준 적용)에서 모두 사용할 수 있게 되면 사이트에서 LCP 측정항목을 더 쉽게 최적화할 수 있기를 바랍니다.

LCP 리소스 유형

하위 부분은 이미지 LCP에 가장 적합하므로 CrUX는 이 데이터를 이미지가 있는 페이지로만 제한합니다. 따라서 텍스트 LCP (예: <h1> 제목 및 긴 단락)가 아닌 이미지 LCP가 얼마나 있는지 파악하는 것이 중요합니다.

이제 CrUX API에는 LCP 이미지 하위 부분 외에도 텍스트와 이미지 간의 LCP 페이지 로드 분할을 보여주는 리소스 분류도 포함됩니다.

예를 들어 PHONE 페이지 조회수의 https://web.dev/에 대한 LCP 리소스 유형을 가져오려면 다음 curl 명령어를 사용하면 됩니다 (API_KEY를 자체 키로 바꾸기).

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "formFactor": "PHONE",
            "url": "https://web.dev/",
            "metrics": ["largest_contentful_paint_resource_type"]}'

다음과 같은 내용이 표시됩니다.

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://web.dev/"
    },
    "metrics": {
      "largest_contentful_paint_resource_type": {
        "fractions": {
          "image": 0.0155,
          "text": 0.9845
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2025,
        "month": 1,
        "day": 12
      },
      "lastDate": {
        "year": 2025,
        "month": 2,
        "day": 8
      }
    }
  }
}

이 데이터를 표시하도록 CrUX Vis도 업데이트되었습니다.

CrUX Vis의 LCP 리소스 유형

예를 들어 web.dev의 홈페이지의 경우 LCP의 98.5% 가 실제로 텍스트 LCP이므로 이 페이지에는 LCP 이미지 하위 파트가 덜 유용합니다. 이 경우 원래 TTFB 및 FCP 측정항목을 더 나은 진단 분석으로 사용할 수 있습니다.

중요: LCP 리소스 유형에는 이미지 분수에 동영상이 포함됩니다. 동영상의 첫 번째 프레임이 애니메이션 이미지와 마찬가지로 LCP에 반영되기 때문입니다. 하지만 LCP 이미지 하위 요소는 실제 이미지 요소에만 적용됩니다. 동영상 스트리밍의 경우 리소스 다운로드 시간을 계산하기가 조금 더 까다로우므로 현재는 포함되지 않습니다. 이와 비슷한 이유로 리소스 유형은 전체 페이지 로드 시만 수집됩니다. 뒤로/앞으로 탐색 및 사전 렌더링된 페이지에서도 수집되는 LCP 측정항목 자체와는 다릅니다.

LCP 리소스 유형은 LCP를 이해하고 개선하는 데 유용한 또 다른 진단 도구로, 특히 LCP 이미지 하위 부분이 얼마나 유용한지 파악하는 데 유용합니다.

RTT 진단 정보

또한 2024년 8월에 처음 도입된 RTT 측정항목을 확장했습니다.

RTT 3개 빈

CrUX API에 RTT 밀도의 세 가지 그룹을 보여주는 삼중 빈이 추가되었습니다.

네트워크 지연 시간	시작	종료
낮음	0밀리초	75밀리초 미만
보통	75밀리초	275밀리초 미만
높음	275밀리초	∞

이러한 빈은 270밀리초 미만의 모든 항목을 4g 카테고리에 포함했던 이전 ECT 카테고리보다 더 많은 정보를 제공합니다. 이러한 카테고리가 출시된 이후 네트워킹 기술이 발전함에 따라 대부분의 사이트에서 해당 카테고리의 트래픽이 대부분을 차지하게 되어 이러한 분류가 덜 유용하게 되었습니다.

핵심사항: 왕복 시간은 사이트 자체가 아닌 사용자의 최근 인터넷 활동을 기반으로 사용자와 사이트 간의 네트워크 연결을 측정한 값입니다.

따라서 일반적인 양호, 개선 필요, 나쁨 라벨 대신 낮음, 중간, 높음 분포 라벨을 사용하는 것이 좋습니다. 사이트 소유자가 직접 개선할 수 있는 측정항목이 아니므로 다른 측정항목을 이해하고 예상과 다를 수 있는 이유를 파악하기 위한 진단 측정항목입니다. 또한 사용자 기반의 변화를 보여주는 경우 사이트가 변경되지 않았음에도 불구하고 시간이 지남에 따라 다른 측정항목이 이동하는 이유를 설명하는 데 도움이 될 수 있습니다.

이러한 빈은 CrUX API에서 사용할 수 있습니다 (예: PHONE 페이지 조회수의 경우 web.dev). 다시 한번 API_KEY를 자체 키로 바꿉니다.

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "formFactor": "PHONE",
            "url": "https://web.dev/",
            "metrics": ["round_trip_time"]}'

다음과 같은 결과가 반환됩니다.

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://web.dev/"
    },
    "metrics": {
      "round_trip_time": {
        "histogram": [
          {
            "start": 0,
            "end": 75,
            "density": 0.1524
          },
          {
            "start": 75,
            "end": 275,
            "density": 0.6641
          },
          {
            "start": 275,
            "density": 0.1835
          }
        ],
        "percentiles": {
          "p75": 230
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2025,
        "month": 1,
        "day": 12
      },
      "lastDate": {
        "year": 2025,
        "month": 2,
        "day": 8
      }
    }
  }
}

분포를 선택하면 CrUX Vis에 구간이 표시됩니다.

CrUX 시각화의 RTT 데이터

BigQuery의 RTT

CrUX API의 RTT 측정항목을 삼중 빈을 포함하도록 확장했을 뿐만 아니라 원시 테이블의 25밀리초 버킷에 전체 히스토그램, 구체화된 테이블의 삼중 빈 및 p75 값을 포함하여 월별 BigQuery 데이터 세트에서 데이터를 사용할 수 있도록 했습니다.

이를 통해 CrUX API에서 제공되는 3개 빈을 넘어 데이터 분포를 더 자세히 파악할 수 있습니다. 또한 이번 달부터 CrUX에서 삭제된 ECT 분석 (자세한 내용은 나중에 설명)을 다시 만들 수 있습니다. 이전의 270밀리초 기준점 대신 4g의 기준점을 275밀리초로 약간 변경했습니다. ECT 분석 (이제 RTT 데이터에서 가져옴)은 CrUX BigQuery 구체화 테이블에서 계속 사용할 수 있으므로 CrUX 대시보드와 같은 도구에서 계속 이 분석을 표시할 수 있습니다.

BigQuery 데이터 세트에는 국가 (ISO 3166-1에 정의됨)별 데이터도 포함됩니다. 이를 통해 더 심층적인 분석을 수행할 수 있으며, 이는 일부 사용자의 실적 측정항목이 더 나쁜 이유를 설명하는 데 유용할 수 있습니다. 예를 들어 https://www.google.com의 데이터를 확인하여 Google 휴대전화 사용자의 데이터를 확인할 수 있습니다.

SELECT
  `chrome-ux-report`.experimental.GET_COUNTRY(country_code) AS geo,
  least(500, p75_rtt) AS capped_p75_rtt,
  p75_rtt
FROM
  `chrome-ux-report.materialized.country_summary`
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202501 AND
  device = 'phone'
ORDER BY
  p75_rtt DESC,
  country_code

그런 다음 지역 지도에 데이터를 시각화합니다.

https://www.google.com
의 국가별 전화 RTT 75번째 백분위수(대화형 차트가 포함된 소스 데이터).

전 세계 대부분의 지역 (특히 '서구 세계')에서는 RTT가 매우 우수한 반면, 사하라 이남 아프리카, 중동 일부 지역, 아시아 일부 지역에서는 RTT가 더 좋지 않은 것으로 나타났습니다. 전체 데이터를 사용하면 색상이 왜곡되므로 그래프는 RTT 500밀리초로 제한됩니다. 특히 에리트레아의 경우 75번째 백분위수인 3,850밀리초로 색상이 왜곡됩니다.

트래픽 패턴이 변경될 때도 유용할 수 있습니다. 예를 들어 RTT가 더 높은 국가의 사용자가 더 많은 비율을 차지하면 사이트에 아무런 변경사항이 없더라도 핵심 웹 Vitals 통계가 악화될 수 있습니다.

사이트에서 RTT를 직접 개선할 수는 없지만 사이트 방문자가 이 데이터를 사용할 수 있도록 하면 전 세계 사이트 사용자를 더 잘 이해할 수 있습니다. 또한 향후 분석할 기회가 많아질 것으로 기대되며 연구원들이 이 데이터 세트에서 흥미로운 통계를 발견하기를 바랍니다.

ECT 측정기준 삭제

2025년 2월 출시의 마지막 변경사항은 BigQuery에서 유효 연결 유형(ECT) 측정기준이 지원 중단된다는 점입니다. 대체 측정항목인 RTT를 도입할 때 이미 2024년 9월부터 API에서 RTT가 삭제되었습니다.

이 게시물에서 앞서 언급한 것처럼 RTT 측정항목을 사용하면 사이트 방문자의 연결 세부정보를 더 세부적으로 확인할 수 있습니다. 이러한 히스토그램에서 ECT 버킷을 다시 만들 수도 있습니다. (기술적으로 ECT는 RTT와 다운링크 속도의 조합이어야 하지만 Chrome에서는 항상 RTT만 사용했습니다.)

중요한 차이점은 ECT가 CrUX 측정기준이었다는 점입니다. 즉, 다른 측정항목을 ECT로 분류할 수 있었습니다. RTT는 측정기준이 아닌 CrUX 측정항목이므로 예를 들어 RTT별로 LCP를 확인할 수는 없고 다른 측정기준 (기기 유형 및 국가)별로 RTT만 확인할 수 있습니다.

제한적으로 들릴 수 있지만 측정기준에서 측정항목으로 전환하면 실제로 CrUX에서 더 많은 데이터를 사용할 수 있습니다. CrUX에 데이터를 표시하기 위한 특정 최소 기준점이 있기 때문입니다. 이미 2022년에 측정기준을 선택사항으로 설정했습니다. 즉, 더 높은 수준에서 보고하는 데 필요한 경우 ECT 또는 기기를 삭제했지만 대부분의 페이지 로드에 포함되지 않은 측정항목 (다음 페인트까지의 상호작용 (INP), 다양한 탐색 유형, 이제 LCP 이미지 하위 요소)은 BigQuery의 출처에서 자주 사용할 수 없었습니다.

차원 수를 줄이면 데이터가 덜 세분화되므로 이러한 최소 요구사항을 충족하는 출처 수가 늘어납니다. 1월에는 출처의 68.1% 에 대해 INP를 보고했지만 12월 데이터 세트의 경우 출처의 64.5% 에 대해서만 INP를 보고했습니다. 이 메커니즘은 이 버전의 탐색 유형, LCP 하위 요소, 리소스 유형에도 적용되며, 모두 ECT 측정기준이 삭제되어 이점을 얻습니다. CrUX API에서는 2월 초부터 적용 범위가 확대되었습니다.

ECT 열은 이전 데이터 세트와의 일관성을 위해 BigQuery에 유지되며, 구체화된 뷰의 ECT 데이터는 계속 사용할 수 있지만 새 RTT p75 및 트리 빈 외에도 RTT 정보 (이전에 언급한 대로 3g 및 4g의 경우 5밀리초 차이)를 기반으로 합니다.

결론

공개 CrUX 데이터 세트에 측정항목이 추가되면 사이트 소유자와 연구원이 성능 문제를 진단하고 궁극적으로 해결하는 데 도움이 되는 더 많은 정보를 얻을 수 있습니다.

CrUX는 공개 데이터 세트이므로 표시할 수 있는 세부정보 수준에 몇 가지 제한사항이 있습니다. 예를 들어 개별 요소 선택기는 CrUX에 표시할 수 없습니다. 이 정도의 세부정보를 원하는 사이트 소유자는 제약이 덜한 RUM 솔루션을 구현하는 것이 좋습니다.

하지만 이 게시물에 설명된 것과 같은 상위 수준의 집계된 데이터는 문제가 있다는 것을 아는 것과 문제가 발생한 이유를 파악하는 것 사이의 격차를 해소하는 데 도움이 될 수 있습니다. 이 추가 데이터가 유용하게 활용되기를 바랍니다. 의견이나 질문이 있으면 토론 그룹에 알려주세요.