Когда сайт на WordPress начинает тормозить и как ускорить его без переезда на новый хостинг?

WordPress тормозит не из-за хостинга, а из-за накопленного слоя плагинов, неоптимизированных запросов к базе и раздутой медиатеки. Хостинг становится виноватым последним, хотя чаще всего проблема решается на уровне кода, кэша и структуры БД. Пока сайт грузится 4–6 секунд, растёт отказ на мобильных и падает конверсия в заявку. Переезд на новый хостинг без чистки сайта переносит те же тормоза на более дорогой тариф.

Ниже — практический разбор с критериями и следующим шагом. Связанные услуги: каталог, AI Boost Team, стать клиентом.

Как отличить тормоза WordPress от проблем хостинга

Сайт на WordPress грузится 5 секунд, и первое, что приходит в голову — сменить хостинг. В 8 из 10 случаев проблема внутри самого сайта. Переезд переносит те же тормоза на более дорогой тариф, только теперь вы платите вдвое больше за то же самое.

Начните с замера. Не «на глаз», не «мне кажется, стало медленнее». Нужны цифры, иначе вы будете оптимизировать наугад.

Что снять в первую очередь:

• TTFB на статичном HTML-файле (например, test.html в корне) и на главной странице WordPress. Если статика отдаётся за 0,2–0,3 с, а WP — за 1,5–3 с, хостинг ни при чём. Разница — это работа PHP и базы.
• Число SQL-запросов на страницу через Query Monitor. 80–150 запросов — типичная картина для сайта с 20+ плагинами без оптимизации. Норма для корпоративного блога — 20–50.
• LCP в Lighthouse на мобильном профиле. Если LCP выше 4 секунд, вы теряете мобильный трафик ещё до того, как человек увидит заголовок.
• Вес страницы и количество ресурсов. 50+ подключённых CSS и JS-файлов — сигнал, что тема и плагины грузят всё подряд.

Когда хостинг действительно виноват: TTFB на статике выше 1,5 с, в логах панели — постоянные CPU-throttling, сайт падает при 10 одновременных посетителях. Тогда да, инфраструктура. Но сначала исключите приложение.

Практический шаг: поставьте Query Monitor, откройте главную, раздел «Queries by Caller». Отсортируйте по времени. Первые 5 записей — ваши кандидаты на оптимизацию. Скорее всего, там будут запросы от плагинов, которые вы не используете, но они висят.

Аудит плагинов: что отключить первым

Дело не в количестве плагинов. 15 аккуратных плагинов работают быстрее, чем 5, каждый из которых на каждой загрузке страницы тянет внешний API. Проблема в том, что плагин делает, а не сколько их.

Порядок действий:

1. Соберите список активных плагинов и отметьте те, что делают внешние HTTP-запросы при загрузке страницы. Типичные примеры: плагины аналитики, чаты, виджеты отзывов, курсы валют, погода. Каждый такой запрос добавляет 0,3–0,8 с к TTFB, если внешний сервис отвечает медленно.
2. Найдите дублирование функций. Два кэш-плагина, три SEO-плагина, плагин оптимизации изображений поверх встроенного в тему. Оставьте по одному на функцию. Конфликты между ними дают не только тормоза, но и ошибки в вёрстке.
3. Проверьте на staging-копии. Не отключайте плагины на живом сайте. Сделайте копию, отключите подозрительные, замерьте TTFB и число запросов. Если разница меньше 0,2 с — плагин не виноват, ищите дальше.
4. Удалите, а не отключайте. Отключённый плагин оставляет таблицы в базе и записи в опциях. Если плагин не нужен — удалите его и почистите базу.

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

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

Кэширование без переезда: что доступно на текущем тарифе

Кэш — самый быстрый способ ускорить WordPress без переезда. Но не все виды кэша доступны на shared-хостинге. Разберём по слоям.

Начните со страничного кэша. WP Super Cache или W3 Total Cache — базовые варианты. Настройте так, чтобы кэш не отдавался авторизованным пользователям и не ломал корзину, если она есть. Проверьте, что после включения TTFB упал хотя бы до 0,8 с.

