Как улучшить INP: почему сайт тормозит именно после клика

Длинные задачи JavaScript, загрузка главного потока и причины задержки реакции интерфейса.

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

Симптом и причина — не одно и то же

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

Что проверить в первую очередь

• Разделить backend latency и frontend rendering.
• Для CLS резервировать размеры медиа и динамических блоков.
• Посмотреть access/error logs.
• Исправлять самый дорогой bottleneck.
• Зафиксировать URL, устройство и время проблемы.

Как сузить круг причин

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

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

Чего я бы не делал на старте

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

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

Что сравнить после исправления

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

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