Аудит autoload-опцій у WordPress: як знайти та зменшити зайве навантаження

Що таке autoload і чому він впливає на швидкість

Під час завантаження WordPress формує набір опцій, позначених для автоматичного завантаження. Надалі ці значення доступні коду плагінів і теми без окремого звернення до бази даних. Це зручно для невеликих налаштувань, які потрібні майже на кожному запиті.

Проблема виникає, коли в autoload потрапляють великі серіалізовані масиви: кеші, списки товарів, журнали, результати сканувань, дані конструкторів сторінок або застарілі налаштування після видалення плагіна. Чим більший сумарний обсяг таких опцій, тим більше пам’яті може використовувати PHP на кожному запиті.

Важливо оцінювати не лише один найбільший запис, а й загальний обсяг autoload-даних. Велика кількість середніх опцій також може створювати проблему.

• autoload не означає, що опція завантажується лише на головній сторінці — вона може читатися на фронтенді, в адміністративній частині та під час AJAX-запитів.
• Розмір у базі даних не дорівнює точному обсягу пам’яті після розпакування PHP-масивів: у пам’яті значення часто займає більше.
• Повільна база даних не завжди є причиною проблеми: надмірний autoload може збільшувати навантаження вже на рівні PHP.

Як знайти найбільші autoload-опції через SQL

Перед перевіркою визначте фактичний префікс таблиць у базі даних. У багатьох сайтів це не wp_, а інше значення, тому назву wp_options у запитах потрібно замінити на власну.

Виконайте запит у phpMyAdmin, Adminer або іншому інструменті для роботи з MySQL. Він покаже найбільші опції, які WordPress зазвичай розглядає як автоматично завантажувані.

• Не запускайте запити на зміну даних, поки не маєте актуальної резервної копії бази.
• Перевіряйте результат на staging, якщо сайт має активний трафік або складну конфігурацію.
• Зверніть увагу на option_name, розмір і належність опції до конкретного плагіна чи теми.

SELECT option_name,
       ROUND(LENGTH(option_value) / 1024, 1) AS kb,
       autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on')
ORDER BY LENGTH(option_value) DESC
LIMIT 30;

Як оцінити сумарний обсяг

Окремий великий запис не завжди є критичним, якщо загальний autoload невеликий. Для загальної оцінки скористайтеся агрегованим запитом. Він покаже приблизний обсяг значень у кілобайтах.

SELECT COUNT(*) AS autoload_options,
       ROUND(SUM(LENGTH(option_value)) / 1024, 1) AS total_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on');

Перевірка значень autoload у конкретній базі

У різних версіях WordPress і сумісних інструментах можуть використовуватися різні значення поля autoload. Сучасні версії можуть застосовувати автоматичні значення на кшталт auto-on та auto-off, тому перед змінами корисно подивитися, які значення реально присутні у вашій базі.

SELECT autoload, COUNT(*) AS options_count
FROM wp_options
GROUP BY autoload
ORDER BY options_count DESC;

Як визначити, який плагін створив велику опцію

Назва опції часто містить префікс плагіна або теми: наприклад, скорочення бренду, назву модуля чи ідентифікатор розробника. Але це не універсальне правило. Частину даних плагін може зберігати під нейтральною назвою, а після видалення розширення записи можуть залишитися в базі.

Порівняйте option_name з документацією плагіна, його вихідним кодом або пошуком по файлах розширення. У коді можна шукати виклики add_option, update_option та назву опції. Також перевірте, чи встановлений відповідний плагін зараз і чи використовує сайт його функції.

Не видаляйте опцію лише тому, що її назва незнайома. У ній можуть зберігатися критичні налаштування, ключі інтеграцій, правила доставки, конфігурація теми або дані, потрібні для відновлення роботи.

• Зробіть резервну копію бази перед будь-яким очищенням.
• Зафіксуйте поточне значення опції або експортуйте відповідний рядок таблиці.
• Перевірте сайт після вимкнення плагіна на staging: якщо опція більше не використовується, це сильніший аргумент для очищення.
• Окремо перевірте залишки після повного видалення плагінів, але не припускайте, що кожен залишений запис безпечний для видалення.