OPcache проверяется через phpinfo() или в панели хостинга. Если выключен — напишите в поддержку, часто включают по запросу. Это не требует смены тарифа.

Object cache — следующий уровень. Если хостер даёт Redis, подключите его через плагин (например, Redis Object Cache). Это снимет нагрузку с базы, но не ускорит сайт в 2 раза. Эффект заметен на сайтах с 100+ запросами на страницу.

Если Redis нет, не пытайтесь ставить его самостоятельно на shared-хостинге. Это закончится блокировкой аккаунта или неработающим сайтом. В таком случае сосредоточьтесь на страничном кэше и чистке базы.

Стоп-сигнал: если после включения кэша сайт начинает показывать разные версии страниц разным пользователям (например, залогиненным и нет), отключите кэш и настройте исключения. Кэш, который ломает логику, хуже, чем его отсутствие.

Чистка базы данных: ревизии, транзиенты, мусор

База WordPress растёт как снежный ком. Ревизии записей, транзиенты, спам-комментарии, таблицы от удалённых плагинов. Всё это замедляет запросы, особенно на слабом хостинге.

Что чистить:

• Ревизии записей. По умолчанию WordPress хранит каждое сохранение. Для блога с 50 постами это могут быть тысячи строк. Ограничьте количество ревизий в wp-config.php или удалите старые через WP-CLI.
• Транзиенты. Временные записи, которые часто остаются после удаления плагинов. Проверьте таблицу wp_options на записи с истёкшим сроком.
• Спам-комментарии. Если у вас открыты комментарии, в базе могут быть тысячи спам-записей. Очистите через админку или SQL.
• Таблицы от удалённых плагинов. Плагины вроде WooCommerce, форм обратной связи, SEO-инструментов создают свои таблицы. После удаления плагина они остаются. Проверьте список таблиц и удалите лишние.
• Автозагружаемые опции. В wp_options есть колонка autoload. Если там сотни записей, каждый запрос к базе тянет их все. Ограничьте автозагрузку для тяжёлых опций.

Для чистки используйте WP-CLI, если есть доступ к терминалу. Команды вроде wp post delete $(wp post list --post_type='revision' --format=ids) удаляют ревизии пачками. Если терминала нет — плагины вроде WP-Optimize, но они не всегда чистят всё.

Перед чисткой сделайте дамп базы. Одна неверная команда — и вы восстанавливаете сайт из бэкапа. Это не страшилка, это стандартная практика.

После чистки замерьте число запросов на страницу. Если было 150, а стало 80 — вы на правильном пути. Если не изменилось — проблема не в базе.

Изображения и медиа: WebP, размеры, CDN

Медиатека — второй по величине источник тормозов после плагинов. Изображения в JPEG и PNG весят в 2–3 раза больше, чем в WebP. Конвертация снижает вес на 25–35% без видимой потери качества.

Что делать:

1. Конвертируйте в WebP при загрузке. Плагины вроде WebP Express или Imagify делают это автоматически. Проверьте, что старые изображения тоже конвертируются, а не только новые.
2. Ресайзьте при загрузке. Не загружайте изображение 3000px, если оно отображается в 800px. WordPress создаёт несколько размеров, но если оригинал огромный, он всё равно грузится в некоторых случаях.
3. Включите ленивую загрузку. WordPress делает это с версии 5.5, но проверьте, что тема не отключает её. Ленивая загрузка не должна ломать вёрстку — если слайдер или галерея перестают работать, настройте исключения.
4. Подключите CDN. Если хостинг не даёт встроенного CDN, используйте Cloudflare или аналоги. Это снимет нагрузку с сервера и ускорит отдачу статики для пользователей из других регионов.

CDN даёт больше, чем оптимизация на сервере, если у вас геораспределённая аудитория. Для локального бизнеса в одном городе эффект меньше, но всё равно заметен.

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

Тема и скрипты: что грузится на каждой странице

Тема может тянуть десятки скриптов и шрифтов на каждой странице, даже если они не используются. Это не всегда вина разработчика темы — часто это настройки по умолчанию.

Аудит:

