Инструменты, которые показывают данные, собранные в лабораторных условиях (Lab data или Имитация загрузки страницы) – данные собираются в контролируемой среде с заранее определённым устройством и настройками сети.
Инструменты, которые показывают данные, собранные в полевых условиях (Field data или Данные наблюдений) – данные собираются на основе реальных пользовательских визитов вашего сайта.

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

Вот пример отчёта PageSpeed Insights сайта web.dev, который показывает, что в некоторых случаях лабораторные и полевые данные могут отличать по всем показателям Core Web Vitals:

Различные значения в Lab и Field data по сайту web.dev

Посмотрим на примерах, почему это может происходить.

Лабораторные данные vs Полевые данные

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

Лабораторные данные

Лабораторные данные определяются путём загрузки веб-страницы в контролируемой среде с заранее определёнными настройками сети и устройства. Эти условия называются лабораторной или синтетической средой.

Инструменты Chrome, которые сообщают лабораторные данные, обычно работают на основе Lighthouse.

Читайте также: Google обновил Lighthouse до версии 8.4

Цель лабораторного теста – проконтролировать как можно больше факторов, чтобы результаты были (насколько это возможно) согласованными и воспроизводимыми.

Полевые данные

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

Полевые данные также известны как данные Мониторинга реальных пользователей или Real User Monitoring (RUM).

Инструменты Chrome, которые сообщают полевые данные, обычно получают их из отчёта Chrome User Experience Report (CrUX).

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

Если инструмент показывает одно число, то на самом деле это репрезентация конкретной одной точки в наборе данных. Инструменты, которые показывают полевые данные, используют значение 75-го процентиля. Это значит, что если по крайней мере 75 % просмотров страниц оцениваются, как просмотры с «хорошей» производительностью, метрика получает оценку «хорошо».

Посмотрите на метрику LCP из полевых данных на скриншоте:

Из распределения по цветам мы видим, что:

В 88 % посещений время LCP составляло 2,5 секунды или меньше (хорошо).
В 8 % посещений – между 2,5 и 4 секундами (требует улучшения).
В 4 % посещений LCP превышал 4 секунды (неудовлетворительно).

Но на 75-м процентиле LCP составлял 1,8 секунды.

Лабораторные данные с той же страницы показывают LCP 3,0 секунды:

Хотя это значение выше, чем 1,8 секунд, оно всё ещё справедливо для этой страницы. Оно означает, что в наборе данных по опыту загрузки страницы в том числе зафиксировано и значение в 3,0 секунды.

Почему лабораторные и полевые данные отличаются

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

Полевые включают обширный спектр состояний сети и типов устройств, а также оценивают поведение пользователей. Кроме этого они включают в себя любые другие факторы, влияющие на пользовательских опыт, например, оптимизацию браузера (вроде кеширования back-forward cache) и оптимизацию платформы (вроде AMP cache).

А лабораторные данные специально ограничивают количество задействованных переменных. При лабораторном тесте мы берём во внимание, что:

одно устройство;
подключено к единой сети;
из одного местоположения.

Сведения любого лабораторного теста не могут точно представивть реальные данные 75-го процентиля полевых данных для сайта или страницы.

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

Помимо этого между лабораторными и реальными условиями есть ряд более тонких различий. Рассмотрим возможные различия в следующих метриках Core Web Vitals:

Largest Contentful Paint (LCP).
First Input Delay (FID).
Cumulative Layout Shift (CLS).

Возможные отличия в LCP

Различные LCP-элементы

LCP-элемент, определённый в лабораторном тесте, может не совпадать с LCP-элементом, который пользователь видит при посещении вашей страницы.

LCP-элемент – это самый крупный видимый элемент в области просмотра. Метрика LCP оценивает время, за которое браузер отрисует этот элемент.

Если вы запустите Google Lighthouse, чтобы посмотреть отчёт по загрузке, он будет каждый раз загружать один и тот же LCP-элемент. Но если вы посмотрите на полевые данные, то увидите множество LCP-элементов для одной и той же страницы. Их определение зависит от ряда обстоятельств, специфичных для каждого посещения страницы.

Определению разных LSP-элементов могут способствовать:

разные размеры экрана – меняются области просмотра и в этих областях отображаются разные элементы;
отображается персонализированный контент – если пользователь зарегистрирован в системе или сайт иным образом персонализирует контент, то LCP-элемент может отличаться для разных пользователей;
на странице выполняется A/B-тест – отображаются разные элементы на странице для разных пользователей;
у пользователя в системе установлен особый набор шрифтов – влияет на размер текста на странице и следовательно на отображение элементов в области просмотра;
пользователи делятся URL-адресом, содержащим параметры запроса или хеш-фрагменты – из-за этого определённый лабораторно LCP-элемент может находиться в середине или внизу реальной области просмотра. Учитывая, что лабораторное исследование проводится на «чистом» URL, итоговые значения могут отличаться.

