Если WordPress стал открываться медленно, а ставить ещё один плагин не хочется, начинать стоит не с «ускорителей», а с того, что реально создаёт задержку: тяжёлая тема, лишние запросы к базе, неудачная загрузка скриптов, отсутствие кэширования на уровне сервера и слишком большой объём того, что сайт отдаёт в браузер. Большую часть этого можно поправить без плагинов — через код темы, настройки WordPress и конфигурацию хостинга.
Ниже — набор базовых действий, которые обычно дают заметный эффект именно за счёт уменьшения лишней работы. Это не магия и не универсальная кнопка: если у вас слабый хостинг или тяжёлая тема, сначала нужно убрать очевидные узкие места, а уже потом смотреть на тонкую оптимизацию.
С чего начать: понять, что именно тормозит
Перед изменениями полезно хотя бы грубо разделить проблему на две части: медленно отвечает сервер или слишком тяжёлый фронтенд. Если страница долго «думает» до первого байта, проблема чаще в PHP, базе данных, запросах темы или хостинге. Если HTML приходит быстро, но страница долго становится интерактивной, обычно виноваты CSS, JavaScript, шрифты и лишние внешние ресурсы.
Проверить это можно без сложных инструментов. Откройте сайт в браузере, посмотрите время ответа в DevTools на вкладке Network и сравните его с общим временем загрузки. Если сервер отвечает быстро, но страница всё равно тяжёлая, оптимизировать нужно фронтенд. Если же первый ответ уже медленный, сначала имеет смысл смотреть в сторону кода темы, запросов к базе и серверных настроек.
Уберите лишнее из темы и шаблонов
Самая частая причина перегруза в WordPress — тема, которая делает слишком много. Это не всегда видно сразу: на странице может быть всего несколько блоков, но тема всё равно подгружает десятки файлов, иконки, шрифты, слайдеры, анимации и скрипты, которые на конкретной странице не нужны.
Что можно оптимизировать в коде:
- убрать из шаблонов подключение скриптов и стилей, которые не используются на всех страницах;
- отключить тяжёлые элементы интерфейса, если они не нужны: слайдеры, анимации, параллакс, встроенные виджеты;
- не тянуть внешние библиотеки, если задача решается стандартными средствами WordPress или чистым CSS;
- проверить, не дублируются ли стили и скрипты в дочерней теме и родительской теме одновременно.
Если вы работаете с собственной темой, подключайте ресурсы точечно. В WordPress для этого обычно используют wp_enqueue_scripts и условные проверки вроде is_front_page(), is_single() или is_page(). Смысл простой: не грузить то, что нужно только на одной странице, на всём сайте.
Например, если скрипт нужен только на странице контактов, его не стоит подключать в общий шаблон header.php. Лучше ограничить загрузку конкретным шаблоном или условием в functions.php. Это уменьшает число запросов и размер страницы без изменения функциональности.
Отключите то, что WordPress добавляет автоматически, но вам не нужно
WordPress по умолчанию включает несколько вещей, которые полезны не всем сайтам. Их можно отключить, если вы понимаете, что именно убираете. Здесь важно не «чистить всё подряд», а убрать только то, что действительно не используется.
Чаще всего на небольших проектах можно сократить лишнюю нагрузку за счёт:
- эмодзи-скриптов, если они не нужны;
- встраивания oEmbed, если сайт не использует автоподстановку внешних ссылок;
- лишних версий скриптов и стилей, если они подключаются повторно;
- ревизий записей в разумных пределах, если контент часто редактируется;
- автосохранений с слишком частым интервалом, если это не критично для редакторов.
Для отключения части встроенных возможностей обычно используют код в functions.php дочерней темы или в собственном мини-плагине. Если менять тему вы не хотите, лучше не править родительскую тему напрямую: при обновлении изменения потеряются.
Пример с ревизиями и интервалом автосохранения подходит только если вы понимаете последствия. Меньше ревизий — меньше мусора в базе, но и меньше точек отката. Для сайта с активной редактурой слишком агрессивно ограничивать ревизии не стоит.
Сократите количество запросов к базе данных
Медленная база данных часто проявляется не на большом магазине, а на обычном контентном сайте, который давно работает и накопил лишние записи. В WordPress это могут быть ревизии, временные данные, старые автосохранения, спам-комментарии и следы от удалённых плагинов.
Безопаснее всего начинать с того, что не затрагивает рабочий контент:
- удалить спам и корзину комментариев;
- очистить устаревшие transient-данные, если они не обновляются корректно;
- удалить старые ревизии, если их слишком много;
- проверить таблицы базы на избыточный размер и фрагментацию.
Если у вас есть доступ к phpMyAdmin или другому инструменту управления базой, сначала сделайте резервную копию. Любая операция с таблицами требует аккуратности: одна лишняя команда может удалить не только мусор, но и нужные данные. Если вы не уверены, лучше ограничиться ручной очисткой через админку WordPress и не трогать SQL напрямую.
Для сайтов с большим количеством записей полезно проверить, не делает ли тема или кастомный код тяжёлые запросы на каждой странице. Типичный пример — вывод похожих записей, связанных материалов или сложных выборок по метаданным без кэширования результата.
Настройте кэширование на уровне сервера, если хостинг это позволяет
Если вы не хотите ставить плагин, это не значит, что кэширование недоступно. На многих хостингах уже есть серверный кэш: Nginx FastCGI cache, LiteSpeed Cache на уровне сервера, Varnish или встроенные механизмы панели управления. Это не плагин WordPress, а часть инфраструктуры, и именно она часто даёт самый заметный эффект.
Что важно проверить:
- есть ли на тарифе серверный кэш;
- не отключён ли он для WordPress-сайта;
- не ломает ли кэш авторизацию, корзину, формы или личный кабинет;
- правильно ли настроены исключения для страниц, которые нельзя отдавать из кэша.
Если хостинг поддерживает полноценный page cache, это обычно лучше, чем пытаться компенсировать отсутствие кэша только кодом темы. Но кэширование должно быть совместимо с сайтом: для страниц с динамическим содержимым, авторизацией или персональными данными нужна отдельная настройка исключений.
Проверить работу кэша можно по заголовкам ответа в браузере или через curl -I https://example.com, если у вас есть доступ к консоли. Ищите признаки вроде HIT, MISS или заголовки, которые добавляет ваш серверный кэш. Названия зависят от конкретной системы, поэтому ориентируйтесь не на универсальную строку, а на поведение вашего хостинга.
Оптимизируйте загрузку CSS и JavaScript
Даже без плагинов можно заметно облегчить фронтенд. Самая полезная идея здесь — не пытаться «сжать всё подряд», а убрать лишнее и не блокировать рендеринг страницы.
Что имеет смысл сделать в коде темы:
- подключать скрипты в футере, если они не нужны в начале загрузки;
- не грузить библиотеку, если на странице нет элемента, который её использует;
- разделять стили по шаблонам, а не держать один огромный файл для всего сайта;
- убирать неиспользуемые CSS-правила из старых шаблонов и компонентов;
- не вставлять большие inline-скрипты в header без необходимости.
Если вы используете собственную тему, проверьте, нет ли у вас подключения скриптов через wp_head там, где они могут спокойно грузиться внизу страницы. Для JavaScript это особенно важно: скрипты в head часто задерживают отрисовку, если они не помечены как отложенные и не нужны сразу.
С CSS ситуация тоньше. Полностью откладывать стили нельзя, иначе страница будет «мигать» без оформления. Но можно убрать лишние файлы и не тащить на каждую страницу стили для блоков, которых там нет.
Сократите внешние ресурсы
Медленный сайт часто тормозит не из-за WordPress как такового, а из-за внешних запросов: шрифтов, картинок с чужих доменов, счётчиков, карт, виджетов и встроенных медиа. Каждый такой ресурс добавляет зависимость от чужого сервера и увеличивает время загрузки.
Практически полезные шаги:
- по возможности хранить шрифты локально, а не тянуть их с внешнего CDN;
- не вставлять на страницу лишние виджеты социальных сетей;
- ограничить число сторонних счётчиков и пикселей;
- проверить, не грузятся ли изображения с другого домена без необходимости;
- использовать локальные превью вместо тяжёлых внешних вставок.
Если внешний сервис отвечает медленно, ваш сайт будет ждать его ответа. Это особенно заметно на мобильных устройствах и при нестабильной сети. Чем меньше сторонних зависимостей, тем предсказуемее загрузка.
Проверьте изображения и медиаконтент
Картинки — один из самых частых источников лишнего веса страницы. Даже если сервер и код настроены нормально, тяжёлые изображения могут свести на нет всю оптимизацию. Здесь не нужен отдельный плагин, если вы готовы привести контент в порядок вручную.
Что стоит сделать:
- не загружать изображения больше, чем нужно для реального отображения на сайте;
- использовать современные форматы там, где это поддерживается и уместно;
- проверить, не вставлены ли в контент оригиналы с камеры вместо оптимизированных копий;
- убрать лишние размеры изображений, если тема их генерирует, но не использует.
WordPress сам создаёт несколько размеров изображений при загрузке. Это удобно, но на старых сайтах может разрастаться медиатека и нагрузка на диск. Если тема использует слишком много промежуточных размеров, имеет смысл пересмотреть её настройки или код, чтобы не плодить ненужные копии.
Когда без правки кода не обойтись
Если сайт медленный из-за темы или кастомной разработки, одних настроек WordPress может не хватить. Тогда оптимизация сводится к точечной правке кода: убрать лишние запросы, не грузить ресурсы на всех страницах, сократить работу шаблонов и не делать повторяющиеся вычисления при каждом открытии страницы.
Особенно полезно проверить:
- не выполняются ли тяжёлые запросы в цикле;
- не вызываются ли одни и те же данные несколько раз подряд;
- не используется ли
query_posts()там, где лучше обойтисьWP_Query; - не создаёт ли тема лишние обращения к метаполям и таксономиям;
- не рендерится ли большой блок HTML для каждой страницы, хотя он нужен только на части сайта.
Если вы не разработчик, не стоит бездумно переписывать шаблоны. Лучше сначала измерить, что именно тормозит, и уже потом менять конкретный участок. Иначе можно ускорить одну страницу и сломать другую.
Как понять, что стало лучше
После изменений проверьте не только скорость в браузере, но и фактическую нагрузку. Сравните:
- время ответа сервера до и после;
- количество запросов к базе на типовой странице;
- размер HTML, CSS и JavaScript;
- число внешних запросов;
- поведение сайта на мобильной сети.
Если вы отключали что-то в коде, откройте несколько разных типов страниц: главную, запись, страницу, архив и, если есть, шаблон с формой или поиском. Оптимизация часто ломает не очевидную страницу, а редкий шаблон, который редко проверяют вручную.
Хороший результат — это не только более низкое время загрузки в тесте, но и меньшее число лишних ресурсов, стабильная работа шаблонов и отсутствие ошибок в консоли браузера. Если после правок сайт стал быстрее, но появились визуальные или функциональные сбои, сначала откатите последнее изменение и проверьте его отдельно.
Если нужен более чистый и управляемый сайт без лишнего кода, часть задач по удалению дублей, чистке и упрощению WordPress можно закрыть и через Clearfy Pro, но для этой темы это уже не обязательный путь: базовую оптимизацию вполне реально сделать вручную, если у вас есть доступ к теме и настройкам хостинга.