Безпечні способи зменшити autoload

Найкраще рішення — усунути причину, а не просто змінити прапорець у базі. Оновіть проблемний плагін або тему: розробник міг уже виправити надмірне збереження даних. Якщо опція пов’язана з непотрібною функцією, вимкніть цю функцію в налаштуваннях.

Якщо значення не потрібне на кожному запиті, його можна перевести в режим без автоматичного завантаження. Перед цим переконайтеся, що плагін коректно отримує опцію за потреби. Деякі розширення помилково очікують, що їхня конфігурація завжди присутня в глобальному наборі autoload.

Зміни можна виконати через інструмент керування WordPress або безпосередньо в SQL. Конкретний спосіб залежить від версії WP-CLI, версії WordPress і значень, які підтримує ваша установка. Якщо використовуєте SQL, змінюйте лише точно визначений option_name.

• Не змінюйте autoload для всіх опцій масово без аналізу залежностей.
• Не встановлюйте значення, якого немає у вашій версії або схемі роботи сайту, не перевіривши сумісність.
• Для одиничної опції краще застосовувати точкову зміну та одразу перевіряти фронтенд, адмінпанель, форми, оплату й інтеграції.
• Видалення опції — крайній крок. Воно відрізняється від вимкнення autoload і може призвести до втрати налаштувань.

UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'example_option_name';

Коли змінювати autoload не можна

Не переводьте опцію в режим без autoload, якщо вона справді використовується майже на кожному запиті або якщо документація плагіна прямо вимагає автоматичного завантаження. У такому випадку виграш може бути нульовим, а кількість окремих звернень до бази — зрости.

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

Як перевірити результат після змін

Після зміни autoload очистіть об’єктний кеш, якщо він використовується, і перевірте сайт у новій PHP-сесії. Частина даних може тимчасово залишатися в memory cache або Redis, тому результат не завжди видно відразу.

Пройдіть ключові сценарії: відкрийте кілька сторінок, увійдіть до адмінпанелі, перевірте пошук, форми, кошик, оформлення замовлення, платежі та інтеграції. Перегляньте PHP error log і журнал помилок WordPress.

Повторіть SQL-аудит і порівняйте сумарний обсяг та список найбільших записів. Оцінюйте не лише один показник: важливі також час відповіді, використання пам’яті PHP, помилки та стабільність функцій.

• Перевірте сторінки для авторизованих і неавторизованих користувачів.
• Подивіться, чи не з’явилися помилки після автоматичного оновлення або очищення кешу.
• Зафіксуйте зміни, щоб за потреби швидко відкотити конкретну опцію.
• Якщо результат негативний, відновіть попереднє значення autoload і повторіть тест із консультацією розробника плагіна.

Типові помилки під час аудиту wp_options

Найпоширеніша помилка — видалення найбільших записів без розуміння їхнього призначення. Розмір сам по собі не доводить, що опція непотрібна. Інша помилка — перевірка лише одного запису без підрахунку загального обсягу autoload.

Не варто також вважати, що зміна autoload автоматично вирішить усі проблеми швидкодії. Причиною можуть бути повільні запити плагіна, відсутність об’єктного кешу, неоптимізовані зовнішні API-запити або надмірне навантаження на PHP.

Регулярний аудит має сенс після встановлення великих плагінів, міграції, зміни теми, видалення розширень і появи різкого зростання використання пам’яті. Найкраще проводити його на staging, а на production застосовувати лише перевірені зміни з резервною копією.

• Не плутайте очищення autoload із видаленням усіх невикористовуваних опцій.
• Не використовуйте однакові SQL-запити для сайтів із різними префіксами таблиць.
• Не оцінюйте ефект тільки за результатом одного тесту швидкості.
• Не ігноруйте помилки після зміни: навіть невелика опція може бути важливою для бізнес-логіки.