WordPress быстрее без плагинов: скрытые возможности движка

Можно ли оптимизировать WordPress без плагинов?

Когда речь заходит об ускорении WordPress, большинство рекомендаций сводится к установке дополнительных плагинов.

Один обещает ускорить загрузку страниц, другой — оптимизировать базу данных, третий — настроить кеширование, четвёртый — уменьшить количество JavaScript и CSS.

В результате на сайте появляется целый набор инструментов, каждый из которых должен улучшать производительность.

Но возникает логичный вопрос: неужели сам WordPress ничего этого не умеет?

На самом деле умеет. Причём довольно многое.

За годы развития WordPress получил собственные механизмы кеширования, оптимизации запросов, обработки изображений, управления загрузкой ресурсов и предварительной загрузки страниц.

Часть возможностей работает автоматически. Другие доступны разработчику через стандартные функции и API.

Поэтому в этой статье я хочу рассмотреть WordPress с другой стороны: не как систему, которую обязательно нужно ускорять сторонними расширениями, а как движок, уже содержащий инструменты для повышения производительности.

При этом сразу обозначу важный момент.

Оптимизация без плагинов не означает, что достаточно добавить несколько строк в functions.php, чтобы любой сайт начал работать в несколько раз быстрее.

Производительность зависит от темы оформления, количества и качества плагинов, запросов к базе данных, серверного окружения, изображений и архитектуры проекта.

Поэтому правильный подход — разобраться, что WordPress уже делает самостоятельно, и научиться использовать эти возможности.

1. Что WordPress уже оптимизирует автоматически

Начнём с возможностей, которые в современных версиях WordPress уже встроены в ядро.

Многие владельцы сайтов даже не подозревают, что движок выполняет дополнительную работу для ускорения страниц.

Например, WordPress умеет:

• создавать несколько размеров загружаемых изображений;

• формировать адаптивные изображения через srcset и sizes;

• добавлять отложенную загрузку для подходящих изображений;

• определять приоритет загрузки некоторых ресурсов;

• кешировать объекты и результаты запросов;

• управлять зависимостями JavaScript;

• загружать стили блоков с учётом их использования;

• предварительно загружать страницы при определённых условиях.

И это далеко не полный список.

Почему тогда WordPress бывает медленным?

Потому что возможности ядра — только одна часть общей системы.

Например, WordPress может правильно сформировать адаптивное изображение, но если тема выводит огромный оригинальный файл вместо подходящего размера, преимущество теряется.

Или движок поддерживает кеширование запросов, но разработчик темы создаёт десятки повторяющихся обращений к базе данных.

Другой пример — сайт с тяжёлым конструктором, множеством сторонних скриптов и неудачной структурой шаблонов.

В таких ситуациях проблема находится не столько в WordPress, сколько в том, как он используется.

2. Базовые настройки WordPress: что действительно влияет на скорость

Прежде чем менять код, я рекомендую проверить стандартные настройки сайта.

Это самый простой этап оптимизации, который не требует установки дополнительных инструментов.

Количество записей на странице

В разделе «Настройки → Чтение» можно указать, сколько записей отображается на страницах блога.

Например, если выводить сразу 50 полноценных публикаций с изображениями, страница может оказаться значительно тяжелее, чем при выводе 10.

Но здесь нет универсального правила.

Для одного сайта удобно отображать 12 записей, для другого — 20.

Важно учитывать дизайн, объём содержимого и работу пагинации.

Комментарии

Если сайт не использует комментарии, нет смысла сохранять возможность их добавления исключительно по привычке.

В WordPress предусмотрены стандартные настройки обсуждений.

Но отключение комментариев само по себе не гарантирует заметного ускорения. Эффект зависит от того, как тема выводит комментарии и какие дополнительные механизмы с ними связаны.

Ревизии записей

WordPress сохраняет предыдущие версии публикаций, позволяя восстановить изменения.

Это полезная функция, особенно если над контентом работают несколько сотрудников.

