Если сайт на WordPress загружается медленно, один из первых кандидатов на проверку — встроенные стили и скрипты ядра. Часть из них действительно нужна только в отдельных сценариях: для комментариев, эмодзи, oEmbed, некоторых блоков и старых функций темы. Остальное на обычном сайте часто просто висит в коде страницы и создаёт лишние запросы.
Но отключать всё подряд нельзя. У WordPress есть ресурсы, которые завязаны на работу редактора, комментариев, блоков и совместимости с темой. Если убрать их без проверки, можно получить сломанный интерфейс, неработающие формы или визуальные артефакты. Поэтому правильный подход здесь не «выключить всё», а сначала понять, что реально используется на сайте, и только потом убирать лишнее.
Что именно можно отключать без риска в типовом сайте
На большинстве сайтов без потери функциональности можно убрать ресурсы, которые нужны только для редких сценариев или устаревших возможностей. Обычно речь идёт о следующем:
- скрипт и стили для эмодзи в старых браузерах;
- oEmbed-скрипт, если вы не встраиваете контент WordPress на сторонние сайты и не используете автоподстановку встроенных материалов;
- стили и скрипты, связанные с комментариями, если комментарии на сайте отключены;
- часть глобальных стилей блоков, если тема не использует стандартные блоки WordPress или вы сознательно заменили их собственными стилями;
- лишние стили плагинов и темы, если они подключаются на всех страницах, хотя нужны только в одном месте.
Самая частая ошибка — считать, что любой ресурс ядра можно убрать без последствий. Это не так. Например, если тема построена на блоках, отключение глобальных стилей блоков может сломать внешний вид заголовков, кнопок, колонок и медиа. Если на сайте есть комментарии, нельзя отключать связанные с ними скрипты и стили, пока не проверите фронтенд и админку.
С чего начать: сначала найдите, что именно грузится на странице
Перед изменениями откройте любую страницу сайта в браузере и посмотрите список подключённых CSS и JS. Проще всего это сделать через инструменты разработчика: вкладка Network покажет, какие файлы загружаются, а исходный код страницы подскажет, откуда они пришли. Если видите ресурсы с путями вроде /wp-includes/ или /wp-content/, это уже хороший ориентир для анализа.
Полезно сравнить главную, запись блога, страницу с формой, страницу товара или другой тип контента, который у вас реально используется. Нередко ресурс нужен только на одном шаблоне, а на остальных он просто тратит время загрузки. В таком случае лучше не отключать его глобально, а убрать только там, где он не нужен.
Отключение встроенных скриптов и стилей через functions.php
Если вы работаете с дочерней темой или своим мини-плагином, самый надёжный способ — использовать стандартные функции WordPress для снятия регистрации ресурсов. Делать это нужно только после резервной копии и лучше сначала на тестовой копии сайта. Ошибка в коде может привести к белому экрану или поломке части фронтенда.
Ниже пример для отключения эмодзи. Он подходит, если вам не нужна поддержка старых сценариев отображения эмодзи через скрипты WordPress:
add_action( 'init', function () {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );
} );Для отключения oEmbed на фронтенде и в редакторе можно использовать такой код:
add_action( 'init', function () {
wp_deregister_script( 'wp-embed' );
} );Этот вариант безопасен только если вам не нужен встроенный WordPress-embed на сайте. Если вы вставляете записи WordPress в другие сайты или используете встраивание как часть контентной стратегии, лучше не трогать этот скрипт.
Если на сайте не используются комментарии, можно убрать связанные с ними ресурсы. Но сначала убедитесь, что комментарии действительно отключены в настройках и тема не выводит их блоки на отдельных шаблонах:
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_singular() || comments_open() || get_comments_number() ) {
return;
}
wp_dequeue_script( 'comment-reply' );
}, 100 );Здесь важно, что скрипт comment-reply нужен только для древовидных комментариев и ответа на комментарий без перезагрузки. Если комментарии отключены, его можно убрать. Если они есть, но вы не уверены, лучше оставить.
Как убрать лишние стили блоков, не сломав верстку
С глобальными стилями блоков нужно быть аккуратнее. В современных версиях WordPress часть базовых стилей блоков подключается ядром, чтобы блоки выглядели предсказуемо в любой теме. Если тема полностью своя и вы вручную стилизуете блоки, можно попробовать отключить часть стандартных стилей, но только после проверки всех шаблонов.
На практике безопаснее не отключать всё подряд, а сначала проверить, действительно ли тема уже содержит собственные стили для блоков. Если после отключения кнопки, таблицы, галереи, цитаты или колонки начинают «сыпаться», значит, эти стили были нужны.
Для точечного отключения ресурсов используйте wp_dequeue_style() или wp_deregister_style(), но только после того, как вы точно определили handle стиля. Пример:
add_action( 'wp_enqueue_scripts', function () {
wp_dequeue_style( 'wp-block-library' );
}, 100 );Этот код убирает стандартную библиотеку стилей блоков на фронтенде. Но он подходит не всем. Если сайт использует редактор блоков без собственной полной стилизации, отключение может ухудшить внешний вид контента. На сайтах с классической темой и минимальным набором блоков эффект обычно заметнее и безопаснее, но проверка всё равно обязательна.
Когда лучше не трогать стили блоков
Не отключайте их, если:
- сайт активно использует Gutenberg-блоки в контенте;
- у темы нет собственных стилей для типовых блоков;
- вы используете паттерны, колонки, кнопки, таблицы и медиа-блоки в статьях;
- на сайте есть редакторские шаблоны, завязанные на стандартное оформление блоков.
Что лучше оставить включённым
Есть ресурсы, которые часто пытаются отключить ради экономии, но на обычном сайте это даёт мало пользы и создаёт лишние риски. К ним относятся скрипты, без которых ломается базовая работа интерфейса, а также ресурсы, которые нужны только в админке, но не грузятся на фронтенде.
Оставляйте включёнными всё, что связано с:
- работой редактора в админке;
- основной логикой темы;
- формами, если они завязаны на встроенные скрипты WordPress;
- комментариями, если они реально используются;
- блоками, если контент собран на Gutenberg.
Если сомневаетесь, ориентируйтесь на принцип: отключать только то, что вы можете проверить на всех типах страниц и в реальных сценариях использования. Экономия в несколько килобайт не стоит сломанной формы комментариев или «поехавшей» верстки.
Как проверить, что отключение прошло без побочных эффектов
После внесения изменений откройте сайт в обычном окне браузера и проверьте не только главную, но и несколько типовых страниц: запись, страницу, архив, страницу с формой, страницу с комментариями, если они есть. Смотрите не только на визуал, но и на консоль браузера: ошибки JavaScript часто проявляются именно там.
Проверка должна отвечать на три вопроса:
- не сломалась ли верстка;
- не перестали ли работать интерактивные элементы;
- не пропали ли нужные стили на отдельных шаблонах.
Если вы отключали конкретный стиль или скрипт, вернитесь в исходный код страницы и проверьте, исчез ли он из списка подключённых ресурсов. Если он всё ещё загружается, значит, его подключает не ядро, а тема или плагин, и искать нужно уже там.
Практичный порядок действий для обычного сайта
Если нужен короткий рабочий план, я бы делал так:
- Сделать резервную копию и, по возможности, проверить изменения на копии сайта.
- Посмотреть, какие CSS и JS реально грузятся на нескольких типовых страницах.
- Сначала отключить только очевидно лишнее: эмодзи, oEmbed, комментарийный скрипт, если комментариев нет.
- Потом отдельно проверить, нужны ли стандартные стили блоков WordPress.
- После каждого изменения открыть сайт и убедиться, что верстка и интерактив не пострадали.
Такой подход обычно даёт лучший результат, чем массовая чистка всего подряд. WordPress сам по себе не перегружен лишними ресурсами настолько, чтобы бездумное отключение дало заметный выигрыш. Зато точечная чистка действительно помогает убрать мусор, который не нужен именно вашему сайту, и не ломает то, что должно работать из коробки.
Если на сайте много лишних подключений не только от ядра, но и от темы или плагинов, удобнее делать это централизованно через один аккуратный слой оптимизации. В таких случаях полезны решения, которые умеют отключать дубли, чистить лишние ресурсы и не заставляют править тему вручную. Например, для этой задачи может подойти Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpclean.ru&utm_medium=article&utm_campaign=otklyuchit-vstroennye-stili-i-skripty-wordpress
