📖 약 6분 읽기

사이트가 느리다는 민원이 들어왔는데, 정작 우리 쪽 테스트 환경에서는 멀쩡하게 잘 열립니다. 담당자 입장에서는 답답한 순간입니다. 개발팀은 “우리 쪽에서는 문제없다”고 하고, 광고팀은 “랜딩페이지가 무겁다는 얘기를 들었다”고 하고, 정작 그 차이를 숫자로 보여줄 방법은 마땅치 않았습니다. 이 간극을 메워 온 것이 CrUX(Chrome User Experience Report)입니다. 구글이 2017년부터 운영해 온 이 데이터셋은 설치하는 도구가 아니라 조회하는 공개 자료이고, 도메인 하나만 있으면 내 사이트든 경쟁사 사이트든 값을 받아 볼 수 있습니다. 2026년 9월 15일부터는 여기에 광고 경험 지표 4종이 더해지면서, 그동안 SEO·개발 담당자의 영역으로만 여겨지던 이 데이터가 광고·퍼블리싱 실무자에게도 필요한 자료가 됐습니다.

이 데이터를 제대로 활용하려면 먼저 CrUX가 어떤 성격의 데이터인지, 무엇을 담고 있었고 이번에 무엇이 늘었는지, 그리고 실제로 어떻게 값을 꺼내 보는지 순서대로 짚어 두는 것이 필요합니다. 태그 관리와 측정 체계를 오래 다뤄 온 실무자 시각에서, 이 데이터를 처음 접하는 분들도 바로 조회까지 이어갈 수 있도록 정리했습니다.

CrUX는 정확히 무엇인가

CrUX는 Chrome User Experience Report, 우리말로는 ‘크롬 사용자 경험 보고서’입니다. 이름 그대로 크롬 브라우저 이용자들이 실제로 웹사이트를 열었을 때 얼마나 빨랐는지, 얼마나 매끄러웠는지를 익명으로 모아 구글이 공개하는 데이터셋입니다.

가장 먼저 짚어 둘 것은 이것이 프로그램이 아니라는 점입니다. 서버에 태그를 심을 필요도, 스크립트 한 줄을 추가할 필요도 없습니다. 크롬이 이미 데이터를 모아 두었고, 우리는 그 값을 조회하기만 하면 됩니다. GA4나 서치콘솔처럼 계정을 만들고 트래킹 코드를 설치해야 값이 쌓이는 도구와는 출발선이 다릅니다.

세 가지 성격을 알아야 숫자를 오해하지 않는다

CrUX 값을 처음 보면 “이게 왜 우리 내부 지표랑 다르지”라는 의문이 자연스럽게 듭니다. 그 이유는 CrUX가 갖는 세 가지 성격에 있습니다.

첫째, 실사용자 데이터(RUM)입니다. 웹 성능을 재는 방법은 크게 둘로 나뉩니다. 하나는 랩 데이터로, 정해진 사양의 테스트 장비에서 페이지를 열어 점수를 매기는 방식입니다. 라이트하우스 점수가 여기 해당하고, 조건이 일정하니 비교하기는 좋지만 실제 이용자가 겪는 상황과는 거리가 있을 수 있습니다. CrUX는 반대쪽에 있습니다. 지하철에서 오래된 안드로이드폰으로 접속한 사람, 사무실 유선망에서 데스크톱으로 접속한 사람이 전부 섞여 들어갑니다. 그래서 “우리 테스트에서는 빨랐는데 고객은 느리다고 한다”는 간극을 설명해 주는 쪽은 랩 데이터가 아니라 CrUX입니다.

둘째, 공개 데이터셋입니다. 사이트 소유권을 증명할 필요가 없습니다. 도메인만 알면 자사 사이트든 경쟁사 사이트든 매체사 사이트든 동일하게 조회됩니다. 서치콘솔이나 GA4처럼 내 사이트 값만 볼 수 있는 도구와 결정적으로 다른 지점이 여기입니다. 광고 지면을 검토할 때 상대 매체가 제시한 자료에만 의존하지 않고, 공개된 값으로 직접 대조해 볼 수 있다는 뜻이기도 합니다.

셋째, 개인별 값이 아니라 집계값입니다. 도메인 또는 URL 단위로 묶이고, 평균이 아니라 75번째 백분위수로 보고됩니다. 전체 방문의 75%가 이 값 이하였다는 뜻입니다. 극소수의 아주 빠른 접속이 전체 지표를 좋아 보이게 만드는 왜곡을 막으려는 설계이니, “대체로 이 정도는 나온다”는 감각으로 읽으시면 됩니다.

