Если WordPress грузится медленно, а в отчётах Lighthouse или WebPageTest видно много запросов, чаще всего проблема не в одном «тяжёлом» месте, а в наборе мелочей: лишние подключения стилей и скриптов, повторные запросы к базе, тяжёлые блоки в шаблоне, внешние шрифты и картинки без нормальной оптимизации. Без плагинов это тоже можно заметно улучшить — за счёт правок в теме, дочерней теме и аккуратной настройке шаблонов.
Ниже — практические приёмы, которые реально уменьшают число запросов и снижают нагрузку на фронтенд. Они не требуют установки оптимизирующих плагинов, но предполагают, что вы можете редактировать файлы темы и понимаете, где именно у сайта формируется HTML, CSS и JS.
Сначала уберите то, что создаёт лишние запросы
Перед правками полезно понять, что именно раздувает страницу. Откройте страницу в браузере, посмотрите вкладку Network и обратите внимание на:
- количество CSS и JS-файлов;
- внешние домены: шрифты, карты, виджеты, счётчики;
- повторяющиеся запросы к одному и тому же ресурсу;
- тяжёлые изображения, которые грузятся сразу, хотя находятся ниже первого экрана.
Если на странице 20–40 запросов, это ещё не катастрофа. Но если половина из них идёт от темы и её мелких подключений, есть смысл чистить именно шаблон, а не пытаться «лечить» всё кэшем.
Отключите в теме всё, что не нужно на каждой странице
Самая частая ошибка — подключать один и тот же CSS и JS на всём сайте, даже если они нужны только на одной странице или в одном типе записей. В WordPress это можно исправить через wp_dequeue_style(), wp_dequeue_script(), wp_deregister_script() и точечные условия.
Пример: если тема подключает скрипт слайдера, а слайдер есть только на главной, не держите его на всех страницах. Добавьте в functions.php дочерней темы или в собственный mu-plugin такой код:
add_action('wp_enqueue_scripts', function () {
if (!is_front_page()) {
wp_dequeue_script('theme-slider');
wp_dequeue_style('theme-slider');
}
}, 100);Здесь важно знать точные handle ресурсов — то есть имена, под которыми тема их подключает. Их можно увидеть в коде темы или через отладку подключений. Если handle не совпадёт, WordPress ничего не отключит.
Такой подход особенно полезен для:
- слайдеров и галерей, которые нужны только на главной;
- стилей и скриптов блоков, если на странице нет соответствующих блоков;
- иконок, виджетов и библиотек, которые тема тащит «на всякий случай»;
- скриптов комментариев, если комментарии отключены или не используются.
Сократите количество CSS и JS, которые грузятся на каждой странице
Даже без плагинов можно уменьшить число запросов за счёт более аккуратной сборки ассетов. Идея простая: вместо десяти мелких файлов лучше отдать один-два, если это не ломает поддержку и не создаёт лишний вес.
Объединяйте только то, что действительно стабильно
Объединение файлов не всегда полезно. На HTTP/2 и HTTP/3 много мелких запросов уже не так страшны, как раньше, а вот один огромный файл может начать тормозить сильнее. Поэтому ориентируйтесь не на количество ради количества, а на смысл:
- базовые стили темы можно держать в одном основном файле;
- редкие стили отдельных шаблонов лучше подключать отдельно;
- скрипты, завязанные на конкретные блоки или страницы, не стоит тащить глобально.
Если вы сами правите тему, удобнее собрать общие стили в один основной файл, а всё остальное подключать по условию. Это уменьшает число запросов без лишнего риска.
Подключайте стили и скрипты только там, где они нужны
В WordPress для этого используют условные теги и контекст страницы. Например, на странице записи может понадобиться один набор ресурсов, а на архиве — другой. Пример:
add_action('wp_enqueue_scripts', function () {
if (is_singular('post')) {
wp_enqueue_style('single-post', get_stylesheet_directory_uri() . '/assets/css/single-post.css', [], '1.0');
}
if (is_page_template('templates/landing.php')) {
wp_enqueue_script('landing', get_stylesheet_directory_uri() . '/assets/js/landing.js', [], '1.0', true);
}
});Такой подход особенно полезен на сайтах, где тема сделана «универсально», но реально используется только часть её возможностей. Чем меньше лишнего CSS и JS на странице, тем ниже нагрузка на фронтенд и тем проще браузеру построить и отрисовать страницу.
Уберите лишние запросы к базе данных в шаблонах
На фронтенде WordPress может тормозить не только из-за файлов, но и из-за повторных запросов к базе. Это часто происходит в шаблонах, где разработчик несколько раз вызывает одни и те же данные внутри цикла или в разных частях страницы.
Типичный пример — когда в шапке, сайдбаре и подвале по отдельности запрашивается одна и та же настройка, список рубрик или меню. Если данные не меняются в рамках одного запроса, их лучше получить один раз и переиспользовать.
Не дёргайте одно и то же значение по нескольку раз
Если в шаблоне несколько раз вызывается get_theme_mod(), get_option() или похожая функция для одного и того же значения, сохраните результат в переменную:
$phone = get_theme_mod('header_phone');
$email = get_theme_mod('header_email');Это не магическая оптимизация, но на сложных шаблонах она помогает убрать лишние обращения и делает код чище. Особенно это заметно, когда такие вызовы стоят внутри повторяющихся блоков.
Осторожнее с произвольными запросами к записи и терминам
Если тема использует WP_Query для вывода похожих записей, последних постов, связанных рубрик и других блоков, следите за двумя вещами: не запускайте одинаковый запрос несколько раз и не выбирайте лишние поля.
Для запросов, где не нужен полноценный объект записи, иногда достаточно указать более узкие параметры. Например, если вам нужен только список ID, а не весь набор данных, это уменьшает объём работы:
$query = new WP_Query([
'post_type' => 'post',
'posts_per_page' => 5,
'fields' => 'ids',
'no_found_rows' => true,
'ignore_sticky_posts' => true,
]);Параметр no_found_rows полезен там, где не нужна пагинация с общим количеством страниц. Он убирает лишнюю работу SQL-запроса. Это реальная оптимизация для блоков «ещё записи», «похожие материалы» и похожих элементов интерфейса.
Сделайте шаблон проще: меньше блоков, меньше вложенности, меньше повторов
Иногда ускорение даёт не один «секретный» хук, а банальное упрощение шаблона. Чем больше вёрстка раздута повторяющимися обёртками, тяжёлыми виджетами и дублирующимися секциями, тем больше HTML на выходе и тем больше работы у браузера.
Посмотрите на страницы, где тема выводит:
- несколько одинаковых блоков с разными настройками;
- дублирующиеся меню для мобильной и десктопной версии;
- одни и те же иконки и SVG в каждом элементе списка;
- лишние секции, которые скрываются через CSS, но всё равно присутствуют в HTML.
Скрытый через display: none блок не создаёт отдельный сетевой запрос сам по себе, но он увеличивает HTML и усложняет рендер. Если блок не нужен на странице вообще, лучше не выводить его в шаблоне, а не прятать стилями.
Оптимизируйте изображения и не грузите тяжёлое раньше времени
Изображения часто создают больше запросов, чем CSS и JS вместе взятые, особенно если тема выводит несколько размеров одной и той же картинки. Здесь задача не только в сжатии, но и в том, чтобы браузер не тратил ресурсы на то, что пользователь ещё не видит.
Что стоит проверить в теме:
- используется ли правильный размер изображения через
the_post_thumbnail()илиwp_get_attachment_image(); - не подставляется ли в карточки слишком большой оригинал вместо подходящего размера;
- есть ли у изображений
widthиheight, чтобы уменьшить сдвиги макета; - не грузятся ли ниже первого экрана картинки без необходимости сразу.
Для изображений ниже первого экрана имеет смысл использовать нативную отложенную загрузку, которая уже поддерживается WordPress и браузерами. Но не стоит бездумно ставить loading="lazy" на всё подряд: логотип, первый экран и ключевое изображение лучше не откладывать, если это ухудшает восприятие.
Уберите внешние зависимости, которые вы не контролируете
Часть запросов уходит не на ваш сервер, а на сторонние домены: Google Fonts, карты, виджеты соцсетей, встроенные видео, рекламные скрипты, счётчики. Без плагинов это тоже можно сократить на уровне темы.
Самый практичный подход — оставить только то, что действительно нужно. Если шрифт используется один, его можно локально подключить в теме вместо обращения к внешнему сервису. Если иконки нужны в небольшом количестве, лучше использовать встроенный SVG, а не тащить целую библиотеку.
Для видео и карт особенно полезно не встраивать тяжёлый код сразу, а показывать превью и загружать внешний ресурс только после действия пользователя. Это не только уменьшает запросы на старте, но и заметно облегчает первый экран.
Проверьте, что оптимизация не сломала тему
После каждой правки проверяйте не только скорость, но и функциональность. Откройте главную, запись, страницу, архив и те шаблоны, где вы отключали ресурсы. Смотрите на:
- отсутствие ошибок в консоли браузера;
- работу меню, слайдеров, галерей, форм и табов;
- корректную загрузку стилей на мобильных устройствах;
- количество запросов в Network до и после правок.
Если после отключения файла что-то перестало работать, не возвращайте всё обратно целиком. Лучше найти конкретный handle и подключать ресурс только там, где он нужен. Так вы сохраните выигрыш в запросах и не сломаете интерфейс.
Ещё один полезный способ проверки — сравнить размер HTML и число запросов на одной и той же странице до и после изменения темы. Если запросов стало меньше, а визуально сайт остался тем же, значит оптимизация сработала правильно.
Что обычно даёт лучший эффект без плагинов
Если выбирать не всё подряд, а только самые результативные шаги, обычно быстрее всего дают эффект такие действия:
- отключение ненужных CSS и JS на страницах, где они не используются;
- перенос ресурсов на условную загрузку по шаблонам;
- уборка повторных запросов к базе в шаблонах;
- сокращение внешних зависимостей;
- чистка тяжёлых блоков, которые выводятся, но не нужны пользователю.
Именно эти правки уменьшают количество запросов и разгружают фронтенд без установки дополнительных плагинов. Если тема написана аккуратно, этого уже достаточно, чтобы заметно улучшить время загрузки. Если же тема сама по себе перегружена, оптимизация в коде поможет, но не заменит нормальную архитектуру шаблона.