Если сайт на WordPress стал заметно медленнее после обновления темы, плагинов или PHP, обычно проблема не в одном «тяжёлом» модуле, а в наборе мелких вещей: лишние запросы к базе, автозагрузка, неудачные хуки, сторонние скрипты, дублирующиеся стили и неаккуратная работа с редактором. Ниже — рабочий сценарий, как найти узкое место, исправить его без гадания и проверить, что просадка действительно ушла.
Когда проблема уже видна без профайлера
Сначала стоит понять, что именно сломалось. Если админка открывается дольше обычного, фронтенд «тяжелеет» после обновления, а в wp-admin появляются задержки при сохранении записей, это уже не абстрактная «медленная тема». В таких случаях полезно разделить симптомы:
- медленно открывается только главная или отдельные шаблоны;
- тормозит весь сайт, включая админку;
- замедление появляется только для неавторизованных пользователей;
- после обновления плагина выросло число запросов к базе;
- страница стала тяжелее из-за скриптов и стилей, а не из-за PHP.
Что проверить первым делом
Начинайте не с оптимизации кода, а с измерения. Без этого легко «лечить» не ту причину. Для WordPress достаточно трёх точек контроля: время генерации страницы, число запросов и размер фронтенда. Если есть доступ к серверу, дополнительно смотрите логи PHP-FPM и slow log MySQL, но даже без них можно собрать полезную картину через Query Monitor и инструменты браузера.
Диагностика: где именно теряется время
Самая частая ошибка — искать виноватый плагин по ощущениям. Правильнее идти от факта к источнику. Удобный порядок такой: сначала фронтенд, потом PHP, потом база данных.
1. Сравните проблемную и нормальную страницу
Откройте страницу, которая стала медленной, и страницу, которая работает нормально. Если разница только в одном шаблоне, почти наверняка проблема в теме или в коде конкретного блока. Если тормозят все страницы, чаще виноваты общие хуки, автозагрузка опций, внешние запросы или глобальные скрипты.
2. Посмотрите, что грузится на фронтенде
В DevTools браузера проверьте:
- сколько CSS и JS подключается;
- есть ли тяжёлые файлы от плагинов, которые не нужны на этой странице;
- не тянутся ли внешние ресурсы синхронно;
- нет ли цепочки редиректов у шрифтов, картинок и скриптов.
Если на странице загрузки много, но PHP отрабатывает быстро, оптимизация должна идти через отключение лишних ассетов на конкретных шаблонах.
3. Проверьте запросы в Query Monitor
Плагин Query Monitor показывает медленные запросы, вызовы хуков, HTTP-запросы и источники нагрузок. Это не «магия», а обычный способ увидеть, какой плагин или шаблон делает лишнюю работу. Особенно полезно смотреть:
- количество запросов на страницу;
- медленные запросы к
wp_postmeta,wp_options,wp_term_relationships; - внешние HTTP-запросы;
- ошибки PHP и предупреждения.
Пошаговое решение: от простого к точечному
Ниже — порядок, который обычно даёт результат без лишнего риска. Не нужно сразу переписывать тему. Сначала убираем очевидные потери, потом трогаем код.
Шаг 1. Отключите лишние ассеты на конкретных страницах
Если плагин или тема подключают стили и скрипты везде, а нужны они только в одном месте, их можно снять через wp_dequeue_script() и wp_dequeue_style(). Делать это лучше точечно, по условию.
<?php
add_action('wp_enqueue_scripts', function () {
if (is_page('contacts')) {
wp_dequeue_style('contact-form-7');
wp_dequeue_script('contact-form-7');
}
}, 100);Здесь важно не угадывать, а смотреть реальные handle в исходном коде страницы или через Query Monitor. Если указать неверный идентификатор, ничего не изменится, и это будет выглядеть как «оптимизация не работает».
Шаг 2. Уберите тяжёлые запросы из шаблона
Часто проблема в том, что тема на каждой странице делает запросы к записям, таксономиям или метаданным без кэширования. Если данные не меняются каждую секунду, их стоит сохранить в transient или хотя бы не запрашивать повторно в одном рендере.
<?php
function wpexperts_get_featured_posts_ids() {
$cache_key = 'wpexperts_featured_posts_ids';
$ids = get_transient($cache_key);
if (false !== $ids) {
return $ids;
}
$query = new WP_Query([
'post_type' => 'post',
'posts_per_page' => 6,
'no_found_rows' => true,
'fields' => 'ids',
'meta_key' => 'featured',
'meta_value' => '1',
]);
$ids = $query->posts;
set_transient($cache_key, $ids, HOUR_IN_SECONDS);
return $ids;
}Для повторяющихся выборок это обычно даёт более предсказуемую нагрузку, чем постоянные запросы к базе при каждом открытии страницы.
Шаг 3. Проверьте автозагрузку опций
Если в wp_options накопилось слишком много автозагружаемых записей, WordPress тратит лишнее время на каждый запрос. Это особенно заметно на сайтах с большим количеством плагинов, которые сохраняют настройки в autoload = yes без необходимости. Проверять нужно не «по размеру базы вообще», а именно по объёму autoload.
Безопасный способ посмотреть проблемные записи — через SQL-запрос в phpMyAdmin или Adminer:
SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;Если наверху списка лежат большие массивы настроек, которые не нужны на каждом запросе, это кандидат на перенос в неавтозагрузку. Но удалять или менять их вручную без понимания источника нельзя: сначала выясните, какой плагин их создаёт.
Шаг 4. Сократите работу на хуках
Иногда просадка появляется после добавления логики в init, wp_head или the_content. Проблема не в самом хуке, а в том, что код выполняется слишком часто или без условий. Если функция нужна только в админке, не вешайте её на фронтенд. Если логика нужна только для одной роли или одного типа записи, оборачивайте её в проверку.
<?php
add_action('wp', function () {
if (!is_singular('post')) {
return;
}
// Лёгкая логика только для одиночной записи.
});Сравнение подходов: плагин, код или сервер
| Подход | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Плагин для кэша/очистки | Нужно быстро убрать часть нагрузки без разработки | Быстрый старт, меньше ручной работы | Не всегда решает точечную проблему в теме |
| Код в теме или mu-plugin | Нужно отключить лишние ассеты, запросы, хуки | Точечный контроль | Требует аккуратности и тестирования |
| Серверная настройка | Проблема в PHP, OPcache, MySQL, кэше | Улучшает весь сайт | Нужен доступ к хостингу и понимание стека |
Если задача именно в WordPress-коде, серверные улучшения не заменяют исправление шаблона. И наоборот: если сайт упирается в слабый хостинг, даже хороший код не даст стабильного результата.
Проверка результата после внедрения
После изменений не ограничивайтесь субъективным «стало быстрее». Нужны повторяемые проверки. Сначала откройте ту же страницу в инкогнито и сравните:
- время полной загрузки в браузере;
- количество запросов;
- размер передаваемых файлов;
- число SQL-запросов и медленных запросов в Query Monitor;
- нагрузку на админку при сохранении записи.
Если вы отключали ассеты, убедитесь, что функциональность не сломалась: формы отправляются, слайдеры работают, кнопки и попапы открываются, а ошибки JavaScript не появились в консоли. Если меняли запросы к базе, проверьте страницу с пустым кэшем и после нескольких обновлений подряд — так видно, не создаёт ли код лишнюю работу при каждом рендере.
Что считать хорошим признаком
Хороший результат — это не только меньшая цифра в отчёте, но и стабильность. Если после исправления сайт перестал «плавать» по скорости от запроса к запросу, значит, вы убрали источник нестабильности, а не просто спрятали симптом кэшем.
Частые ошибки и как их исправить
- Отключают скрипт по неверному handle. Проверьте имя файла через исходный код страницы или Query Monitor.
- Удаляют ассеты глобально. В результате ломается форма, галерея или навигация на других шаблонах. Используйте условия по типу записи, странице или роли.
- Чистят autoload без понимания источника. Сначала найдите плагин-владельца опции, потом решайте, можно ли её менять.
- Ставят кэш на всё подряд. Кэш не исправляет тяжёлый запрос, если он каждый раз строится заново или содержит уникальные параметры.
- Оптимизируют только фронтенд. Админка, REST API и фоновые задачи тоже могут быть источником нагрузки.
Практические советы по безопасности и производительности
Любые изменения в теме или через сниппеты лучше вносить не в основной файл functions.php, а в отдельный mu-plugin или в дочернюю тему. Так проще откатить правку и не потерять её при обновлении. Перед удалением ассетов и оптимизацией запросов обязательно делайте резервную копию и тестируйте на staging-копии, если сайт рабочий.
Если вам нужен не разовый фикс, а системная чистка сайта, имеет смысл посмотреть в сторону инструментов, которые помогают убирать лишнее и контролировать технические настройки. Например, для части задач по очистке и SEO-оптимизации уместно использовать Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином принцип остаётся тем же: сначала диагностика, потом точечное изменение, потом повторная проверка.
Если после всех правок сайт всё ещё медленный, смотрите уже не только WordPress-код, но и стек целиком: версию PHP, OPcache, объём памяти, качество хостинга и работу базы. В большинстве случаев узкое место находится именно на стыке темы, плагинов и сервера, а не в одном «плохом» файле.