Посетитель не видит показатель LCP в отчёте и не знает, что такое INP. Он просто ждёт загрузку, пытается нажать кнопку или возвращается назад, если страница дёрнулась под пальцем. Поэтому Core Web Vitals полезно рассматривать не как соревнование за зелёные цифры, а как способ найти места, где сайт мешает человеку сделать следующий шаг.
Сейчас в набор входят три метрики: LCP показывает скорость появления крупнейшего элемента, INP — отзывчивость интерфейса на действия пользователя, а CLS — устойчивость макета. В качестве ориентиров Google указывает LCP до 2,5 секунды, INP до 200 миллисекунд и CLS не выше 0,1 на 75-м перцентиле отдельно для мобильных и десктопных пользователей.
Какие страницы проверять в первую очередь
Не начинайте с главной только потому, что она самая заметная. Выберите страницы, где скорость связана с деньгами:
- посадочная страница рекламной кампании;
- страница услуги с формой заявки;
- категория и карточка товара;
- корзина и оформление заказа;
- личный кабинет, фильтр каталога или поиск.
Одна и та же проблема может проявляться по-разному. Большое изображение тормозит первый экран, тяжёлый скрипт блокирует кнопку, а баннер без заданных размеров сдвигает форму вниз. Проверяйте не только URL, но и сценарий, который человек выполняет на странице.
LCP: почему главный экран появляется поздно
LCP обычно связан с крупным изображением, заголовком, видео или блоком, который занимает большую часть первого экрана. На WordPress задержку часто создают слишком тяжёлые изображения, цепочка фоновых CSS-файлов, медленный ответ сервера и поздняя загрузка шрифтов.
Диагностика начинается с вопроса: какой элемент выбран LCP и когда браузер получил его содержимое. Затем проверьте:
- размер и формат главного изображения;
- есть ли у него правильные размеры для мобильного и десктопного экранов;
- не загружается ли ниже первого экрана ресурс с более высоким приоритетом;
- сколько времени занимает ответ сервера;
- не блокируют ли рендер критические скрипты и стили.
Простое включение кэша не всегда решает проблему. Если кэшируется неправильная версия страницы или динамический магазин, можно получить быстрый отчёт и медленный реальный заказ. После изменения проверяйте анонимную страницу и сценарий с корзиной отдельно.
INP: почему кнопка нажата, но ничего не происходит
INP связан с реакцией страницы на действия: нажатие меню, фильтра, кнопки «В корзину», поля поиска или отправку формы. Главный подозреваемый — длинная задача JavaScript, которая блокирует главный поток браузера. На практике это бывает из-за лишних виджетов, тяжёлого конструктора, аналитики, фильтра каталога или обработчика, который пересчитывает слишком много элементов.
Проверьте путь пользователя:
- нажмите кнопку несколько раз и убедитесь, что действие не дублируется;
- откройте каталог с реальным количеством фильтров;
- проверьте мобильное меню на обычном телефоне, а не только в эмуляторе;
- посмотрите, не выполняется ли тяжёлая аналитика до показа результата;
- сравните работу страницы без каждого необязательного виджета.
Ускорять нужно не показатель сам по себе, а конкретное действие. Если фильтр нужен покупателю, его нельзя просто удалить ради отчёта. Лучше сократить объём пересчёта, отложить второстепенный код или изменить способ обновления списка.
CLS: откуда берутся прыгающие кнопки и формы
Визуальная нестабильность появляется, когда уже показанный блок меняет положение без действия пользователя. Самые частые причины — изображения и рекламные блоки без заданной высоты, поздняя подгрузка шрифтов, динамические уведомления и вставка элементов в начало страницы.
На странице услуги это может выглядеть как скачок формы, а в магазине — как смещение кнопки заказа после появления цены или доставки. Для проверки прокрутите страницу от первого экрана до формы и следите, не меняется ли положение уже найденного элемента.
Базовые исправления просты:
- задайте ширину и высоту изображений или устойчивое соотношение сторон;
- оставьте место под баннеры, уведомления и виджеты;
- не вставляйте форму выше текущего контента после загрузки;
- проверьте поведение шрифтов и fallback-гарнитур;
- согласуйте динамические блоки с макетом, а не добавляйте их поверх него.
Лабораторный тест и реальные пользователи — это разные данные
PageSpeed Insights, Lighthouse и DevTools помогают воспроизвести проблему на этапе разработки. Полевые данные показывают, как страница работает у настоящих людей с разными телефонами, сетями и способами взаимодействия. Хороший лабораторный результат не доказывает, что у всех посетителей всё быстро, а плохой результат подсказывает, что проверить первым.
Для INP особенно важна оговорка: без реального взаимодействия лабораторный инструмент не измеряет его так же, как поле. Поэтому после исправлений проверьте отчёт реальных пользователей, если он доступен, и отдельно прогоните ключевые сценарии вручную.
План работ без «магической оптимизации»
- Составьте список коммерческих страниц и действий на них.
- Зафиксируйте текущие значения и источник данных.
- Найдите один наиболее дорогой элемент для каждой метрики.
- Измените только одну группу причин, чтобы увидеть эффект.
- Повторите тест на мобильном и десктопном сценарии.
- Проверьте, не сломались ли формы, корзина, аналитика и кэш.
Если после сжатия изображений показатель почти не изменился, это полезный результат: причина, вероятно, в серверном ответе, JavaScript или структуре страницы. Не стоит бесконечно оптимизировать JPEG, когда задержка возникает до его запроса.
Для WordPress и WooCommerce производительность — часть разработки, а не финальная косметика. Чем раньше учтены размеры медиа, количество плагинов, динамика каталога и реальные сценарии заказа, тем меньше вероятность переделывать готовую страницу.
Если нужна техническая проверка WordPress, заранее подготовьте список URL, устройств и действий, на которых заметна задержка.