Если WordPress стал заметно медленнее, не спешите переезжать на другой хостинг. В большинстве случаев тормоза появляются не из-за самого сервера, а из-за конкретных узких мест: тяжёлых плагинов, больших изображений, лишних скриптов, разросшейся базы данных и запросов, которые выполняются на каждой странице. Эти проблемы можно найти и исправить на текущем хостинге, если действовать по порядку.
Сначала нужно понять, что именно замедляет сайт. Потом — убрать лишнюю нагрузку там, где она действительно есть. Такой подход обычно даёт больший эффект, чем установка очередного «ускорителя» без диагностики.
С чего начать: найти источник тормозов
Перед любыми настройками проверьте, что именно стало медленным: весь сайт, только главная, отдельные записи, админка или форма отправки. Это помогает сразу сузить круг причин. Например, если медленно открываются только страницы с большим количеством изображений, проблема почти наверняка не в базе данных. Если тормозит админка, чаще виноваты плагины, фоновые задачи или слишком тяжёлые запросы к базе.
Для первичной проверки достаточно трёх вещей:
- время ответа сервера в браузере или в инструментах разработчика;
- количество и размер загружаемых файлов;
- какие плагины добавляют больше всего запросов и скриптов.
Если у вас есть доступ к плагину для профилирования запросов, посмотрите, какие действия занимают больше всего времени. Если такого инструмента нет, начните с отключения недавно установленных и самых тяжёлых плагинов. Это самый быстрый способ понять, не они ли создают проблему.
Уберите тяжёлые плагины и лишние функции
Плагины — частая причина медленной работы WordPress. Проблема не в количестве как таковом, а в том, что один плагин может добавлять десятки запросов, подключать большие скрипты на всех страницах или регулярно обращаться к внешним сервисам.
Особенно внимательно проверьте плагины, которые:
- добавляют слайдеры, анимации, попапы и визуальные эффекты;
- подключают шрифты, иконки и библиотеки на каждой странице;
- создают сложные формы, фильтры, конструкторы или таблицы;
- синхронизируются с внешними API;
- сохраняют много данных в базе и регулярно пишут туда служебную информацию.
Если плагин нужен только на одной странице, не стоит держать его активным для всего сайта без необходимости. Многие скрипты можно ограничить по страницам через настройки самого плагина или через отдельные инструменты управления загрузкой ассетов. Это особенно полезно для форм, галерей, слайдеров и виджетов.
Удаляйте неиспользуемые плагины полностью, а не просто деактивируйте их. Отключённый плагин всё ещё может оставлять таблицы, опции и служебные данные в базе.
Оптимизируйте изображения, а не только сжимайте их
На медленных сайтах изображения часто дают самый заметный выигрыш после оптимизации. Но обычного сжатия недостаточно, если на страницу загружаются файлы в исходном размере 3000–4000 пикселей, а в шаблоне они показываются как маленькие превью.
Проверьте три момента:
- не загружаете ли вы слишком большие исходники;
- используются ли корректные размеры изображений в теме;
- есть ли у картинок отложенная загрузка для контента ниже первого экрана.
Если на сайте много старых изображений, имеет смысл пересоздать миниатюры после изменения размеров в теме. Иначе WordPress может продолжать использовать неподходящие варианты файлов.
Для новых изображений придерживайтесь простого правила: загружайте файл примерно того размера, который реально нужен на странице, а не «на всякий случай побольше». Это особенно важно для главных баннеров, карточек товаров, галерей и изображений в статьях.
Сократите вес и количество скриптов
Даже быстрый сервер будет ощущаться медленным, если страница тянет за собой слишком много JavaScript и CSS. Часто это происходит из-за темы, визуального конструктора, аналитики, чатов, рекламных вставок и сторонних виджетов.
Здесь полезно разделить проблему на две части:
- лишний код — то, что можно отключить совсем;
- код не на месте — то, что нужно загружать только там, где оно реально используется.
Например, если на сайте есть карта только на странице контактов, нет смысла подгружать её библиотеку на всех страницах. То же касается слайдеров, иконок, скриптов отзывов и виджетов социальных сетей.
Если тема сама по себе тяжёлая, проверьте, какие её модули можно отключить в настройках. Иногда достаточно убрать встроенные анимации, ненужные шрифты, эффекты параллакса и дополнительные библиотеки, чтобы страница стала ощутимо легче.
Отдельно посмотрите на сторонние сервисы: онлайн-чаты, счётчики, рекламные сети, трекеры и виджеты. Каждый такой скрипт добавляет задержку, а некоторые ещё и блокируют отрисовку страницы до загрузки внешнего ресурса.
Приведите в порядок базу данных
Со временем база WordPress разрастается: в ней накапливаются ревизии записей, автосохранения, временные записи, спам-комментарии, устаревшие транзиенты и служебные данные плагинов. На небольшом сайте это может быть незаметно, но на старом проекте база нередко становится одной из причин медленных запросов.
Что стоит проверить в первую очередь:
- количество ревизий у записей и страниц;
- спам и удалённые комментарии;
- временные данные, которые уже не нужны;
- таблицы плагинов, которые давно удалены, но оставили следы;
- слишком большие опции в таблице
wp_options.
Очистку базы лучше делать после резервной копии. Это не формальность: если удалить не то или сломать зависимость плагина, восстановление из бэкапа сэкономит много времени. Особенно осторожно нужно работать с таблицами, которые созданы сторонними плагинами, потому что не все из них безопасно чистятся штатными средствами WordPress.
Если сайт работает давно, полезно проверить автозагрузку опций. Когда в wp_options слишком много данных с автозагрузкой, WordPress тратит лишнее время на каждый запрос страницы, даже если эти данные нужны только в редких сценариях.
Уберите лишние запросы на каждой странице
Иногда сайт тормозит не из-за одного большого плагина, а из-за множества мелких запросов, которые выполняются постоянно. Это может быть вывод похожих записей, счётчики просмотров, проверка внешних сервисов, динамические блоки в сайдбаре или запросы к базе внутри шаблона темы.
Типичная ошибка — выводить на каждой странице то, что нужно только в одном месте. Например:
- похожие записи в сайдбаре на всех страницах;
- сложные виджеты с десятками условий;
- блоки, которые каждый раз обращаются к внешнему API;
- счётчики и рейтинги, обновляющиеся при каждом просмотре.
Если вы правите тему или дочернюю тему, проверьте шаблоны на повторяющиеся запросы внутри циклов. Запрос в цикле, который выполняется десятки раз, легко превращается в заметную задержку. В таких случаях помогает предварительная выборка данных, кэширование результата или перенос тяжёлой логики из шаблона в более простой вариант вывода.
Настройте кэширование там, где это реально помогает
Кэширование не лечит плохой код, но хорошо снимает нагрузку с сайта, если страницы часто открываются без персонализации. Для обычного контентного сайта это один из самых полезных способов ускорения без смены хостинга.
Имеет смысл использовать:
- страничный кэш для публичных страниц;
- кэш браузера для статических файлов;
- объектный кэш, если хостинг поддерживает Redis или Memcached;
- кэширование результатов тяжёлых запросов, если они повторяются.
Но кэш нужно настраивать аккуратно. Если на сайте много динамики — личные кабинеты, корзины, персональные блоки, формы с уникальным содержимым — не всё можно кэшировать одинаково. В таких случаях лучше исключить проблемные страницы из кэша, чем получить быстрый, но неправильный сайт.
После включения кэша проверьте не только главную страницу, но и записи, архивы, страницы с формами и административную часть. Иногда ускорение публичной части ломает обновление контента или мешает видеть изменения сразу после публикации.
Проверьте тему и шаблоны
Бывает, что WordPress и плагины настроены нормально, а медленность создаёт сама тема. Это особенно заметно у тяжёлых шаблонов с большим количеством встроенных эффектов, универсальных блоков и лишних зависимостей.
Обратите внимание на такие признаки:
- страница долго строится даже без активных плагинов;
- подключается много файлов CSS и JS из темы;
- в шаблонах используются сложные запросы к базе;
- на каждой странице выводятся одинаковые тяжёлые блоки;
- встроенные модули темы дублируют функции плагинов.
Если тема давно не обновлялась или написана без оглядки на производительность, иногда проще отключить её тяжёлые функции, чем пытаться компенсировать их плагинами оптимизации. Но менять тему целиком не обязательно: часто достаточно убрать лишние модули и оставить только нужный набор.
Как понять, что сайт действительно ускорился
После изменений не ориентируйтесь только на субъективное ощущение. Откройте несколько типовых страниц и сравните их до и после по трём параметрам: время ответа, размер страницы и количество запросов. Для WordPress этого обычно достаточно, чтобы увидеть, что именно дало эффект.
Проверяйте отдельно:
- главную страницу;
- обычную запись или страницу;
- страницу с изображениями;
- страницу с формой или другим динамическим блоком;
- админку, если она тоже тормозила.
Если после оптимизации сайт стал быстрее только в тесте, но не в реальной работе, значит вы ускорили кэш, а не саму проблему. В таком случае возвращайтесь к плагинам, скриптам и базе данных — именно там обычно остаётся основной запас.
На практике самый заметный результат даёт не одна «волшебная» настройка, а сочетание нескольких простых действий: убрать тяжёлые плагины, уменьшить изображения, сократить скрипты, почистить базу и включить кэш там, где он уместен. Это вполне реально сделать без переезда на другой хостинг, если не пытаться лечить всё сразу и вслепую.