Рекламные метрики CrUX: как измерять Ad Density, CPU и сетевую нагрузку

На контентном сайте реклама часто попадает в общий список подозреваемых, когда мобильная версия начинает тормозить. Но до недавнего времени спор быстро упирался в довольно примитивные аргументы: «у нас всего три блока», «баннеры маленькие» или «PageSpeed ругается на сторонний JavaScript».

Chrome предлагает более предметный подход.

15 сентября 2026 года Chrome User Experience Report получил четыре экспериментальные рекламные метрики:

Ad Count — сколько рекламных элементов пользователь в среднем одновременно видит во viewport.

Ad Density — какую часть видимой области занимает реклама.

Ad Weight: CPU — сколько процессорного времени потребляют рекламные frames.

Ad Weight: Network — сколько сетевых данных загружают рекламные ресурсы.

Это field data реальных пользователей Chrome, агрегированные через CrUX. Одновременно Chrome DevTools получил локальные инструменты, позволяющие перейти от вопроса «почему рекламная нагрузка высокая?» к конкретному frame, script или ресурсу.

Но есть важное ограничение: это не новые Core Web Vitals и не опубликованные ranking factors.

Chrome описывает их как экспериментальные показатели рекламного опыта. Для них нет официальных порогов Good, Needs Improvement или Poor.

Поэтому число вроде Ad Density = 23 нельзя превращать в универсальный диагноз «плохо». Значение полезно в сравнении: между страницами, устройствами, периодами и версиями рекламной реализации.

Четыре метрики отвечают на четыре разных вопроса

Ad Count: сколько рекламы реально находится перед пользователем

Chrome не просто считает количество рекламных слотов в HTML.

Во время посещения браузер раз в секунду делает sample viewport и определяет, сколько отдельных рекламных элементов находится в видимой области. Если хотя бы один пиксель рекламного элемента попадает во viewport, он учитывается в Count для этого sample.

Затем значения усредняются за сессию пользователя.

Это особенно важно для длинных статей.

На странице физически может находиться восемь рекламных блоков, но пользователь никогда не видит их одновременно. С другой стороны, sticky-реклама способна сопровождать читателя почти всё время и заметно влиять на среднее значение.

Поэтому Ad Count описывает не число рекламных мест в шаблоне, а опыт просмотра страницы.

Ad Density: сколько экрана занимает реклама

Density отвечает уже не на вопрос «сколько элементов?», а «какую часть того, что видит пользователь, занимает реклама?».

Chrome каждую секунду рассчитывает отношение видимой площади рекламных элементов к площади viewport и усредняет эти значения за сессию. Перекрывающиеся рекламные площади при расчёте Density не учитываются дважды. Если реклама видна частично, измеряется только находящаяся внутри viewport часть.

Поэтому два сайта с одинаковым Ad Count могут иметь совершенно разный опыт.

На одном одновременно видны два небольших блока.

На другом — те же два элемента, но один занимает половину экрана.

Count одинаковый. Density — нет.

Ad Weight: CPU: сколько вычислений забирает реклама

CPU metric суммирует JavaScript CPU execution time рекламных frames и их subresources за жизнь посещения страницы и публикуется в миллисекундах.

Здесь есть техническая деталь, которую легко потерять: текущая CrUX CPU-метрика измеряет ad frames и не включает CPU time рекламных scripts, выполняющихся непосредственно в main frame.

Поэтому нельзя интерпретировать значение как абсолютно весь CPU, который бизнес рекламной системы создаёт на странице.

Для поиска конкретных main-frame scripts как раз полезна локальная диагностика DevTools.

Ad Weight: Network: сколько данных загружает реклама

Network Weight — суммарный объём compressed wire bytes, переданных при загрузке рекламных ресурсов: scripts, изображений, stylesheets и других связанных файлов. Метрика измеряется на протяжении посещения и публикуется в килобайтах.

Это помогает отделить ситуацию:

«реклама мешает потому, что занимает экран»

от другой:

«реклама почти незаметна визуально, но тянет большой объём JS и media».

Для мобильного пользователя на слабой сети второй сценарий может оказаться не менее важным.

