Почему WordPress медленный: 7 настоящих причин

Медленный WordPress почти всегда чинят не там. Типичный сценарий: сайт тормозит — владелец ставит «плагин ускорения», потом второй, отключает эмодзи по совету из статьи, а LCP как был 5 секунд, так и остался. Причина в том, что скорость складывается из полудюжины независимых слагаемых, и пока вы не знаете, какое из них весит больше всех, любая оптимизация — стрельба по площадям.

Эта статья — не про «что сделать», а про «как найти виновника». Разберём семь настоящих причин медленного WordPress и, главное, как каждую диагностировать измерением, а не на глаз. Когда виновник назван — исправление обычно очевидно, и его мы уже подробно расписали в чек-листе ускорения WordPress.

Сначала — одно измерение, которое делит проблему пополам

Прежде чем перебирать причины, откройте DevTools браузера (F12), вкладку Network, и перезагрузите страницу. Найдите первый запрос — сам HTML-документ — и посмотрите на TTFB (Time To First Byte, время до первого байта). Это время, за которое сервер начал отдавать ответ.

Одно это число делит все проблемы на два лагеря:

TTFB	Где искать виновника	Причины из списка ниже
Высокий (> 600 мс)	Сервер (бэкенд)	Хостинг, PHP, отсутствие кеша, тяжёлая база
Низкий (< 300 мс), но страница долго «собирается»	Браузер (фронтенд)	Картинки, шрифты, сторонние скрипты, тяжёлая тема

Без этого шага вы будете оптимизировать картинки, когда тормозит база, — и наоборот. Всё дальнейшее строится на нём.

Причина 1. Хостинг, который не тянет

Самая частая и самая недооценённая причина. Дешёвый или перегруженный shared-хостинг физически не успевает обрабатывать запросы: сотни сайтов делят один процессор, а вам достаётся, сколько осталось.

Как диагностировать. Замерьте TTFB на статичной странице (например, «О компании») несколько раз за день — утром, днём, вечером. Тревожные признаки: стабильно выше 600–800 мс или сильно плавает (200 мс утром, 1,5 секунды вечером). Плавающий TTFB — почти верный признак того, что сервер перегружен соседями.

Чистый тест: временно отключите плагин кеширования и замерьте снова. Если без кеша TTFB улетает в небо — сервер вытягивает сайт только за счёт кеша, а это костыль, а не решение.

Причина 2. Устаревший PHP

WordPress работает на PHP, и версия PHP напрямую влияет на скорость: каждая мажорная ветка 8.x ощутимо быстрее предыдущей. Сайт на PHP 7.4 может исполнять код вдвое медленнее того же сайта на PHP 8.3 — при нулевых изменениях в самом WordPress.

WordPress 7.0 формально работает с PHP 7.4, но это минимум ради совместимости, а не рекомендация: PHP 7.4 не получает обновлений безопасности с конца 2022 года. Рекомендованная версия на 2026 год — PHP 8.3, а многие хостинги уже предлагают быстрый и поддерживаемый 8.4.

Как диагностировать. Панель хостинга → раздел PHP, или загляните в «Здоровье сайта» (Инструменты → Здоровье сайта → Информация → Сервер). Если там 7.x или ранний 8.0/8.1 — вы оставляете скорость на столе.

Нюанс. Не переключайте версию на проде вслепую: старый плагин или тема, несовместимые с новым PHP, дадут ошибку 500 или белый экран. Проверьте совместимость на тестовой копии, потом переключайте.

Причина 3. Нет страничного кеша

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

Как диагностировать. Во вкладке Network посмотрите заголовки ответа для HTML-документа. Плагины кеширования обычно добавляют что-то вроде x-cache: HIT или свой служебный заголовок. Нет таких заголовков и высокий TTFB на неавторизованном заходе — кеша, скорее всего, нет.

Механизм кеша должен быть один: серверный кеш хостинга или один плагин, но не оба сразу и не два плагина. Дубли дают конфликты вплоть до белого экрана. Какой плагин выбрать под ваш сервер, разобрали в сравнении плагинов кеширования.

Причина 4. Один тяжёлый плагин (а не «их много»)

Миф «много плагинов = медленно» вводит в заблуждение. Дело не в числе, а в весе: один page builder или «универсальный» плагин, делающий 300 запросов к базе на каждой странице, грузит сайт сильнее двух десятков лёгких. Считать плагины бессмысленно — надо взвесить каждый.

Как диагностировать. Поставьте бесплатный Query Monitor. Он показывает в админ-баре реальные цифры страницы: сколько запросов к базе, сколько времени заняло, и — ключевое — разбивку по плагинам. Обычно 2–3 плагина съедают львиную долю. Дальше решение простое:

