Core Web Vitals: LCP, INP и CLS человеческим языком

Что измеряют метрики и почему лабораторный тест не равен реальным пользователям.

PageSpeed полезен для диагностики, но зелёный балл не заменяет реальную производительность. Нужно разделять backend, frontend и бизнес-сценарии.

Не чинить то, что ещё не диагностировано

Один и тот же внешний симптом может появляться по разным причинам. Сначала стоит записать конкретный сценарий: URL, устройство, шаг, момент появления и последние изменения.

Первые проверки без переделки сайта

• Сегментировать по источнику, устройству и интенту.
• Для LCP найти конкретный элемент и его critical path.
• Зафиксировать URL, устройство и время проблемы.
• Для CLS резервировать размеры медиа и динамических блоков.
• Сравнивать не CPL, а стоимость квалифицированного лида.

Что чаще оказывается источником

Скорость нельзя диагностировать одним баллом Lighthouse. Я бы разделял серверное время, загрузку ресурсов, отрисовку, JavaScript и реальные пользовательские метрики.

Высокий CPU на хостинге — симптом, а не диагноз. Причиной могут быть реальные посетители, боты, cron, резервные копии, тяжёлый SQL или PHP-код.

Популярные ложные решения

• высокий CPU = много клиентов
• удаление скриптов без проверки функций
• вывод о сервере по одному тесту
• игнорирование cron и backups

Кеш и CDN не исправят тяжёлый PHP-запрос, бесконечный cron или несколько мегабайт JavaScript на первом экране.

Проверка после исправления

• TTFB
• CPU/RAM
• slow SQL
• LCP/INP/CLS

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