Но на некоторых проектах количество ревизий становится значительным.

Ограничить число сохраняемых ревизий можно через wp-config.php:

define( 'WP_POST_REVISIONS', 10 );

В данном примере WordPress будет ограничивать количество сохраняемых ревизий для записей.

Важно: эта настройка не удаляет автоматически все старые ревизии и не гарантирует ускорения страниц.

Её задача — контролировать дальнейшее накопление данных.

Полностью отключать ревизии я обычно не рекомендую: возможность восстановить предыдущую версию публикации часто полезнее предполагаемой экономии.

Интервал автосохранения

В WordPress предусмотрено автоматическое сохранение черновиков.

Интервал можно изменить:

define( 'AUTOSAVE_INTERVAL', 120 );

Значение указывается в секундах.

Но увеличение интервала не следует считать универсальной оптимизацией. Это компромисс между частотой автосохранения и риском потери несохранённых изменений.

На современных версиях WordPress поведение редактора также зависит от клиентских механизмов сохранения.

Поэтому менять этот параметр стоит только при наличии конкретной причины.

3. Встроенный Object Cache: кеширование уже есть в WordPress

Один из самых интересных механизмов WordPress — Object Cache.

О нём часто говорят в контексте Redis или Memcached.

Из-за этого складывается впечатление, что без соответствующего плагина объектного кеширования в WordPress вообще нет.

Это не так.

WordPress содержит собственный класс WP_Object_Cache и функции для работы с кешем.

Например:

wp_cache_get();
wp_cache_set();
wp_cache_delete();

Как это работает

Представим, что при формировании страницы необходимо получить определённые данные.

Вместо повторного выполнения одной и той же операции можно сохранить результат в памяти.

Например:

$cache_key = 'denkon_example_data';

$data = wp_cache_get( $cache_key, 'denkon' );

if ( false === $data ) {
    $data = [
        'title' => 'Пример данных',
        'count' => 25,
    ];

    wp_cache_set(
        $cache_key,
        $data,
        'denkon'
    );
}

При повторном обращении в рамках того же запроса данные можно получить из кеша.

Главное ограничение встроенного Object Cache

По умолчанию кеш WordPress хранится в памяти только во время выполнения текущего PHP-запроса.

Когда запрос завершается, содержимое такого кеша обычно исчезает.

То есть встроенный Object Cache полезен для предотвращения повторных вычислений в пределах одного запроса, но не заменяет постоянное кеширование между посещениями.

Для persistent object cache обычно используется дополнительный backend, например Redis или Memcached, подключаемый через соответствующий механизм WordPress.

Вывод: Object Cache уже встроен в WordPress, но постоянным он по умолчанию не является.

4. Transients API: кеширование без Redis и специальных плагинов

Следующий инструмент — Transients API.

Это стандартный API WordPress, позволяющий временно сохранять результаты операций.

Он особенно полезен, если необходимо кешировать данные между запросами.

Например, сайт выводит блок популярных статей, для которого требуется дополнительная обработка данных.

Если результат не должен пересчитываться при каждом открытии страницы, можно использовать transient.

Пример использования

$cache_key = 'denkon_popular_posts';

$post_ids = get_transient( $cache_key );

if ( false === $post_ids ) {

    $post_ids = get_posts( [
        'post_type'      => 'post',
        'posts_per_page' => 5,
        'fields'         => 'ids',
        'orderby'        => 'comment_count',
        'order'          => 'DESC',
        'no_found_rows'  => true,
    ] );

    set_transient(
        $cache_key,
        $post_ids,
        HOUR_IN_SECONDS
    );
}

В данном примере список идентификаторов популярных записей сохраняется на срок до одного часа.

При последующих обращениях WordPress может использовать сохранённый результат.

Где хранятся Transients

Если на сайте не настроен внешний persistent object cache, transients обычно хранятся в базе данных WordPress.

Это означает, что кеширование возможно без Redis.

