Как ускорить WordPress в 2026: полный чек-лист

Скорость WordPress — это не один волшебный плагин, а сумма решений: хостинг, PHP, кеширование, картинки, код темы. Хорошая новость в том, что вклад у них разный: два-три шага из этого чек-листа дают больше, чем остальные пятнадцать вместе.

Прежде чем что-то менять — измерьте. Прогоните главную и пару типовых страниц через PageSpeed Insights и запишите цифры: LCP, INP, CLS и общий балл. Без точки отсчёта вы не узнаете, что сработало, а карго-культ «поставил плагин — вроде быстрее» тратит время. После каждого крупного шага измеряйте снова.

Чек-лист построен по приоритету: сначала фундамент с максимальным эффектом, потом тонкая настройка. Делайте сверху вниз.

Ориентиры: Core Web Vitals

Google оценивает скорость по опыту реальных пользователей — метрикам Core Web Vitals:

Метрика	Что измеряет	Хорошо
LCP	Когда появился основной контент	≤ 2,5 с
INP	Как быстро сайт реагирует на клики и ввод	≤ 200 мс
CLS	Насколько «прыгает» вёрстка при загрузке	≤ 0,1

Эти пороги — не абстракция: Web Vitals входят в факторы ранжирования, а медленный сайт теряет посетителей до того, как они увидят контент. Все шаги ниже работают на одну или несколько этих метрик.

Фундамент: хостинг и PHP

1. Актуальный PHP. Современному WordPress нужен PHP 8.2+, и каждая мажорная версия PHP 8.x быстрее предыдущей — это самое дешёвое ускорение из возможных: переключается в панели хостинга за минуту. Перед переключением проверьте совместимость плагинов на тестовой копии — резкая смена версии PHP на проде порой заканчивается ошибкой 500.

2. Нормальный хостинг. Никакая оптимизация не спасёт сайт на перегруженном сервере. Признаки проблемы: TTFB (время до первого байта) стабильно выше 600–800 мс на нединамичных страницах, плавающая скорость в течение дня. Смотрите в сторону тарифов с NVMe-дисками, HTTP/2 или HTTP/3 и достаточным лимитом процессов PHP.

3. OPcache включён. Кеш байткода PHP на приличных хостингах включён по умолчанию — но проверьте (в панели или через wp eval 'var_dump(function_exists("opcache_get_status"));'). Без него PHP компилирует код заново на каждый запрос.

Кеширование: главный множитель

4. Страничный кеш. Один запрос собирает страницу из PHP и базы, все последующие получают готовый HTML. Это самый большой единичный выигрыш для типового сайта. Варианты: серверный кеш хостинга (часто самый быстрый — включается в панели) или зрелый плагин кеширования — какой выбрать под ваш сервер, разобрали в сравнении плагинов кеширования. Правило одно: механизм кеширования — один. Два плагина кеша или плагин поверх включённого серверного кеша дают конфликты, а иногда и белый экран — как это разгребать, мы писали в разборе белого экрана.

5. Объектный кеш для динамики. Интернет-магазину, форуму, сайту с личным кабинетом страничный кеш помогает лишь частично — там много запросов мимо кеша. Redis или Memcached хранят результаты запросов к базе между обращениями и заметно разгружают динамические страницы. Нужна поддержка хостинга и плагин-коннектор.

6. Кеш браузера и сжатие. Заголовки Cache-Control для статики и сжатие текстовых ответов (Brotli или Gzip) — стандартная настройка, которую делают плагины кеширования или пара директив в конфиге сервера. Проверить, что сжатие работает, можно во вкладке Network браузера: заголовок content-encoding в ответе.

Картинки: половина веса страницы

7. Современные форматы. WebP даёт файлы заметно легче JPEG/PNG при том же качестве, AVIF — ещё легче. WordPress поддерживает загрузку WebP и AVIF в медиабиблиотеку; конвертацию существующих картинок делают плагины оптимизации изображений или сервисы на лету.

8. Правильные размеры. Не отдавайте фотографию 4000px в блок шириной 400px. WordPress сам генерирует уменьшенные копии и подставляет srcset — но проверьте, что тема этим пользуется, а в контент не вставлены «оригиналы».

9. Ленивая загрузка — но не для главного изображения. WordPress добавляет loading="lazy" картинкам ниже первого экрана автоматически. Важный нюанс для LCP: главное изображение первого экрана (обложка, баннер) должно грузиться сразу, с fetchpriority="high" — ленивая загрузка hero-картинки ухудшает LCP, а не улучшает.

Код: тема, плагины, скрипты

