Если на сайте WordPress грузится лишний CSS и JavaScript, не нужно сразу отключать всё подряд. У ядра есть набор встроенных стилей и скриптов, которые действительно могут быть не нужны на конкретном проекте: на лендинге, в блоге без комментариев, на сайте без эмодзи, без oEmbed и без встроенного редактора блоков на фронтенде. Задача не в том, чтобы «обнулить» WordPress, а в том, чтобы убрать только те ресурсы, которые не участвуют в работе темы и плагинов.
Правильный подход здесь один: сначала понять, что именно подключается, затем отключать выборочно и после каждого изменения проверять страницу в браузере. Если убрать не тот файл, можно сломать меню, формы, слайдеры, комментарии или стили блоков.
Какие встроенные ресурсы WordPress обычно можно отключать
У WordPress есть несколько типичных CSS и JS, которые часто оказываются лишними на части сайтов. Ниже — не список для бездумного удаления, а ориентир, с чего обычно начинают проверку.
- Emoji — скрипт и стили для эмодзи. На большинстве сайтов они не нужны, если вы не полагаетесь на старые браузеры и не хотите отдельную поддержку эмодзи через WordPress.
- oEmbed — скрипт, который помогает WordPress подставлять предпросмотр встроенного контента. Если вы не используете автоподстановку встраиваемых ссылок через ядро, его можно убрать.
- Dashicons — иконки админки. На фронтенде они нужны только если тема или плагин реально выводят эти иконки для посетителей.
- Block Library — стили редактора блоков на фронтенде. Если тема не использует стандартные блоки Gutenberg или переопределяет их своими стилями, часть этих файлов может быть лишней.
- Global styles — глобальные стили темы и блоков. Их отключают только после проверки, что тема не зависит от них визуально.
- wp-embed — отдельный скрипт для встраивания контента WordPress в WordPress. На многих сайтах он не нужен.
- Comment reply — скрипт для древовидных комментариев. Если комментарии отключены или не используются вложенные ответы, этот файл можно убрать.
Важно понимать: не все эти ресурсы подключаются всегда. Часть из них появляется только при определённых условиях — например, когда на странице есть комментарии, блоки, встроенные медиа или соответствующие функции темы.
Сначала проверьте, что именно загружается на странице
Отключать ресурсы вслепую не стоит. На практике сначала смотрят, какие файлы реально подключены на конкретной странице, а уже потом решают, что можно убрать.
Самый простой способ — открыть страницу сайта в браузере, вызвать инструменты разработчика и посмотреть вкладки Network или Sources. Там видно, какие CSS и JS файлы загружаются, откуда они пришли и сколько весят. Если нужен более удобный способ, можно использовать плагины для анализа ассетов, которые показывают список подключённых стилей и скриптов прямо в админке.
Ищите не только ядро WordPress, но и зависимости. Иногда файл кажется лишним, но его использует тема или плагин. Например, отключение стилей блока может испортить карточки записей, если тема опирается на стандартную разметку Gutenberg.
Как отключать встроенные стили и скрипты выборочно
Лучше всего делать это через дочернюю тему или через собственный мини-плагин. Не правьте ядро WordPress и не вносите изменения прямо в файлы темы, если не хотите потерять их после обновления.
Для отключения используют стандартные функции WordPress: wp_dequeue_script(), wp_deregister_script(), wp_dequeue_style() и wp_deregister_style(). Обычно достаточно wp_dequeue_*, если нужно убрать уже подключённый файл на фронтенде.
Ниже пример, который отключает несколько типичных встроенных ресурсов. Его можно добавить в functions.php дочерней темы или в отдельный плагин для сайта.
add_action( 'wp_enqueue_scripts', function () {
// Emoji
wp_dequeue_script( 'wp-emoji-release' );
wp_deregister_script( 'wp-emoji-release' );
// oEmbed
wp_dequeue_script( 'wp-embed' );
wp_deregister_script( 'wp-embed' );
// Dashicons на фронтенде
if ( ! is_user_logged_in() ) {
wp_dequeue_style( 'dashicons' );
wp_deregister_style( 'dashicons' );
}
// Скрипт для вложенных комментариев
if ( ! is_singular() || ! comments_open() || ! get_option( 'thread_comments' ) ) {
wp_dequeue_script( 'comment-reply' );
wp_deregister_script( 'comment-reply' );
}
}, 100 );Здесь важен приоритет 100: он помогает выполнить отключение после того, как тема и плагины уже успели подключить свои ресурсы. Если поставить слишком ранний приоритет, нужный файл может снова появиться позже.
С блоковыми стилями ситуация тоньше. У WordPress есть несколько стилей, связанных с блоками, и не все из них можно отключать без последствий. Если тема использует блоки в контенте, не спешите удалять всё подряд. Начинайте с точечной проверки: отключите один ресурс, обновите страницу, посмотрите, не изменились ли отступы, ширина контейнеров, кнопки, галереи и колонки.
Когда отключение безопасно, а когда лучше не трогать
Безопасность здесь зависит не от самого файла, а от того, использует ли сайт соответствующую функцию.
Обычно можно отключать безболезненно, если на сайте нет:
- вложенных комментариев;
- автоматических встраиваний через WordPress oEmbed;
- иконок Dashicons на фронтенде;
- эмодзи, которые должны поддерживаться именно через ядро WordPress;
- зависимости темы от стандартных стилей блоков.
Лучше не отключать сразу, если:
- тема построена на блоках и использует стандартные стили Gutenberg;
- на сайте есть формы, слайдеры или виджеты, которые могут зависеть от библиотек, подключённых через WordPress;
- вы не уверены, какой именно файл отвечает за конкретный элемент интерфейса;
- сайт работает на кастомной теме, где часть визуала собрана из стандартных блоков без собственного CSS.
Если сомневаетесь, отключайте по одному ресурсу и проверяйте результат. Массовое удаление нескольких файлов сразу — самый быстрый способ получить неработающую страницу и долго искать причину.
Как проверить, что сайт не сломался после отключения
После каждого изменения откройте несколько типовых страниц: главную, запись, страницу с комментариями, если они есть, и страницу с блоками, которые чаще всего используются в контенте. Смотрите не только на внешний вид, но и на поведение элементов.
Проверка должна включать такие вещи:
- меню открывается и закрывается;
- кнопки и ссылки выглядят нормально;
- галереи, колонки и блоки не «поплыли»;
- комментарии отправляются, если они включены;
- нет ошибок в консоли браузера;
- страница не потеряла критичные отступы и шрифты.
Если хотите проверить точнее, откройте консоль разработчика и посмотрите, не появились ли ошибки JavaScript после отключения. Ошибка может не быть заметна визуально сразу, но сломать часть интерактивных элементов.
Полезно сравнить страницу до и после через режим инкогнито и очистку кэша. Если на сайте стоит кэш-плагин или серверный кэш, изменения могут не проявиться сразу, и вы решите, что отключение не сработало.
Что делать, если ресурс нужен только на части страниц
Частая ситуация: скрипт или стиль нужен на одной странице, но мешает на остальных. В этом случае не отключайте его глобально. Лучше ограничить загрузку по условию.
Например, если комментарии есть только в записях, а не на страницах, скрипт comment-reply можно оставить только для одиночных записей с открытыми комментариями. Аналогично можно поступать с другими ресурсами, если они подключаются через ваш код или через хук темы.
Если ресурс подключает плагин, а не ядро WordPress, иногда проще настроить сам плагин или заменить его на более лёгкий вариант, чем пытаться вырезать файл на уровне фронтенда. Это особенно актуально для библиотек, которые нужны только в отдельных шаблонах.
Практичный порядок действий
Если нужно быстро и без лишнего риска уменьшить количество CSS и JS, действуйте так:
- Откройте страницу и посмотрите, какие встроенные ресурсы WordPress реально загружаются.
- Определите, используются ли на сайте комментарии, эмодзи, oEmbed, Dashicons и блоковые стили.
- Добавьте отключение в дочернюю тему или мини-плагин, а не в ядро и не в основную тему.
- Убирайте по одному ресурсу за раз.
- После каждого шага проверяйте внешний вид и поведение сайта в браузере.
- Если что-то сломалось, верните конкретный файл и ищите зависимость дальше.
Такой подход обычно даёт лучший результат, чем попытка «почистить WordPress» одной большой настройкой. У ядра много встроенных ресурсов, но часть из них действительно нужна только в определённых сценариях. Задача не в том, чтобы отключить всё, а в том, чтобы оставить только то, что реально работает на вашем сайте.