Если WordPress стал грузиться медленнее, а ставить ещё один плагин для оптимизации не хочется, начинать стоит не с «ускорителей», а с лишнего кода и запросов, которые уже есть в теме и на сайте. В большинстве проектов можно убрать часть фронтенд-нагрузки вручную: отключить то, что не используется, сократить количество подключаемых файлов и перестать отдавать на страницу лишние данные.
Это не заменяет нормальный хостинг, кэширование и оптимизацию изображений, но часто даёт заметный эффект именно там, где сайт перегружен темой, виджетами и стандартными функциями WordPress, которые никто не использует.
С чего начать: что реально можно отключить без риска для сайта
Самая частая ошибка — пытаться «ускорить всё подряд» и вырезать из WordPress полезные вещи наугад. Безопаснее идти от простого к сложному: сначала убрать то, что не влияет на контент и не нужно посетителям, потом уже трогать шаблоны темы и отдельные скрипты.
Обычно безболезненно отключают или сокращают:
- эмодзи-скрипты WordPress, если они не нужны;
- встроенные стили и скрипты, которые тема подключает только ради отдельных блоков;
- лишние шрифты и иконки;
- неиспользуемые виджеты, блоки и шаблонные элементы;
- автоэмбед внешних сервисов, если вы не вставляете такие ссылки;
- лишние метаданные в <head>, если они не нужны для вашей логики.
А вот отключать всё подряд, включая REST API, XML-RPC, комментарии или jQuery, без понимания последствий не стоит. На некоторых сайтах это ломает тему, редактор, формы, авторизацию или сторонние интеграции.
Что можно убрать из темы без потери функциональности
Если вы используете кастомную тему или дочернюю тему, именно здесь обычно лежит самый большой запас для ручной оптимизации. Смысл простой: тема часто подключает больше, чем нужно конкретному сайту. Чем меньше лишних файлов и зависимостей, тем меньше запросов и быстрее отрисовка страницы.
Отключите то, что не используется на вашем сайте
Проверьте, какие элементы темы реально задействованы. На практике часто можно убрать:
- слайдеры на главной, если они не дают пользы и только тянут изображения и JavaScript;
- анимации появления блоков;
- иконки социальных сетей, если они не ведут на актуальные профили;
- встроенные карты, если адрес можно показать ссылкой или статичным изображением;
- лишние шрифты Google Fonts, если достаточно системного шрифта или одного семейства;
- библиотеки иконок, если в теме используются 2–3 значка, а не полноценный набор.
Особенно часто тормозят темы, которые подключают несколько вариантов шрифтов и наборов иконок на каждой странице, даже если используется только часть из них. В таком случае лучше оставить один шрифт и один набор иконок, а остальное убрать из шаблонов или настроек темы.
Уберите лишние подключения через functions.php
Если тема подключает скрипты и стили через wp_enqueue_scripts, их можно отключить точечно. Это рабочий путь, но делать его нужно аккуратно: сначала убедитесь, что файл действительно не нужен на всех страницах, и проверьте сайт после изменения.
Например, если тема загружает отдельный скрипт только для комментариев, а комментарии у вас отключены, его можно не подключать. Логика обычно строится через условные проверки: на странице записи нужен один набор файлов, на главной — другой, на архиве — третий. Чем точнее условие, тем меньше лишнего кода попадает в браузер.
Пример подхода: если на сайте не используются встроенные комментарии WordPress, можно не подключать скрипт ответа на комментарий. Это не ускорит всё радикально, но уберёт один лишний файл на страницах записей.
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_singular() ) {
return;
}
if ( comments_open() && get_option( 'thread_comments' ) ) {
wp_enqueue_script( 'comment-reply' );
}
} );В этом примере скрипт подключается только тогда, когда он действительно нужен. Если комментарии на сайте закрыты, файл не грузится вообще.
Точно так же можно убрать подключение лишних стилей темы, если они относятся к неиспользуемым шаблонам. Но здесь важно не трогать общие стили, от которых зависит верстка сайта.
Что можно отключить на стороне WordPress
У WordPress есть несколько стандартных функций, которые полезны не всем сайтам. Они не всегда критично нагружают страницу, но в сумме дают лишние запросы, дополнительные теги в коде и иногда — ненужные обращения к внешним ресурсам.
Отключите эмодзи, если они не нужны
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' );Это убирает лишние подключения и не влияет на обычный текст сайта. Если после этого на сайте всё выглядит нормально, значит отключение прошло без побочных эффектов.
Сократите лишнее в <head>
В шапке страницы WordPress по умолчанию выводит несколько служебных ссылок и метаданных. Часть из них не нужна обычному сайту и только засоряет HTML. Это не самый большой источник ускорения, но убрать лишнее здесь разумно.
Часто отключают:
- ссылку на RSD;
- ссылку на WLW Manifest;
- ссылку на короткий URL записи;
- генератор версии WordPress;
- ссылки на oEmbed, если вы не используете автоподстановку внешних материалов.
Для этого обычно используют remove_action и фильтры в functions.php. Но если вы не уверены, что конкретный тег нужен вашей интеграции, лучше не удалять его вслепую. Например, oEmbed может быть полезен, если вы часто вставляете материалы с других сайтов и хотите, чтобы WordPress корректно их обрабатывал.
Отключите автозагрузку эмбедов, если не вставляете внешние ссылки
WordPress подключает скрипт wp-embed для обработки встроенных объектов. Если на сайте нет необходимости автоматически превращать ссылки в встраиваемые блоки, этот скрипт можно убрать. На многих обычных корпоративных сайтах он не нужен.
Пример отключения:
add_action( 'wp_enqueue_scripts', function () {
wp_deregister_script( 'wp-embed' );
} );После этого проверьте, не используете ли вы в записях вставки, которые завязаны на автоподстановку внешнего контента. Если используете, лучше оставить скрипт включённым.
Какие элементы фронтенда чаще всего дают лишнюю нагрузку
Даже без плагинов сайт может тормозить из-за того, как собран фронтенд. Обычно проблема не в одной тяжёлой функции, а в наборе мелочей: много внешних ресурсов, тяжёлые изображения, лишний JavaScript и повторяющиеся блоки, которые выводятся на каждой странице.
Шрифты и иконки
Если тема подключает несколько начертаний одного шрифта, это почти всегда лишнее. Для большинства сайтов достаточно одного семейства и двух начертаний: обычного и жирного. Всё остальное увеличивает число запросов и объём загрузки.
То же касается иконок. Если тема использует Font Awesome или похожий набор ради нескольких значков, это невыгодно. Лучше заменить такие иконки на встроенные SVG или обычный текст, если дизайн это позволяет. SVG обычно легче и не требует отдельной библиотеки.
Слайдеры, анимации и тяжёлые блоки на главной
Слайдеры часто выглядят эффектно, но для скорости это один из самых спорных элементов. Они тянут несколько изображений, JavaScript и иногда дополнительные стили. Если главная страница должна быстро открываться на мобильных устройствах, статичный первый экран почти всегда лучше.
Анимации тоже стоит пересмотреть. Если блоки появляются с задержкой, двигаются при скролле или завязаны на сторонние библиотеки, это добавляет работу браузеру. На слабых устройствах такой «эффект» ощущается как тормоза. Если анимация не помогает контенту, её лучше убрать.
Виджеты и блоки, которые дублируются на каждой странице
Иногда сайт медленный не из-за одной тяжёлой страницы, а из-за одинакового набора блоков в сайдбаре, футере и шапке. На каждой странице повторяются:
- списки популярных записей с миниатюрами;
- ленты последних комментариев;
- встроенные карты;
- виджеты соцсетей;
- большие баннеры и рекламные блоки.
Если такие элементы не приносят пользы, их лучше убрать. Особенно это касается блоков, которые делают дополнительные запросы к базе данных или тянут внешние скрипты. На небольшом сайте это может быть незаметно, но при росте контента и трафика лишняя нагрузка становится ощутимой.
Что можно делать вручную, а что лучше не трогать
Ручная оптимизация хороша тем, что вы контролируете каждый шаг. Но именно здесь легко сломать тему, если отключить что-то системное. Есть простое правило: если элемент отвечает только за оформление или второстепенную функцию, его можно рассматривать как кандидат на отключение. Если он участвует в работе редактора, навигации, форм или авторизации, сначала нужно проверить последствия.
| Что отключать можно чаще всего | Что требует осторожности |
|---|---|
| эмодзи-скрипты, лишние шрифты, неиспользуемые иконки, слайдеры, анимации, автoembed | jQuery, комментарии, REST API, стили и скрипты, которые тема использует на всех страницах |
| служебные теги в <head>, если они не нужны | функции, связанные с редактором, формами, личным кабинетом и интеграциями |
Если сайт сделан на готовой теме, часть отключений может быть недоступна без правки файлов темы. В этом случае безопаснее использовать дочернюю тему, чтобы обновление основной темы не затёрло ваши изменения. Это особенно важно, если вы редактируете functions.php или шаблоны header.php, footer.php и отдельных страниц.
Как проверить, что сайт действительно стал легче
После отключения лишнего не стоит ориентироваться только на ощущение «стало быстрее». Нужно посмотреть, что изменилось в самой странице. Самый простой способ — открыть сайт в браузере и проверить исходный код, а затем сравнить число подключаемых файлов и внешних запросов до и после правок.
Что смотреть в первую очередь:
- сколько CSS и JS-файлов загружается на главной и на записи;
- есть ли внешние запросы к шрифтам, картам, иконкам и виджетам;
- не появились ли ошибки в консоли браузера;
- не сломалась ли верстка в мобильной версии;
- не исчезли ли нужные элементы интерфейса.
Если после отключения чего-то сайт выглядит нормально, а лишний файл действительно пропал из загрузки, значит шаг был полезным. Если же вы не видите разницы, возможно, отключённый элемент и так не использовался, либо узкое место находится не в теме, а в изображениях, запросах к базе данных или хостинге.
На практике ручная оптимизация без плагинов лучше всего работает там, где тема перегружена лишними блоками и стандартными подключениями WordPress. Убрать всё сразу не получится, но даже точечная чистка даёт более предсказуемый результат, чем попытка лечить медленный сайт очередным универсальным плагином.