Насколько быстр веб? Исследуйте миллиарды измерений реальных пользователей с помощью BEACON28.09.2026 17:43

Если вы работаете в сфере технологий, то, скорее всего, читаете этот текст на мощном ноутбуке или флагманском смартфоне через надежный и молниеносный Wi-Fi. Это великолепно для создания программного обеспечения, но зачастую очень далеко от реальности, с которой сталкиваются многие пользователи этого софта.

Конечные пользователи могут пользоваться четырехлетним бюджетным телефоном, страдать от низкого заряда батареи, сидеть на тарифном плане, ограничивающем скорость после 2 ГБ, жить в условиях недостаточно развитой общественной инфраструктуры или просто зайти в тот угол спортзала, где Wi-Fi почему-то никогда не работает. Умножьте это на миллиарды людей по всему миру, и разрыв между «работает на моем компьютере» и «работает для всех» начнет увеличиваться, искажая важнейшие решения, касающиеся нашего выбора технологий и приоритетов.

Устранение этого разрыва в восприятии с помощью объективных данных лежит в основе нашей миссии — помогать строить лучший Интернет, быстрый и доступный для каждого, а не только для тех из нас, кто использует лучшее железо.

Именно поэтому сегодня мы делимся представлением о том, как реальные люди воспринимают веб, опубликовав набор данных Cloudflare BEACON — Browser Experience Across Cloudflare’s Observed Network (опыт работы с браузерами в наблюдаемой сети Cloudflare). Cloudflare собирает такую телеметрию уже много лет от имени наших клиентов, предоставляя им специфическое для каждого клиента детальное понимание того, как реальные пользователи воспринимают их сайты. Сегодня мы открываем этот обзор для всех.

BEACON — это анонимизированный набор данных, созданный на основе миллиардов измерений производительности в реальных условиях на 10 000 крупнейших сайтов нашей сети. Он охватывает все основные движки браузеров, ежедневно обновляется в Google BigQuery и использует стандарты, определенные созданным силами сообщества проектом RUM Archive, общедоступной базой данных мониторинга реальных пользователей (RUM). Увеличивая охват этого проекта в 100 раз, BEACON предоставляет исследователям беспрецедентный взгляд на производительность веб-сайтов в различных браузерах, на разных устройствах и в разных странах.

Что раскрывает BEACON

Основные показатели эффективности работы сайта (Core Web Vitals) уже давно стали де-факто стандартом для измерения воспринимаемой производительности в интернете, и BEACON сообщает обо всех трех:

• Largest Contentful Paint (LCP): время загрузки
• Cumulative Layout Shift (CLS): визуальная стабильность
• Interaction to Next Paint (INP): отзывчивость на взаимодействие

Поскольку мы публикуем их в виде полных гистограмм, а не единичных средних значений, вы можете получить любой интересующий вас перцентиль. Вместо того чтобы останавливаться на P75 (75-й перцентиль), вы можете изучить «хвост» распределения (long tail) и увидеть, где индустрия все еще испытывает трудности с обеспечением быстрой работы для всех.

Кто сталкивается с более медленным интернетом?

Core Web Vitals для P90 в iOS и Android.

WebKit, в настоящее время единственный движок браузера на iOS, в целом показывает лучшие результаты по этим метрикам, однако это преимущество не является универсальным. В 46 странах, где доля WebKit превышает 10% трафика, его показатели LCP, INP или оба параметра как минимум на 10% хуже, чем у браузеров на базе Blink, таких как Chrome, Edge и Opera. Например, в Камбодже на долю WebKit приходится 17,5% просмотров страниц, но его LCP на 50% хуже, чем у Blink.

BEACON также включает классификацию доменов по отраслям из нашего API Intel. Категории «Правительство и политика», «Здравоохранение» и «Безопасно для детей» выделяются как категории с высокой производительностью, в то время как «Реклама», «Религия» и «Погода» обычно показывают худшие результаты:

Запрос для таблицы выше, сохраненный в BigQuery как «CWVs by Industry».

