Как ускорить WordPress в 2026 году: контрольный список оптимизации производительности

Прогоните свой сайт через PageSpeed Insights (pagespeed.web.dev) и запишите четыре цифры: LCP (Largest Contentful Paint, время до появления основного контента), INP (Interaction to Next Paint, отзывчивость), CLS (Cumulative Layout Shift, визуальная стабильность) и общий вес страницы. Пороги Core Web Vitals от Google: LCP ниже 2,5 с, INP ниже 200 мс, CLS ниже 0,1. Они напрямую влияют на ваши позиции с 2021 года. Ниже этих порогов — «хорошо»; между порогами и 4 с/500 мс/0,25 — «требует улучшения»; хуже — «плохо». Весь смысл оптимизации скорости WordPress — перевести эти три цифры в зелёную зону. Не полагайтесь на оценки GTmetrix или другие агрегированные рейтинги: они не соответствуют реальным сигналам Google.

Проверьте TTFB (Time To First Byte) из географии вашей аудитории с помощью WebPageTest. Если TTFB превышает 1 секунду, узкое место — ваш хостинг: никакая оптимизация фронтенда это не исправит. Частые виновники: дешёвый общий хостинг с перегруженными серверами, хостинг на другом континенте, нежели ваша аудитория, отсутствие PHP opcache (любая версия PHP 7+ должна иметь его включённым по умолчанию). Самое дешёвое решение — перейти на более быстрый хостинг того же уровня плана. Для менее чем 50 000 визитов/мес Hostinger Business с LiteSpeed Cache даёт TTFB ниже 400 мс. Для большего трафика Kinsta или WP Engine на премиальном уровне Google Cloud стабильно дают TTFB ниже 300 мс. Смена хостинга — больше работы, чем установка плагина, но улучшение обычно резкое.

По умолчанию WordPress генерирует каждую страницу из PHP + MySQL при каждом запросе. Кэширование страниц сохраняет сгенерированный HTML и отдаёт его напрямую последующим посетителям: обычно в 10–20 раз быстрее. На хостингах на базе LiteSpeed (Hostinger, большинство Bluehost, A2 Turbo, NameHero) установите LiteSpeed Cache (бесплатно): он интегрируется с кэшем на уровне сервера. На хостингах Apache/Nginx установите WP Rocket (59 $/год): это плагин кэширования высшего качества, и он стоит своих денег. Бесплатные альтернативы (W3 Total Cache, WP Super Cache) работают, но требуют больше настройки. После включения кэширования страниц снова проверьте в PageSpeed Insights: вы должны увидеть резкое падение TTFB.

Изображения обычно составляют 60–80 % веса страницы WordPress. Две победы, которые стоит получить: (1) Сжатие: каждое изображение должно сжиматься перед загрузкой. Используйте наш Компрессор изображений или установите ShortPixel/Smush для автоматического сжатия при загрузке. Цель: изображения шапки ниже 200 КБ, контентные изображения ниже 100 КБ. (2) Современные форматы: отдавайте WebP (или AVIF) вместо JPG/PNG. WebP на 25–35 % меньше при том же качестве. ShortPixel и Smush Pro конвертируют автоматически; как альтернатива, оптимизация изображений Cloudflare переписывает изображения на лету. (3) Ленивая загрузка: изображения ниже линии сгиба должны загружаться только при прокрутке к ним. WordPress 5.5+ добавляет loading='lazy' автоматически; проверьте, что это работает, просмотрев исходный код. (4) Атрибуты ширины: всегда задавайте явные width/height для изображений, чтобы избежать CLS.

Большинство плагинов кэширования (WP Rocket, LiteSpeed Cache) включают минификацию CSS/JS: включите её. Самая большая победа — отложить или удалить неиспользуемые скрипты. Запустите Chrome DevTools → вкладку Coverage на вашей главной странице; она показывает, какие байты CSS и JS реально используются. Типичные результаты: 50–80 % CSS не используется, 30–60 % JS не используется. Решения: (а) используйте более лёгкую тему (GeneratePress или Kadence отдают менее 30 КБ CSS), (б) отключите неиспользуемые плагины (часто источник неиспользуемых скриптов), (в) используйте плагин вроде Asset CleanUp, чтобы отключать скрипты на страницах, где они не нужны (например, Contact Form 7 по умолчанию грузится везде, даже если вы используете его только на /contact).

Каждый активный плагин WordPress выполняется при каждой загрузке страницы, потенциально добавляя запросы, JavaScript и CSS. У большинства медленных сайтов более 30–50 активных плагинов, половиной которых уже не пользуются. Используйте Query Monitor (бесплатно), чтобы увидеть, какие плагины делают больше всего запросов к базе данных. Используйте бесплатный уровень New Relic или APM от Kinsta, чтобы увидеть, какие функции плагинов выполняются дольше всего. Главные исторические нарушители: Jetpack (делает много всего, всё — при каждом запросе), раздутые плагины резервного копирования, работающие во время пиков трафика, плагины кнопок соцсетей, грузящие свои CSS/JS даже на страницах без кнопок «Поделиться», плагины безопасности, выполняющие сканирование файлов в реальном времени. Отключите плагин, снова проверьте производительность и решите, стоила ли функция своих затрат.

WordPress со временем накапливает мусор в базе данных: ревизии записей, истёкшие transients, спам-комментарии, осиротевшие метаданные. Установите WP-Optimize (бесплатно) и один раз выполните очистку базы данных. Разумное ежемесячное обслуживание: удаляйте ревизии старше 60 дней (свежие сохраняйте на всякий случай), истёкшие transients, очередь спама. Для высоконагруженных сайтов самая большая победа по базе данных — кэширование объектов: Redis или Memcached хранят в памяти результаты дорогих запросов MySQL, избегая повторной работы. Большинство управляемых хостингов WordPress включают Redis на старших уровнях; на базовом общем хостинге это недоступно.

CDN (Сеть доставки контента) кэширует ваши статические ресурсы (изображения, CSS, JS) в edge-расположениях рядом с вашими посетителями. Для аудитории только из США с хостингом в США CDN даёт скромное улучшение. Для глобальной аудитории CDN необходим: он снижает задержку ресурсов с 200–500 мс до 20–50 мс. Бесплатного уровня Cloudflare хватает для большинства нужд; BunnyCDN по 0,01–0,05 $/ГБ — платное улучшение с отличной производительностью. Для изображений в частности Cloudflare Images или Bunny Image Optimizer могут изменять размер и конвертировать форматы на лету.

После каждого значимого изменения снова запускайте PageSpeed Insights. Цель — постепенный прогресс: большинство сайтов не переходят из «плохо» в «хорошо» одним изменением. После полного прохода оптимизации типичные результаты: магазин WooCommerce на общем хостинге переходит с LCP 4–6 с на LCP 1,5–2,5 с. Контентный блог на управляемом хостинге переходит с LCP 2–3 с на LCP 0,8–1,5 с. Если после всего вышеперечисленного вы остаётесь выше 3 с по LCP, узкое место, вероятно, — ваша тема: перейдите на более лёгкую тему (GeneratePress, Kadence или Astra), прежде чем оптимизировать дальше.