Если сайт на WordPress стал тяжёлым, а ставить ещё один плагин для оптимизации не хочется, начинать стоит не с «ускорителей», а с отключения лишнего. В ядре WordPress и в теме часто остаются вещи, которые нужны не каждому сайту: эмодзи, oEmbed, REST-ссылки, встроенные стили и скрипты, лишние SVG-иконки, шрифты, метаданные в <head>. Это не магия, а нормальная чистка фронтенда: меньше запросов, меньше кода на странице, проще отрисовка.
Ниже — практический список того, что можно отключить без плагинов, если вы работаете с дочерней темой или своим кодом. Я отдельно отмечаю, что безопасно почти для любого сайта, а что лучше трогать только после проверки.
С чего начать: не отключайте то, что реально используется
Перед правками проверьте три вещи: есть ли у сайта встроенные комментарии, используются ли в контенте встраивания с YouTube/ВК/Rutube, и не завязана ли тема на собственные скрипты или иконки из ядра. Если убрать функцию, которая нужна текущему шаблону, можно получить не ускорение, а поломку верстки или поведения интерфейса.
Самый безопасный подход такой: делайте изменения в дочерней теме или в отдельном mu-plugin, а не в файле родительской темы. Так обновление темы не сотрёт ваши правки. Если у вас нет дочерней темы, сначала создайте её или вынесите код в небольшой собственный плагин.
Что можно отключить в ядре WordPress
Ниже — функции, которые часто можно убрать без заметного ущерба для обычного сайта-визитки, блога или корпоративного проекта. Код добавляют в functions.php дочерней темы либо в свой плагин.
Эмодзи WordPress
WordPress добавляет скрипт и стили для старой поддержки эмодзи. На современных браузерах это обычно не нужно. Отключение убирает лишнюю загрузку с фронтенда и из админки.
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
WordPress добавляет в <head> ссылки, связанные с oEmbed. Если вы не встраиваете контент через механизм WordPress и не используете автоподстановку встраиваний, часть этих тегов можно убрать.
remove_action( 'wp_head', 'wp_oembed_add_discovery_links' );
remove_action( 'wp_head', 'wp_oembed_add_host_js' );Это не отключает саму возможность вставлять iframe вручную, но убирает служебные вещи, которые не всегда нужны.
REST API-ссылки в разметке
В некоторых темах и на некоторых сайтах в <head> остаются ссылки на REST API. Для обычного публичного сайта они часто не дают пользы фронтенду. Если тема и плагины не используют эти ссылки на клиенте, их можно убрать.
remove_action( 'wp_head', 'rest_output_link_wp_head' );
remove_action( 'template_redirect', 'rest_output_link_header', 11 );Здесь важна осторожность: если у вас есть фронтенд-логика, которая обращается к REST API, не трогайте это без проверки.
WLW, RSD и другие старые служебные ссылки
Для большинства современных сайтов эти элементы уже не нужны. Они исторически остались в ядре и только засоряют <head>.
remove_action( 'wp_head', 'rsd_link' );
remove_action( 'wp_head', 'wlwmanifest_link' );
remove_action( 'wp_head', 'wp_generator' );wp_generator скрывает версию WordPress в исходном коде. Это не полноценная защита, но лишнюю информацию на публичном сайте обычно убирают.
Ссылки на короткие URL и adjacent posts
Если вы не используете короткие ссылки и не полагаетесь на навигационные ссылки между соседними записями, их можно отключить.
remove_action( 'wp_head', 'wp_shortlink_wp_head', 10, 0 );
remove_action( 'wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0 );Это небольшая оптимизация, но на больших сайтах такие мелочи тоже имеют значение, особенно если вы чистите фронтенд системно.
Что убрать из темы без риска сломать сайт
В теме обычно больше всего лишнего: иконки, шрифты, глобальные библиотеки, стили, которые подключаются «на всякий случай». Здесь уже нельзя действовать вслепую — сначала смотрим, что именно подключает тема.
Неиспользуемые шрифты и наборы иконок
Частая история: тема грузит Google Fonts, хотя в дизайне используется один системный шрифт, или подключает целую библиотеку иконок ради пары значков. Если шрифт не нужен, его лучше убрать совсем, а не просто прятать CSS-ом.
Проверьте HTML страницы и список запросов в DevTools. Если видите загрузку шрифтов или иконок, которые не используются в макете, отключайте их в коде темы там, где они подключаются через wp_enqueue_style() или wp_enqueue_script().
Пример: если тема регистрирует отдельный файл шрифтов, его можно не подключать в условии или удалить соответствующий вызов. Универсального кода здесь нет, потому что у каждой темы свои handle и структура.
Скрипты и стили, которые нужны только на отдельных шаблонах
Типичная ошибка темы — грузить один и тот же JS/CSS на всех страницах, хотя он нужен только для формы на контактах, слайдера на главной или галереи в записях. Это уже не «чистка ядра», а нормальная оптимизация темы.
Логика простая: если файл нужен только на одной странице или в одном типе записей, подключайте его условно. Например, через is_page(), is_singular() или has_block(), если вы точно знаете сценарий.
Такой подход обычно даёт больше пользы, чем попытка вырезать что-то из ядра. Но здесь важно не переусердствовать: если скрипт используется в нескольких местах, условие должно это учитывать.
Встроенные библиотеки, которые уже не нужны
Некоторые темы до сих пор тащат старые библиотеки ради совместимости: слайдеры, lightbox, анимации, которые фактически не используются. Если вы не видите их на страницах, проверьте, не подключаются ли они по инерции.
Отключать такие файлы лучше после проверки зависимостей. Иногда один визуально «лишний» скрипт нужен другому модулю темы. Если удалить его без анализа, можно сломать меню, галерею или мобильную навигацию.
Как аккуратно отключать лишнее через functions.php
Для большинства задач достаточно нескольких хуков WordPress. Главное — не править ядро и не вносить изменения прямо в родительскую тему. Добавляйте код в дочернюю тему и проверяйте результат после каждого шага.
Если нужно убрать конкретный стиль или скрипт, сначала найдите его handle. Это можно сделать через исходный код страницы, просмотр подключаемых файлов в DevTools или по коду темы. Затем отключайте его через wp_dequeue_style() или wp_dequeue_script() на правильном хуке, обычно wp_enqueue_scripts.
add_action( 'wp_enqueue_scripts', function () {
wp_dequeue_style( 'handle-style' );
wp_dequeue_script( 'handle-script' );
}, 100 );Приоритет 100 здесь нужен, чтобы код отработал после того, как тема и плагины уже подключили свои файлы. Если поставить слишком рано, отключение просто не сработает.
Что лучше не отключать без проверки
Есть вещи, которые выглядят как «лишние», но на практике завязаны на работу темы, редактора или фронтенд-функций. Их отключают только после теста на staging-копии.
wp-embed, если на сайте есть встроенные записи WordPress или тема использует этот механизм.- REST API, если на фронтенде есть формы, фильтры, динамические блоки или кастомный JS.
- jQuery, если тема или плагины реально на нём завязаны. Убирать его «для скорости» без анализа нельзя.
- Стили и скрипты блок-редактора, если тема использует блоки WordPress на фронтенде.
Отдельно отмечу: отключение jQuery ради моды часто даёт обратный эффект. Если тема написана с расчётом на него, вы получите ошибки в консоли и сломанные элементы интерфейса. Сначала ищите, что именно грузится и кто это использует.
Как проверить, что сайт действительно стал легче
После правок не ориентируйтесь только на «ощущение скорости». Проверьте страницу в браузере и сравните до и после.
Что смотреть:
- количество запросов в Network;
- объём CSS и JS, загружаемый на главной и внутренних страницах;
- наличие ошибок в консоли;
- не пропали ли иконки, шрифты, меню, слайдеры, формы.
Если хотите быструю ручную проверку, откройте исходный код страницы и найдите, исчезли ли теги и подключения, которые вы убирали. Для CSS и JS удобнее всего смотреть вкладку Network в DevTools: там видно, грузится файл или нет.
Ещё один практичный тест — пройтись по нескольким типам страниц: главная, запись, страница, архив, контактная форма. Часто отключение кажется безопасным на главной, но ломает отдельный шаблон.
Самый рабочий порядок действий
Если нужен короткий чеклист без лишней теории, я бы шёл так:
- Создать дочернюю тему или вынести код в свой мини-плагин.
- Отключить эмодзи, RSD, WLW, generator, shortlink и лишние oEmbed-ссылки.
- Проверить, нужны ли REST-ссылки и adjacent posts.
- Найти в теме шрифты, иконки и библиотеки, которые не используются на фронтенде.
- Убрать глобальные CSS/JS, если они нужны только на отдельных шаблонах.
- Сравнить страницу до и после в DevTools и пройтись по ключевым шаблонам сайта.
Такой порядок обычно даёт лучший результат, чем хаотичное удаление всего подряд. В WordPress ускорение без плагинов почти всегда начинается не с «секретных трюков», а с аккуратного вырезания лишнего из ядра и темы. Если делать это последовательно, сайт становится легче без риска превратить оптимизацию в источник новых проблем.