Если сайт на WordPress стал заметно медленнее, не обязательно сразу ставить ещё один оптимизационный плагин. Часть проблем можно убрать вручную: сжать изображения, сократить лишний JavaScript и CSS, почистить шаблон, проверить кэширование на сервере и убрать лишнюю нагрузку от самой установки WordPress. В реальной работе это часто даёт более предсказуемый результат, чем набор универсальных настроек из плагина, который может конфликтовать с темой или другим кодом.
Ниже — только те шаги, которые действительно можно сделать без отдельного оптимизационного плагина. Где есть риск сломать верстку или доступ к сайту, я это отдельно отмечу.
Сначала поймите, что именно тормозит сайт
Ускорение лучше начинать не с хаотичной «чистки», а с понимания узкого места. Иначе легко потратить время на изображения, когда основная проблема в тяжёлом шаблоне или медленном сервере.
Проверьте страницу в PageSpeed Insights или в DevTools браузера. Смотрите не на общий балл, а на конкретные признаки:
- долго грузится первый ответ сервера — проблема в хостинге, кэше или PHP;
- страница открывается, но долго «достраивается» — обычно тяжёлые скрипты, стили, шрифты или изображения;
- много запросов к сторонним доменам — виджеты, счётчики, карты, рекламные блоки;
- медленно работает админка — часто виноваты плагины, автозагрузки в базе или слабый сервер.
Это важно: ручная оптимизация работает лучше, когда вы устраняете конкретную причину, а не пытаетесь «ускорить всё сразу».
Изображения: самый быстрый ручной выигрыш
На большинстве сайтов именно изображения дают самый заметный запас для ускорения. Здесь не нужен плагин, если вы готовы один раз привести медиафайлы в порядок и дальше загружать их правильно.
Загружайте изображения в подходящем размере
Не стоит загружать в WordPress картинку с камеры на 4000 пикселей по ширине, если на сайте она показывается в 1200 пикселей. Браузер всё равно будет скачивать исходник, а потом уменьшать его на лету.
Практика простая: перед загрузкой подгоняйте изображение под реальный размер в макете. Для большинства контентных сайтов достаточно ширины 1200–1600 пикселей для больших иллюстраций и меньших размеров для превью.
Используйте современные форматы, если это поддерживает ваш браузерный сценарий
WordPress умеет отдавать WebP, если файл загружен в этом формате и сервер не мешает его обработке. Это не магия, а просто более компактный формат по сравнению с JPEG и PNG. Для фотографий обычно подходит WebP, для графики с прозрачностью — тоже, но не всегда без потерь по качеству.
Если вы не хотите менять весь медиаконтент, начните с новых изображений. Старые можно постепенно заменить по мере обновления материалов.
Проверьте, не выводятся ли лишние размеры изображений
WordPress создаёт несколько промежуточных размеров для каждой загруженной картинки. Это нормально, но если тема или плагин регистрируют слишком много размеров, медиатека разрастается, а на сервере появляется лишняя нагрузка.
Если вы уверены, что какие-то размеры не используются, их можно убрать из темы или дочерней темы через functions.php. Но здесь нужна аккуратность: сначала проверьте, где именно используется размер, иначе можно сломать сетку карточек или блоков.
Сократите вес и количество скриптов
Часто сайт тормозит не из-за WordPress как системы, а из-за того, что тема и дополнительные блоки загружают слишком много CSS и JavaScript на каждой странице. Убрать это вручную можно, но лучше делать точечно.
Отключайте то, что не нужно на конкретных страницах
Если на сайте есть скрипты, которые нужны только в одном разделе, не стоит грузить их везде. Например, карта, слайдер или форма обратной связи не должны подключаться на каждой странице.
В теме или дочерней теме это обычно делают через wp_dequeue_script() и wp_dequeue_style() в хук wp_enqueue_scripts. Пример ниже показывает общий принцип:
add_action('wp_enqueue_scripts', function () {
if ( ! is_page('contacts') ) {
wp_dequeue_script('contact-form-script');
wp_dequeue_style('contact-form-style');
}
}, 100);Здесь важно знать точные handle скрипта или стиля. Их можно посмотреть в коде темы, в подключениях плагина или через инструменты разработчика. Если ошибиться с именем, ничего не произойдёт; если отключить не тот файл, можно сломать форму, меню или верстку.
Не злоупотребляйте внешними сервисами
Сторонние виджеты часто добавляют больше задержки, чем кажется: чат, карты, счётчики, рекламные сети, шрифты с внешнего CDN. Если сервис не критичен для конверсии, подумайте, нужен ли он вообще.
Особенно осторожно относитесь к:
- нескольким системам аналитики одновременно;
- встраиваемым картам на каждой странице контактов;
- внешним шрифтам с большим количеством начертаний;
- скриптам, которые блокируют отрисовку страницы.
Иногда достаточно оставить один набор шрифтов и один счётчик, а остальное убрать. Это даёт более заметный эффект, чем косметическая минификация.
Почистите и упростите шаблон
Тема WordPress может быть тяжёлой сама по себе. Если шаблон перегружен визуальными эффектами, лишними обёртками и универсальными блоками «на все случаи жизни», сайт будет медленнее даже на хорошем хостинге.
Уберите лишние элементы из шаблонов
Посмотрите, что реально нужно на страницах:
- автор, дата, рубрики и теги — не всегда обязательны;
- сайдбар — часто только утяжеляет страницу;
- слайдер на главной — почти всегда тяжелее статичного первого экрана;
- лишние блоки в шапке и подвале — добавляют HTML, CSS и запросы.
Если тема позволяет, отключайте ненужные элементы через настройки. Если нет — правьте шаблоны в дочерней теме. Это безопаснее, чем менять файлы родительской темы напрямую: обновление их не перезапишет.
Проверьте, не тянет ли тема слишком много ресурсов
Некоторые темы подключают библиотеки и стили даже там, где они не используются. Например, иконки, анимации, слайдеры, стили для блоков, которые на странице отсутствуют. Это не всегда критично, но на слабом сервере и мобильных устройствах заметно.
Если тема позволяет отключить отдельные модули, используйте это. Если нет — стоит оценить, не проще ли перейти на более лёгкий шаблон. Для WordPress это часто более честное решение, чем бесконечно «допиливать» тяжёлую тему.
Проверьте серверные настройки, которые не требуют плагинов
Даже идеально собранная страница будет открываться медленно, если сервер отвечает долго. Здесь многое зависит от хостинга, версии PHP и доступных модулей. Часть настроек можно проверить и включить без плагинов, но иногда это уже зона поддержки хостинга.
Обновите PHP до поддерживаемой версии
WordPress работает быстрее на актуальных версиях PHP, а старые версии обычно медленнее и менее безопасны. Если у вас ещё используется устаревший PHP, это один из первых кандидатов на улучшение.
Перед обновлением проверьте совместимость темы и плагинов на тестовой копии сайта. На старом коде обновление PHP может вызвать предупреждения или белый экран. Если тестовой копии нет, хотя бы сделайте резервную копию файлов и базы данных.
Включите серверный кэш, если он доступен
На уровне хостинга может быть доступен OPcache для PHP, а также кэширование страниц на стороне сервера. Это не плагин, а инфраструктурная настройка, и она часто даёт лучший эффект, чем попытка кэшировать всё на уровне WordPress.
Если сайт на Apache или LiteSpeed, проверьте, поддерживает ли тариф серверный кэш. На Nginx и Apache с PHP-FPM тоже можно добиться хорошего результата, но конкретная схема зависит от конфигурации хостинга. Если вы не администрируете сервер сами, попросите поддержку включить OPcache и уточнить, есть ли page cache на уровне сервера.
Проверьте сжатие и заголовки ответа
Для статических файлов полезны gzip или Brotli, а для кэширования — корректные заголовки Cache-Control. Обычно это настраивается на сервере или в панели хостинга. Если у вас есть доступ к конфигу, можно проверить, не отключено ли сжатие случайно.
На Apache это часто делается через .htaccess, на Nginx — в конфигурации сервера. Но если вы не уверены, лучше не править это вручную на боевом сайте без бэкапа: одна ошибка в конфиге может уронить весь домен.
Уберите лишнюю нагрузку от самой установки WordPress
Иногда сайт медленный не из-за фронтенда, а из-за того, что WordPress делает слишком много фоновой работы. Это тоже можно частично разгрузить вручную.
Сократите автозагрузку в базе данных
Многие плагины и тема сохраняют настройки в таблице wp_options с автозагрузкой. Если таких записей слишком много, WordPress тратит лишнее время на каждый запрос, даже когда эти данные не нужны на странице.
Проверить это можно через phpMyAdmin или другой доступ к базе. Ищите большой объём в автозагружаемых опциях и удаляйте только то, что точно относится к удалённым плагинам или старым настройкам. Здесь легко навредить, поэтому без понимания структуры таблицы лучше не удалять записи наугад.
Ограничьте лишние ревизии и фоновые задачи
WordPress хранит ревизии записей, а также выполняет фоновые задачи через WP-Cron. На небольшом сайте это нормально, но при большом количестве контента и частых правках база может разрастаться.
Если ревизий слишком много, можно ограничить их количество в wp-config.php:
define('WP_POST_REVISIONS', 5);Это не ускорит уже существующую базу мгновенно, но поможет не раздувать её дальше. Для сайтов с активным трафиком полезно также перевести WP-Cron на системный cron, если хостинг это позволяет. Тогда фоновые задачи будут запускаться стабильнее и не будут зависеть от визитов пользователей.
Как проверить, что сайт действительно стал быстрее
После изменений не ориентируйтесь только на ощущение «кажется, стало лучше». Проверьте результат теми же инструментами, которыми смотрели исходную проблему.
- сравните время ответа сервера до и после;
- посмотрите, уменьшился ли общий вес страницы;
- проверьте, не выросло ли число запросов;
- откройте сайт в мобильной сети или через throttling в DevTools;
- убедитесь, что не сломались формы, меню, галереи и адаптивная верстка.
Если после отключения скрипта или стиля что-то перестало работать, верните изменение и ищите более точечный способ. В ручной оптимизации лучше убрать один лишний ресурс, чем случайно сломать важную функцию сайта.
На практике самый разумный порядок такой: сначала изображения, потом тяжёлые скрипты и шаблон, затем сервер и база. Если сайт всё ещё медленный после этих шагов, проблема уже не в «настройках WordPress», а в хостинге, теме или архитектуре проекта. Тогда ручная оптимизация всё ещё возможна, но без анализа конкретного узкого места она быстро упирается в потолок.