10. Аудит плагинов. Установите Query Monitor и посмотрите, кто генерирует запросы и время: обычно 2–3 плагина съедают больше всех. Удалите неиспользуемое (деактивированный плагин — тоже риск, но активный ещё и тормозит), замените тяжёлые аналоги лёгкими. Каждый плагин — это код, стили и скрипты на каждой загрузке страницы.

11. Лёгкая тема. Тяжёлые многофункциональные темы и page builder'ы тянут мегабайты CSS/JS на каждую страницу. Блоковые FSE-темы, как правило, заметно легче: WordPress подгружает только стили используемых блоков.

12. Меньше блокирующего JavaScript. Скрипты аналитики, чатов, пикселей — с defer или через отложенную загрузку по взаимодействию. Именно сторонний JS чаще всего портит INP. Регулярно спрашивайте себя: все ли эти счётчики ещё нужны?

13. Шрифты. Локальное размещение шрифтов вместо сторонних CDN, формат WOFF2, font-display: swap и подгрузка только нужных начертаний. Четыре начертания вместо десяти — типичная лёгкая победа и для CLS (меньше перерисовок).

База данных и фоновые процессы

14. Чистка базы. Сотни ревизий записей, спам-комментарии, transient-мусор раздувают базу. Ограничьте ревизии в wp-config.php:

define( 'WP_POST_REVISIONS', 5 );

Чистку выполняют плагины оптимизации базы или WP-CLI:

wp transient delete --expired
wp post delete $(wp post list --post_type=revision --format=ids) --force

15. Cron без сюрпризов. WP-Cron запускается посетителями: на посещаемом сайте это лишняя работа на случайных запросах, на пустом — задачи не выполняются вовремя. Переведите на серверный cron:

define( 'DISABLE_WP_CRON', true );

И добавьте в панели хостинга задание раз в 5–10 минут: wp cron event run --due-now (или запрос к wp-cron.php).

Доставка: CDN и протоколы

16. CDN для статики. Сеть доставки контента отдаёт картинки, стили и скрипты с ближайшего к посетителю узла и снимает нагрузку с хостинга. Обязательно при географически распределённой аудитории, полезно и без неё.

17. HTTP/2 или HTTP/3. Мультиплексирование запросов ощутимо ускоряет загрузку страниц с десятками ресурсов. Обычно включается на стороне хостинга или CDN — просто проверьте, что оно включено (вкладка Network → колонка Protocol).

Чего делать не стоит

Пара анти-советов, потому что типичные ошибки оптимизации отнимают больше, чем дают. Не ставьте несколько «ускоряющих» плагинов одновременно: минификаторы, оптимизаторы и кеши дублируют функции друг друга и конфликтуют — выберите один комбайн или минимальный набор без пересечений. Не включайте агрессивные опции скопом: объединение и минификация JS в один клик регулярно ломает скрипты темы — включайте по одной опции и проверяйте сайт. И не оптимизируйте вслепую по чужим статьям «отключите emoji и heartbeat»: такие микротвики дают доли процента, пока картинки весят мегабайты. Сначала — крупные пункты чек-листа, потом косметика.

Чек-лист с приоритетами

Сводная таблица — что делать в каком порядке, если время ограничено:

#	Шаг	Эффект	Трудозатраты
1	PHP 8.2+ (актуальная версия)	Высокий	15 минут
2	Страничный кеш	Очень высокий	1 час
3	WebP/AVIF + размеры картинок	Высокий	1–2 часа
4	Аудит и чистка плагинов	Высокий	2 часа
5	Отложенный JS, локальные шрифты	Средний	2 часа
6	Объектный кеш (Redis)	Средний*	1 час
7	Чистка базы + серверный cron	Средний	1 час
8	CDN	Средний	1 час
9	Смена темы на лёгкую	Высокий	Дни
10	Смена хостинга	Высокий	Полдня

*Для динамических сайтов (магазин, кабинеты) — высокий.

Первые четыре пункта обычно переводят сайт из «красной» зоны PageSpeed в «зелёную» или близко к ней. Дальше — работа над деталями под ваши конкретные метрики.

Финальное правило: измеряй — меняй — измеряй

Оптимизация без измерений превращается в коллекционирование плагинов. Цикл простой: снять метрики → сделать один шаг → снять метрики снова. Раз в квартал сверяйтесь с реальными полевыми данными (отчёт Core Web Vitals в Search Console) — лабораторные тесты не всегда совпадают с опытом живых посетителей. И не гонитесь за 100 баллами PageSpeed: разница между 90 и 100 для пользователя незаметна, а часы на неё уходят настоящие.