• используете плагин — оставьте;
• не используете — удалите (даже деактивированный плагин остаётся в коде и обновлениях);
• функция нужна, но плагин тяжёлый — ищите лёгкую замену.

Ориентиры по подбору инструментов — в подборке лучших плагинов WordPress: важнее не количество, а вес и поддержка.

Причина 5. Картинки в оригинальном размере

Картинки — обычно половина веса страницы, а то и больше. Два греха: неправильный формат (тяжёлый JPEG/PNG вместо WebP или AVIF) и неправильный размер (фотография 4000 px, вставленная в блок шириной 400 px, — браузер всё равно качает все 4000).

Как диагностировать. Во вкладке Network отсортируйте запросы по размеру (колонка Size) и типу (Img). Если сверху висят изображения по 1–3 МБ — вот ваш LCP. Ещё быстрее: PageSpeed Insights прямо покажет «Показывайте изображения в подходящем формате» и «Правильно подбирайте размер изображений» с конкретным списком файлов и потенциальной экономией.

Причина 6. Сторонние скрипты и шрифты

Счётчики аналитики, пиксели соцсетей, виджеты чатов, карты, шрифты со стороннего CDN — каждый тянет свой запрос к чужому серверу, а их код исполняется в браузере посетителя. Именно сторонний JavaScript чаще всего портит INP (отзывчивость на клики) и добавляет секунды к загрузке, потому что вы не управляете скоростью чужих серверов.

Как диагностировать. В Network отфильтруйте запросы к внешним доменам (всё, что не ваш сайт). Каждый — кандидат на вопрос «он ещё нужен?». Три пикселя, два чата, четыре начертания шрифта, которые никто не читает, — типичная находка. В отчёте PageSpeed ищите «Уменьшите влияние стороннего кода» с разбивкой по доменам.

Причина 7. Раздутая база и WP-Cron

Со временем база обрастает мусором: сотни ревизий каждой записи, спам-комментарии в очереди, просроченные transient'ы, «хвосты» удалённых плагинов. Запросы к раздутым таблицам идут медленнее — и это бьёт в первую очередь по динамике (магазин, поиск, личный кабинет), где страничный кеш не спасает.

Отдельный тихий тормоз — WP-Cron. Он запускается не по расписанию, а на запросах живых посетителей: на каждом заходе WordPress проверяет, нет ли отложенных задач. На посещаемом сайте это лишняя работа на случайных запросах — иногда именно поэтому «то быстро, то медленно».

Как диагностировать. Query Monitor покажет медленные запросы к базе (подсвечивает красным те, что заняли много времени) и раздел с задачами cron. Размер базы видно в phpMyAdmin: таблицы wp_postmeta и wp_options на сотни мегабайт — сигнал к чистке. Ограничить ревизии можно в wp-config.php:

define( 'WP_POST_REVISIONS', 5 );
define( 'DISABLE_WP_CRON', true );

Вторая строка отключает запуск cron на посетителях — после этого добавьте в панели хостинга задание раз в 5–10 минут на wp-cron.php или wp cron event run --due-now, иначе отложенные задачи (публикации по расписанию, письма) просто перестанут выполняться.

Порядок диагностики: от дешёвого к дорогому

Собрали всё в один маршрут — идите сверху вниз, каждый шаг отсекает часть гипотез:

Шаг	Инструмент	Что смотрим	Вывод
1	DevTools → Network → TTFB	Высокий или низкий	Бэкенд или фронтенд
2	Здоровье сайта	Версия PHP	7.x → обновить
3	Заголовки ответа	Есть ли x-cache	Нет кеша → включить
4	Query Monitor	Запросы и время по плагинам	Найти тяжёлый плагин
5	Network → Img по размеру	Картинки > 500 КБ	Формат и размеры
6	Network → внешние домены	Сторонние скрипты	Убрать лишнее
7	Query Monitor + phpMyAdmin	Медленные запросы, размер базы	Чистка, серверный cron

Пройдя эти семь шагов, вы будете знать не «сайт медленный», а «TTFB 900 мс из-за PHP 7.4 и отсутствия кеша, плюс hero-картинка на 2 МБ» — а это уже не проблема, а список задач.

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

Медленный WordPress лечится не коллекционированием плагинов, а диагностикой. Снимите метрики (PageSpeed Insights + вкладка Network), найдите виновника по маршруту выше, сделайте один шаг и замерьте снова. Один — потому что если менять пять вещей разом, вы не узнаете, какая сработала, а какая сломала вёрстку.

И не переезжайте на новый хостинг первым же действием: перенос лечит только причину №1, а если сайт тормозит из-за темы и картинок, он будет так же тормозить на любом сервере — просто дороже. Сначала измерение, потом счёт.