Но необходимо учитывать важный нюанс: срок жизни transient — это максимальное время его хранения, а не гарантия, что данные обязательно будут доступны всё это время.

Transient может исчезнуть раньше.

Поэтому код всегда должен уметь заново получить данные.

Когда сбрасывать кеш

Если содержимое блока зависит от публикаций, кеш желательно очищать после соответствующих изменений.

Например, при обновлении записи можно удалить transient:

add_action( 'save_post_post', function () {
    delete_transient( 'denkon_popular_posts' );
} );

Это упрощённый пример. В реальном проекте нужно учитывать также удаление записей, изменение статусов и другие события, влияющие на результат.

Когда Transients API действительно полезен

Я использую такой подход для данных, которые дорого получать или обрабатывать, но которые не обязаны обновляться при каждом запросе.

Например:

• результаты сложных вычислений;

• данные внешних API;

• предварительно сформированные списки;

• статистические блоки;

• редко изменяющиеся справочники.

Однако кешировать абсолютно всё не нужно.

Если запрос и так выполняется быстро, дополнительное кеширование может лишь усложнить код и управление актуальностью данных.

5. WP_Query: оптимизация запросов средствами движка

Одна из наиболее распространённых причин замедления WordPress — неэффективные запросы к базе данных.

Причём проблема часто находится в коде темы или собственного плагина.

WordPress предоставляет класс WP_Query, который позволяет получать публикации с помощью стандартных параметров.

Но далеко не все разработчики используют его возможности оптимизации.

Параметр no_found_rows

Представим, что на главной странице необходимо вывести пять последних статей.

Обычный запрос:

$query = new WP_Query( [
    'post_type'      => 'post',
    'posts_per_page' => 5,
] );

Но если пагинация не нужна, можно явно указать:

$query = new WP_Query( [
    'post_type'      => 'post',
    'posts_per_page' => 5,
    'no_found_rows'  => true,
] );

Параметр no_found_rows позволяет не выполнять дополнительную работу, связанную с определением общего количества найденных записей.

Это полезно для небольших блоков, где не требуется рассчитывать количество страниц.

Но если используется полноценная пагинация, отключать подсчёт нельзя без учёта её логики.

Получение только идентификаторов

Если необходимы только ID записей:

$ids = get_posts( [
    'post_type'      => 'post',
    'posts_per_page' => 20,
    'fields'         => 'ids',
] );

WordPress может вернуть список идентификаторов вместо полноценного набора объектов публикаций.

Это полезно, когда дальнейшая обработка действительно требует только ID.

Но если после этого для каждого идентификатора отдельно запрашивать заголовок, метаданные и другие поля, итоговая нагрузка может оказаться выше.

Поэтому параметр нужно использовать с пониманием дальнейших операций.

Кеширование метаданных

WP_Query поддерживает параметры:

'update_post_meta_cache' => false,
'update_post_term_cache' => false,

Они управляют предварительной загрузкой метаданных записей и терминов таксономий.

Если в конкретном блоке эти данные не используются, отключение предварительной загрузки иногда уменьшает ненужную работу.

Но если шаблон затем обращается к метаполям каждой записи, отключение может привести к дополнительным запросам.

Почему нельзя отключать всё подряд

Иногда встречается совет:

«Поставьте cache_results => false, и WordPress станет быстрее».

Это ошибочное обобщение.

Отключение кеширования результатов запроса может увеличить количество повторных обращений к базе данных.

Оптимизировать необходимо не количество включённых функций, а фактическую работу конкретного запроса.

6. wp_options и autoload: скрытая нагрузка на сайт

В WordPress существует таблица настроек, обычно называемая wp_options.

В ней хранятся параметры ядра, тем и плагинов.

Некоторые настройки загружаются автоматически.

Это удобно, потому что WordPress может получить часто используемые значения без отдельных запросов для каждого параметра.

Но возникает проблема, если автоматически загружаемых данных становится слишком много.

Например, плагин может сохранить большой массив настроек и включить его в автозагрузку, хотя эти данные нужны только на одной странице административной панели.