Представим, что у более чем 75 % пользователей LCP-элементом был абзац текста, отображаемый с помощью системного шрифта, и он загрузился очень быстро. В этом случае, даже если у 25 % пользователей LCP-элементом было большое медленно загружаемое изображение, определённое в лабораторных тестах, это может не повлиять на оценку страницы по метрике LCP в полевых данных.

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

Состояние кеша

Лабораторные тесты обычно загружают страницу с «холодным» кешем, но когда реальные пользователи посещают страницу, некоторые из её ресурсов могут быть уже кешированы.

«Холодный» кеш – пустой или содержащий устаревшие данные.

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

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

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

Оптимизация AMP или Signed Exchange (подписанные обмены)

Сайты, созданные с помощью AMP или Signed Exchange (SXG), могут быть предварительно загружены агрегаторами контента, такими как Google Поиск. Это может значительно повысить производительность у пользователей, посещающих ваши страницы с этих платформ.

Про подписанные обмены (Signed Exchange) в справке AMP

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

Лабораторные инструменты не могут имитировать такую оптимизацию. Даже если бы они это сделали, то не смогли бы точно рассчитать процент трафика, который на самом деле поступает на ваш сайт из Google Поиска по сравнению с другими источниками.

Back-forward cache (bfcache)

Когда страницы восстанавливаются из bfcache, загрузка происходит практически мгновенно, и эти действия отражаются на полевых данных.

Технология back-forward cache сохраняет страницу в памяти, даже если пользователь перешёл с неё на другую страницу. В этом случае при возвращении на страницу по кнопке «Назад» и «Вперёд» в браузере страницы загружаются быстро и показываются в том же состоянии, в каком пользователь их оставил.

Лабораторные тесты не учитывают bfcache, поэтому если он настроен, это приведёт к более хорошим показателям LCP в полевых данных.

Поведение пользователя

LCP определяет время рендеринга самого большого изображения или текстового блока в области просмотра. Но этот самый большой элемент может изменяться пока страница загружается или при динамическом добавлении нового контента в область просмотра.

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

Поэтому полевые данные могут сообщать о более высоком значении LCP, в зависимости от поведения пользователей.

Возможные отличия в FID

FID требует действий реальных пользователей

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

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

TBT и TTI не учитывают поведение пользователей

Лабораторные показатели, такие как общее время блокировки (TBT) и время до взаимодействия (TTI) , предназначены для помощи в диагностике проблем с FID, поскольку они количественно определяют, насколько основной поток блокируется пока страница загружается.

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

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

Когда пользователи решат взаимодействовать со страницей во многом зависит от того, выглядит ли страница так, что с ней можно взаимодействовать, или нет. Это нельзя измерить с помощью TBT или TTI.

TBT и TTI не учитывают задержку нажатия

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

Эта задержка засчитывается в FID страницы, потому что она способствует реальной задержке действия после нажатия, которую ощущают пользователи. Но поскольку эта задержка технически не является «Long Task», она не влияет на TBT или TTI страницы. Это означает, что страница может иметь плохой FID, несмотря на очень хорошие показатели TBT и TTI.

Чтобы избежать задержки, добавляйте метатег viewport в <head> страницы:

<meta name="viewport" content="width=device-width">

Состояние кеша и bfcache

Точно так же, как правильное кеширование может улучшить LCP в полевых данных, оно также может улучшить и FID.

В реальном мире JavaScript сайта может быть уже в кеше, поэтому его обработка займёт меньше времени и уменьшит задержку.

То же самое и для страниц, восстановленных из bfcache. В этих случаях JavaScript восстанавливается из памяти, поэтому время обработки может быть небольшим или вообще отсутствовать.

Возможные отличия в CLS

Поведение пользователя

CLS, измеренный в лабораторных условиях, учитывает только сдвиги макета, которые происходят «выше линии сгиба» (на первом экране) и в процессе загрузки. Но на CLS фактически влияет не только это.

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

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

Персонализированный контент

Персонализированный контент, включая таргетированную рекламу и A/B-тесты, влияет на то, какие элементы загружаются на странице. Такой контент часто загружается позже и вставляется в основной контент страницы, вызывая сдвиги макета.

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

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

Состояние кеша и bfcache

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

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

Что делать, если вы видите разные результаты в Lab и Field

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

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

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

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