Autoloaded options в WordPress: как очистить wp_options и ускорить сайт

Autoloaded options в WordPress загружаются автоматически при большинстве запросов. Это удобно для часто используемых настроек, но со временем плагины и темы могут оставить в wp_options крупные или уже ненужные записи. Тогда каждый PHP-запрос получает лишний объём данных ещё до того, как страница начнёт выполнять основную бизнес-логику.

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

Что такое autoload в wp_options

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

Официальная документация WordPress отдельно предупреждает, что чрезмерный объём autoloaded options может ухудшать производительность. В руководстве по оптимизации WordPress приводится практический ориентир — стараться удерживать общий объём автоматически загружаемых опций ниже примерно 800 КБ. Это не универсальный «лимит безопасности», а сигнал для диагностики: важны также количество запросов, object cache, PHP memory и структура конкретных данных.

Как понять, что проблема действительно в autoload

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

На staging-копии можно получить сводку SQL-запросом:

SELECT autoload, COUNT(*) AS rows_count,
       ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS size_mb
FROM wp_options
GROUP BY autoload
ORDER BY size_mb DESC;

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

Найдите самые тяжёлые записи

Следующий шаг — не очищать всё подряд, а отсортировать крупные значения:

SELECT option_name, autoload, LENGTH(option_value) AS bytes
FROM wp_options
ORDER BY bytes DESC
LIMIT 50;

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

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

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

Безопасный процесс — определить источник записи по коду плагина, документации или поиску по option_name, затем проверить её использование на staging.

Когда менять autoload вместо удаления

Если опция нужна, но не должна загружаться на каждом запросе, логичнее изменить её режим autoload. WordPress предоставляет штатные функции работы с options. В актуальном API параметр autoload можно задавать через update_option(), а для пакетного изменения существуют функции управления autoload-значениями.

Пример для контролируемого случая:

$value = get_option( 'my_large_plugin_setting' );
if ( false !== $value ) {
    update_option( 'my_large_plugin_setting', $value, false );
}

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

Что делать с транзиентами

Транзиенты — отдельная категория. Просроченные transient-записи можно очищать штатными инструментами, но постоянная масса транзиентов обычно указывает на плагин, который создаёт кэш быстрее, чем он обслуживается. Однократная очистка уменьшит таблицу, но не исправит первопричину.

Если сайт использует persistent object cache, например Redis, поведение кэша меняется. Поэтому оптимизацию wp_options полезно рассматривать вместе с архитектурой кэширования. Отдельно мы разбирали Redis Object Cache для WooCommerce.

Как безопасно провести очистку

1. Сделать свежий backup базы.
2. Повторить диагностику на staging.
3. Зафиксировать общий размер autoload и топ тяжёлых options.
4. Определить владельца каждой подозрительной записи.
5. Удалять только подтверждённые orphan options.
6. Для нужных, но редко используемых данных изменить autoload штатным API.
7. Очистить object cache после изменений.
8. Проверить frontend, админку, cron, формы, WooCommerce и интеграции.

Как измерить эффект

После оптимизации сравнивайте не только размер таблицы. Важнее TTFB, время PHP, число SQL-запросов, memory usage и стабильность под нагрузкой. Если autoload уменьшился с нескольких мегабайт до сотен килобайт, но TTFB не изменился, узкое место может быть в другом месте: внешнем API, тяжёлом запросе, шаблоне, cron или плагине.

Полезно повторить тот же тест до и после изменений на одинаковой странице и с одинаковым состоянием кэша. Для сложных проектов лучше использовать APM, Query Monitor и slow query log.

Autoload и persistent object cache

Persistent object cache способен снизить повторные обращения к MySQL, но не делает бесконечно большой набор autoloaded данных бесплатным. Большой объект всё равно нужно сериализовать, передавать и держать в памяти. Поэтому Redis — не замена гигиене wp_options.

Когда проблема возникает чаще всего

• сайт много лет обновлялся без ревизии плагинов;
• ставились и удалялись десятки расширений;
• конструктор или SEO-плагин хранит крупные массивы настроек;
• миграции создавали копии options;
• кастомный код сохраняет большие JSON/serialized структуры с autoload;
• на WooCommerce много интеграций и служебных модулей.

Чек-лист перед production

Когда нужна ручная диагностика

Если в wp_options тысячи записей и непонятно, какие из них используются, безопаснее не запускать универсальный cleanup-плагин. Для живого коммерческого сайта нужна инвентаризация: связи option с кодом, профилирование запросов и проверка на staging.

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

Официальные источники

• WordPress Performance Optimization
• WordPress update_option()
• WordPress Options API
• wp_set_option_autoload_values()