Core Web Vitals assessment: Failed - как читать отчёт Search Console и что чинить первым (2026)

Отчёт Core Web Vitals - одно из немногих мест, где Google прямо говорит о сайте «прошёл» или «не прошёл», и именно поэтому красное Failed вызывает больше паники и больше бессмысленной работы, чем почти любое другое сообщение в Search Console. Отчёт не является оценкой скорости и не является мнением о вашем коде. Это агрегат того, что реальные пользователи Chrome испытали на ваших страницах за последние 28 дней, сжатый до трёх порогов. Прочитать его правильно - примерно десять минут работы, и это избавляет от куда более частого исхода: команда шесть недель жмёт картинки, тогда как провалилась метрика задержки отклика. По данным HTTP Archive 2025 Web Almanac, 43% мобильных источников до сих пор не проходят INP, и INP - единственная метрика, которую лабораторный тест не показывает вообще. Здесь разбирается, что именно оценивается, как определить провалившуюся метрику и стоящий за ней шаблон страниц, почему статус отстаёт от исправления на недели, во что провал обходится в позициях и в выручке, и где проходит граница между починкой силами вашей команды и инженерной задачей.

Что на самом деле означает «Core Web Vitals assessment: Failed»?

Оценка - это вердикт по группе URL, построенный на Chrome User Experience Report (CrUX). CrUX собирает измерения с реальных пользователей Chrome, согласившихся на передачу статистики, на реальных устройствах и реальных сетях. Search Console берёт 28 дней этих данных, группирует URL по структурному сходству (на практике - по шаблону страницы) и считает 75-й перцентиль каждой метрики для каждой группы. Группа проходит, только если все три метрики попадают в зону «Good» на этом перцентиле. Одна метрика вне зоны обрушивает всю группу, а мобильные и десктоп оцениваются как независимые наборы данных, поэтому сайт может проходить на десктопе и проваливаться на мобильных при одинаковом коде. Слово Failed несёт узкий и точный смысл: как минимум одно из трёх конкретных чисел, измеренных не менее чем на четверти реальных визитов, оказалось за порогом, который Google опубликовал заранее.

• LCP (Largest Contentful Paint): Good ≤ 2.5 с, требует улучшения 2.5–4.0 с, плохо > 4.0 с. Показывает, когда дорисовался самый крупный видимый элемент в области просмотра. Это ближайшее техническое соответствие ощущению «страница загрузилась».
• INP (Interaction to Next Paint): Good ≤ 200 мс, требует улучшения 201–500 мс, плохо > 500 мс. Измеряет задержку взаимодействий на протяжении всей сессии, отчёт идёт примерно по 98-му перцентилю взаимодействий одного пользователя. Заменила FID в составе Core Web Vitals 12 марта 2024 года.
• CLS (Cumulative Layout Shift): Good ≤ 0.1, требует улучшения 0.1–0.25, плохо > 0.25. Измеряет неожиданные смещения видимого контента за время жизни страницы, считается как безразмерное произведение доли влияния и доли расстояния.
• Правило 75-го перцентиля: Метрика считается хорошей для группы URL, только если как минимум 75% подходящих визитов дали хорошее значение. Оптимизация под собственное устройство на собственном канале ничего не говорит о тех 25% хвоста, которые и решают исход.
• Раздельные вердикты по устройствам: Провалы концентрируются на мобильных, потому что выборка CrUX состоит преимущественно из среднебюджетного Android, а не из ноутбука, на котором сайт тестировали.

Почему PageSpeed Insights показывает 95, а Search Console пишет Failed?

Потому что PageSpeed Insights помещает два несвязанных измерения на один экран, а большинство читает только цветной кружок. Верхний блок, когда он есть, - полевые данные CrUX: то самое 28-дневное распределение реальных пользователей, которое оценивает Search Console. Крупный балл под ним - Lighthouse, один синтетический прогон на эмулированном среднем устройстве с придушенными процессором и сетью, выполненный прямо сейчас, без единого живого человека на странице. Эти два числа расходятся регулярно, и оба при этом верны. Главный структурный разрыв - INP: в лабораторном прогоне нет реальных взаимодействий, которые можно замерить, поэтому Lighthouse не выдаёт значение INP вообще и подставляет Total Blocking Time как грубый заменитель. Страница может набрать 100 в лаборатории и иметь 600 мс INP в поле, и лабораторный балл не предупредит об этом никак. Одно правило снимает почти всю путаницу: полевые данные определяют вашу оценку, лабораторные нужны только для отладки.