여기에 조건이 하나 붙습니다. 데이터가 잡히려면 일정 수준 이상의 트래픽이 필요합니다. 방문이 적은 사이트나 개별 URL은 조회해도 값이 비어 있는 경우가 흔한데, 이는 사이트에 문제가 있어서가 아니라 표본이 모자라기 때문입니다. 신규 오픈한 랜딩페이지나 방문이 적은 서브 도메인을 조회했을 때 값이 안 나온다면 우선 이 가능성부터 확인하시는 것이 좋습니다.

원래 담고 있던 것 — 코어 웹 바이탈

CrUX의 중심에는 구글이 코어 웹 바이탈이라 부르는 세 지표가 자리하고 있습니다.

• LCP — 화면에서 가장 큰 콘텐츠가 그려지기까지 걸린 시간입니다. 이용자가 체감하는 로딩 속도와 가장 가깝습니다.
• INP — 이용자가 버튼을 누르거나 무언가를 입력했을 때 화면이 반응하기까지의 지연입니다. 예전에 쓰이던 FID를 대체한 지표입니다.
• CLS — 읽는 도중 레이아웃이 밀리는 정도입니다. 버튼을 누르려는 순간 광고가 갑자기 밀고 들어와 엉뚱한 곳을 누르게 만드는, 그 불편함을 수치로 잡아냅니다.

이 세 지표는 구글 검색 랭킹 신호에도 반영됩니다. 그래서 CrUX는 오랫동안 SEO 담당자와 웹 개발자가 주로 들여다보는 데이터였고, 마케팅이나 애드옵스 쪽에서는 이름은 들어 봤어도 자기 업무와 직접 연결해 본 경험은 드물었습니다.

2026년 9월, 광고 지표가 새로 들어왔다

이번에 추가된 것이 바로 그 연결 고리입니다. 광고 경험 지표 네 가지가 CrUX에 편입됐습니다.

• Ad Count — 화면에 한 번에 보이는 광고의 평균 개수입니다.
• Ad Density — 화면 면적 가운데 광고가 차지하는 평균 비율입니다.
• Ad Weight(Network) — 광고를 불러오느라 쓴 데이터량(KB)입니다. 이용자의 데이터 요금과 직결되는 부분입니다.
• Ad Weight(CPU) — 광고를 그리고 실행하느라 쓴 처리 시간(ms)입니다. 기기가 버벅이는 정도로 이해하면 됩니다.

측정 대상은 ads.txt에 승인 판매자가 등재된 사이트로 한정됩니다. ads.txt는 이 사이트의 광고를 누가 팔 자격이 있는지 적어 둔 공개 파일로, 광고 사기를 막기 위해 업계가 채택한 표준입니다. 여기에 등재되지 않은 사이트는 애초에 측정 대상에서 빠지기 때문에, 값이 안 나온다고 해서 그 사이트의 광고가 가볍다는 의미는 아닙니다.

한 가지 더 주의할 부분이 있습니다. CPU 지표는 메인 프레임에서 실행되는 광고 스크립트는 제외하고, 광고 컨테이너 안쪽에서 일어나는 처리 비용만 잡습니다. 즉 실제 부하보다 작게 나올 가능성이 있다는 뜻이라, 절대값 자체보다는 사이트 간 비교나 시점에 따른 변화 추이로 읽는 편이 안전합니다.

네 지표 모두 아직 실험 단계라는 점도 함께 기억해 두어야 합니다. 코어 웹 바이탈에 포함되지 않고, 검색 랭킹 신호도 아니며, 구글이 권장 임계값을 제시하지도 않았습니다.

어떻게 조회하나 — 쉬운 순서로 넷

개념을 알았다면 이제 직접 값을 꺼내 볼 차례입니다. 진입 장벽이 낮은 순서대로 네 가지 경로가 있습니다.

1. PageSpeed Insights에 주소를 넣는다. pagespeed.web.dev에 도메인을 입력하면 화면 위쪽 ‘실제 사용자 환경에서 확인된 데이터’ 영역이 바로 CrUX입니다. 별다른 준비물 없이 링크 하나로 확인할 수 있어, CrUX가 어떤 데이터인지 감을 잡는 데 가장 빠른 방법입니다. 다만 이 화면은 코어 웹 바이탈 중심으로 구성되어 있어 새로 추가된 광고 지표는 바로 보이지 않을 수 있습니다.

