Аудит 50 высоконагруженных WordPress‑сайтов: скрытые паттерны, которые почти никто не обсуждает

Миф «сайт падает из‑за множества плагинов» не объясняет реальные тормоза. В 50 аудитах ключевые проблемы оказались другими: кэш и TTL, индексы, фоновые задачи, внешние запросы и раздутая база.

TL;DR

• Не количество плагинов ломает большие сайты, а 2–3 «тяжёлых» источника нагрузки в конкретной связке.
• Быстрые проекты используют «тяжёлую» технику (Redis, очереди, кастомные таблицы) для предсказуемости.
• Популярные причины тормозов: неверные TTL в объектном кэше, мусор в базе из‑за черновиков и автозагрузок, фоновые задачи на WP Cron, внешние HTTP‑вызовы на рендере.

Неожиданные выводы

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

И наоборот — «лёгкие» инсталляции с десятком плагинов регулярно упирались в единичные медленные запросы, вызванные неиндексированными мета‑фильтрами или устаревшими кастомными модулями.

Пять повторяющихся паттернов

1. 92% проблем производительности происходили из трёх плагинов или меньше. Это часто не «популярные виновники», а внутренние модули с 2018 года, которые никто не трогал. Один такой индексатор «фич» съедал бюджет CPU на каждом хите.
2. Отсутствие страничного кеширования. Даже если стоит плагин кеширования, у 90% сайтов настройки либо не сделаны, либо сделаны не правильно.
3. Контент процессы раздувают базу в среднем на ~37% за полгода. Черновики, автосохранения, дубликаты и версии превращают wp_posts и wp_postmeta в склад. Умножьте на редакторскую команду — и на каждом запросе растёт ненужная I/O.
4. Крон и фоновые задачи — главный «невидимый» источник блокировок. Долгие отчёты, импорты и синхронизации, запускаемые через WP Cron, блокируют таблицы и добивают TTFB при пиках.
5. Объектный кэш есть, но настроен плохо. TTL не соответствуют профилю чтения, отсутствует защита от штормов кэша, группы не разделены, а autoloaded‑опции грузят лишние килобайты на каждый запрос.

Что показали цифры

• 68% использовали объектный кэш, но с неверными TTL и отсутствием политики сброса.
• 41% имели хотя бы один плагин, делающий удалённые API‑вызовы на рендере страницы.
• 72% держали неиспользуемые опции с autoload, съедавшие 5–20% времени генерации.
• 38% запускали более 500 задач WP Cron в час.
• Менее 10% применяли воркеры/очереди для тяжёлых задач.
• Лишь единицы отслеживали медленные запросы проактивно через APM/профилировщики.

Кейс из практики

Крупный e‑commerce (4,2 млн визитов/мес.) жаловался на скачки до 7 секунд. Оказалось, система фильтров выполняла 14 запросов на каждую категорию; один мета‑запрос жил 3,8 секунды в часы пик.

Добавление внешнего индекса через Algolia на мета‑таблицу (например, составной по полям meta_key и meta_value с префиксом) снизило время до ~90 мс. 

Headless — не панацея

Headless решает задачи изоляции фронтенда и гибкой доставки, но создаёт новые: предпросмотры, фрагментированное кэширование, двойной стек компетенций.

В реальных выборках лишь малая доля крупного трафика требует headless; часть проектов откатывается, как только растущие накладные расходы перевешивают профит.

План действий для продвинутых

1) Приручите autoloaded‑опции

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

wp option list --autoload=on --fields=option_name,size | sort -nrk2 | head -50

Проверьте общий размер автозагрузки и удерживайте его в пределах разумного для вашего профиля (часто — до ~800 КБ).

SELECT SUM(LENGTH(option_value)) AS autoload_bytes
FROM wp_options WHERE autoload = 'yes';

2) Найдите топ‑10 запросов по стоимости

Используйте профилировщик и Query Monitor. Оптимизируйте: уберите LIKE с ведущим %, добавьте покрытия индексами, перепишите мета‑фильтры. Для meta‑запросов часто помогает индекс по (meta_key, meta_value(191)) или вынесение интенсивно используемых атрибутов в отдельные таблицы.

3) Уберите тяжёлые задачи из WP Cron на системный уровень

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

# В crontab сервера
* * * * * wp cron event run --due-now --path=/var/www/site

Импорты, отчёты, синхронизации — через воркеры/Action Scheduler, с контролем конкурентности и ретраями.

4) Настройте объектный кэш как систему, а не плагин

• Задайте TTL по типам данных (навигация — дольше, динамика — короче).
• Минимизируйте шторм кэша: блокировки на ключ, «мягкое» протухание, фоновое обновление.
• Отдельные пространства ключей для разных сред, сериализация с экономией памяти.
• Не кэшируйте короткоживущие токены/nonce; чистите горячие ключи осмысленно.

5) Контролируйте удалённые вызовы на рендере

• Логируйте внешние HTTP‑запросы и их латентность.
• Старайтесь получать конфигурации вне запроса пользователя (по расписанию), на рендере — только из кэша.
• Выставляйте таймауты и «план B» при недоступности поставщика.

6) Перенесите безопасность на «край» и оффлайн‑сканы

Сканирование на вредонос и тяжёлые проверки переносите в фон/cron. Веб‑фильтрацию отдавайте серверному/периметральному слою. Никаких синхронных проверок в момент рендера.

7) Схема данных: таблицы и индексы под вашу доменную модель

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

8) AI‑документы — вне WP

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

Ограничьте количество ревизий и регулярно чистите корзину/осиротевшие записи.

# Ограничение числа ревизий
# define('WP_POST_REVISIONS', 10);

9) Включите наблюдаемость

• Долгие запросы базы: минимум — slow_query_log; лучше — APM/трейсинг.
• Метрики кэша: hit ratio, пропуски, размер ключевых пространств.
• Алармы на рост очередей, время задач и частоту ретраев.

Контрольный чек‑лист

• Автозагрузка опций <= целевого порога, топ‑ключи очищены.
• Топ‑10 медленных запросов зафиксированы и оптимизированы, индексы покрывают фильтры.
• WP Cron не выполняет тяжёлых задач; очереди работают с ограничением конкурентности.
• Объектный кэш с корректными TTL и защитой от штормов.
• Удалённых HTTP‑вызовов на рендере — минимум, стоят таймауты и кэш.
• Security‑проверки вынесены из рендера, периметр отрабатывает на «краю».
• AI‑черновики не плодят ревизии внутри CMS; установлен лимит ревизий.
• APM и профилировщики включены, алерты настроены.

Вывод

Большинство проблем высоконагруженных WordPress‑проектов — это не «масштаб», а невидимая нагрузка из решений, принятых когда‑то «временно» или в слепую.

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