• Лабораторные данные (балл Lighthouse): Один прогон, эмулированное среднее устройство, искусственное ограничение сети, ноль взаимодействий, ноль расширений, ноль разброса по холодному кэшу. Полезно для воспроизведения проблемы и для регрессионных проверок в CI. Никогда не является основанием оценки.
• Полевые данные (CrUX): 28 дней реальных сессий на фактическом распределении устройств, сетей, географий и браузерных расширений ваших посетителей. Именно это оценивает Search Console и именно это потребляют ранжирующие системы Google.
• INP существует только в поле: Lighthouse вместо неё показывает Total Blocking Time. TBT коррелирует с INP, но измеряется во время загрузки, тогда как INP измеряется по всей сессии, включая клики по фильтрам и тапы по меню, которые происходят сильно позже загрузки.
• URL против домена: PageSpeed Insights откатывается к полевым данным уровня домена, когда у конкретного URL слишком мало выборки. Вы можете смотреть на главную, а число на экране будет средним по всем страницам домена.
• Практическая проверка: Если лабораторный балл зелёный, а оценка красная, откройте блок полевых данных и прочитайте три полосы. В большинстве случаев виновата INP или CLS, и ни одна из них не видна в крупном числе сверху.

Какая из трёх метрик провалилась и как это проверить?

Search Console отвечает на это прямо, но ответ лежит в строках проблем, а не в графике сверху. Откройте Core Web Vitals, выберите «Мобильные» или «Десктоп» и прочитайте список проблем под графиком. Каждая строка сформулирована как метрика, порог и устройство, например «Проблема с LCP: более 2,5 с (мобильные)», и несёт счётчик затронутых URL. Клик по строке раскрывает примеры URL, и именно примеры ценнее всего, потому что показывают, какой шаблон страниц проваливается. Провалы группируются по шаблонам, а не рассыпаются случайно, поэтому один макет листинга товаров или один макет статьи обычно объясняет всю группу целиком. Подтвердите диагноз на одном показательном URL в PageSpeed Insights, читая блок полевых данных, а не балл, и если выборка выглядит тонкой, CrUX API вернёт полную гистограмму для любого URL или домена.

