Сайт тормозит, а GTMetrix показывает 130+ HTTP-запросов на страницу?

Это не абстрактная цифра из отчёта. Каждый запрос, обращение браузера к серверу за файлом: скриптом, стилем, картинкой, шрифтом. Чем их больше, тем дольше посетитель смотрит на белый экран. По данным Portent, задержка загрузки с 0 до 3 секунд снижает конверсию на 2,5%. А каждая лишняя секунда сверх того, ещё минус 4,4%.

Проблема HTTP-запросов, не в том, что они есть. А в том, что большинство сайтов на WordPress генерирует их в разы больше, чем нужно. Ниже, пять конкретных шагов, которые сокращают количество запросов без переписывания сайта с нуля.

💡 Быстрый обзор:

• Удалите неиспользуемые плагины и темы, которые создают лишние запросы на каждой странице
• Оптимизируйте изображения: сожмите файлы, уберите неиспользуемые картинки, объедините иконки в спрайты
• Объедините CSS и JavaScript в 1-2 файла и включите минификацию
• Настройте отложенную загрузку для скриптов, блокирующих рендеринг страницы
• Подключите кеширование и CDN, чтобы повторные посетители не грузили сайт заново

Шаг 1. Удалите мусор

Каждый установленный плагин тянет за собой файлы. PHP, CSS, JavaScript, любой из них создаёт HTTP-запрос при загрузке страницы. Плагинов двадцать штук, запросов уже под сотню просто на старте, до контента.

Первое, что стоит сделать, аудит. Откройте Plugins → Installed Plugins и честно ответьте: какие из них критичны для работы сайта, а какие висят «на всякий случай»? SEO-анализатор, который вы поставили год назад и открыли дважды, кандидат на удаление. Плагин для вставки иконок соцсетей, тоже, если вы и так вывели ссылки в футере.

Отдельная категория, плагины, которые подключаются к сторонним серверам. Live-чат, радио, push-уведомления. Каждый такой плагин создаёт дополнительные внешние HTTP-запросы к серверам третьих сторон. Удалите всё, без чего сайт функционирует. Нужен раз в месяц? Установите на день и удалите.

То же правило работает для тем. В Appearance → Themes держите только активную тему и одну запасную (например, стандартную Twenty Twenty-Five). Остальные, в корзину.

Если плагин нужен, но только на конкретной странице, загружайте его выборочно. Для этого есть Asset CleanUp: Page Speed Booster, бесплатный плагин со 100 000+ активных установок и рейтингом 4,7 на WordPress.org.

Плагин сканирует страницу, показывает список загруженных CSS и JS и позволяет отключить отдельные файлы на конкретных страницах, типах записей или для всего сайта. Нужна Contact Form 7 только на странице контактов, снимите галочку с остальных страниц, и её скрипты не будут грузиться там, где форма не используется.

🔗 Asset CleanUp на WordPress.org

Кстати, заодно оптимизируйте базу данных, после чистки плагинов в таблицах остаются настройки и записи, которые тоже стоит убрать. И проверьте битые ссылки, каждый редирект это лишний HTTP-запрос.

Чтобы наглядно увидеть масштаб проблемы до и после, протестируйте сайт в GTMetrix:

Первый прогон покажет исходную картину: количество запросов, общий размер страницы, время загрузки. После каждого шага из этой статьи, повторяйте тест. Так вы увидите, что именно дало наибольший эффект.

Шаг 2. Оптимизируйте изображения

Изображения, главный «вес» среднестатистической страницы WordPress. По данным HTTP Archive, на десктопе картинки занимают около 44% от общего объёма страницы. И каждое изображение, это HTTP-запрос.

Начните с удаления неиспользуемых файлов. В Media → Library отфильтруйте «Unattached», это картинки, которые не прикреплены ни к одной записи. Если они не используются в теме или в футере, удаляйте.

Дальше, сжатие. Плагины вроде WP Compress делают это автоматически: при загрузке изображения оно прогоняется через облачный оптимизатор, сжимается без видимой потери качества и конвертируется в WebP или AVIF. Эти форматы заметно легче JPEG при том же визуальном качестве, по данным Google, WebP уменьшает размер файла в среднем на 25-35% по сравнению с JPEG.

У WP Compress 10 000+ активных установок, рейтинг 4,5 из 5 и более 1,1 миллиона загрузок на WordPress.org. Первые 100 изображений бесплатно, достаточно, чтобы оценить разницу.

🔗 WP Compress на WordPress.org

Сжатие само по себе не уменьшает количество HTTP-запросов. Но оно снижает размер каждого файла, а значит, время на его передачу. В связке с остальными шагами это даёт ощутимый прирост скорости.

CSS-спрайты: один файл вместо десяти

Если на странице десяток мелких иконок (соцсети, стрелки, звёзды рейтинга), каждая грузится отдельным запросом. CSS-спрайт решает эту проблему: все иконки собираются в один файл, а CSS показывает нужный фрагмент.

