Если Вы искали «проверка Core Web Vitals не пройдена», хотя балл скорости зелёный, сначала выясните, какие данные описывает каждый результат. PageSpeed Insights (PSI) объединяет данные реальных посещений с отдельным тестом в контролируемых условиях. Прежде чем покупать инструмент или просить переделать сайт, запишите адрес, устройство, охват данных и метрику, которая не прошла проверку.

Мы начинаем с этой записи, потому что задача «сделать балл зелёным» оставляет слишком много неопределённости. Разработчику нужно понимать, какой пользовательский опыт требует внимания и какие подтверждения позволят считать исправление полезным.

Проверка Core Web Vitals не пройдена: что измерял отчёт?

Проверка описывает зафиксированный опыт посетителей, а раздел Lighthouse запускает диагностический тест. Документация Google по PageSpeed Insights поясняет: полевые данные поступают из Chrome User Experience Report, или CrUX, за скользящий период в 28 дней. Поэтому новый диагностический запуск и накопленная история могут показывать разные результаты.

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

Результат может охватывать больше одной страницы. Если для конкретной страницы данных мало, PSI может использовать данные источника — origin, то есть адреса сайта с учётом протокола и имени хоста. Такой результат объединяет посещения разных страниц. Проверьте указанный в отчёте охват, прежде чем считать его доказательством проблемы конкретной страницы товара или услуги.

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

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

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

Какая метрика требует внимания?

Прежде чем выбирать исправление, рассмотрите LCP, INP и CLS по отдельности. Руководство Google по Web Vitals разделяет загрузку, отзывчивость и визуальную стабильность. В таблице приведены пороги оценки «Хорошо» из этого руководства: их применяют к 75-му процентилю для соответствующей группы устройств. Руководство Google по порогам поясняет: не менее 75% измеренных просмотров страниц должны укладываться в хороший порог для данной метрики. Это не среднее значение и не общий балл Lighthouse.

МетрикаЧто описываетПорог «Хорошо»Что спросить у специалиста
LCP, Largest Contentful PaintКогда появляется самый крупный видимый элемент содержимогоНе более 2,5 секундыКакой элемент задерживается и на каком этапе его загрузки?
INP, Interaction to Next PaintНасколько быстро страница реагирует на взаимодействияНе более 200 миллисекундКакое касание, нажатие мыши или клавиши замедляется в затронутых условиях?
CLS, Cumulative Layout ShiftНеожиданные смещения макетаНе более 0,1Какой элемент сдвигается и в какой момент посещения?

Когда данных достаточно по всем этим метрикам, для успешной проверки PSI требует оценку «Хорошо» у их значений на 75-м процентиле. Если данных INP недостаточно, хорошие LCP и CLS всё равно могут дать успешный результат. Если не хватает данных LCP или CLS, PSI не может оценить страницу или источник.

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

Что проверить до оплаты работ?

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

  1. Откройте в PSI точную страницу, важную для бизнеса. Сохраните её адрес и дату отчёта. Укажите посадочную страницу или шаблон, который влияет на исследуемую заявку или покупку.
  2. Запишите тип устройства и охват данных. Отметьте, что представляет полевой раздел: URL, источник или недостаточный объём данных. Для последующих сравнений используйте тот же вариант.
  3. Назовите метрику, требующую внимания. Посмотрите отдельные результаты Core Web Vitals, затем изучите диагностический раздел в поиске подсказок. Явно отмечайте отсутствующие выборки.
  4. Выполните реальную задачу на телефоне. Откройте меню, примените нужный фильтр или заполните соответствующую форму. Запишите, что загружается поздно, медленно реагирует или неожиданно сдвигается.
  5. Свяжите наблюдение с тестом. Попросите специалиста воспроизвести проблемное действие или задержку загрузки и объяснить, что именно способен установить этот тест.

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

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

Что должно входить в исправление?

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

  1. Свяжите предложение с метрикой. Руководство web.dev по LCP разделяет задержки ответа, обнаружения, загрузки и отрисовки самого крупного элемента. Руководство по INP сосредоточено на медленных взаимодействиях. Руководство по CLS рассматривает и смещения после начальной загрузки. Просите соответствующие подтверждения вместо общего обещания ускорить сайт.
  2. Устраните найденную причину и повторно проверьте поведение. Точечное исправление ресурса или шаблона может входить в разработку и поддержку сайтов. Запишите, что и когда изменилось, а по возможности — как это отменить.
  3. Убедитесь, что клиентская задача по-прежнему выполнима. Проверьте навигацию, формы и этапы покупки, относящиеся к странице. Сохраните работоспособность элементов управления согласием; исследуйте их поведение и расположение, сохраняя юридически корректное получение согласия.
  4. Определите, нужны ли дополнительные данные. Если доступные отчёты не позволяют найти проблемное взаимодействие или страницу, дополнительные измерения могут помочь. Прежде чем подключать платный сервис, спросите, на какой вопрос ответит предлагаемый мониторинг.

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

Вы можете скопировать эту карточку задачи и оставить неизвестные поля пустыми:

Страница и бизнес-задача:
Устройство и охват полевых данных:
Метрика, требующая внимания:
Наблюдаемое поведение и условия теста:
Предполагаемая причина и изменение:
Дата выкладки:
Сопоставимая проверка после изменения:
Последующее полевое наблюдение и оставшаяся неопределённость:

Как проверить, что работа помогла?

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

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

Как мы подключаемся

Мы начинаем с отчёта, важных страниц и задачи, которую можем воспроизвести. Отдельно рассматриваем предлагаемое исправление, его проверку и последующие данные посещений — так у каждого решения есть основание, которое можно оценить. Бриф по производительности сайта можно начать с карточки выше; явно отмечайте неизвестные поля.

Частые вопросы

Означает ли непройденная проверка, что сайт медленный для каждого посетителя?
Результат обобщает подходящие для измерения реальные посещения. Он не описывает опыт каждого посетителя и не доказывает, какой элемент вызвал проблему. Прежде чем ставить задачу, проверьте устройство, охват данных и отдельную метрику.
Можно ли пройти Core Web Vitals без данных INP?
Документация Google по PageSpeed Insights допускает успешную проверку при недостатке данных INP, если LCP и CLS имеют оценку «Хорошо». Если недостаточно данных LCP или CLS, PSI не может оценить страницу или источник.
Нужен ли платный плагин, чтобы исправить непройденную проверку?
Начните с определения метрики и воспроизведения проблемы. Инструмент или плагин стоит рассматривать, только если Вы можете объяснить, какие недостающие данные он даст или какую техническую причину устранит.
Нужно ли ждать после исправления производительности?
Сразу проверьте изменённое поведение в сопоставимых условиях, а позднее отдельно оцените новые данные реальных посещений. PageSpeed Insights использует скользящий период сбора, поэтому исправление не заменяет накопленную историю мгновенно.

← Все статьи