Если страницы WordPress стали тяжёлыми, а в отчётах Lighthouse или PageSpeed Insights слишком много запросов, проблема часто не в одном «тяжёлом» файле, а в наборе лишних подключений: стили и скрипты от темы, плагинов и встроенных функций WordPress. Полностью переписывать тему для этого не нужно. Обычно достаточно понять, что именно загружается на конкретной странице, и отключить только то, что там не используется.
Работать лучше аккуратно: сначала найти источник подключения, потом проверить, не нужен ли он на других страницах, и только после этого отключать. Такой подход безопаснее, чем массово вырезать всё подряд по советам из интернета.
Что именно можно отключать без переделки темы
В WordPress подключаются два основных типа ресурсов: стили через `wp_enqueue_style()` и скрипты через `wp_enqueue_script()`. Источником может быть тема, плагин или сам WordPress. Отключать стоит только то, что действительно не используется на конкретной странице.
Чаще всего безболезненно убирают:
- стили и скрипты плагинов, которые нужны только на отдельных страницах;
- блоки и библиотеки, которые тема подключает «на всякий случай»;
- эмодзи, oEmbed и другие встроенные функции WordPress, если они вам не нужны;
- дублирующиеся библиотеки, когда один и тот же функционал загружается несколькими плагинами.
А вот с файлами, которые отвечают за меню, слайдеры, формы, галерею, валидацию или поведение темы, нужно быть осторожнее. Если отключить такой ресурс на нужной странице, можно сломать интерфейс или отправку формы.
Сначала найдите, что именно грузится
Самая частая ошибка — отключать ресурсы вслепую. Сначала нужно увидеть список подключений на конкретной странице. Для этого подойдут браузерные инструменты разработчика и отчёты аудита производительности.
Проверка в браузере
Откройте страницу сайта, нажмите F12 и перейдите во вкладку Network. Обновите страницу и отфильтруйте запросы по типу CSS и JS. Так вы увидите, какие файлы реально загружаются, с каких доменов и сколько их на странице.
Если нужно понять, какой файл принадлежит теме или плагину, смотрите на путь в URL. Обычно это что-то вроде `/wp-content/themes/...` или `/wp-content/plugins/...`. Это уже хороший ориентир: если файл идёт из плагина, его можно отключать точечно, не затрагивая весь сайт.
Проверка через исходный код
Иногда удобнее открыть исходный HTML страницы и найти подключение по имени файла. Это помогает понять, не добавляет ли ресурс сам WordPress, тема или конкретный плагин. Для этого достаточно посмотреть исходник и поискать `wp-content`, `wp-includes` или название плагина.
Если файл подключается только на одной странице, а не на всём сайте, это уже кандидат на точечное отключение. Если он нужен на нескольких шаблонах, отключать его глобально нельзя.
Самый безопасный способ: отключать через код в дочерней теме
Если у вас есть доступ к файлам темы, надёжнее всего отключать лишние подключения через `functions.php` дочерней темы или через небольшой собственный плагин. Так изменения не пропадут после обновления основной темы.
Для снятия подключения используются функции `wp_dequeue_style()`, `wp_deregister_style()`, `wp_dequeue_script()` и `wp_deregister_script()`. В большинстве случаев достаточно `wp_dequeue_*`, если нужно убрать уже зарегистрированный и подключённый файл. `wp_deregister_*` применяют реже, когда нужно полностью удалить регистрацию ресурса.
Пример: если плагин подключает ненужный стиль на всех страницах, можно убрать его так:
add_action( 'wp_enqueue_scripts', function () {
wp_dequeue_style( 'plugin-style-handle' );
}, 100 );Здесь `plugin-style-handle` — это не имя файла, а handle, то есть внутренний идентификатор подключения. Его нужно узнать заранее. Обычно он виден в коде плагина или в списке ресурсов, если использовать инструменты для анализа подключений.
Для скрипта логика та же:
add_action( 'wp_enqueue_scripts', function () {
wp_dequeue_script( 'plugin-script-handle' );
}, 100 );Приоритет `100` нужен, чтобы ваш код выполнился после того, как тема и плагины уже зарегистрировали свои файлы. Если поставить слишком ранний приоритет, отключение может не сработать.
Как отключать только на нужных страницах
Глобальное отключение подходит не всегда. Чаще полезнее убрать ресурс только там, где он не нужен. Например, стили формы комментариев на страницах без комментариев или скрипт слайдера на страницах, где слайдера нет.
Для этого используют условные теги WordPress: `is_front_page()`, `is_page()`, `is_single()`, `is_home()`, `is_archive()` и другие. Пример для отключения скрипта только на главной:
add_action( 'wp_enqueue_scripts', function () {
if ( is_front_page() ) {
wp_dequeue_script( 'plugin-script-handle' );
}
}, 100 );Если нужно убрать ресурс только на странице контактов, логика будет такой:
add_action( 'wp_enqueue_scripts', function () {
if ( is_page( 'contacts' ) ) {
wp_dequeue_style( 'plugin-style-handle' );
}
}, 100 );Здесь `contacts` — это slug страницы. Такой подход безопаснее, чем отключать ресурс по всему сайту, если он нужен хотя бы на одной важной странице.
Что можно убрать без кода, если не хочется лезть в functions.php
Если вы не хотите править код вручную, есть плагины для управления подключениями. Они удобны, когда нужно быстро отключить ресурсы на конкретных страницах через интерфейс. Но и здесь важно не превращать сайт в набор случайных выключателей: сначала проверяйте, что именно отключаете, и тестируйте результат.
Для владельца сайта такой вариант часто проще, если нужно работать без разработчика. Например, в Clearfy Pro есть инструменты для отключения части лишних функций WordPress и чистки сайта от ненужных подключений. Это не заменяет ручную диагностику, но помогает убрать типовые лишние ресурсы без правки темы. Если задача именно в сокращении дублей и отключении части встроенных функций, такой инструмент может сэкономить время.
Но даже с плагином принцип тот же: сначала находите источник, потом отключаете точечно, потом проверяете страницу в браузере и в отчёте производительности.
Что обычно отключают в WordPress без заметного риска
Ниже перечислены подключения, которые часто можно убрать, если вы понимаете, что они вам не нужны. Это не универсальный список для всех сайтов, а практический ориентир.
- Emoji-скрипты WordPress — если вы не используете встроенные эмодзи в старом виде и не зависите от этой функции.
- oEmbed — если вам не нужно автоматическое встраивание контента по ссылке.
- Стили и скрипты плагинов — если плагин используется только на одной странице, а подключение идёт везде.
- Библиотеки темы — например, слайдеры, анимации, иконки, если на части страниц они не нужны.
Но не стоит отключать всё подряд только ради уменьшения числа запросов. Один лишний файл иногда весит меньше, чем последствия от сломанного интерфейса или формы. Смысл оптимизации — убрать то, что не участвует в работе страницы.
Как проверить, что отключение сработало и ничего не сломалось
После каждого изменения откройте страницу в обычном браузере и проверьте, что работает всё важное: меню, кнопки, формы, галереи, слайдеры, всплывающие окна, если они есть. Затем снова посмотрите список запросов в Network и убедитесь, что ненужный файл исчез.
Полезно сравнить страницу до и после в одном и том же инструменте аудита. Если количество запросов уменьшилось, а интерфейс не пострадал, вы всё сделали правильно. Если что-то сломалось, верните отключённый handle и ищите более точечный способ: например, отключать ресурс только на части страниц, а не глобально.
Ещё один практический момент: после правок очистите кэш, если на сайте есть кэш-плагин, серверный кэш или CDN. Иначе вы можете смотреть на старую версию страницы и сделать неверный вывод, что изменения не сработали.
Типичные ошибки, из-за которых сайт ломается
Самая частая ошибка — отключить файл по названию, не проверив, где он используется. Вторая — убрать не тот handle, потому что имя файла и внутренний идентификатор не совпадают. Третья — отключить ресурс на фронтенде, а потом обнаружить, что он нужен в админке или на странице редактирования.
Чтобы не попасть в такую ситуацию, придерживайтесь простого порядка:
- сначала найдите источник подключения;
- проверьте, где именно он нужен;
- отключайте только на конкретной странице или типе страниц;
- после каждого изменения тестируйте сайт в браузере;
- держите под рукой способ быстро вернуть код назад.
Если правите `functions.php`, делайте это через дочернюю тему или через отдельный мини-плагин. Так вы не потеряете изменения при обновлении основной темы и сможете быстро откатить правку, если что-то пойдёт не так.
В итоге задача сводится не к «очистке всего лишнего», а к точному управлению подключениями. Когда вы понимаете, что грузится, откуда и на каких страницах это действительно нужно, WordPress можно заметно облегчить без полной переделки темы и без риска сломать рабочие элементы сайта.