Если сайт в целом долго загружается, полезно не сводить диагностику только к рекламе: тяжёлыми могут быть изображения, собственный JavaScript, шрифты, тема и сторонние виджеты. Это отдельно разобрано в материале «Медленный сайт: 15 частых причин и что делать».

Почему Chrome использует p75

CrUX не публикует среднее значение всех пользовательских сессий как итоговый site metric.

Для рекламных показателей используется 75-й процентиль.

Если Ad Density на p75 равен определённому значению, это означает, что 75% учтённых сессий получили такое значение или ниже, а оставшиеся 25% — выше. Тот же принцип применяется к Count, CPU и Network.

Это важно для интерпретации.

p75 — не «типичный средний посетитель».

Это граница, ниже которой находится 75% распределения.

Такой подход помогает не строить отчёт вокруг случайного экстремального визита, но одновременно показывает опыт значительной части аудитории ближе к тяжёлому краю распределения.

Именно поэтому сравнивать собственный единичный DevTools test с CrUX p75 один к одному нельзя.

Один — lab measurement конкретного прогона.

Другой — агрегированные реальные посещения.

Как Chrome вообще понимает, что является рекламой

Chrome использует собственную ad detection logic.

Ресурс или frame может быть классифицирован как рекламный, если запрос совпадает с правилами filter list или был инициирован из JavaScript stack уже распознанного рекламного script. Frame после получения ad classification сохраняет её и для последующих ресурсов внутри себя.

Main frame страницы рекламным frame не считается, хотя отдельные subresources внутри него могут классифицироваться как ad-related.

Это полезно помнить по двум причинам.

Во-первых, Chrome измеряет не то, что издатель вручную пометил классом .advertisement.

Во-вторых, результат может отличаться от внутренней системы учёта рекламных slots.

Для диагностики классификации в DevTools можно:

• подсветить распознанную рекламу;
• посмотреть Ad Status конкретного frame;
• включить колонку Is ad-related в Network;
• найти ad adorner у элемента.

Как Chrome собирает рекламные метрики

Chrome начинает сбор рекламных метрик, когда получает первые байты основного HTML-документа.

Дальше механика расходится.

Для Count и Density браузер раз в секунду делает snapshot видимой области.

Для CPU и Network значения накапливаются непрерывно в течение активной сессии.

Измерение заканчивается при выгрузке страницы: hard navigation, закрытии вкладки или завершении браузера. На Android сбор также прекращается, если приложение Chrome уходит в background.

Если вкладка просто становится фоновой, sampling приостанавливается и после возврата пользователя продолжается. Picture-in-Picture Chrome для этой телеметрии игнорирует.

Есть интересное следствие для SPA: soft navigation сейчас не сбрасывает окно измерения рекламных метрик. Данные разных client-side views продолжают накапливаться в рамках жизни вкладки до hard navigation или закрытия. Chrome отдельно пишет, что это поведение в будущем, вероятно, изменится.

Это важное ограничение при анализе очень долгоживущих SPA.

Почему для публикации данных нужен ads.txt

Локальный Chrome способен увидеть рекламу и показать Ads metrics в DevTools даже на сайте без ads.txt.

Для публичного CrUX reporting правила строже.

Chrome объясняет это качеством ad detection: в агрегированную рекламную отчётность включаются сайты, которые публикуют в ads.txt хотя бы одного authorized seller. Origins без ads.txt и варианты только с placeholder record исключаются.

Одновременно продолжают действовать обычные требования eligibility самого CrUX.

Поэтому ситуация:

«DevTools видит рекламу, а CrUX API не возвращает ad metrics»

вполне возможна.

Это не обязательно ошибка API.

Сначала нужно проверить:

CrUX eligibility → ads.txt → authorized seller → достаточность данных.

И ещё одно ограничение: Chrome учитывает для этих метрик только страницы с рекламой.

Где смотреть field data

На старте Chrome предоставляет несколько способов.

CrUX Vis

CrUX Vis подходит для визуального мониторинга без собственной интеграции.

Он показывает исторические тенденции rolling 28-day periods, обновляется еженедельно и позволяет переключаться между origin- и URL-level и устройствами.

Это хороший вариант, если нужно быстро проверить:

«нагрузка по рекламе становится тяжелее или легче?»

