CLS: почему сайт прыгает при загрузке и как это исправить

Размеры медиа, шрифты и динамические элементы интерфейса как основные источники смещений.

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

Сначала зафиксировать симптом

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

С чего я бы начал проверку

• Для LCP найти конкретный элемент и его critical path.
• Зафиксировать URL, устройство и время проблемы.
• Для CLS резервировать размеры медиа и динамических блоков.
• Проверить SQL, cron, backup и bots.
• Разделить backend latency и frontend rendering.

Где обычно находится причина

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

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

Что легко сделать хуже

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

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

Как понять, что проблема решена

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

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