В результате лишняя информация может загружаться при каждом обращении к сайту.

Что изменилось в современных версиях WordPress

Начиная с WordPress 6.6, механизм автозагрузки настроек получил дополнительные улучшения.

В частности, ядро может автоматически не включать большие новые значения в автозагрузку при определённых условиях.

Также появились штатные функции для управления этим поведением.

Например:

wp_set_option_autoload(
    'denkon_large_settings',
    false
);

Такая команда изменяет режим автозагрузки существующей настройки.

Но использовать её без анализа нельзя.

Если параметр действительно нужен на каждой странице, отключение автозагрузки может привести к дополнительным обращениям к базе.

Как проверить объём автозагружаемых данных

Для технической диагностики можно использовать SQL-запрос.

Пример для стандартного префикса таблиц:

SELECT
    SUM(LENGTH(option_value)) AS total_bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

Этот запрос позволяет приблизительно оценить объём значений, которые относятся к автозагрузке.

В зависимости от версии WordPress и истории базы могут встречаться разные значения поля autoload.

Важно: результат показывает объём данных, но сам по себе не определяет, какие настройки следует отключить.

Что я рекомендую

Сначала определить самые крупные значения.

Затем выяснить, кому они принадлежат и как используются.

И только после этого принимать решение.

Массово отключать autoload у всех крупных настроек опасно.

Это может привести к дополнительным запросам и нарушению работы отдельных компонентов сайта.

7. Изображения: WordPress уже многое делает самостоятельно

Изображения часто занимают значительную часть общего объёма страницы.

Но WordPress содержит несколько встроенных механизмов, которые помогают оптимизировать их загрузку.

Автоматическое создание размеров

Когда пользователь загружает изображение, WordPress обычно создаёт дополнительные размеры в соответствии с настройками и зарегистрированными размерами.

Это позволяет использовать уменьшенные версии в карточках, списках и других элементах.

Например, вместо загрузки оригинальной фотографии шириной 4000 пикселей можно вывести изображение подходящего размера.

В PHP для этого предусмотрена функция:

echo wp_get_attachment_image(
    $attachment_id,
    'medium'
);

Она формирует HTML изображения с учётом механизмов WordPress.

Responsive Images: srcset и sizes

WordPress умеет формировать атрибуты srcset и sizes.

Они позволяют браузеру выбирать подходящий вариант изображения в зависимости от устройства и условий отображения.

Но это работает корректно только тогда, когда тема использует соответствующие функции и размеры изображений.

Если разработчик вручную выводит URL оригинала в обычном теге img, часть возможностей WordPress может не использоваться.

Lazy Loading

WordPress умеет добавлять:

loading="lazy"

Для изображений, которые целесообразно загружать отложенно.

Это позволяет не загружать сразу все изображения длинной страницы.

Но важное изображение первого экрана, особенно если оно является LCP-элементом, обычно не следует загружать лениво.

Современный WordPress учитывает контекст изображения при определении атрибутов загрузки.

Fetch Priority

Для некоторых изображений WordPress может использовать:

fetchpriority="high"

Этот атрибут сообщает браузеру, что ресурс имеет высокий приоритет.

Но назначать высокий приоритет всем изображениям бессмысленно: если всё важно, приоритет перестаёт помогать.

Что ещё необходимо учитывать

WordPress поддерживает современные форматы изображений, включая WebP, при наличии соответствующей поддержки серверного окружения.

Однако поддержка формата не означает, что каждое загруженное JPEG-изображение автоматически будет преобразовано в WebP.

Это отдельная задача.

Вывод: WordPress уже умеет оптимизировать выдачу изображений, но разработчик должен правильно использовать его API.

8. JavaScript и CSS: штатные механизмы оптимизации

Большое количество JavaScript и CSS может замедлять отображение страницы.

Но прежде чем устанавливать плагин минификации, стоит разобраться, как WordPress подключает ресурсы.

