Ускорить WordPress-сайт: что реально даёт эффект, а что только зелёный отчёт

Профилирование, backend, frontend, кеширование, Core Web Vitals и влияние скорости на бизнес-сценарии.

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

Сначала определить границы задачи

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

• Для INP искать long tasks и тяжёлые обработчики.
• Сопоставить активные плагины с реально используемыми функциями.
• Для CLS резервировать размеры медиа и динамических блоков.
• Измерить ресурсы и long tasks.

Вариант без лишней разработки

Простой вариант нормален, когда задача локальная, зависимости понятны и результат можно проверить одним-двумя сценариями. Не каждая проблема требует нового сайта или большой переделки.

Ситуации, где экономия выйдет дороже

Более глубокая работа нужна, когда дефект повторяется в шаблоне, затрагивает много URL, ограничивает SEO, рекламу, аналитику или делает каждую следующую правку непропорционально дорогой.

Фраза «сайт тормозит» может означать медленный серверный ответ, тяжёлую базу, большой JavaScript, изображения, сторонние виджеты или интерфейс, зависающий после клика. Ускорение начинается с измерения.

Что спросить до старта

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

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

Нормальный критерий выбора

Я бы сравнивал варианты по тому, что именно изменится, как это проверят и что останется управляемым после завершения работ.

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