Если сайт на WordPress простой, а в коде страницы всё равно тянется длинный список CSS и JavaScript-файлов, часть из них действительно можно убрать. Но отключать всё подряд нельзя: некоторые стили и скрипты нужны теме, блоку редактора, комментариям, эмодзи или встроенным функциям ядра. Ошибка здесь обычно проявляется не сразу — сначала ломается мелкая верстка, потом перестают работать формы, меню или слайдеры.
Правильный подход такой: сначала понять, что именно подключается, затем проверить, используется ли это на конкретных страницах, и только после этого отключать точечно. Для этого не нужен тяжёлый редизайн сайта или переписывание темы с нуля.
Что именно можно отключать без риска
Речь не о полном удалении всех ресурсов WordPress, а о точечной чистке. На многих сайтах можно безопасно убрать:
- эмодзи-скрипт WordPress, если он не нужен;
- стили и скрипты, связанные с комментариями, если комментарии отключены;
- стили блоков Gutenberg на страницах, где нет блоков редактора;
- ненужные стили и скрипты плагинов, которые не используются на всех страницах;
- встроенные библиотеки, если их уже подключает тема или другой плагин, но только после проверки зависимостей.
А вот ресурсы темы, критические стили интерфейса, скрипты меню, формы, корзины, слайдера или галереи отключать нужно только если вы точно понимаете, откуда они берутся и кто их заменяет.
Сначала проверьте, что реально грузится на странице
Самый надёжный способ — открыть страницу сайта в браузере и посмотреть список подключений. В Chrome и Edge это делается через инструменты разработчика: вкладка Network, фильтр по CSS и JS. Перезагрузите страницу и посмотрите, какие файлы приходят с домена сайта, а какие — от внешних сервисов.
Для WordPress полезно смотреть не только на количество файлов, но и на их источник. Если файл идёт из /wp-includes/ или /wp-content/plugins/, можно понять, ядро это, тема или плагин. Если ресурс загружается только на одной странице, а нужен на всём сайте, это уже повод проверить, нельзя ли ограничить его вывод.
Ещё один практичный способ — временно отключить плагины по одному на тестовой копии сайта и сравнить список подключений. Так проще найти источник лишнего CSS или JS, чем гадать по названию файла.
Как отключать встроенные стили и скрипты через functions.php
Если ресурс подключается через WordPress-хуки, его можно снять через wp_dequeue_style(), wp_dequeue_script() и при необходимости wp_deregister_style(), wp_deregister_script(). Обычно это добавляют в functions.php дочерней темы или в небольшой функциональный плагин. Так безопаснее, чем править файлы родительской темы: обновление не затрёт изменения.
Ниже пример, который отключает эмодзи WordPress. Это один из самых частых и безопасных кандидатов, если на сайте не нужна встроенная поддержка эмодзи в старых окружениях.
add_action( 'init', function () {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );
} );Этот код убирает и фронтенд, и админку. Если вам нужно оставить эмодзи в админке, удалите только фронтенд-строки.
Для отключения стилей блоков Gutenberg на страницах, где они не нужны, используют более аккуратный подход. Но здесь важно понимать: если на странице есть блоки редактора, их стили нужны. Поэтому отключать их глобально можно только на очень простых сайтах, где контент собран без блоков WordPress.
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_admin() ) {
wp_dequeue_style( 'wp-block-library' );
wp_dequeue_style( 'wp-block-library-theme' );
wp_dequeue_style( 'global-styles' );
}
}, 100 );Здесь есть важная оговорка: global-styles относится к глобальным стилям темы и редактора блоков. Если тема активно использует блоки или стили из Site Editor, отключение может поломать внешний вид. На классических темах без блокового оформления этот приём часто помогает убрать лишний CSS, но проверять его нужно на каждой странице отдельно.
Как отключать стили и скрипты плагинов точечно
Если лишний ресурс добавляет плагин, лучше отключать его не глобально, а только там, где он не нужен. Для этого сначала нужно узнать его handle — внутреннее имя стиля или скрипта. Его можно увидеть в коде плагина или через инструменты отладки, если ресурс подключён через стандартные функции WordPress.
Пример: плагин подключает скрипт на всех страницах, а нужен он только на странице контактов. Тогда логика будет обратной — не отключать на одной странице, а включать только там, где он нужен. Но если плагин не даёт удобного условия, можно снять его на всех страницах кроме нужной:
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_page( 'contacts' ) ) {
wp_dequeue_script( 'plugin-script-handle' );
wp_dequeue_style( 'plugin-style-handle' );
}
}, 100 );Замените plugin-script-handle и plugin-style-handle на реальные имена ресурсов. Если вы не уверены в handle, не подставляйте его наугад: в лучшем случае код не сработает, в худшем — вы начнёте отключать не тот файл и долго искать причину поломки.
Когда лучше не трогать встроенные ресурсы WordPress
Есть несколько ситуаций, в которых отключение встроенных стилей и скриптов даёт больше проблем, чем пользы.
- Сайт использует блоки Gutenberg, шаблоны блоков или стили из Site Editor.
- Тема опирается на встроенные стили WordPress для типографики и отступов.
- На сайте есть комментарии, AJAX-формы, всплывающие окна, меню с мобильным переключателем.
- Вы не тестировали изменения на staging-копии и хотите править сразу на боевом сайте.
В этих случаях лучше не отключать всё глобально, а убирать только очевидно лишнее: эмодзи, неиспользуемые стили плагинов, ресурсы, которые нужны только на отдельных шаблонах.
Как проверить, что после отключения ничего не сломалось
После каждого изменения откройте несколько типовых страниц: главную, запись, страницу, архив, контактную форму, страницу с комментариями, если они есть. Смотрите не только на визуальную часть, но и на поведение:
- не съехала ли сетка;
- работает ли мобильное меню;
- открываются ли модальные окна и выпадающие элементы;
- не исчезли ли отступы и шрифты;
- не перестали ли работать формы и кнопки отправки;
- нет ли ошибок в консоли браузера.
Если что-то сломалось, откатите последнее изменение и проверьте, какой именно ресурс был связан с проблемой. На практике чаще всего ломаются не «встроенные стили WordPress» как таковые, а стили темы или плагина, которые ошибочно приняли за лишние.
Что даёт более аккуратную чистку, чем массовое отключение
На простом сайте можно добиться заметного упрощения фронтенда без агрессивной оптимизации. Но эффект появляется не от количества удалённых строк кода, а от точности. Если убрать только то, что не используется на конкретном сайте, вы уменьшите число запросов и вес страницы, не рискуя версткой.
Если нужна более удобная ручная чистка без постоянного редактирования кода, можно использовать плагины оптимизации, которые умеют отключать отдельные стили и скрипты по страницам. Но даже в этом случае принцип остаётся тем же: сначала диагностика, потом точечное отключение, затем проверка на реальных страницах.
Для сайтов, где нужно не только убрать дубли и лишние подключения, но и навести порядок в технической части WordPress, часто используют Clearfy Pro: он помогает управлять частью служебных функций и чистить сайт без ручного вмешательства в каждую мелочь. Но и с таким инструментом не стоит отключать всё подряд — сначала смотрите, что именно он собирается убрать.
Если действовать аккуратно, встроенные стили и скрипты WordPress можно сократить без поломки верстки. Главный принцип здесь простой: отключайте только то, что вы проверили на конкретном сайте, а не то, что кажется лишним по названию файла.