Правильное подключение JavaScript

В WordPress существует функция:

wp_enqueue_script();

Она позволяет управлять подключением скриптов и их зависимостями.

Начиная с WordPress 6.3, поддерживается настройка стратегии загрузки скрипта.

Например:

add_action( 'wp_enqueue_scripts', function () {

    wp_enqueue_script(
        'denkon-frontend',
        get_theme_file_uri( 'assets/js/frontend.js' ),
        [],
        '1.0.0',
        [
            'strategy'  => 'defer',
            'in_footer' => true,
        ]
    );

} );

Стратегия defer позволяет браузеру не блокировать разбор HTML обычным выполнением скрипта.

При этом WordPress учитывает зависимости и может выбирать допустимую стратегию с учётом всей цепочки скриптов.

Почему async подходит не всегда

async и defer работают по-разному.

async позволяет выполнять скрипт после загрузки без гарантии порядка относительно других независимых скриптов.

defer сохраняет порядок выполнения отложенных классических скриптов и запускает их после разбора HTML.

Поэтому нельзя просто добавить async ко всем файлам JavaScript.

Это может нарушить работу зависимых компонентов.

Условное подключение ресурсов

Представим, что JavaScript нужен только на странице контактов.

Нет смысла загружать его на каждой странице сайта.

Можно использовать условие:

add_action( 'wp_enqueue_scripts', function () {

    if ( is_page( 'contacts' ) ) {

        wp_enqueue_script(
            'denkon-contacts',
            get_theme_file_uri(
                'assets/js/contacts.js'
            ),
            [],
            '1.0.0',
            true
        );

    }

} );

Такой подход уменьшает количество ненужных ресурсов.

Однако он требует понимания, на каких страницах действительно используется соответствующий функционал.

9. WordPress 6.9: оптимизация стилей блоков

Отдельно хочу обратить внимание на улучшения WordPress 6.9.

Одна из проблем классических тем заключалась в том, что стили блоков могли загружаться в большем объёме, чем необходимо конкретной странице.

WordPress 6.9 расширил механизм загрузки стилей отдельных блоков по требованию для классических тем.

Это позволяет не загружать полный набор CSS для блоков, которые на странице не используются.

Кроме того, были улучшены механизмы встраивания небольших CSS-файлов непосредственно в HTML.

Почему это интересно

Раньше разработчики нередко пытались вручную отключать стандартные стили блоков WordPress.

Иногда это действительно уменьшало объём CSS.

Но вместе с этим можно было нарушить оформление элементов.

Теперь часть соответствующей оптимизации выполняется самим ядром.

Нужно ли дополнительно что-то отключать?

В большинстве случаев я рекомендую сначала проверить, как работает стандартный механизм.

Если тема правильно использует API WordPress, дополнительные вмешательства могут оказаться ненужными.

Более того, принудительное удаление стандартных стилей способно конфликтовать с современными механизмами загрузки ресурсов.

Поэтому перед отключением CSS необходимо измерить, сколько он занимает и действительно ли используется на странице.

10. Speculative Loading: предварительная загрузка страниц

Одна из наиболее интересных встроенных возможностей WordPress — Speculative Loading.

Она появилась в ядре WordPress 6.8.

Механизм использует браузерный Speculation Rules API, позволяющий заранее подготавливать загрузку некоторых страниц.

Как это работает

Представим, что пользователь собирается перейти по ссылке.

Браузер может начать предварительную загрузку ещё до завершения перехода.

Если пользователь действительно откроет страницу, часть работы уже будет выполнена.

В результате переход может ощущаться быстрее.

Что WordPress делает по умолчанию

В WordPress 6.8 механизм включён для подходящих страниц с консервативной стратегией prefetch.

По умолчанию предварительная загрузка запускается вблизи момента перехода, например при начале нажатия на ссылку.

Для авторизованных пользователей и сайтов без красивых постоянных ссылок действуют ограничения.

Кроме того, механизм зависит от поддержки браузера.

