Если страница WordPress открывается медленно, причина не всегда в «тяжёлых» картинках или слабом хостинге. Часто тормозит именно количество HTTP-запросов: браузер вынужден отдельно запрашивать стили, скрипты, шрифты, изображения, иконки и сторонние виджеты. Чем больше таких обращений, тем дольше стартует отрисовка страницы, особенно на мобильных устройствах и при нестабильной сети.
Чтобы ускорить сайт, сначала нужно понять, что именно грузится, а уже потом убирать лишнее. На практике это даёт больше пользы, чем бездумное сжатие всех файлов подряд.
Как посмотреть количество HTTP-запросов на странице
Самый надёжный способ — открыть страницу в браузере и посмотреть список сетевых запросов. Для этого подойдут инструменты разработчика в Chrome, Edge или Firefox. Они показывают не только число запросов, но и то, какие из них действительно влияют на загрузку.
Откройте нужную страницу, затем:
- нажмите
F12илиCtrl+Shift+I; - перейдите во вкладку
Network; - обновите страницу с открытой панелью;
- посмотрите список запросов и итоговое число внизу панели.
Полезно смотреть не только общий счётчик, но и типы файлов. Обычно на WordPress-странице вы увидите:
document— сам HTML-документ;stylesheet— CSS-файлы темы и плагинов;script— JavaScript;image— изображения и иконки;font— веб-шрифты;xhrилиfetch— запросы скриптов, виджетов и некоторых плагинов.
Если запросов много, не спешите удалять всё подряд. Важно понять, какие из них критичны для первого экрана, а какие можно отложить или убрать совсем.
Что именно чаще всего создаёт лишние запросы в WordPress
На типичном сайте лишние обращения к серверу появляются не из-за одной причины, а из-за набора мелких источников. Чаще всего это:
- тема, которая подключает несколько CSS и JS-файлов даже на простых страницах;
- плагины, которые загружают свои стили и скрипты на всём сайте, хотя нужны только в одной зоне;
- внешние шрифты и иконки;
- большое число изображений в первом экране;
- встраивания с внешних сервисов: карты, видео, чаты, счётчики, рекламные блоки;
- блоки и виджеты, которые подтягивают дополнительные файлы на каждой странице.
Отдельно стоит смотреть на запросы к сторонним доменам. Даже если сам файл небольшой, браузер тратит время на DNS, установку соединения и TLS-рукопожатие. Для внешних ресурсов это особенно заметно.
Как понять, какие запросы можно убрать без вреда
Здесь важен практический подход: не удалять всё, а оставить только то, что действительно нужно для работы страницы. В инструментах разработчика удобно отсортировать запросы по типу и посмотреть, что загружается на первом экране, а что появляется только из-за вспомогательных функций.
Ориентируйтесь на такой принцип:
- если файл нужен для видимой части страницы, его лучше не трогать;
- если скрипт относится к форме, слайдеру, попапу или виджету, который есть не на всех страницах, его можно ограничить по месту загрузки;
- если ресурс не влияет на контент и не нужен пользователю сразу, его можно отложить или заменить более лёгким вариантом.
Хороший пример — скрипт контактной формы, который подключается на всех страницах, хотя форма есть только на странице «Контакты». В таком случае разумнее загружать его только там, где он нужен.
Что реально уменьшает число HTTP-запросов
Уменьшение запросов — это не одна настройка, а набор точечных действий. Ниже — те, которые обычно дают ощутимый эффект именно на WordPress-сайте.
Убирать неиспользуемые стили и скрипты
Многие темы и плагины подключают свои файлы глобально. Если вы уверены, что конкретный стиль или скрипт не нужен на части страниц, его можно отключить выборочно через код темы или дочерней темы. Для этого используют wp_dequeue_style() и wp_dequeue_script() в хук wp_enqueue_scripts.
Пример нужен только как ориентир: перед отключением проверьте, не сломает ли это интерфейс или функциональность.
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_page( 'contact' ) ) {
wp_dequeue_script( 'contact-form-script' );
wp_dequeue_style( 'contact-form-style' );
}
}, 100 );Здесь важно, что contact-form-script и contact-form-style — это реальные handle файлов, а не произвольные названия. Их нужно смотреть в коде темы, плагина или через инструменты диагностики.
Ограничивать загрузку плагинов по страницам
Если плагин нужен только в одной части сайта, не стоит держать его активным для всего фронтенда без необходимости. Иногда достаточно отключить его вывод на отдельных шаблонах, а иногда — заменить тяжёлый плагин более простым решением. Это особенно заметно для плагинов с фронтенд-скриптами: слайдеров, галерей, форм, рейтингов, чатов и социальных кнопок.
Перед удалением плагина проверьте, не использует ли его тема или другой плагин. Если зависимость есть, сначала найдите замену или ограничьте загрузку только нужными страницами.
Объединять и сокращать только там, где это уместно
Раньше часто советовали объединять CSS и JS в один файл. Сейчас это не универсальная рекомендация. На HTTP/2 и HTTP/3 большое число файлов не всегда так критично, как раньше, а неудачное объединение может наоборот ухудшить кэширование и усложнить отладку.
Практически полезнее не «склеивать всё», а убрать лишнее и уменьшить объём того, что действительно нужно. Если у вас много мелких файлов от одного плагина, сначала проверьте, можно ли отключить часть из них. Объединение имеет смысл только после диагностики и если вы понимаете, как это повлияет на кэш и обновления.
Отложить неважный JavaScript
Часть скриптов не нужна для первого экрана. Их можно загружать с атрибутом defer или async, если это не ломает порядок выполнения. Это не уменьшает число запросов, но сокращает блокировку рендера и делает страницу отзывчивее.
Важно не путать ускорение отрисовки с уменьшением количества запросов. Скриптов станет столько же, но браузер начнёт показывать страницу раньше. Для некоторых сайтов это даёт больший эффект, чем попытка сократить каждый файл.
Упростить шрифты и иконки
Веб-шрифты часто создают лишние запросы незаметно для владельца сайта. Один набор шрифтов с несколькими начертаниями может дать несколько отдельных файлов. Если дизайн позволяет, оставьте один-два начертания вместо четырёх-пяти. Ещё лучше — использовать системные шрифты там, где это не мешает визуальной задаче.
С иконками похожая история: если тема подключает целую библиотеку ради пары значков, это лишняя нагрузка. Иногда выгоднее встроить SVG только для нужных элементов, чем держать большой набор иконок на каждой странице.
Не тащить внешние сервисы без необходимости
Видео, карты, чаты и виджеты соцсетей часто создают десятки дополнительных запросов. Если сервис не обязателен на первом экране, лучше заменить его лёгкой заглушкой с загрузкой по клику. Это особенно заметно на мобильных устройствах, где каждый внешний запрос добавляет задержку.
Например, вместо автоматической загрузки встроенного видео можно показать превью и подгружать плеер только после нажатия. Это уменьшает не только количество запросов, но и объём данных на старте.
Как проверить, что стало лучше после изменений
После оптимизации не ограничивайтесь субъективным ощущением. Снова откройте страницу в Network и сравните:
- общее число запросов;
- количество запросов к сторонним доменам;
- размер переданных данных;
- время до появления основного контента;
- наличие ошибок загрузки в консоли.
Полезно проверять страницу в режиме инкогнито и с очищенным кэшем, а затем отдельно — после повторной загрузки. Так вы увидите разницу между первой загрузкой и кэшированным сценарием.
Если после отключения файла что-то перестало работать, верните изменение и проверьте зависимости. Обычно проблема не в самой идее оптимизации, а в том, что скрипт был нужен другой части интерфейса, о которой сразу не подумали.
На что не стоит тратить время без диагностики
Есть несколько распространённых действий, которые часто делают «для ускорения», но без проверки они дают мало пользы или создают новые проблемы:
- массовое объединение всех CSS и JS в один файл;
- слепое удаление библиотек, которые используются темой или плагинами;
- отключение всех внешних ресурсов без понимания, что именно они делают;
- установка нескольких оптимизаторов одновременно, которые начинают конфликтовать друг с другом.
Если у вас уже есть кэш-плагин или оптимизатор, сначала посмотрите, какие именно функции он выполняет. Два инструмента, которые одновременно минифицируют, объединяют и откладывают скрипты, нередко мешают друг другу и усложняют диагностику.
Владельцу сайта обычно достаточно пройти три шага: посмотреть список запросов, убрать очевидно лишнее и перепроверить результат. Этого уже хватает, чтобы заметно сократить время открытия страниц без рискованных экспериментов с кодом и настройками.