SEO-Studio
Блог · SEO

Database bloat revisions і TTFB у WordPress

Практичний розбір database bloat у WordPress revisions, transients, автозавантаження options і вплив на TTFB з швидкою перевіркою БД.

~3 хв читання SEO

Адміністратор біля монітора з графіком розміру таблиць wp_posts і TTFB

Чому revisions і transients бʼють TTFB

Database bloat у WordPress рідко виглядає як «сайт упав». Частіше зростає Time to First Byte на динамічних URL, довшає адмінка, а кеш лише маскує проблему на публічних сторінках. Revisions, прострочені transients і важкі ряди в wp_options з autoload=yes читаються на майже кожен запит PHP.

Якщо TTFB у PageSpeed Insights або лабораторному тесті стабільно вище 600–800 мс без CDN-затримки спочатку перевірте БД, а не лише тему. Для SEO це критично бо повільний старт відповіді гірше індексується на слабих зʼєднаннях і гірше конвертує.

  • Revisions роздувають wp_posts / wp_postmeta і сповільнюють редакційні запити.
  • Transients без очистки лишають тисячі ключів у options або окремій таблиці.
  • Autoload options тягнуться в памʼять на кожен front-end hit.

Revisions як контролювати

Екран зі списком ревізій поста і лічильником рядків у wp_posts
Кожна ревізія це рядок у wp_posts. На великих редакційних сайтах їх тисячі.

WordPress за замовчуванням зберігає всі чернетки змін. На каталозі з 5–10 тис. товарів і щоденними правками ревізій легко набрати сотні тисяч рядків. Практичні кроки

  • Обмежте кількість у wp-config.php через WP_POST_REVISIONS (наприклад 5–10).
  • Вимкніть ревізії для типів контенту де історія не потрібна (часто product без редакційної політики).
  • Періодично чистіть старі ревізії WP-CLI (wp post delete $(wp post list --post_type='revision' --format=ids) лише після бекапу) або перевіреним плагіном.
  • Не чіпайте revisions «наосліп» на сайтах із юридично важливими змінами тексту без політики retention.

Хак на замітку. У phpMyAdmin виконайте SELECT COUNT(*) FROM wp_posts WHERE post_type='revision';. Якщо число близьке або більше за кількість опублікованих постів у 10–50 разів це червоний прапорець.

Transients і autoload options

Таблиця wp_options з виділеними transient-ключами і autoload=yes
Прострочені transients і важкі autoload options часто непомітні в адмінці, але читаються на кожен запит.

Transients зручні для кешу API, але плагіни часто пишуть ключі без нормального TTL або не видаляють прострочені. Autoload options ще гірші бо WordPress підвантажує їх одразу. Типові «важкі» автори analytics-сніпети в options, мегамасиви налаштувань конструкторів, застарілі ліцензійні payload.

  • Порахуйте розмір autoload SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload IN ('yes','on','auto');
  • Орієнтир тривоги понад 1–2 МБ autoload на середньому сайті, понад 3–5 МБ майже завжди варто розбирати.
  • Прострочені transients шукайте за _transient_timeout_ з минулим timestamp.
  • Після видалення зайвого зніміть object cache flush якщо використовуєте Redis/Memcached.

Як виміряти вплив на TTFB

Ноутбук з PageSpeed Insights і Query Monitor біля графіка TTFB
Порівнюйте TTFB до і після очистки на одному URL без кешу сторінки.

Без вимірювання «очистка БД» перетворюється на ритуал. Зробіть базу порівняння

  1. Виберіть 3 URL (головна, категорія, картка) і вимкніть page cache для тесту або додайте cache-buster.
  2. Зніміть TTFB у DevTools → Network (поле Waiting) і в PageSpeed lab.
  3. Увімкніть Query Monitor на staging і подивіться найповільніші SQL та розмір options.
  4. Після cleanup повторіть ті самі URL у той самий час доби.

Якщо TTFB майже не змінився, а SQL уже легші проблема може бути в PHP, зовнішніх HTTP або хостингу. Тоді bloat був симптомом другого плану, але його все одно варто тримати під контролем.

Швидка перевірка БД

Чекліст WP-CLI і phpMyAdmin для revisions, autoload і transients
Швидка перевірка займає 10–15 хвилин і одразу показує чи є bloat.

Чекліст на замітку (10–15 хвилин). Зробіть зараз

  1. Бекап БД (хостинг або wp db export).
  2. Порахуйте revisions wp post list --post_type=revision --format=count.
  3. Перевірте розмір autoload options (SQL вище) і топ-20 найважчих ключів.
  4. Знайдіть прострочені transients і оцініть їх кількість.
  5. Порівняйте розмір таблиць wp_posts, wp_postmeta, wp_options у phpMyAdmin.
  6. Зніміть TTFB до змін на 1–2 money-URL.
  7. У Search Console перевірте чи немає скарг на server error після робіт.
Джерело bloat Симптом Дія
Revisions Великий wp_posts, повільне збереження в редакторі Ліміт WP_POST_REVISIONS, планова очистка
Transients Тисячі ключів _transient_, стрибки розміру options Видалити expired, полагодити TTL у плагінах
Autoload options Високий TTFB навіть на простих URL Зняти autoload з важких ключів, розібрати плагін
Orphan postmeta Великий wp_postmeta після імпортів Обережне прибирання сиріт після аудиту

Типові помилки

  • Чистити прод без бекапу і без staging-прогону.
  • Видаляти всі options з «незнайомими» іменами і зламати ліцензії/плагіни.
  • Очікувати що database cleanup замінить CDN, OPcache і нормальний хостинг.
  • Залишати object cache зі старими значеннями після змін у MySQL.
  • Ігнорувати повторне накопичення бо корінь у плагіні який знову пише гігантські autoload.

Висновок

Database bloat це не абстрактна «гігієна», а прямий важіль TTFB і стабільності WordPress. Контроль revisions, дисципліна transients і аудит autoload options дають вимірюваний ефект швидше ніж черговий візуальний редизайн.

Потрібен технічний SEO-аудит із перевіркою швидкості відповіді команда SEO-Studio допоможе в рамках SEO-послуг.