Можно ли управлять поведением?

Да.

WordPress предоставляет фильтр:

wp_speculation_rules_configuration

С его помощью разработчик может изменять параметры предварительной загрузки.

Например, в поддерживаемых версиях WordPress можно использовать:

add_filter(
    'wp_speculation_rules_configuration',
    function ( $config ) {

        $config['mode'] = 'prefetch';
        $config['eagerness'] = 'moderate';

        return $config;
    }
);

В данном случае используется более активная стратегия предварительной загрузки.

Но я не рекомендую применять её без тестирования.

Когда предварительная загрузка может навредить

Она способна создавать дополнительные запросы, которые не всегда завершаются реальным переходом.

На сайтах с высокой нагрузкой это может увеличивать потребление ресурсов.

Особенно осторожно нужно работать с персонализированными страницами, корзиной, оформлением заказа и действиями, которые изменяют состояние системы.

Поэтому для интернет-магазинов и сложных веб-приложений необходимо отдельно проверять правила предварительной загрузки.

11. WP-Cron: фоновые задачи без лишней нагрузки

WordPress использует собственный механизм планирования задач — WP-Cron.

Он необходим для выполнения отложенных операций:

• публикации записей по расписанию;

• некоторых проверок обновлений;

• задач плагинов;

• служебных операций.

В отличие от обычного системного cron, стандартный WP-Cron связан с обращениями к сайту.

Это означает, что при отсутствии посещений некоторые задачи могут выполняться с задержкой.

Нужно ли отключать WP-Cron?

Не всегда.

Для небольшого сайта стандартного механизма часто достаточно.

Но на проектах с высокой посещаемостью или большим количеством фоновых операций может быть полезно использовать системный планировщик.

В wp-config.php можно указать:

define( 'DISABLE_WP_CRON', true );

Однако это не оптимизация сама по себе.

После отключения стандартного запуска необходимо настроить альтернативное выполнение задач.

Например, через системный cron и WP-CLI:

wp cron event run --due-now

Иначе запланированные операции могут перестать выполняться своевременно.

Что изменилось в WordPress 6.9

В WordPress 6.9 были улучшены некоторые аспекты запуска WP-Cron, включая перенос инициирования фонового запуска на этап завершения запроса.

Поэтому советы об обязательном отключении WP-Cron, написанные для старых версий WordPress, необходимо оценивать с учётом актуального поведения ядра.

12. Оптимизация темы: часто важнее любого плагина

На практике я считаю качество темы одним из ключевых факторов производительности WordPress.

Даже хорошо настроенный сервер не исправит неудачную архитектуру шаблонов.

Повторяющиеся запросы

Например, разработчик получает список публикаций, а затем для каждой записи выполняет дополнительные запросы.

Если таких публикаций 30, количество обращений к базе может значительно вырасти.

Это распространённая проблема N+1.

Решение заключается в правильной организации запросов и предварительной загрузке необходимых данных.

Лишние вычисления

Иногда один и тот же результат вычисляется несколько раз при формировании страницы.

Если операция дорогая, её лучше выполнить один раз и повторно использовать результат.

Для этого могут подходить локальные переменные, Object Cache или Transients API.

Неиспользуемые библиотеки

В теме могут подключаться большие JavaScript-библиотеки ради одного небольшого эффекта.

Например, если для простого раскрывающегося блока подключается крупная библиотека, стоит оценить, нельзя ли реализовать задачу стандартными средствами браузера.

Избыточная универсальность

Некоторые темы содержат десятки функций, которые никогда не используются на конкретном сайте.

Это не означает, что все универсальные темы плохие.

Но при индивидуальной разработке можно создавать более компактную архитектуру, соответствующую реальным задачам проекта.

Мой принцип: сначала устранить лишнюю работу в коде, а уже потом кешировать её результат.

13. Серверная оптимизация без плагинов

До этого момента речь шла преимущественно о возможностях самого WordPress.