• Начинайте со строк проблем, а не с графика: График показывает, сколько URL попало в каждую зону. Строки называют метрику и порог, которые дали вердикт.
• Используйте примеры URL как карту шаблонов: Сгруппируйте их по паттерну адреса. Если все проваленные примеры лежат в /collections/* или /blog/*, у вас один макет для починки, а не сотни страниц.
• Проверяйте по URL в PageSpeed Insights: Читайте блок «Узнайте, как ваш сайт работает у реальных пользователей». Балл под ним - отдельное измерение, и он не подтверждает и не опровергает оценку.
• Тяните сырую гистограмму, когда выборка тонкая: https://chromeuxreport.googleapis.com/v1/records:queryRecord принимает URL или домен и возвращает полное распределение, включая то самое значение p75, которое использовал Search Console.
• Снимайте метрики со своих сессий: Официальная библиотека web-vitals реализует те же алгоритмы, что и CrUX. Отправка onLCP, onINP и onCLS в вашу аналитику даёт атрибуцию, которой у CrUX нет: какой элемент, какой маршрут, какое взаимодействие.

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

Search Console показывает Failed на мобильных и Good на десктопе. С чем работать?

Начинайте с мобильных, и читайте эти два вердикта как отдельные, а не как противоречие. Search Console присваивает метки Poor, Needs improvement и Good группе URL «для конкретного типа устройства», поэтому мобильная и десктопная строки - это два независимых утверждения о двух разных группах посетителей, и ничего непоследовательного в том, что одна проходит, а другая нет. Одна и та же страница на среднем Android-телефоне в мобильной сети и на десктопе по оптике действительно даёт разные числа, и первыми на мобильных ломаются LCP и INP, потому что у телефона меньше процессорного времени на ваш JavaScript и медленнее круг до сервера. Но приоритет мобильных держится на причине попроще любых опубликованных весов в ранжировании. Откройте отчёт «Эффективность», разбейте по устройствам, и в большинстве случаев увидите, что основная часть сессий пришла с телефона, а значит мобильный вердикт и есть описание того, что получило большинство ваших посетителей.

• Одна плохая метрика роняет всю группу устройства: Группа получает «самый медленный статус, присвоенный ей для этого типа устройства», поэтому единственная метрика в Poor на мобильных помечает Poor всю мобильную группу, пока остальные две спокойно сидят в зелёном. Прочитайте строки проблем, прежде чем решать, что страница медленная в целом.
• Приоритет берите из своего разделения по устройствам, а не из общего правила: Фильтр устройств в отчёте «Эффективность» показывает, как трафик делится именно у вас. У B2B-инструмента с 70% десктопных сессий и проваленной десктопной группой первая задача другая, чем у потребительского магазина с 85% мобильных.
• Прохождение на десктопе не подтверждает мобильную починку: Проверяйте на том типе устройства, который провалился. Проверка на машине, где вы делали правку, воспроизводит ровно те условия, которые изначально спрятали проблему.
• У десктопных провалов обычно другая причина: Если мобильные проходят, а десктоп нет, ищите то, что растёт на широком вьюпорте: hero на полную ширину в десктопном разрешении, карусель, которая рендерится только выше брейкпоинта, виджет, который мобильная вёрстка прячет целиком. Привычка тестировать узкие вьюпорты по мобайл-ферст пропускает всё это.

Почему URL, который вы замерили как быстрый, лежит в проваленной группе?

Потому что вердикт принадлежит группе похожих страниц, а не тому URL, который вы проверили. Search Console объединяет URL «в страницы с похожим пользовательским опытом», исходя из заявленного допущения, что страницы на общем каркасе ломаются по одной и той же причине, и затем публикует один статус на всю группу. Ваша страница товара может быть по-настоящему быстрой, пока её группа в Poor, потому что 75-й перцентиль группы собран из визитов на все URL внутри неё, включая страницы, которые никто не догадывается проверить: вариант с сорока картинками, категорию, отдающую две тысячи строк, старый лендинг кампании, который до сих пор тянет забытый виджет. Когда данных не хватает, чтобы описать группу вообще, отчёт сводит то, что есть, до уровня домена, и поэтому часть сайтов видит один вердикт на весь домен и не может привязать его ни к одной странице.

• Проваленная группа - это проваленный шаблон: Починка живёт в общей вёрстке группы, а не в том URL, который вы случайно открыли. Одна правка шаблона сдвигает все URL группы сразу.
• Ищите худший URL, а не типичный: Примеры URL в строке проблемы - это примеры, а не полный список. Отсортируйте свою аналитику по самым тяжёлым страницам внутри проваленного паттерна и мерьте их, потому что именно они вытолкнули перцентиль за порог.
• Данные уровня домена нельзя отладить по URL: Если отчёт свёл вас до домена, проверка отдельных страниц причину не изолирует. Разметка своих маршрутов через web-vitals даёт ту атрибуцию по шаблонам, которую CrUX не отдаёт.
• Группа может исчезнуть, а не пройти: Группа URL без достаточных данных по метрикам вообще не попадает в отчёт, поэтому уход группы из отчёта не доказывает починку. Падение трафика ниже порога выборки выглядит снаружи ровно как успех.

Почему отчёт всё ещё показывает Failed через недели после починки?

Потому что оценка считается по скользящему окну в 28 дней, а деплой не меняет задним числом сессии, которые уже внутри этого окна. В день выкатки исправления окно по-прежнему содержит 28 дней визитов до починки. Каждый следующий день выбрасывает один день старых данных и добавляет один день новых, поэтому 75-й перцентиль улучшается постепенно и доходит до истинного значения примерно через четыре недели. Search Console сверху добавляет собственную задержку обработки в несколько дней. Это отставание - самое дорогое непонимание во всём отчёте, потому что естественное прочтение неизменившегося красного статуса звучит как «починка не сработала», и команда идёт менять ещё код, окончательно теряя возможность что-либо атрибутировать. Правильная реакция на красный статус через две недели после деплоя - проверить исправление на свежих данных, а не чинить заново.

• Рассчитывайте примерно на четыре недели до полного эффекта: Частичное движение видно уже через несколько дней по мере вымывания старых сессий, но итоговому числу нельзя доверять, пока окно не сменится полностью.
• Search Console отстаёт от CrUX: Отчёт отражает данные, которым уже несколько дней. Проверка на той же неделе не говорит вообще ни о чём.
• Запуск проверки ничего не меняет в сроках: Кнопка Start tracking в этом отчёте перезапускает четырёхнедельный период наблюдения за данными CrUX, а не запрашивает что-либо у Google, поэтому она полезна как датированная отметка о заявленной починке и бесполезна как ускоритель.
• Смотрите тем временем на собственный RUM: Полевые замеры через web-vitals показывают эффект деплоя за часы, на вашем трафике, без 28-дневного сглаживания. Это единственная быстрая обратная связь, которая существует.
• Не наваливайте исправления вслепую: Три новых изменения во время окна валидации делают невозможным понять, какое из них сдвинуло число, а какое вызвало регресс.

Ускоряет ли запуск проверки в Search Console повторную оценку исправления?

Нет. Сначала найдите саму кнопку, потому что называется она не тем, что обычно ищут: в этом отчёте она подписана Start tracking, а формулировка Validate fix относится к другим отчётам Search Console. Дальше Google прямо говорит, что происходит при нажатии. Кнопка «не запускает переиндексацию или какое-либо иное активное действие со стороны Google. Она лишь (пере)запускает отсчёт четырёхнедельного периода наблюдения за данными CrUX». Просить обход нечего, и очереди, в которую можно встать, не существует, потому что оценка никогда не строилась на обходе. Она строится на замерах, которые Chrome собирает с реальных посетителей, и они приходят своим темпом независимо от того, нажали вы что-нибудь или нет. Единственная настоящая функция кнопки - учёт, а ошибка, которой стоит избегать, это нажать её слишком рано: период наблюдения, открытый до того как починка реально в проде, потратит свои четыре недели на замер сломанной версии и вернётся с Failed, что потом читается как доказательство неработающей починки.

• Нажимайте после деплоя, а не вокруг него: Сначала подтвердите починку в своих полевых замерах, потом запускайте наблюдение. Тогда окно содержит только сессии после исправления, и только так результат вообще что-то значит.
• Failed не значит, что ваша починка не сработала: Это значит, что хотя бы один URL всё ещё был затронут в течение окна. Документированная реакция - починить оставшиеся URL и запустить новый период наблюдения, а не переделывать то, что вы уже проверили.
• Кнопка вообще не обязательна: Проблема может вернуться со статусом N/A, и это метка Google для проблемы, которую он увидел исправленной без всякого запроса на проверку. Оценка становится зелёной на одних полевых данных.
• «Похоже, всё в порядке» - это не «пройдено»: Такое состояние говорит только о том, что проверенные к этому моменту URL чистые, пока окно ещё открыто. Ждать нужно статус Passed.

Действительно ли проваленная оценка Core Web Vitals бьёт по позициям в Google?

Слабее, чем подразумевает большинство статей на эту тему, и здесь стоит быть точным, потому что преувеличение ведёт к плохим бюджетным решениям. Page experience, измеримой частью которого являются Core Web Vitals, - реальный вход ранжирующих систем Google, но работает он как различитель между результатами сопоставимой релевантности, а не как первичный фактор. Быстрая страница с пустым содержанием не обойдёт более медленную, которая нормально отвечает на запрос. Если ваши страницы не ранжируются, Core Web Vitals редко является причиной, и работа над скоростью не починит проблему контента или авторитетности. Где провал стабильно стоит денег, так это после клика: медленные и прыгающие страницы теряют пользователей на каждом шаге воронки, и эта потеря совершенно не зависит от вашей позиции. Честная формулировка такая: Core Web Vitals - вопрос конверсии и удержания, к которому прилагается скромный бонус в ранжировании, и финансировать эту работу нужно по первому основанию, а не по второму.

• Различитель, а не рычаг: Собственные рекомендации Google позиционируют page experience как полезный тогда, когда остальные сигналы сопоставимы. Считайте прирост позиций возможным побочным эффектом, а не бизнес-обоснованием.
• Аргумент выручки сильнее аргумента позиций: Отказы растут с временем загрузки и с нестабильностью независимо от места в выдаче. Эффект распространяется и на платный, и на почтовый, и на прямой трафик, которым ваша позиция безразлична.
• Провалы концентрируются там, где намерение выше всего: Проблемы INP обычно всплывают на фильтрах, поиске по сайту, выборе вариантов товара и действиях с корзиной, то есть ровно там, где посетитель уже решил купить.
• Сначала диагноз, потом бюджет: Если органика стоит на месте и позиции плохие, аудируйте сначала контент, перелинковку и индексацию. Работа над Core Web Vitals на сайте без релевантного контента - дорогое украшение.
• По теме: О сигналах ранжирования, которые обычно значат больше, есть руководство по JSON-LD, а полная картина по скорости - в руководстве по веб-производительности.

Что делать, если Search Console вообще не показывает данные Core Web Vitals?

Это проблема размера выборки, а не наказание, и для большой доли сайтов это нормальное состояние. CrUX начинает отчитываться по URL или домену только после того, как собрал достаточно подходящих визитов от согласившихся пользователей Chrome, чтобы построить статистически значимое распределение и не раскрыть поведение отдельного человека. Небольшие сайты часто видят отсутствие данных на уровне URL, только данные уровня домена или данные, которые появляются и исчезают вместе с колебаниями трафика. Ни на что в ранжировании это не влияет, и никакая оптимизация не заставит данные появиться быстрее, потому что ограничение здесь в объёме трафика, а не в качестве страниц. Практическое следствие: Search Console не может быть вашей обратной связью, поэтому её придётся построить самостоятельно.

• Сначала посмотрите, что вообще есть: Запросите CrUX API и по URL, и по домену. Данные уровня домена часто существуют там, где данных по URL нет, и они остаются законным сигналом о ваших шаблонах.
• Снимайте метрики с реальных пользователей сами: npm install web-vitals, затем отправляйте onLCP, onINP и onCLS в аналитику. Даже несколько сотен сессий в неделю дают пригодный 75-й перцентиль задолго до того, как это сделал бы CrUX.
• Пользуйтесь лабораторными данными честно: Lighthouse на придушенном среднем профиле - разумный заменитель для LCP и CLS. Для INP он заменителем не является, поэтому реальные взаимодействия проверяйте руками на настоящем среднебюджетном Android.
• Не гоняйтесь за зелёным лабораторным баллом: Без полевых данных лабораторное число - единственная доступная обратная связь, и потому появляется соблазн оптимизировать прямо под него. Этот путь заканчивается идеальным баллом и сайтом, который в руках всё равно ощущается медленным.

Какие провалы можно починить своими силами, а где нужен инженер?

Граница проходит по тому, меняет ли исправление настройку и файл или же меняет способ построения страницы. Большинство провалов CLS и заметная доля провалов LCP лежат на первой стороне и реально чинятся грамотной маркетинговой командой за полдня: раздутая картинка в первом экране, отсутствующие ширина и высота у встраиваемого блока, баннер, вставляемый в первый экран после загрузки, шрифт, блокирующий отрисовку. Провалы INP там почти никогда не лежат. Задержка отклика - это свойство того, сколько JavaScript выполняется в главном потоке и когда именно, а значит починка живёт внутри архитектуры компонентов, стратегии гидратации и бюджета сторонних скриптов, и ни до чего из этого нельзя дотянуться из панели настроек. Полезный вопрос перед выделением бюджета звучит не «насколько плох балл», а «в какую из двух категорий попадает мой провал», потому что ответ меняет стоимость на порядок.

• Обычно чинит ваша команда: Несжатые или избыточно большие картинки первого экрана; отсутствие атрибутов width и height у изображений, iframe и рекламных блоков; поздно вставляемые cookie-баннеры и промо-полосы; настройка font-display, блокирующая первую отрисовку; неиспользуемые приложения, пиксели и контейнеры тег-менеджера; хостинг без CDN перед ним.
• Требует инженера: INP, вызванная стоимостью гидратации или размером бандла; элемент LCP, который рендерится на клиенте и потому не может начать загружаться до выполнения JavaScript; блокирующие отрисовку сторонние скрипты, которые нельзя просто удалить по бизнес-причинам; смещения макета, рождающиеся в дереве компонентов, а не в одном файле; переписывание шаблонов там, где проблема в самой структуре страницы.
• Быстрый диагностический признак: Если провалилась CLS, начинайте со своей команды. Если INP, начинайте с инженера. Если LCP, посмотрите, что именно является самым крупным элементом: картинка обычно ваша, клиентски отрисованный блок обычно нет.
• По теме: Об архитектурном разборе пути отрисовки и отклика за проваленной оценкой - услуга Core Web Vitals и оптимизация производительности. Инженерные детали именно по INP - в руководстве по оптимизации INP.

В каком порядке чинить проблемы Core Web Vitals?

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

• 1. Подтвердите цель. Назовите провалившуюся метрику, устройство и шаблон до того, как трогать код. Починка не той метрики даёт зелёный лабораторный балл и неизменившуюся оценку.
• 2. Почините CLS. Зарезервируйте размеры у каждого изображения, iframe, встраиваемого блока и рекламного места. Вынесите вставляемые баннеры из потока макета или отрисовывайте их на сервере с уже выделенным местом. Грузите шрифты с сопоставленным по метрикам запасным вариантом, чтобы подмена не перекладывала текст.
• 3. Почините LCP. Определите элемент LCP в DevTools, затем сделайте его обнаружимым в исходном HTML, корректно размерным, отданным в современном формате и приоритетным. Если он рендерится на клиенте, перенос его в серверную отдачу обычно даёт больше, чем любая оптимизация файла.
• 4. Почините INP. Сократите и отложите JavaScript в главном потоке, разбейте длинные задачи на границах взаимодействий, изолируйте сторонние скрипты и сузьте поверхность гидратации. Это архитектурная работа, и её место последнее, когда измерение уже не загрязнено первыми тремя шагами.
• 5. Измеряйте в поле и ждите. Подтвердите изменение в собственном RUM за несколько дней, затем дайте 28-дневному окну смениться, прежде чем читать оценку как вердикт.

Сколько времени нужно, чтобы оценка снова стала зелёной?

От четырёх до шести недель с того деплоя, который действительно чинит провалившуюся метрику, при условии, что исправление верное и за ним ничего не регрессировало. Нижнюю границу задаёт 28-дневное окно CrUX, сократить которое нельзя, плюс собственная задержка обработки Search Console в несколько дней. На практике срок растягивается, когда первое исправление целится не в ту метрику, что бывает часто, или когда изменение улучшает медиану, не сдвигая 75-й перцентиль, - это специфическая ловушка тестирования на хорошем железе и быстром канале. Сайты с тонким покрытием в CrUX вдобавок могут какое-то время перескакивать между состояниями из-за колебаний выборки. Планируйте работу как один деплой плюс месяц ожидания, а не как месяц итераций, и используйте собственные полевые замеры для обратной связи в промежутке.

Заключение

Проваленная оценка Core Web Vitals - узкое и точно определённое утверждение: за последние 28 дней как минимум одно из трёх чисел вышло за свой порог более чем на четверти реальных визитов по группе ваших страниц. Почти вся напрасная работа вокруг этого сводится к трём ошибкам прочтения: доверию лабораторному баллу вместо полевых данных, восприятию 28-дневного отставания как доказательства неудачной починки и предположению, что влияние на позиции больше, чем оно есть. Прочитайте строки проблем, чтобы назвать метрику и шаблон, решите, файловая это проблема или архитектурная, чините в порядке предсказуемости, а затем переждите окно вместо того, чтобы итерировать внутри него. При таком подходе работа занимает несколько сфокусированных дней плюс месяц терпения вместо шестинедельного проекта по сжатию картинок, который оставляет провалившуюся метрику нетронутой.

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

Источники

• Google web.dev - Core Web Vitals
• Справка Search Console - отчёт Core Web Vitals
• Google web.dev - Largest Contentful Paint (LCP)
• Google web.dev - Interaction to Next Paint (INP)
• Google web.dev - Cumulative Layout Shift (CLS)
• Chrome UX Report - документация API
• Google web.dev - различия лабораторных и полевых данных
• HTTP Archive - 2025 Web Almanac, глава Performance
• Google Search Central - о page experience
• Библиотека web-vitals на GitHub