Core/Dash Измерение: Браузер

Измерение: Страница и Навигация: URLs (u)

Измерение Браузер группирует данные о производительности на основе строки User Agent, отправленной клиентом. Это позволяет проводить аудит производительности Core Web Vitals через призму конкретного программного обеспечения, выполняющего рендеринг вашего приложения (например, Chrome, Firefox, Safari, Edge, Samsung Internet).

Измерение Браузер изолирует программные ограничения, различия движков рендеринга (Blink, Gecko, WebKit) и совместимость сторонних скриптов.

RUM против CrUX

Понимание источника ваших данных важно для точного инженерного анализа.

• CrUX (Chrome User Experience Report): Этот набор данных собирает данные исключительно от пользователей Chrome (и некоторых производных Chromium), давших согласие на передачу данных. Он слепо исключает трафик из Firefox (движок Gecko) и Safari (движок WebKit).
• CoreDash RUM: Собирает данные из каждого браузера, который выполняет JavaScript сниппет.

Для многих веб-сайтов браузеры, отличные от Chrome, составляют 30-50% трафика. Полагаясь исключительно на CrUX, вы создаете слепую зону: вы оптимизируете для движка Google V8, пренебрегая движками SpiderMonkey (Firefox) и JavaScriptCore (Safari), используемыми огромным сегментом вашей аудитории.

Диагностика по конкретным метрикам

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

Interaction to Next Paint (INP)

Проблемы INP напрямую коррелируют с эффективностью движка JavaScript браузера и планированием основного потока.

• Firefox (SpiderMonkey): Firefox обрабатывает приоритеты задач иначе, чем Chrome. Тяжелый event listener, который проходит в Chrome, может вызвать заметную задержку ввода в Firefox из-за различий в том, как основной поток выполняет yield.
• Safari (JavaScriptCore): часто демонстрирует отличное поведение в отношении задержки «тапа» на мобильных устройствах. Логика гидратации, которая кажется мгновенной на Android (Chrome), может вызывать задержки на iOS из-за отличных моделей распространения событий.

Largest Contentful Paint (LCP)

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

• Согласование форматов: Если Chrome сообщает о быстром LCP, а Firefox отстает, проверьте вашу стратегию форматов изображений. Возможно, вы отдаете AVIF для Chrome, используя fallback на более тяжелые JPEG для старых версий браузеров, не имеющих поддержки.
• Подсказки приоритета: Chrome агрессивно учитывает fetchpriority="high". Браузеры, игнорирующие этот атрибут, обрабатывают ресурс LCP со стандартным приоритетом, искусственно завышая задержку загрузки.
• Протоколы соединения: Edge и Firefox могут по-разному согласовывать соединения HTTP/3 (QUIC) в корпоративных или ограниченных сетевых средах, влияя на компонент TTFB метрики LCP.

Cumulative Layout Shift (CLS)

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

• Рендеринг шрифтов (Gecko против Blink): Firefox (Gecko) и Chrome (Blink) рендерят базовые линии шрифтов и трекинг немного по-разному. Если вы не идеально сопоставите метрики вашего fallback шрифта, текстовый блок изменит размер при загрузке веб-шрифта, вызывая сдвиг в одном браузере, но не в другом.
• Резервирование полосы прокрутки: Браузеры Windows (Edge/Firefox/Chrome) резервируют физическое пространство для полос прокрутки, тогда как браузеры macOS накладывают их поверх. Это несоответствие часто вызывает сдвиги макета, основанные на ширине, которые невидимы при разработке на Mac, но заметны для пользователей Windows.

Рабочий процесс: Изоляция регрессий, специфичных для движка

Основной вариант использования этого измерения — «Валидация движка».

• Определите выброс: Отсортируйте таблицу Браузер по влиянию (Impact) или объему (Volume). Ищите конкретный браузер (например, Firefox Mobile), у которого оценка значительно хуже базовой (Chrome Mobile).
• Проверьте окружение: Убедитесь, связана ли проблема строго с браузером или с комбинацией браузера и ОС (например, Edge на Android против Edge на Windows).
• Отладка: Если Edge медленный, а Chrome быстрый (оба используют Blink), исследуйте сторонние расширения или корпоративное ПО безопасности, распространенное среди пользователей Edge, которое внедряет скрипты в DOM. Если Firefox медленный, проведите аудит CSS на наличие нестандартных свойств или layout thrashing, которые Gecko наказывает сильнее, чем Blink.

Устаревшие и встроенные браузеры

Используйте измерение Браузер для выявления факторов, снижающих производительность в «длинном хвосте».

In-App браузеры: Трафик из Instagram, LinkedIn или Facebook часто проходит через ограниченные WebViews, которые ведут себя иначе, чем нативный мобильный браузер.

Устаревшие версии: Вы можете обнаружить трафик от устаревших версий браузеров. Если они генерируют высокий INP, настройте инструменты сборки (Babel/PostCSS) так, чтобы отдавать необходимые полифилы, или, если объем незначителен, примите стратегическое решение прекратить поддержку, чтобы уменьшить размер бандла для современных пользователей.