2. 크롬 개발자도구의 Ad 패널로 재 본다. 페이지를 열고 F12(맥은 ⌥⌘I)로 개발자도구를 연 뒤 Ad 패널에서 그 페이지의 광고 개수·밀도·무게를 확인합니다. 공개 CrUX 값이 75번째 백분위수 집계인 것과 달리, 이 방법은 지금 내 기기에서의 실측이라 두 값은 서로 다를 수 있습니다. 랜딩페이지 몇 개를 빠르게 훑어볼 때 유용합니다.

3. CrUX API로 도메인 값을 받아 온다. 무료 키를 발급받아 도메인 단위로 조회합니다. 자사 도메인과 주요 매체사 도메인을 나란히 놓고 비교할 때 쓰는 경로입니다.

API_KEY="발급받은_키"

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{"origin": "https://example.co.kr"}'

한 번에 하나의 도메인 또는 URL만 조회됩니다. “formFactor”: “PHONE”을 넣으면 모바일만 따로 볼 수 있고, 값은 DESKTOP / PHONE / TABLET 세 가지로 구분됩니다. 데이터가 없으면 404가 돌아오는데, 대개는 트래픽이 기준에 못 미친 경우입니다.

4. BigQuery로 대량 비교한다. 여러 개 도메인을 한 번에 비교하거나 시간에 따른 추이를 뽑아 볼 때 씁니다. SQL로 조회하며, CrUX 데이터셋 자체는 공개지만 쿼리 스캔량에 따라 GCP 과금이 발생합니다. 광고 지표의 BigQuery 제공은 아직 예고 단계이므로, 지금 시점에서는 2번과 3번 경로가 현실적인 선택지입니다.

읽기 전에 알아 둘 것

숫자를 받아 들었을 때 바로 목표치를 세우기보다, 아래 몇 가지 전제를 먼저 확인하는 것이 순서에 맞습니다.

• 광고 지표 4종은 실험 단계입니다. 코어 웹 바이탈에 포함되지 않고 검색 랭킹 신호도 아닙니다.
• 구글이 권장 임계값을 제시하지 않았습니다. “몇 % 이하가 좋다”는 기준이 아직 없으니, 지금은 목표를 세우기보다 현재 값을 기록해 두고 변화를 지켜보는 쪽이 맞습니다.
• ads.txt에 판매자가 등재되지 않은 사이트는 측정 대상에서 빠집니다.
• 국내 사이트가 이 지표에 어느 정도 잡히는지는 아직 확인되지 않았습니다. 자사와 고객사 도메인을 직접 조회해 보는 것이 먼저입니다.
• 데이터 커버리지는 발표 후 시간이 지나며 점차 넓어질 예정이라고 밝혀져 있습니다.

실무에서 어디에 쓸 수 있나

퍼블리셔 입장이라면 자기 지면의 광고 밀도와 무게를 협상 자리에 감이 아니라 공개 데이터로 올릴 수 있습니다. 광고주 입장이라면 매체 제안서를 받아 놓고, 그 매체 도메인을 브라우저가 공개한 값으로 직접 대조해 볼 수 있습니다. 데이터 담당자라면 기존에 운영하던 웹 성능 리포트에 광고 무게라는 축을 하나 더 얹는 정도로 시작할 수 있습니다. 어느 쪽이든 공통점은, 조회 자체에는 비용이 들지 않는다는 점입니다.

비즈스프링(BizSpring Inc.)과 인트렌치컨설팅(Entrench Consulting Inc.)은 태그 관리와 측정 체계를 다뤄 왔습니다. 사이트에 어떤 스크립트가 얼마나 실려 있는지 목록이 정리되어 있다면, 공개된 CrUX 값과 대조해 어느 스크립트가 무게를 만드는지 좁혀 나가는 작업이 한결 수월해집니다. 아직 임계값이 없는 실험 지표인 만큼, 당장 목표를 세우기보다 현재 값을 한 번 기록해 두고 시간에 따른 변화를 지켜보는 것이 지금 시점에서는 현실적인 출발점으로 보입니다.

출처 :

• Chrome for Developers, 「New ad metrics in Chrome User Experience Report」 (2026-09-15) — developer.chrome.com/blog/crux-ad-metrics
• Chrome for Developers, 「How to use the CrUX API」 — developer.chrome.com/docs/crux/guides/crux-api
• Chrome for Developers, 「Ad measurement」 — developer.chrome.com/docs/ads
• PPC Land, 「Chrome puts publishers’ ad loads on public record with 4 new metrics」 — ppc.land
• Search Engine Land, 「Google Chrome launches new metrics to measure ad-heavy websites」 — searchengineland.com