Принцип работы: пять картинок, пять запросов к серверу. Те же пять картинок, собранные в один спрайт, один запрос. Для создания спрайтов есть онлайн-инструменты вроде CSS Sprite Generator. Потребуется базовое знание CSS, задать background-position для каждой иконки.

Обратите внимание: если сервер поддерживает HTTP/2, файлы загружаются асинхронно в рамках одного соединения. В этом случае экономия от спрайтов менее заметна. Но на практике десяток иконок одним файлом всё равно загружается быстрее, чем десятью отдельными.

Шаг 3. Объедините и минифицируйте CSS и JavaScript

Типичная картина на WordPress-сайте: 40+ файлов JS и 20+ CSS. Каждый, отдельный HTTP-запрос. В сумме это 60+ обращений к серверу только за скриптами и стилями, которые грузятся до показа контента.

Минификация убирает из файлов всё лишнее: пробелы, переносы строк, комментарии. Файл становится легче, но количество HTTP-запросов не меняется.

Объединение склеивает несколько файлов в один. Было пять CSS, стало два (один для первого экрана, один для остального). Пять JS, аналогично. И запросов вместо десяти остаётся два-три.

Самый популярный бесплатный инструмент для этого, Autoptimize. Плагин с миллионом активных установок и рейтингом 4,7. В настройках, три галочки: оптимизировать HTML, CSS и JS. Включаете все три и получаете немедленный результат.

Для более тонкой настройки есть WP Rocket, премиум-решение, которое объединяет файлы, минифицирует их и добавляет кеширование в одном интерфейсе.

После объединения обязательно проверьте сайт в режиме инкогнито: иногда склеивание файлов ломает вёрстку. Если что-то поехало, отключите объединение для проблемного файла и оставьте только минификацию.

🔗 WP Rocket на официальном сайте

И ещё раз: объединение файлов, не панацея. Если плагин подгружает внешние скрипты с CDN (Google Fonts, reCAPTCHA, YouTube-плеер), объединить их не получится. Их можно только отложить или загружать асинхронно, об этом следующий шаг.

Шаг 4. Настройте блокирующие рендеринг скрипты

Браузер читает страницу сверху вниз. Когда он встречает <script src="..."> в <head>, он останавливает отрисовку, загружает скрипт полностью и только потом продолжает. Посетитель в это время видит пустую страницу.

Решение, перенести скрипты, которые не нужны для отрисовки первого экрана, вниз страницы или добавить атрибут async/defer. Разница:

• defer, скрипт загружается в фоне, но выполняется строго после HTML-парсинга и в порядке подключения;
• async, скрипт загружается и выполняется при первой возможности, порядок не гарантирован.

Для WordPress есть бесплатный плагин Async JavaScript. Он добавляет async или defer к выбранным скриптам через понятный интерфейс. Работает из коробки, но требует осторожности: если скрипт, добавленный через async, должен выполниться раньше другого, страница может сломаться.

Безопасный подход, протестировать на одном скрипте, проверить сайт в инкогнито, затем переходить к следующему.

WP Rocket тоже умеет откладывать скрипты: вкладка File Optimization → Load JavaScript deferred. Выберите «Deferred» и добавьте jQuery в исключения, большинство тем и плагинов WordPress от него зависят.

Результат: страница начинает отрисовываться раньше, даже если общее количество HTTP-запросов не изменилось. Посетитель видит контент, пока остальные скрипты догружаются в фоне.

Шаг 5. Подключите кеширование и CDN

Кеширование напрямую сокращает HTTP-запросы при повторных визитах. Механика проста: браузер сохраняет статические файлы (CSS, JS, изображения, шрифты) локально. При следующем открытии страницы вместо запроса к серверу он берёт файл из кеша. Ноль HTTP-запросов за этот файл.

Серверное кеширование, следующий уровень: сервер отдаёт уже собранную HTML-страницу вместо того, чтобы гонять десятки PHP-запросов к базе данных. Плагины кеширования (WP Rocket, Flying Press, W3 Total Cache) делают это автоматически.

CDN (Content Delivery Network), сеть серверов по всему миру. Вместо того чтобы тянуть файлы с вашего хостинга в Нидерландах для посетителя из Бразилии, CDN отдаёт их с ближайшего к нему узла. Плюс CDN-провайдеры часто включают сжатие, минификацию и оптимизацию изображений «из коробки».

Cloudflare, бесплатный вариант, который закрывает базовые потребности: CDN, защита от DDoS, бесплатный SSL.

Установите плагин Cloudflare для WordPress, он свяжет сайт с CDN и даст базовые настройки прямо из админки. Для более тонкой настройки зайдите в панель управления Cloudflare: включите Auto Minify для CSS/JS/HTML, Brotli-сжатие и Rocket Loader для асинхронной загрузки скриптов.

🔗 Cloudflare на WordPress.org

С кешированием и CDN количество HTTP-запросов для повторного посетителя падает радикально. Первый визит, полная загрузка. Второй, большинство файлов отдаётся из браузерного кеша и ближайшего CDN-узла без обращений к вашему серверу.