Но существуют и серверные механизмы, которые не требуют установки WordPress-плагинов.

Важно не путать их со встроенными функциями движка.

PHP OPcache

OPcache позволяет сохранять скомпилированный PHP-код в памяти и уменьшать затраты на его повторную обработку.

Это особенно полезно для PHP-приложений, включая WordPress.

Но OPcache настраивается на уровне PHP, а не через административную панель WordPress.

Актуальная версия PHP

Современные поддерживаемые версии PHP обычно содержат улучшения производительности и безопасности.

Однако обновление PHP необходимо предварительно проверять на совместимость с темой и плагинами.

HTTP-кеширование

Веб-сервер может кешировать готовые HTML-ответы.

Это позволяет обслуживать часть запросов без полного выполнения WordPress.

Но необходимо учитывать авторизованных пользователей, корзины, персональные данные и другие динамические страницы.

Brotli и Gzip

Сжатие текстовых ресурсов помогает уменьшить объём передаваемых HTML, CSS и JavaScript.

Обычно оно настраивается на уровне веб-сервера или CDN.

База данных

Правильная конфигурация MySQL или MariaDB, индексы и достаточные серверные ресурсы также влияют на скорость WordPress.

Но изменение конфигурации базы данных требует диагностики.

Нельзя рассчитывать, что один универсальный набор настроек одинаково хорошо подойдёт всем сайтам.

14. Популярные советы по ускорению, которые могут навредить

В интернете можно найти множество инструкций, предлагающих отключить практически все стандартные функции WordPress.

Я рекомендую относиться к таким советам осторожно.

«Отключите REST API»

REST API используется не только внешними приложениями.

Он необходим для работы многих возможностей WordPress, включая редактор блоков и интеграции.

Его глобальное отключение может нарушить функциональность сайта.

«Отключите Heartbeat»

Heartbeat API используется для некоторых механизмов взаимодействия административной панели с сервером.

Например, для блокировки редактирования записей и других операций.

При наличии конкретной проблемы частоту запросов можно анализировать и настраивать.

Но полное отключение без понимания последствий — сомнительная оптимизация.

«Удалите все стандартные стили WordPress»

Это может нарушить оформление блоков и компонентов.

В современных версиях ядро уже использует более эффективные способы загрузки части CSS.

«Отключите все ревизии»

Ревизии полезны для восстановления изменений.

Ограничение их количества часто разумнее полного отключения.

«Отключите XML-RPC — сайт станет быстрее»

Если XML-RPC не используется, ограничение доступа может быть оправдано с точки зрения безопасности.

Но само по себе отключение XML-RPC не гарантирует заметного улучшения скорости обычных страниц.

«Удалите поддержку эмодзи»

На старых версиях WordPress подобные рекомендации иногда имели практический смысл.

Но ядро продолжает оптимизировать загрузку соответствующих ресурсов.

В WordPress 6.9, например, изменён способ загрузки скрипта определения поддержки эмодзи.

Поэтому нельзя автоматически считать, что старый сниппет для отключения эмодзи обязательно ускорит современный сайт.

«Отключите кеширование запросов»

Это особенно опасный совет.

Кеширование существует для уменьшения повторной работы.

Отключать его имеет смысл только при наличии конкретных причин и понимании последствий.

15. Как проверить, действительно ли сайт стал быстрее

Оптимизация без измерений легко превращается в набор субъективных предположений.

Например, после изменения кода страница может визуально открываться быстрее на компьютере разработчика.

Но это ещё не доказывает улучшение для реальных посетителей.

Я рекомендую проверять несколько показателей.

TTFB

Time to First Byte показывает время до получения первого байта ответа от сервера.

Он помогает оценивать серверную часть загрузки, хотя включает и сетевые задержки.

LCP

Largest Contentful Paint характеризует скорость отображения основного содержимого страницы.

INP

Interaction to Next Paint отражает отзывчивость интерфейса на действия пользователя.

CLS

Cumulative Layout Shift показывает визуальную стабильность страницы.

