Узнайте, почему инструменты, отслеживающие показатели Core Web Vitals, могут сообщать разные цифры и как интерпретировать эти различия.
Google предоставляет ряд инструментов , которые помогут владельцам сайтов отслеживать свои показатели Core Web Vitals . Эти инструменты делятся на две основные категории:
- Инструменты, передающие лабораторные данные — данные, собранные в контролируемой среде с предопределенными настройками устройства и сети.
- Инструменты, которые сообщают данные полей — данные, собранные от реальных пользователей, посещающих ваш сайт.
Проблема в том, что иногда данные, полученные с помощью лабораторных инструментов, могут существенно отличаться от данных, полученных с помощью полевых инструментов! Данные вашей лаборатории могут указывать на то, что ваш участок работает отлично, но данные ваших полевых работ говорят о том, что он нуждается в улучшении. Альтернативно, ваши полевые данные могут говорить о том, что все ваши страницы хороши, но ваши лабораторные данные могут указывать на очень низкую оценку.
Следующий реальный пример отчета PageSpeed Insights от web.dev показывает, что в некоторых случаях лабораторные и полевые данные могут различаться по всем показателям Core Web Vitals:
Различия между инструментами — понятный источник путаницы для разработчиков. В этом посте объясняются основные причины, по которым могут существовать эти различия (с конкретными примерами, охватывающими каждый из показателей Core Web Vitals), а также что делать, если вы обнаружите различия на своих страницах.
Лабораторные данные и полевые данные
Чтобы понять, почему лабораторные и полевые инструменты могут сообщать разные значения (даже для одной и той же веб-страницы), вам необходимо понять разницу между лабораторными и полевыми данными.
Лабораторные данные
Лабораторные данные определяются путем загрузки веб-страницы в контролируемой среде с заранее определенным набором условий сети и устройства. Эти условия известны как лабораторная среда, иногда ее также называют синтетической средой.
Инструменты Chrome, которые сообщают лабораторные данные, обычно работают под управлением Lighthouse .
Целью лабораторного теста является контроль как можно большего количества факторов, чтобы результаты были (насколько это возможно) последовательными и воспроизводимыми от запуска к запуску.
Данные поля
Полевые данные определяются путем мониторинга всех пользователей, посещающих страницу, и измерения заданного набора показателей эффективности для каждого индивидуального опыта этих пользователей. Поскольку полевые данные основаны на посещениях реальных пользователей, они отражают фактические устройства, условия сети и географическое расположение ваших пользователей.
Полевые данные также широко известны как данные реального мониторинга пользователей (RUM) ; эти два термина взаимозаменяемы.
Инструменты Chrome, которые сообщают данные полей, обычно получают эти данные из отчета об опыте пользователя Chrome (CrUX) . Владельцам сайтов также часто (и рекомендуется) самостоятельно собирать полевые данные, поскольку это может дать более полезную информацию , чем простое использование CrUX.
Самое важное, что нужно понимать о полевых данных, — это то, что это не просто одно число, это распределение чисел. То есть у некоторых людей, посещающих ваш сайт, он может загружаться очень быстро, а у других – очень медленно. Полевые данные вашего сайта — это полный набор всех данных о производительности, полученных от ваших пользователей.
В качестве примера отчеты CrUX показывают распределение показателей производительности реальных пользователей Chrome за 28-дневный период. Если вы посмотрите практически на любой отчет CrUX, вы увидите, что некоторые пользователи, посещающие сайт, могут иметь очень хорошие впечатления, в то время как другие могут иметь очень плохие впечатления.
Если инструмент сообщает одно число для данного показателя, оно обычно представляет собой определенную точку распределения. Инструменты, сообщающие об оценках полей Core Web Vitals, делают это с использованием 75-го процентиля .
Глядя на LCP по полевым данным на скриншоте выше, вы можете увидеть распределение, где:
- В 88% посещений LCP составляло 2,5 секунды или меньше (хорошо).
- В 8% посещений время LCP составляло от 2,5 до 4 секунд (нужно улучшить).
- В 4% посещений LCP длился более 4 секунд (плохое значение).
На 75-м процентиле LCP составила 1,8 секунды:
Лабораторные данные с той же страницы показывают значение LCP, равное 3,0 секунды. Хотя это значение превышает 1,8 секунды, показанные в данных поля, оно по-прежнему является допустимым значением LCP для этой страницы — это одно из многих значений, которые составляют полное распределение нагрузки.
Почему лабораторные и полевые данные различаются
Как поясняется в приведенном выше разделе, лабораторные и полевые данные на самом деле измеряют совершенно разные вещи.
Полевые данные включают в себя широкий спектр состояний сети и устройств, а также множество различных типов поведения пользователей. Сюда также входят любые другие факторы, влияющие на взаимодействие с пользователем, такие как оптимизация браузера, такая как обратный/прямой кеш (bfcache), или оптимизация платформы, такая как кеш AMP .
Напротив, лабораторные данные намеренно ограничивают количество задействованных переменных. Лабораторное исследование состоит из:
- Одно устройство…
- подключены к единой сети…
- запускаться из одного географического местоположения.
Подробности любого лабораторного теста могут или не могут точно отражать 75-й процентиль полевых данных для данной страницы или сайта.
Контролируемая среда лаборатории полезна при отладке проблем или тестировании функций перед развертыванием в рабочей среде, но когда вы контролируете эти факторы, вы явно не отражаете различия, которые вы видите в реальном мире для всех типов сетей, возможностей устройств или географические местоположения. Вы также, как правило, не фиксируете влияние на производительность реального поведения пользователя, такого как прокрутка, выбор текста или нажатие элементов на странице.
Помимо возможного несоответствия между лабораторными условиями и условиями большинства реальных пользователей, существует также ряд более тонких различий, которые важно понимать, чтобы извлечь максимальную пользу из ваших лабораторных и полевых данных. как и любые различия, которые вы можете найти.
В следующих нескольких разделах подробно рассматриваются наиболее распространенные причины различий между лабораторными и полевыми данными для каждого из показателей Core Web Vitals:
- Самая большая содержательная краска (LCP)
- Взаимодействие со следующей отрисовкой (INP)
- Совокупное изменение макета (CLS)
ЛКП
Различные элементы LCP
Элемент LCP, выявленный в ходе лабораторного испытания, может отличаться от того элемента LCP, который пользователи видят при посещении вашей страницы.
Если вы запустите отчет Lighthouse для данной страницы, он будет каждый раз возвращать один и тот же элемент LCP. Но если вы посмотрите на данные полей одной и той же страницы, вы обычно обнаружите множество различных элементов LCP, которые зависят от ряда обстоятельств, специфичных для каждого посещения страницы.
Например, следующие факторы могут способствовать определению другого элемента LCP для одной и той же страницы:
- Различные размеры экрана устройства приводят к тому, что в области просмотра отображаются разные элементы.
- Если пользователь вошел в систему или каким-либо образом отображается персонализированный контент, элемент LCP может сильно отличаться от пользователя к пользователю.
- Как и в предыдущем пункте, если на странице выполняется A/B-тест, это может привести к отображению очень разных элементов.
- Набор шрифтов, установленных в системе пользователя, может влиять на размер текста на странице (и, следовательно, на то, какой элемент является элементом LCP).
- Лабораторные тесты обычно выполняются на «базовом» URL-адресе страницы — без добавления каких-либо параметров запроса или хеш-фрагментов. Но в реальном мире пользователи часто используют общие URL-адреса, содержащие идентификатор фрагмента или текстовый фрагмент , поэтому элемент LCP на самом деле может находиться в середине или внизу страницы (а не «над сгибом»).
Поскольку LCP в этом поле рассчитывается как 75-й процентиль всех посещений страницы пользователями, если у большого процента этих пользователей был элемент LCP, который загружался очень быстро (например, абзац текста, отображаемый с использованием системного шрифта), то даже если у некоторых из этих пользователей в качестве элемента LCP было большое, медленно загружающееся изображение, это может не повлиять на оценку этой страницы, если это произойдет с менее чем 25% посетителей.
Альтернативно, может быть и наоборот. Лабораторный тест может идентифицировать блок текста как элемент LCP, поскольку он эмулирует телефон Moto G4 с относительно небольшой областью просмотра, а главное изображение вашей страницы изначально отображается за кадром. Однако ваши полевые данные могут включать в основном пользователей Pixel XL с большими экранами, поэтому для них медленно загружающееся главное изображение является элементом LCP.
Влияние состояния кэша на LCP
Лабораторные тесты обычно загружают страницу с холодным кешем, но когда реальные пользователи посещают эту страницу, у них уже могут быть кэшированы некоторые ее ресурсы.
Когда пользователь впервые загружает страницу, она может загружаться медленно, но если на странице настроено правильное кэширование , в следующий раз, когда пользователь вернется, страница может загрузиться сразу.
Хотя некоторые лабораторные инструменты поддерживают несколько запусков одной и той же страницы (чтобы имитировать взаимодействие с вернувшимися посетителями), лабораторный инструмент не может узнать, какой процент реальных посещений происходит от новых пользователей по сравнению с вернувшимися.
Сайты с хорошо оптимизированными конфигурациями кэша и большим количеством постоянных посетителей могут обнаружить, что их реальный LCP работает намного быстрее, чем показывают лабораторные данные.
Оптимизация AMP или Signed Exchange
Сайты, созданные с использованием AMP или использующие Signed Exchanges (SXG), могут быть предварительно загружены агрегаторами контента, такими как Google Search. Это может привести к значительному повышению производительности загрузки для пользователей, посещающих ваши страницы с этих платформ.
Помимо предварительной загрузки между источниками, сами сайты могут предварительно загружать контент для последующих страниц своего сайта, что также может улучшить LCP для этих страниц.
Лабораторные инструменты не моделируют выгоды, полученные от этой оптимизации, и даже если бы они это сделали, они не могли бы знать, какой процент вашего трафика поступает с таких платформ, как Google Search, по сравнению с другими источниками.
Влияние bfcache на LCP
Когда страницы восстанавливаются из bfcache, загрузка происходит практически мгновенно, и эти события включаются в ваши полевые данные .
Лабораторные тесты не учитывают bfcache, поэтому, если ваши страницы поддерживают bfcache , это, скорее всего, приведет к более быстрым результатам LCP, сообщаемым на местах.
Влияние взаимодействия с пользователем на LCP
LCP определяет время рендеринга самого большого изображения или текстового блока в области просмотра, но этот самый большой элемент может меняться по мере загрузки страницы или при динамическом добавлении нового контента в область просмотра.
В лабораторных условиях браузер будет ждать полной загрузки страницы, прежде чем определить, что это за элемент LCP. Но в полевых условиях браузер перестанет отслеживать более крупные элементы после того, как пользователь прокручивает страницу или взаимодействует с ней.
Это имеет смысл (и необходимо), поскольку пользователи обычно ждут взаимодействия со страницей до тех пор, пока она не «покажется» загруженной, а это именно то, на что направлена метрика LCP. Также не имеет смысла рассматривать элементы, добавленные в область просмотра после взаимодействия пользователя, поскольку эти элементы могли быть загружены только из-за каких-то действий пользователя.
Однако следствием этого является то, что данные полей для страницы могут сообщать о более быстром времени LCP, в зависимости от того, как пользователи ведут себя на этой странице.
ИЯФ
INP требует реального взаимодействия с пользователем
Метрика INP измеряет, насколько страница реагирует на взаимодействие с пользователем в тот момент, когда пользователи действительно решили с ней взаимодействовать.
Вторая часть этого предложения имеет решающее значение, поскольку лабораторные тесты, даже те, которые поддерживают поведение пользователей сценариев, не могут точно предсказать, когда пользователи захотят взаимодействовать со страницей, и, следовательно, не могут точно измерить FID.
TBT не учитывает поведение пользователей
Лабораторная метрика общего времени блокировки (TBT) предназначена для помощи в диагностике проблем с INP, поскольку она количественно определяет, насколько основной поток блокируется во время загрузки страницы.
Идея состоит в том, что страницы с большим количеством синхронного JavaScript или другими интенсивными задачами рендеринга с большей вероятностью будут блокировать основной поток при первом взаимодействии пользователя. Однако если пользователи ждут взаимодействия со страницей до завершения выполнения JavaScript, INP может быть очень низким.
Когда пользователи решат взаимодействовать со страницей, во многом зависит от того, выглядит она интерактивной или нет, и это невозможно измерить с помощью TBT.
TBT не учитывает задержку касания
Если сайт не оптимизирован для просмотра на мобильных устройствах, браузеры добавляют задержку в 300 мс после любого нажатия перед запуском обработчиков событий. Они делают это, потому что им нужно определить, пытается ли пользователь дважды нажать, чтобы увеличить масштаб, прежде чем он сможет активировать события мыши или щелчка.
Эта задержка учитывается при расчете INP страницы, поскольку она влияет на реальную задержку ввода, с которой сталкиваются пользователи. Но поскольку эта задержка технически не является длинной задачей , она не влияет на TBT страницы. Это означает, что страница может иметь плохой INP, несмотря на очень хорошие показатели TBT.
Влияние состояния кэша и bfcache на INP
Точно так же, как правильное кэширование может улучшить LCP в полевых условиях, оно также может улучшить INP.
В реальном мире у пользователя может быть код JavaScript для сайта уже в кеше, поэтому его обработка может занять меньше времени и привести к меньшим задержкам.
То же самое справедливо и для страниц, восстановленных из bfcache. В этих случаях JavaScript восстанавливается из памяти, поэтому время обработки может быть незначительным или вообще отсутствовать.
ЦЛС
Влияние взаимодействия с пользователем на CLS
CLS, измеренный в лаборатории, учитывает только сдвиги макета, которые происходят над сгибом и во время загрузки, но это лишь часть того, что на самом деле измеряет CLS.
На практике CLS учитывает все неожиданные изменения макета , которые происходят на протяжении всего срока службы страницы, включая контент, который меняется при прокрутке пользователем или в ответ на медленные сетевые запросы после взаимодействия с пользователем.
Например, на страницах довольно часто отложенная загрузка изображений или iframe без размеров , и это может привести к смещению макета, когда пользователь прокручивает эти разделы страницы. Но эти сдвиги могут произойти только в том случае, если пользователь прокручивает страницу вниз, что часто не фиксируется лабораторными тестами.
Персонализированный контент
Персонализированный контент, включая таргетированную рекламу и A/B-тесты, влияет на то, какие элементы загружаются на страницу. Это также влияет на то, как они загружаются, поскольку персонализированный контент часто загружается позже и вставляется в основной контент страницы, что приводит к сдвигам макета.
В лаборатории страница обычно загружается либо без персонализированного контента, либо с контентом для общего «тестового пользователя», который может вызвать или не вызвать изменения, которые видят реальные пользователи.
Поскольку полевые данные включают в себя опыт всех пользователей, количество (и степень) изменений макета на любой конкретной странице во многом зависит от того, какой контент загружается.
Влияние состояния кэша и bfcache на CLS
Двумя наиболее распространенными причинами смещения макета во время загрузки являются изображения и iframe без размеров (как упоминалось выше) и медленная загрузка веб-шрифтов . Обе эти проблемы с большей вероятностью повлияют на работу пользователя при первом посещении сайта, когда их кэш пуст.
Если ресурсы страницы кэшированы или сама страница восстановлена из bfcache, браузер обычно может отображать изображения и шрифты сразу, не дожидаясь их загрузки. Это может привести к более низким значениям CLS в полевых условиях, чем могут сообщить лабораторные приборы.
Что делать, если результаты разные
Как правило, если у вас есть как полевые, так и лабораторные данные для данной страницы, именно полевые данные следует использовать для определения приоритетов своих усилий. Поскольку полевые данные отражают то, что испытывают реальные пользователи, это наиболее точный способ понять, с чем сталкиваются ваши пользователи и что необходимо улучшить.
С другой стороны, если ваши полевые данные показывают хорошие результаты по всем направлениям, но ваши лабораторные данные показывают, что еще есть возможности для улучшения, стоит понять, какие дальнейшие оптимизации можно провести.
Кроме того, хотя полевые данные действительно отражают опыт реальных пользователей, они касаются только тех пользователей, которые могут успешно загрузить ваш сайт . Лабораторные данные иногда могут помочь определить возможности расширения охвата вашего сайта и сделать его более доступным для пользователей с более медленными сетями или устройствами более низкого уровня.
В целом, как лабораторные, так и полевые данные являются важной частью эффективного измерения производительности. У каждого из них есть свои сильные и слабые стороны, и если вы используете только один из них, вы можете упустить возможность улучшить работу своих пользователей.