Подрядчик присылает скриншот с зелёным кругом и числом 94 и пишет: «Сайт ускорили». Через месяц в Search Console часть страниц по-прежнему в статусе «требует улучшения», а менеджеры слышат от клиентов, что на телефоне кнопка заказа «прыгает». Все три сообщения могут быть правдой одновременно: они описывают разные страницы, устройства и источники данных.
Core Web Vitals — это три показателя: LCP, INP и CLS. Каждый нужно читать вместе с четырьмя уточнениями: какая страница, какое устройство, откуда данные и за какой период. Показатели помогают проверить, быстро ли посетитель видит основное содержимое, быстро ли страница откликается на нажатия и не смещаются ли элементы под пальцем. Сами по себе они не доказывают ни потерянных, ни полученных продаж.
Ниже — как прочитать отчёт, поставить задачу разработчику и принять исправление.
Что показывают LCP, INP и CLS
Google объединяет под названием Core Web Vitals три показателя, которые описывают разные стороны опыта посетителя: загрузку основного содержимого, отклик на действия и стабильность расположения элементов. В одну «общую скорость» они не складываются: страница может быстро показывать содержимое и при этом медленно реагировать на нажатия.
LCP: когда появился самый крупный элемент
LCP (Largest Contentful Paint) показывает, когда в видимой части экрана отрисовался самый крупный элемент из тех, что учитывает эта метрика. Отсчёт идёт от начала перехода на страницу. Учитываются изображения, кадр-заставка видео, фоновое изображение, подключённое через стили, и текстовые блоки — например, главное фото товара или баннер на первом экране.
LCP не означает «когда появилась цена» или «когда стала доступна кнопка». Если самый крупный элемент — фото, показатель описывает именно фото.
Пример проблемы: на мобильной странице категории сначала появляются меню и фильтры, а большой баннер с предложением — через несколько секунд. Посетитель видит пустое место там, где должен быть главный блок.
INP: как быстро страница откликается на действие
INP (Interaction to Next Paint) измеряет задержку от действия посетителя до следующего обновления экрана, которое показывает отклик. Учитываются клики мышью, касания экрана и нажатия клавиш; прокрутка и наведение курсора — нет. Пока страница открыта, браузер фиксирует задержки всех таких действий, и итогом становится самая долгая. Если взаимодействий много, на каждые 50 одно самое долгое отбрасывается, чтобы единичный сбой не определял результат.
INP заканчивается, как только экран впервые изменился в ответ на действие. Он не измеряет, сколько сервер обрабатывал заказ. Если после нажатия сразу появляется индикатор загрузки, а сама операция длится три секунды, INP может быть хорошим, хотя для клиента процесс долгий. Это две разные проблемы.
Пример проблемы: посетитель нажимает «Добавить в корзину», полсекунды ничего не происходит, человек нажимает ещё раз — и в корзине две единицы товара.
INP стал одним из Core Web Vitals в марте 2024 года и заменил показатель FID. Если отчёт подрядчика до сих пор опирается на FID, он составлен по устаревшему набору.
CLS: смещаются ли элементы неожиданно
CLS (Cumulative Layout Shift) оценивает неожиданные смещения элементов страницы. Это безразмерное число: для каждого смещения учитывается, какую долю экрана затронуло движение и на какое расстояние сдвинулись элементы. Смещения, близкие по времени, объединяются в группы, и показатель берёт самую крупную группу. Движение в течение полусекунды после нажатия посетителя, например раскрытие списка, в CLS не учитывается.
Пример проблемы: в карточке товара на телефоне фото загружается без зарезервированного места, блок опускается, и палец, который тянулся к «Купить», попадает на «Доставка».
Пороговые значения
| Показатель | Хорошо | Требует улучшения | Плохо |
|---|---|---|---|
| LCP, секунды | LCP ≤ 2,5 | 2,5 < LCP ≤ 4 | LCP > 4 |
| INP, миллисекунды | INP ≤ 200 | 200 < INP ≤ 500 | INP > 500 |
| CLS, безразмерное число | CLS ≤ 0,1 | 0,1 < CLS ≤ 0,25 | CLS > 0,25 |
Пороги соответствуют описанию Web Vitals и PageSpeed Insights. Они применяются к 75-му процентилю загрузок, отдельно для мобильных и настольных устройств.
Где смотреть показатели и какие данные вы видите
Владельцу достаточно двух инструментов Google: PageSpeed Insights для отдельной страницы и отчёта Core Web Vitals в Search Console для групп страниц.
PageSpeed Insights: реальные данные и лабораторный тест
В отчёте PageSpeed Insights две части, которые часто путают.
Верхняя часть — данные реальных посещений. Они берутся из CrUX (Chrome User Experience Report): обезличенных измерений от пользователей Chrome на компьютерах и Android, которые согласились отправлять статистику. Посещения с iPhone и из других браузеров сюда не попадают. Данные охватывают последние 28 дней и обновляются ежедневно как скользящее окно. Именно здесь есть INP и итог проверки Core Web Vitals.
Нижняя часть — лабораторный тест Lighthouse. Это одна загрузка страницы на сервере Google с имитацией телефона среднего уровня в мобильной сети или компьютера с проводным подключением. Тест помогает найти причину и быстро повторить проверку после изменений, но не описывает ваших посетителей и не содержит реальных нажатий, поэтому INP в нём нет.
Результаты для мобильных устройств и компьютеров отдельные; начинайте с того варианта, которым пользуется большинство ваших посетителей.
Страница или весь origin
Если посещений конкретной страницы в CrUX недостаточно, PageSpeed Insights может показать данные для origin — сочетания протокола, домена и порта, например https://shop.example.ua. Такие данные объединяют посещения всех страниц в этих границах. Адреса https://example.ua и https://shop.example.ua — разные origin, как и варианты с http и https.
Когда отчёт показывает origin, это нужно назвать прямо: «данные для всего сайта, конкретная страница отдельно не оценена». Хороший результат origin не доказывает, что именно страница оформления заказа работает хорошо.
Если реальных данных нет
Пустой блок реальных данных означает, что для этой страницы нет доступных полевых данных. Причиной может быть недостаточное число посещений или то, что страница не соответствует условиям CrUX: например, закрыта от индексации или недоступна публично. О скорости такое отсутствие ничего не говорит. Остаются лабораторный тест и собственные измерения, если сайт собирает показатели из браузеров посетителей через систему мониторинга.
Отчёт Core Web Vitals в Search Console
Отчёт Core Web Vitals использует те же реальные данные, но объединяет похожие страницы в группы. Для сайта с сотнями карточек товаров это удобнее, чем проверять адреса по одному. Мобильные и настольные данные разделены. Статус группы определяет худший из показателей: если LCP в зоне «хорошо», а CLS — «плохо», группа получит статус «плохо». Если хотя бы для одного из показателей LCP или CLS данных недостаточно, группа не показывается, и это тоже не оценка.
Как читать оценку без ложных выводов
Что означает 75-й процентиль
Представьте, что все загрузки страницы за 28 дней выстроены от самого быстрого LCP до самого медленного. 75-й процентиль — значение на отметке трёх четвертей этого ряда. LCP 2,3 с означает: в 75 % загрузок самый крупный элемент появился за 2,3 с или быстрее, в остальных — медленнее. Среднее значение могло бы скрыть медленные загрузки за счёт быстрых.
По описанию PageSpeed Insights, страница проходит проверку Core Web Vitals, когда все три показателя на 75-м процентиле находятся в зоне «хорошо». Один показатель вне этой зоны означает, что проверка не пройдена. Исключение — INP: если данных о взаимодействиях недостаточно, достаточно хороших LCP и CLS, но тогда отклик страницы на действия никто не оценил.
Балл Lighthouse — не проверка Core Web Vitals
Число от 0 до 100 в круге — балл лабораторного теста; зелёный цвет означает 90 и выше. Балл рассчитывается из нескольких лабораторных метрик, среди которых есть LCP и CLS, но нет INP. Балл 94 означает, что одна тестовая загрузка в заданных условиях прошла хорошо.
Проверка Core Web Vitals опирается на реальные посещения, поэтому возможны оба расхождения. Лабораторный балл бывает высоким, когда реальные данные плохие — например, если телефоны посетителей медленнее имитируемого или на странице срабатывают скрипты, которые в тесте не проявились. Бывает и наоборот. Причину в каждом случае проверяют отдельно.
В лабораторном отчёте есть TBT (Total Blocking Time) — показатель блокировки основного потока браузера длинными задачами: для каждой задачи дольше 50 мс учитывается время сверх этих 50 мс. TBT помогает искать причины плохого INP, но это другой показатель, и подписывать его как INP нельзя.
Условный пример: один отчёт, два вывода
Условный пример. Данные вымышлены для объяснения.
| Что в отчёте | Значение | Правильное прочтение |
|---|---|---|
| Балл лабораторного теста, мобильный | 94 | Тестовая загрузка прошла хорошо |
| LCP реальных посещений, мобильные, 75-й процентиль | 3,6 с | Зона «требует улучшения» |
| INP реальных посещений, мобильные | 180 мс | Зона «хорошо» |
| CLS реальных посещений, мобильные | 0,05 | Зона «хорошо» |
| Источник реальных данных | Origin | Оценён весь сайт, а не страница |
Мобильная проверка Core Web Vitals не пройдена из-за LCP, и эта оценка относится ко всему origin. Сообщение «балл 94» этого не опровергает. Следующий шаг — выяснить, какие типы страниц дают медленный LCP.
Типичные ошибки: сравнивать лабораторный результат «до» с реальными данными «после»; оценивать мобильную версию по результату для компьютера; принимать данные origin за данные страницы; делать вывод о продажах по изменению одного показателя.
Какие страницы проверять в первую очередь
Главная страница — не всегда самая важная. Посетители из поиска и рекламы часто попадают сразу в категорию, на карточку товара или страницу услуги, а обращения приходят через форму или корзину. Порядок проверки редакция советует составлять по четырём признакам:
- Роль в сценарии: страницы на пути к обращению или заказу — страницы входа, категории, карточки, услуги, корзина, форма.
- Шаблон: проблема шаблона повторяется на многих страницах, и исправление может подействовать на все; группы в Search Console помогают это увидеть.
- Наблюдаемая проблема: реальные данные вне зоны «хорошо», жалобы клиентов, запись сеанса посетителя, где видно смещение или задержку.
- Доля посещений по данным вашей аналитики.
Первыми берут страницы с важной ролью и наблюдаемой проблемой; шаблон и доля посещений помогают выбрать между ними. Эти признаки упорядочивают работу, но не оценивают, сколько денег принесёт каждое исправление.
Как превратить отчёт в задачу для разработчика
Красный показатель — симптом, а не причина. Причиной медленного LCP может быть медленный ответ сервера, тяжёлое изображение, поздняя загрузка главного фото, стили, которые задерживают отрисовку, или построение страницы скриптами. Причиной плохого INP — сторонний виджет, чат, счётчик или собственный код сайта. Диагноз ставит разработчик после проверки.
Поэтому задачу формулируют так, чтобы разработчик мог воспроизвести проблему, а вы — принять результат:
| Поле задачи | Что вписать |
|---|---|
| Симптом для посетителя | Что происходит со страницей с точки зрения человека |
| Страница или шаблон | Адрес примера и тип страницы |
| Условия и источник | Устройство, источник данных, дата, значение показателя |
| Предполагаемая причина | Помечена как гипотеза |
| Как подтвердить причину | Какую проверку выполнить до изменения |
| Ответственный | Кто выполняет и кто принимает |
| Критерий приёмки | По какому признаку задача выполнена |
Условный пример. Заполненная задача:
Симптом: в мобильной карточке товара после загрузки фото кнопка «Купить» опускается; пользователь может нажать не туда.
Шаблон: карточка товара, пример —
/catalog/boiler-24/.Условия и источник: мобильные; группа карточек в отчёте Core Web Vitals в Search Console имеет статус «требует улучшения» по CLS; данные на дату постановки задачи.
Предполагаемая причина: для главного фото не заданы размеры или соотношение сторон.
Как подтвердить: воспроизвести загрузку на имитации телефона с медленной сетью и зафиксировать смещения в инструментах разработчика.
Ответственный: разработчик выполняет; SEO-специалист проверяет показатели; менеджер проекта принимает.
Критерий приёмки: на трёх примерах карточек кнопка не смещается после загрузки фото; сценарий «вариант → корзина» работает; изменения опубликованы, дата зафиксирована.
Если проверка показывает другую причину, разработчик описывает найденную причину и что именно изменено. Когда исправление касается кода шаблона, настроек сервера или сторонних скриптов, к работе подключается разработка.
Как принять исправление
Приёмка состоит из двух отдельных частей. Техническое исправление можно принять сразу после проверки. Реальные данные проверяют позже отдельной задачей, потому что их 28-дневное окно лишь постепенно заполняется посещениями после изменений.
Техническая приёмка — сразу после публикации изменений:
- лабораторная проверка в тех же условиях: тот же адрес, мобильный режим, несколько запусков, потому что результат колеблется; редакция советует сравнивать типичное значение, а не один лучший запуск, и проверять несколько страниц шаблона;
- сценарий: поиск и фильтры, выбор варианта, корзина, форма, оплата, поступление обращений в CRM, события аналитики;
- отсутствие регрессий: исправление одного показателя не ухудшило два других и не сломало другие шаблоны.
Контроль реальных данных — отдельная задача с датой и ответственным. Новое 28-дневное окно полностью сложится из посещений после изменений примерно через 28 дней после публикации; в Search Console для группы можно запустить проверку исправления, которая тоже наблюдает 28 дней. Если показатели улучшились, а в журнале изменений нет других правок, которые могли на них повлиять, это согласуется с исправлением. Если нет — проверяют, дошли ли изменения до всех страниц группы. Изменилась ли стоимость обращений, отчёт о скорости не показывает: для этого нужна отдельная проверка с данными о расходах и обращениях.
Результат фиксируется в карточке приёмки. Её заполняет исполнитель, а владелец или менеджер проверяет, нет ли пустых полей.
Карточка приёмки технических изменений
Условный пример. Карточка заполнена для объяснения, это не результат реального проекта.
| Поле карточки | Значение |
|---|---|
| Страница или шаблон | Карточка товара, мобильная версия |
| Проблема посетителя | После загрузки фото кнопка «Купить» смещается, человек может нажать не туда |
| Показатель | CLS |
| Источник и условия | Search Console, группа карточек товара, мобильные, статус «требует улучшения» на дату постановки задачи; лабораторная проверка трёх карточек |
| Что изменено | Для главного фото задано соотношение сторон, место резервируется до загрузки |
| Результат проверки | Технически принято: на трёх карточках смещения кнопки нет, сценарий «вариант → корзина → оформление» работает, события корзины поступают. Не определено: изменение CLS в реальных данных |
| Следующий шаг | Контроль статуса группы в Search Console через 28 дней после публикации; ответственный — SEO-специалист |
Перед подписанием акта задайте подрядчику четыре вопроса, на которые карточка отвечает лишь частично:
- Как именно подтвердили причину проблемы?
- На скольких страницах шаблона и на каких устройствах проверяли результат?
- Откуда цифры: реальные данные страницы, данные origin или лабораторный тест, и на какую дату?
- Что осталось неисправленным или неопределённым и почему?
Следующие шаги
- Владелец или руководитель маркетинга выбирает несколько страниц или шаблонов по признакам выше.
- SEO-специалист фиксирует для них реальные и лабораторные данные с датой и отмечает, где показан origin или где реальных данных нет.
- Разработчик по задаче подтверждает причину, вносит изменения и заполняет карточку приёмки.
- Менеджер проекта принимает техническое исправление и ставит отдельную задачу на контроль реальных данных с датой и ответственным.
Работа завершена, когда техническое исправление принято по карточке, а контроль реальных данных назначен. Результат контроля записывается в карточку, когда контроль завершится, каким бы он ни был.
Обсудим, какие страницы нуждаются в проверке и как принимать исправления.