CrUX API

Через API можно получить актуальный 28-дневный snapshot.

Ключи новых метрик:

experimental_ad_density
experimental_ad_count
experimental_ad_cpu
experimental_ad_kilobytes

Для origin запрос может выглядеть так:

{
  "origin": "https://example.com",
  "metrics": [
    "experimental_ad_density",
    "experimental_ad_count",
    "experimental_ad_cpu",
    "experimental_ad_kilobytes"
  ]
}

Для конкретной страницы вместо origin используется url. API возвращает значения p75.

Это уже удобно для собственного мониторинга: можно сохранять значения и отслеживать регресс после изменения рекламного стека.

CrUX History API

History API нужен, когда интересен тренд.

Он возвращает историю rolling 28-day aggregations и подходит для проверки эффекта релиза во времени.

На момент публикации Chrome ещё работает над добавлением этих метрик в CrUX BigQuery dataset. Поэтому не стоит писать инструкцию, будто рекламные поля уже гарантированно доступны там.

Field data отвечает «что происходит», DevTools — «почему»

В октябрьском обновлении DevTools Chrome добавил централизованный Ads sub-panel в Application panel.

Он показывает:

• локальные Viewport ad density и count;
• total CPU usage by ads;
• total network usage by ads;
• разбивку CPU и Network по рекламным элементам;
• таблицу ad scripts в main frame;
• переключатель визуальной подсветки рекламы.

Это и есть мост между field и lab.

CrUX может показать, что мобильные пользователи сайта получают большой Network Weight.

Но CrUX не скажет редактору:

«вот этот конкретный creative загрузил столько-то лишнего контента».

Для этого открывается конкретная страница в DevTools.

Дополнительно в Network можно включить колонку Is ad-related, а в Application → Frames посмотреть причину классификации frame как рекламы.

Практический сценарий: RTB-реклама тормозит мобильный медиасайт

Представим контентный проект с длинными статьями и RTB.

Редакция видит жалобы: на мобильном страница открывается нормально, но во время чтения интерфейс периодически тормозит, появляются дополнительные запросы, а аккумулятор расходуется заметно быстрее.

Первое желание — удалить один рекламный блок.

Но это пока догадка.

Сначала смотрим CrUX

Открываем рекламные метрики на уровне origin и, если доступны данные, для основных шаблонных URL.

Предположим, картина такая:

• Count выглядит относительно стабильным;
• Density тоже не выделяется;
• CPU заметно тяжелее на phone;
• Network также вырос относительно предыдущих периодов.

Это ещё не доказывает, какой партнёр или creative виноват.

Но направление уже понятно:

проблема, скорее всего, не в количестве видимых рекламных блоков как таковом, а в ресурсном весе рекламной системы.

Затем воспроизводим страницу

Открываем статью на мобильном профиле, запускаем реальную рекламную загрузку и переходим:

DevTools → Application → Ads.

Проверяем, какие рекламные frames Chrome распознал и как распределяются CPU и network resources.

Если один элемент заметно выделяется, продолжаем диагностику его ресурсов.

В Network включаем Is ad-related.

В таблице ad scripts смотрим main-frame scripts рекламного стека.

Так вместо:

«RTB тормозит сайт»

получаем:

«вот этот рекламный путь создаёт существенную вычислительную или сетевую нагрузку».

Меняем только одну существенную переменную

Например, разработчик:

• откладывает конкретный слот;
• уменьшает количество refresh;
• меняет problematic creative handling;
• исключает ненужного рекламного партнёра;
• меняет момент инициализации определённого script.

Здесь важно не одновременно переписать всю рекламную систему.

Иначе через неделю будет невозможно понять, что именно дало эффект.

Сразу проверяем DevTools

Локальные метрики позволяют не ждать несколько недель, чтобы увидеть, стало ли конкретное поведение легче.

Повторяем сопоставимый сценарий.

Если CPU конкретного элемента снизился, Network уменьшился, а реклама продолжает нормально работать — у нас появляется техническое подтверждение, что изменение хотя бы локально решает нужную проблему.

При этом обязательно проверяем обычные показатели страницы: рекламная оптимизация не должна ломать layout, пользовательские действия или основной контент.