Бонус: проверьте, что сервер поддерживает HTTP/2

HTTP/2, протокол, который передаёт несколько файлов через одно TCP-соединение. Браузер не ждёт окончания загрузки файла №1, чтобы запросить файл №2, они грузятся параллельно. Это снижает эффект от большого количества HTTP-запросов: 60 файлов через HTTP/2 загружаются быстрее, чем те же 60 через HTTP/1.1.

Проверьте свой сервер через инструмент KeyCDN HTTP/2 Test, введите домен и нажмите «Test». Результат «HTTP/2 is supported» означает, что мультиплексирование работает.

Если тест показывает HTTP/1.1, обратитесь к хостеру. Большинство современных хостингов (SiteGround, Cloudways, Kinsta) включают HTTP/2 по умолчанию. На shared-хостингах 2010-х годов бывает иначе. Заодно проверьте версию PHP: переход на современную версию PHP даёт заметный прирост производительности, а устаревшие версии обрабатывают запросы кратно медленнее. Если хостер не обновляет ни протокол, ни версию PHP, возможно, пора задуматься о смене хостинга.

Если предпочитаете видеоформат, вот наглядное руководство по сокращению HTTP-запросов в WordPress (на английском, 12 минут).

⁉️🤔 Частые вопросы

Сколько HTTP-запросов считается нормальным для WordPress?

Ориентир, от 30 до 60 на страницу. Всё, что выше 80-90, повод для оптимизации. GTMetrix и Pingdom показывают конкретные цифры в своих отчётах. После применения пяти шагов из этой статьи реально опуститься с 130 до 35-45 запросов.

«У меня сайт на Elementor, там 100+ запросов и так. Это нормально?»

Конструкторы страниц генерируют много CSS и JS по своей природе. Elementor и Divi добавляют 30-50 запросов сами по себе. Это не значит «смириться», это значит, что остальной сайт должен быть максимально чистым. Уберите всё, что не относится к конструктору: лишние плагины, внешние шрифты, неоптимизированные картинки. Оставьте только то, что реально работает на посетителя.

Что важнее: количество запросов или общий размер страницы?

И то, и другое. 20 запросов по 1 МБ каждый, страница грузится 20 секунд. 100 запросов по 5 КБ, может загрузиться быстрее, но каждый запрос создаёт накладные расходы на DNS, TCP-соединение и TLS-рукопожатие. На HTTP/2 эта разница сглаживается. На HTTP/1.1, критично. Оптимизируйте оба параметра: сокращайте количество запросов через объединение файлов и спрайты, уменьшайте размер через сжатие и минификацию.

Можно ли обойтись без плагинов?

Частично да. Минификацию CSS/JS можно настроить через Gulp или Webpack на этапе сборки темы. HTTP/2 включается на уровне сервера (конфигурация Nginx/Apache). Кеширование, через серверные правила. Но для большинства владельцев WordPress-сайтов плагины, самый практичный путь: настройка за несколько минут, результат немедленный, риск сломать сайт ниже.

Как часто нужно перепроверять количество HTTP-запросов?

После каждой крупной установки или обновления плагина. Новый плагин может добавить свои CSS/JS на все страницы, и вы этого не заметите, пока сайт не начнёт тормозить. Раз в месяц, достаточная периодичность для рутинной проверки. GTMetrix позволяет настроить автоматический мониторинг с оповещением при падении производительности.

Нужен ли вообще этот гайд, если у меня и так быстрый хостинг?

Хостинг решает часть проблемы на уровне сервера, но не на уровне кода. Если плагин вставляет 15 скриптов в <head> страницы, даже топовый сервер не заставит их загрузиться мгновенно. Браузер всё равно будет ждать. Быстрый хостинг даёт фору, но выигрывает тот, кто чистит и клиентскую часть.

Что реально сокращает HTTP-запросы, а что, нет?

Пройдёмся по всем шагам без иллюзий:

• Чистка плагинов и тем, даёт самый заметный прирост. Каждый удалённый плагин убирает его CSS, JS и внешние вызовы. На практике после аудита уходит 10-30 запросов.
• Сжатие изображений, размер файлов уменьшается, количество запросов не меняется. Но суммарное время загрузки падает ощутимо.
• Объединение CSS и JS, сильно режет число запросов. Минус: может сломать вёрстку, проверяйте после каждого изменения.
• Отложенная загрузка скриптов, запросов столько же, но страница становится видимой раньше.
• Кеширование и CDN, для новых посетителей разница минимальна. Для повторных, повторная загрузка страницы без единого запроса к серверу.

Если бы мы выбирали ровно три действия, которые дают наибольший эффект на типичном WordPress-сайте: (1) удалить ненужные плагины, (2) включить объединение CSS/JS через Autoptimize, (3) поставить Cloudflare. Это три шага, которые занимают вечер, а не неделю, и которые вы увидите в цифрах GTMetrix уже на следующий день.