• Откройте исходный код страницы и посмотрите, сколько CSS и JS подключено. Если больше 20 файлов — есть что оптимизировать.
• Проверьте шрифты. Google Fonts, подключённые через тему, грузятся с внешнего сервера. Локальные шрифты быстрее, но требуют настройки.
• Отложите загрузку JS. Скрипты, которые не нужны для первой отрисовки, можно грузить с атрибутом defer или async. Плагины вроде Async JavaScript делают это автоматически.
• Объедините файлы. Если у вас 10 CSS-файлов, объединение в один снизит количество запросов. Но не объединяйте всё подряд — некоторые скрипты могут конфликтовать.

Если тема тянет десятки скриптов и шрифтов на каждой странице, смена темы может дать больше, чем все оптимизации вместе. Но перед сменой проверьте через Query Monitor, сколько запросов и ресурсов генерирует текущая тема. Если 50+ запросов только от темы — это повод задуматься.

Сторонние виджеты (чат, карты, соцсети) тоже грузятся на каждой странице. Если виджет не используется на 80% страниц, отключите его глобально и подключайте только там, где нужно.

Мониторинг: как не вернуться к проблеме через полгода

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

Что настроить:

• Cron-проверка TTFB. Скрипт раз в час замеряет TTFB главной страницы и пишет в лог. Если значение выше порога (например, 1,5 с), отправляет алерт на почту или в Telegram.
• Логи медленных запросов. Включите slow query log в MySQL, если хостер даёт доступ. Это покажет, какие запросы тормозят базу.
• Чек-лист после обновления плагинов. После каждого обновления проверяйте TTFB и число запросов. Новые версии плагинов могут добавить нагрузку.

Практический шаг: напишите простой скрипт на PHP или используйте сервис вроде UptimeRobot. Настройте алерт при TTFB выше 1,5 с. Это дешевле, чем раз в полгода разбираться, почему сайт снова тормозит.

Если у вас есть штатный разработчик на 0,2 ставки, включите проверку TTFB в его регулярные задачи. Раз в 2 недели — замер, раз в 6 месяцев — полный аудит.

Когда без переезда не обойтись

Оптимизация внутри WordPress даёт частичный эффект, если сайт упирается в ограничения хостинга. Вот случаи, когда переезд или смена архитектуры обоснованы:

• CPU-лимиты shared-хостинга. Если сайт стабильно упирается в лимиты процессорного времени, никакая оптимизация не поможет. Нужен VPS или выделенный сервер.
• Медленные внешние API в критичном пути. Если сайт не может работать без внешнего сервиса, который отвечает 2–3 секунды, кэширование не спасёт. Нужно либо кэшировать ответы, либо менять архитектуру.
• Тяжёлые хуки в дочерней теме. Если тема содержит хуки, которые нельзя отключить без переписывания, оптимизация даст мало. В этом случае смена темы или переписывание критичных участков — единственный выход.

Переезд на новый хостинг без чистки сайта перенесёт те же тормоза на более дорогой тариф. Сначала оптимизируйте то, что можете, замерьте результат. Если TTFB всё ещё выше 1,5 с на статике — тогда да, инфраструктура.

Для каталогов и лендингов с блогом часто достаточно оптимизации внутри WordPress. Если вам нужен аудит или помощь с настройкой, посмотрите наши решения для разработки или оставьте заявку — разберём ваш случай.

FAQ

Как понять, что тормозит именно WordPress, а не хостинг?

Замерьте TTFB на статичной HTML-странице и на странице WordPress. Если статика отдаётся быстро (0,2–0,3 с), а WP — медленно (1,5–3 с), проблема в приложении: плагины, запросы к БД, тема. Хостинг виноват, если статика тоже тормозит.

Сколько плагинов — это уже много?

Дело не в количестве, а в том, что каждый делает на каждой загрузке страницы. 15 аккуратных плагинов работают быстрее, чем 5, каждый из которых тянет внешние API. Смотрите на число SQL-запросов и внешних HTTP-запросов, а не на количество плагинов.

Можно ли ускорить сайт без доступа к серверу?

Частично. Кэш-плагин, оптимизация изображений, чистка базы и отклю