Почему Google Search Console LCP Не Ошибается, По Мнению Google

Барри Поллард из Google объяснил в Bluesky, почему Google Search Console может сообщать о плохом показателе Largest Contentful Paint (LCP), даже если отдельные страницы кажутся загружающимися быстро. Он предоставил подробное объяснение, и я делюсь его словами, чтобы обеспечить точность.

Купил акции на все деньги, а они упали? А Илон Маск снова написал твит? Знакомо. У нас тут клуб тех, кто пытается понять этот цирк и не сойти с ума.

Купить на падении (нет)

Вот что он написал в нескольких постах на Bluesky:

Загадка Core Web Vitals для вас:

Почему Google Search Console сообщает, что мой LCP плохой, но по каждому образцовому URL LCP хороший?

Как человек, который давно занимается управлением веб-сайтами, я часто вижу, как разработчики ломают голову, когда обнаруживают неожиданные данные в Google Search Console. Они спрашивают, как могут возникнуть эти проблемы, и сразу же подозревают, что GSC сообщает что-то неверно. Честно говоря, я редко думаю, что проблема в GSC! Итак, реальный вопрос заключается в следующем: что *мы* можем сделать, чтобы выяснить, что на самом деле происходит, и исправить это?

Это, признаться, сбивает с толку, так давайте разберемся…

Давайте начнем с понимания того, как этот отчет и Chrome User Experience Report (CrUX) измеряют Core Web Vitals. Как только вы это поймете, будет легче увидеть, какие действия вы можете предпринять для их улучшения — и мы рассмотрим это далее.

Похоже, есть расхождение: CrUX сообщает о 90% положительных загрузок страниц, в то время как Google Search Console показывает, что только 50% URL-адресов работают хорошо. Чем это объясняется, и какой источник предоставляет более точные данные?

Мне часто задают вопросы о Core Web Vitals, и это *действительно* запутанно — но обе точки зрения на самом деле верны. Это потому, что они измеряют разные вещи…

1/5 ð§µ

— Barry Pollard (@tunetheweb.com) August 19, 2025 at 6:32 AM

CrUX измеряет загрузки страниц, а показатель Core Web Vitals — это 75-й процентиль этих загрузок страниц.

По сути, это означает оценку, достигнутую как минимум 75% просмотров страницы.

Филип Уолтон освещает это более подробно в этом видео:

https://www.youtube.com/watch?v=fWoI9DXmpdk

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

Проблема возникает, когда длинный хвост в сумме составляет более 25% от общего числа просмотров страниц.

Веб-страницы, получающие большой трафик, с большей вероятностью имеют подробные данные о производительности в наших системах (мы собираем данные только тогда, когда трафик достигает определенного уровня). По этой причине они часто используются в качестве примеров в Google Search Console.

Как вебмастер, позвольте мне сказать вам, это те страницы, на которых вам действительно нужно сосредоточиться — они приводят весь трафик на ваш сайт!

Но популярные страницы имеют еще одну интересную особенность: они часто работают быстрее!

Часто ответы хранятся во временных кэшах. Это происходит в кэшах баз данных, с использованием таких инструментов, как Varnish, и особенно на серверах на периферии сетей доставки контента (CDNs).

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

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

Кэши — это здорово! Но они могут маскировать медлительность, которая видна только при ‘cache misses’.

И это часто является причиной того, что вы видите это в GSC.

Итак, как это исправить?

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

Кэширование — отличный способ сделать ваш сайт ещё быстрее, но не стоит полагаться только на него для повышения скорости. Рассматривайте это как дополнительный импульс, а не основу.

Я часто проверяю это, добавляя случайную строку к URL-адресу (например, ?test=1234), а затем снова запускаю тест Lighthouse, меняя строку каждый раз. Обычно это заставляет страницу загружаться без использования кэша.

Сравните это с запуском кэшированной страницы (запустив обычный URL несколько раз).

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

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

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

Вы можете настроить Сети доставки контента (CDN) для игнорирования определенных URL-параметров и предотвращения их обработки как уникальных страниц. Кроме того, разрабатывается новый стандарт, который позволит веб-страницам указывать, какие параметры можно безопасно игнорировать.

Приятно видеть, что No-Vary-Search расширяет свою изначальную область применения, выходя за рамки правил спекуляций, и становится более широко применимым.

Эта функция позволяет исключать конкретные URL-параметры, добавленные для отслеживания (например, ‘gclid’ или другие аналитические теги), при этом извлекая контент из кэша. По сути, это гарантирует, что коды отслеживания не помешают вам использовать кэшированные версии ваших страниц.

— Barry Pollard (@tunetheweb.com) September 26, 2025 at 11:57 AM

Смотрите также

2025-10-03 16:15