Количество SQL-запросов

При разработке полезно отслеживать количество запросов к базе данных, их продолжительность и повторения.

Для этого можно использовать отладочные инструменты, журналирование и профилирование.

При необходимости WordPress поддерживает константу:

define( 'SAVEQUERIES', true );

Она позволяет собирать информацию о SQL-запросах в $wpdb->queries.

Но использовать такой режим постоянно на рабочем сайте не следует: сбор диагностической информации сам создаёт дополнительные расходы памяти и времени.

Как проводить сравнение

Для объективной оценки желательно:

1. Зафиксировать показатели до изменений.

2. Изменить один конкретный механизм.

3. Повторить измерения в сопоставимых условиях.

4. Проверить функциональность сайта.

5. Оставить изменение только при подтверждённой пользе.

Особенно важно проводить несколько измерений, поскольку отдельные результаты могут отличаться из-за сетевых условий, кеширования и нагрузки на сервер.

16. Практический чек-лист оптимизации WordPress без плагинов

Ниже приведу последовательность, которой я рекомендую придерживаться.

С чего я рекомендую начинать

Если сайт работает медленно, не стоит сразу редактировать wp-config.php или отключать стандартные механизмы WordPress.

Сначала необходимо выяснить, где возникает задержка.

Если проблема в тяжёлых изображениях, оптимизация SQL-запросов может почти не повлиять на LCP.

Если сервер долго формирует HTML, уменьшение размера CSS не устранит первопричину.

Если основной JavaScript блокирует интерфейс, ускорение базы данных не обязательно улучшит INP.

Поэтому правильная оптимизация всегда начинается с диагностики.

17. Что WordPress умеет без плагинов, а что — нет

Для наглядности соберу основные возможности в одной таблице.

Эта таблица хорошо показывает, что WordPress уже содержит значительную часть инструментов оптимизации.

Но некоторые задачи действительно требуют серверных решений или дополнительных компонентов.

Мой подход к оптимизации WordPress

Я придерживаюсь принципа: не устанавливать дополнительный инструмент, пока не понятно, какую проблему он должен решить.

Если WordPress уже умеет правильно загружать изображения, нет необходимости дублировать эту работу без причины.

Если запрос можно оптимизировать штатными параметрами WP_Query, сначала стоит сделать это.

Если тяжёлый блок можно кешировать через Transients API, необязательно сразу подключать сложную инфраструктуру.

Если тема загружает ненужные скрипты, разумнее исправить их подключение, чем пытаться компенсировать проблему очередным плагином оптимизации.

При этом я не считаю плагины кеширования бесполезными.

Хорошо подобранный инструмент может существенно улучшить производительность, особенно если требуется кеширование готовых страниц, оптимизация ресурсов или интеграция с CDN.

Но он должен дополнять качественную архитектуру, а не скрывать её недостатки.

Вывод: сначала возможности WordPress, потом дополнительные инструменты

WordPress давно перестал быть простой системой публикации записей.

Современное ядро содержит множество механизмов, которые помогают эффективнее работать с базой данных, изображениями, JavaScript, CSS и фоновыми задачами.

Часть этих возможностей уже включена автоматически.

Другие требуют грамотной настройки и правильного использования API.

Именно поэтому оптимизация WordPress не должна начинаться с установки пяти плагинов, отключения десятка функций и копирования случайных фрагментов кода из интернета.

Сначала необходимо понять, что движок уже умеет, какие механизмы действительно используются и где возникает реальная нагрузка.

После этого можно последовательно улучшать запросы, загрузку ресурсов, кеширование и архитектуру темы.

Такой подход позволяет не только ускорить сайт, но и сохранить его стабильность, совместимость с обновлениями и удобство дальнейшего обслуживания.

Для меня как разработчика это и есть основа профессиональной оптимизации WordPress: не искать универсальную кнопку ускорения, а устранять реальные причины замедления.
Вы всегда можете заказать сайт на WordPress под ключ.