Если WordPress стал заметно медленнее, а ставить еще один плагин не хочется, начинать нужно не с «ускорителей», а с поиска узкого места. Чаще всего тормозит не сам WordPress как система, а тема, тяжелые запросы к базе данных, лишние автозагрузки или код, который делает слишком много работы на каждом открытии страницы.
Без плагинов тоже можно получить ощутимый прирост. Но здесь важно идти по порядку: сначала понять, что именно тормозит, потом убрать лишнее в теме и только после этого разбираться с базой данных и запросами. Иначе легко потратить время на чистку того, что почти не влияет на скорость.
С чего начать: где именно теряется время
Если сайт стал медленным не после одного конкретного изменения, а «в целом», проверьте три зоны: тему, базу данных и запросы к серверу. Это самые частые источники проблем на обычных сайтах WordPress.
Признаки тоже обычно разные:
- страницы долго собираются, даже если контента немного — часто виновата тема или тяжелые запросы;
- админка открывается медленно — нередко проблема в базе данных, автозагрузке или слишком большом количестве записей в таблицах;
- одни страницы быстрые, а другие заметно тормозят — обычно это отдельные шаблоны темы или запросы в конкретных блоках, виджетах и циклах.
Перед любыми изменениями сделайте резервную копию базы данных и файлов. Если будете править тему или чистить таблицы вручную, откат может понадобиться быстрее, чем кажется.
Проверьте тему: именно она часто делает сайт тяжелым
Тема может быть медленной не из-за «плохого WordPress», а из-за того, как она собирает страницу. Типичные проблемы — слишком много запросов к базе, лишние вызовы функций в шаблонах, тяжелые слайдеры, встроенные библиотеки, большое количество скриптов и стилей, которые грузятся на каждой странице.
Что смотреть в первую очередь
Откройте проблемную страницу и сравните ее с простой записью или страницей без сложной верстки. Если разница большая, ищите в теме:
- слайдеры и анимации на главной;
- блоки «похожие записи», «популярное», «последние комментарии» и другие секции, которые делают дополнительные запросы;
- шаблоны, где выводятся десятки элементов в одном цикле;
- подключение скриптов и стилей на всех страницах, даже там, где они не нужны;
- встроенные шрифты, иконки и сторонние библиотеки, загружаемые без необходимости.
Если у темы есть отдельные настройки для отключения лишних блоков, используйте их. Это безопаснее, чем править шаблоны вручную. Когда настроек нет, уже имеет смысл смотреть в код темы.
Как понять, что проблема именно в шаблоне
Самый практичный способ — временно переключиться на стандартную тему WordPress, например на одну из дефолтных тем текущей версии. Если сайт заметно ускорился, причина почти наверняка в текущей теме или в ее дочерней теме.
Если вы не хотите менять тему на рабочем сайте, сравните скорость на тестовой копии. Это особенно полезно, когда сайт уже приносит трафик и нельзя рисковать внешним видом.
Еще один полезный ориентир — количество запросов внизу страницы, если у вас включен вывод отладки на тестовом стенде. Но полагаться только на число запросов не стоит: иногда запросов немного, а один из них очень тяжелый.
Уберите лишнее из базы данных
Со временем база данных WordPress разрастается не только из-за записей и страниц. В ней накапливаются ревизии, временные записи, спам-комментарии, удаленные комментарии, транзиенты и служебные данные от плагинов и темы. Если этого много, WordPress начинает тратить больше времени на поиск и сортировку данных.
Чистка базы данных не всегда делает сайт «в разы быстрее», но на перегруженных сайтах часто дает заметный эффект, особенно в админке и на страницах с большим количеством контента.
Что можно проверить без риска для контента
- Ревизии записей — если их сотни или тысячи, база раздувается без пользы.
- Автосохранения и черновики — обычно не критичны сами по себе, но в больших объемах тоже засоряют таблицы.
- Спам и корзина комментариев — особенно если сайт активно комментируют.
- Временные данные — transient-значения, которые давно не нужны.
- Старые данные от удаленных плагинов — если плагин удалили, а его таблицы и опции остались.
Удалять стоит только то, в чем вы уверены. Если не понимаете назначение конкретной таблицы или опции, лучше сначала выяснить, к чему она относится. Ошибка здесь может привести к потере настроек темы или плагинов.
На что обратить внимание в таблице wp_options
Для производительности особенно важна таблица wp_options. В ней хранятся настройки сайта, а также автозагружаемые опции — данные, которые WordPress подгружает на каждой странице. Если таких данных слишком много, сайт начинает тормозить еще до вывода контента.
Проблема обычно возникает, когда в автозагрузку попадают большие массивы данных от темы или плагинов. Это не видно на глаз, но хорошо заметно по медленной загрузке фронтенда и админки.
Если у вас есть доступ к phpMyAdmin или другому SQL-интерфейсу, можно посмотреть самые тяжелые автозагружаемые опции. Запрос ниже показывает крупные записи в wp_options с автозагрузкой:
SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 20;Здесь важно не удалять данные вслепую. Сначала посмотрите, что это за опции, и только потом решайте, можно ли их убрать или перенести из автозагрузки. Если запись относится к активной теме или важному плагину, удаление сломает настройки.
Найдите медленные запросы, а не просто «много запросов»
Когда сайт тормозит, проблема не всегда в количестве обращений к базе. Иногда один запрос, который тянет много строк без индекса или делает сложную выборку, съедает больше времени, чем десятки обычных запросов.
Без дополнительных плагинов искать такие места можно через инструменты хостинга, лог медленных запросов MySQL или временную отладку на тестовой копии.
Что реально помогает в диагностике
Если хостинг дает доступ к slow query log, это лучший вариант. В нем видно запросы, которые выполняются дольше заданного порога. Дальше уже можно понять, какой шаблон, функция или участок кода их вызывает.
Если доступа к логам нет, включите отладку WordPress только на тестовой копии сайта. Для этого в wp-config.php временно задают параметры отладки:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);После этого ошибки и предупреждения будут писаться в файл wp-content/debug.log. Это не полноценный профилировщик запросов, но он помогает увидеть повторяющиеся ошибки, которые часто и создают лишнюю нагрузку.
Если в логах появляются предупреждения о несуществующих индексах, неправильных аргументах запросов или ошибках в шаблонах, это уже повод смотреть в тему или в кастомный код. Такие ошибки не только засоряют лог, но и могут замедлять страницу.
Что обычно вызывает тяжелые запросы в теме
- вывод связанных материалов без ограничения по объему;
- сортировка по мета-полям, когда таблица
postmetaуже большая; - частые запросы к опциям внутри каждого элемента цикла;
- получение данных в шаблоне по одному элементу вместо одного общего запроса;
- сложные фильтры и выборки на архивных страницах.
Если у вас есть доступ к коду темы, ищите места, где внутри цикла вызываются функции, которые каждый раз идут в базу. Иногда достаточно вынести запрос за пределы цикла или сократить объем выбираемых данных.
Что можно исправить в теме без переписывания всего шаблона
Не всегда нужно менять тему целиком. Часто хватает точечной правки.
- Отключить блоки, которые не нужны на всех страницах.
- Убрать лишние скрипты и стили с тех страниц, где они не используются.
- Сократить количество элементов в списках и каруселях.
- Заменить тяжелые виджеты на более простую разметку.
- Не грузить изображения в полном размере там, где достаточно миниатюр.
Если вы правите functions.php или шаблоны дочерней темы, делайте это аккуратно: одна ошибка в PHP может положить сайт. Для правок лучше использовать дочернюю тему, а не менять исходные файлы родительской.
На практике самый безопасный путь — сначала отключить лишнее через настройки темы, потом проверить скорость, и только если этого мало, переходить к коду.
Как проверить, что сайт действительно ускорился
После каждого изменения измеряйте не «на глаз», а по одному и тому же сценарию. Откройте несколько типовых страниц: главную, запись, архив и страницу с самым тяжелым шаблоном. Сравните:
- время полной загрузки страницы;
- количество запросов к базе;
- размер HTML-ответа;
- нагрузку на админку, если вы чистили базу или опции.
Если у вас есть доступ к инструментам браузера, посмотрите вкладку Network и время ответа HTML-документа. Когда именно сервер отвечает медленно, проблема обычно в теме, базе или запросах. Если HTML приходит быстро, а страница все равно кажется медленной, тогда уже стоит смотреть в сторону фронтенд-ресурсов, но это отдельная задача.
Еще один полезный тест — повторить проверку после очистки кэша браузера и серверного кэша, если он есть. Иначе можно принять старую закэшированную версию за результат своих правок.
Когда без помощи разработчика не обойтись
Если после чистки базы и отключения лишнего сайт все равно тормозит, вероятно, проблема глубже: в архитектуре темы, в кастомных запросах, в большом объеме метаданных или в неудачной логике шаблонов. Здесь уже нужен разбор конкретного кода и профилирование запросов.
Но даже в этом случае вы не зря начали с базы и темы. Это самые частые и самые доступные точки, где можно убрать лишнюю нагрузку без установки дополнительных плагинов и без перестройки всего сайта.
Если коротко, порядок действий такой: сначала исключить тяжелую тему и лишние блоки, затем проверить автозагрузку и мусор в базе, после этого искать медленные запросы в логах или отладке. Такой подход обычно дает больше пользы, чем попытка «ускорить WordPress» одной настройкой или случайным плагином.