Дополнительные перцентили выявляют различия, которые скрывает единственный результат P75. В ряде отраслей самые медленные варианты использования резко уходят в «хвост» распределения, особенно в отношении визуальной стабильности, измеряемой с помощью Cumulative Layout Shift.

Что заставляет страницы казаться медленными?

BEACON расширяет стандарт RUM Archive подкомпонентами LCP и INP, которые разделяют этапы загрузки и отклика на взаимодействие. В ближайшие недели мы также добавим эти метрики в нашу панель мониторинга реальных пользователей (RUM). Их агрегирование в предложенные пороги «Хорошо» («Good»), «Требует улучшения» («Needs Improvement») и «Плохо» («Poor») помогает точнее определить, что именно нуждается в оптимизации:

Запрос для таблицы выше и другие запросы для всех данных сохранены в BigQuery под названием «Global LCP Sub-parts», так что вы можете настроить их по своему усмотрению.

Результаты ставят под сомнение распространенное предположение: скачивание самого ресурса, такого как изображение, шрифт или видео, как правило, вносит наименьший вклад в воспринимаемое время загрузки. Для большинства просмотров страниц, преодолевающих порог «Хорошо», основные возможности кроются в обнаружении кандидата LCP (время загрузки) и разблокировании его рендеринга. Клиенты Cloudflare могут решить некоторые проблемы с задержками обнаружения ресурсов с помощью функции Smart Hints.

Аналогичным образом метрика Interaction to Next Paint (INP), наш показатель отзывчивости, разбивается на задержку ввода, время обработки и задержку представления:

Запрос для таблицы выше сохранен в BigQuery как «Global INP Sub-parts»

Для самых медленных взаимодействий время выполнения JavaScript занимает наибольший период, однако мы также наблюдаем значительный рост времени представления, в котором обычно доминируют сложные перерасчеты макета CSS. Клиенты Cloudflare могут использовать такие инструменты, как Zaraz, чтобы снизить влияние стороннего JavaScript на производительность.

Как архитектура приложения меняет картину

Говоря о JavaScript, мы недавно добавили поддержку нового API мягких навигаций (Soft Navigations API) от Google Chrome, который обеспечивает точный отчет LCP для навигаций на стороне клиента, широко используемых в одностраничных приложениях (SPA), созданных на таких фреймворках, как React, Vue, Angular и Svelte.

Запрос для таблицы выше сохранен в BigQuery как «Blink — Hard vs Soft Navigations»

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

Запрос для таблицы выше сохранен в BigQuery как «Blink — Landing Pages»

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

Что исследователи могут открыть, объединяя данные?

Поскольку BEACON — это открытый набор данных, его ценность не ограничивается содержащимися в нем полями. Исследователи могут объединять его с другими источниками для изучения новых вопросов. Например, объединение BEACON с данными Группы Всемирного банка по ВВП на душу населения показывает, как экономические условия соотносятся с производительностью сайтов в разных странах:

Запрос для таблицы выше, сохраненный в BigQuery как «Country-level Performance Aggregates».

Cloudflare Radar, наша платформа публичной аналитики и визуализации данных, начнет использовать этот подход в новом разделе «Веб-производительность» на Radar, где будут представлены результаты сопоставления данных индекса качества интернета (IQI) с данными BEACON. IQI представляет собой агрегацию данных бенчмаркинга производительности, на основе которых формируются наши отчеты о производительности сетей, выходящие два раза в год.

Соединение BEACON и IQI представляет особый интерес, так как оно разделяет пользовательский опыт на два наиболее влиятельных компонента: производительность посещаемого сайта и производительность сети доступа (eye-ball network), через которую пользователь на него заходит. Оба фактора влияют на скорость загрузки страницы, а вместе они определяют, покажется ли посещение сайта мучительным или бесшовным.

Первичный анализ показывает, что эти два показателя имеют тенденцию двигаться синхронно: хорошая веб-производительность обычно совпадает с хорошим качеством сети, и наоборот. На графиках выше видно, что чем выше пропускная способность, тем быстрее воспринимаемое время загрузки (LCP). Например, в Европе пропускная способность выше по сравнению с другими континентами, в то время как LCP в целом выше на нижнем уровне.