Если проблема шире рекламного стека, имеет смысл включить её в полноценный технический аудит сайта, а не пытаться объяснить все задержки одной рекламной сетью.

И только потом ждём field confirmation

CrUX использует rolling 28-day window.

Поэтому сегодняшний релиз не должен завтра полностью изменить полевой p75.

Более того, состав пользователей, рекламы, creatives, устройств и сетей в реальности меняется.

Поэтому нормальная проверка выглядит так:

field проблема
→
локальное воспроизведение
→
конкретная причина
→
точечная правка
→
локальная перепроверка
→
следующие CrUX периоды.

Не наоборот.

Почему нельзя оптимизировать только одну из четырёх метрик

Каждая метрика показывает только часть рекламного опыта.

Можно сократить Count, объединив несколько маленьких slots в один огромный sticky-блок. Count улучшится, а Density — станет хуже.

Можно уменьшить визуальную Density, оставив тяжёлый невидимый рекламный script. Пользователь увидит меньше рекламы, но CPU и Network не обязательно улучшатся.

Можно оптимизировать Network через более лёгкие creatives, но оставить тяжёлую JavaScript-аукционную логику.

Поэтому правильная единица анализа — профиль рекламной нагрузки, а не одна цифра.

Он отвечает на четыре разных вопроса:

сколько → сколько места → сколько CPU → сколько сети.

После этого уже проверяются LCP, INP, CLS и другие показатели пользовательского опыта.

Новые метрики не заменяют Core Web Vitals

CrUX ad metrics и Core Web Vitals могут быть связаны причинно на конкретном сайте, но это не одно и то же.

Например, тяжёлый ad script может блокировать main thread и косвенно ухудшить responsiveness.

Поздно появившийся рекламный slot способен вызвать layout shift.

Большая реклама в начале статьи может конкурировать за сеть с LCP-ресурсом.

Но из самого факта высокого experimental_ad_cpu нельзя автоматически вывести значение INP.

И наоборот: плохой INP не доказывает, что виновата реклама.

Именно поэтому Chrome отдельно оставляет эти показатели вне Core Web Vitals и не задаёт для них CWV-подобные пороги.

Диагностика должна связывать метрики через конкретный trace или воспроизводимый сценарий, а не через предположение.

У новых метрик пока есть важные ограничения

Во-первых, они experimental. Chrome прямо предупреждает, что методика может меняться на основании обратной связи.

Во-вторых, публичный field reporting зависит от CrUX eligibility и корректного ads.txt.

В-третьих, CPU metric не покрывает CPU-время main-frame ad scripts, поэтому локальный Ads panel остаётся важным дополнением.

В-четвёртых, обычный JavaScript RUM сейчас не может просто воспроизвести эти измерения самостоятельно: cross-origin iframes, через которые часто работает реклама, создают ограничения, и Chrome не предоставляет эквивалентный JS API для этих метрик.

В-пятых, SPA сейчас накапливает рекламные показатели через soft navigations в рамках одной жизни вкладки.

И наконец, отсутствие официального threshold означает, что отраслевой совет:

«Ad Density выше X — плохо»

нельзя выдавать за рекомендацию Chrome, если Chrome такого порога не публиковал.

Как я бы использовал CrUX ad metrics в рабочем проекте

Не как ещё четыре KPI для красивого dashboard.

И не как цель «снизить всё до нуля».

У контентного проекта реклама существует по бизнес-причине. Смысл оптимизации — найти точку, где монетизация не создаёт лишнюю техническую нагрузку.

Поэтому рабочая модель такая:

CrUX показывает, что получают реальные пользователи.

URL-level comparison помогает определить проблемные шаблоны.

DevTools Ads находит конкретные элементы и scripts.

Performance/Network подтверждают механизм задержки.

Релиз меняет одну управляемую причину.

CrUX History показывает, закрепился ли эффект в полевых данных.

Так новая отчётность действительно помогает разработчику.

Не отвечает на абстрактный вопрос:

«много ли у нас рекламы?»

а позволяет сформулировать технически полезный:

«какая именно часть рекламной системы создаёт визуальную, процессорную или сетевую нагрузку у реальных пользователей и что можно изменить, не ломая монетизацию?»