Связь между пропускной способностью и LCP была ожидаемой, но при сравнении IQI с размером передаваемых данных мы обнаружили нечто удивительное. Можно было бы ожидать, что объем передаваемых данных будет одинаковым на всех континентах — в конце концов, контент сайтов обычно тот же самый. Тем не менее, в Африке объем передаваемых данных заметно меньше, что говорит о меньшем количестве контента, загружаемого этими пользователями. Хотя мы не можем быть уверены в причине, данные IQI показывают, что в Африке ниже пропускная способность сети, что наводит на мысль о том, что местный бизнес адаптирует свои веб-сайты для оптимизации с учетом ограничений сетевых условий. Высококачественные сети доступа также потенциально более снисходительны к плохо оптимизированным сайтам, в то время как медленные сети усугубляют узкие места. Каждая из этих гипотез может стать направлением для будущего анализа.

В новом разделе «Веб-производительность» будет исследовано, насколько распространены эти паттерны и, в частности, как часто одна составляющая пользовательского опыта сводит на нет достижения другой. Следите за нашими успехами на Radar.

Со временем мы будем добавлять новые метрики и измерения, и мы приветствуем запросы о том, какие данные вы хотели бы увидеть в следующем обновлении.

Как мы обрабатываем все эти данные и делаем их полезными

Анонимизация

Публикация набора данных реального мира в таком масштабе влечет за собой ответственность за конфиденциальность. Наш продукт Real User Monitoring (RUM) изначально создавался с приоритетом конфиденциальности, а для BEACON мы также удаляем любые потенциальные идентификаторы сайтов клиентов, такие как доменное имя и пути URL. В конечном итоге сообщество получает ценную аналитику без ущерба для доверия людей и стоящих за ними компаний.

Нормализация

Для основной таблицы включение всех сайтов из наших данных привело бы к одной из двух проблем:

1. Крупнейшие сайты доминировали бы в данных по объему трафика, смещая показатели производительности в сторону их архитектуры, профилей посетителей и т. д., либо:
2. Если бы мы вместо этого нормировали каждый сайт до объема трафика наименьшего сайта, это радикально сократило бы общее количество записей в данных.

Эти две крайности сделали необходимым ограничить набор данных наибольшим числом крупнейших веб-сайтов в нашей сети, чтобы обеспечить максимальное разнообразие архитектур, технологий, географии и многого другого при сохранении общего количества маячков (beacon) после нормализации. Мы сочли 10 000 оптимальным балансом: это репрезентативная для всего мира выборка с достаточным объемом на 10 000-м месте, при котором в случае нормализации данных до этого уровня общий набор данных все равно коллективно представляет миллиарды ежедневных записей.

Агрегация

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

Как получить доступ и внести свой вклад

BEACON общедоступен в Google BigQuery. Мы включили запросы для всех данных, представленных в этой статье, в качестве примеров, которые вы можете адаптировать для собственного анализа, а сайт RUM Archive также содержит дополнительную документацию.

Нам очень интересно узнать, что вы обнаружите. Поделитесь своими выводами на нашем форуме сообщества или в Discord.

BEACON позволяет изучать производительность веб-сайтов в масштабе и с таким уровнем географического разнообразия и разнообразия браузеров, который ранее был недоступен общественности. Мы надеемся, что исследователи, разработчики браузеров, программисты и группы по разработке стандартов будут использовать его для выявления слабых мест интернета и содействия обеспечению быстрого доступа к нему для всех.

Отдельная благодарность участникам программы стажировки Cloudflare 1,111. Этого не произошло бы без упорного труда двух наших замечательных летних стажеров, которые довели первоначальную идею до того, что вы видите сегодня. Их вклад сыграл ключевую роль в запуске этого проекта. Спасибо, Чисара Дуру и Тон Чжоу!

© Cloudflare Blog