Небольшой WordPress-сайт может годами работать без специальной оптимизации базы. Affiliate-проект с каталогами, API, аналитикой, событиями и cron-нагрузкой ведёт себя иначе: проблемы производительности появляются не из-за одного «тяжёлого плагина», а из-за накопления множества небольших операций.
Начните с профиля нагрузки
Разделите проблему на frontend и backend. Медленная публичная страница может упираться в изображения, JavaScript или серверный TTFB. Медленная админка — в запросы к базе, cron или внешние API.
Полезно отдельно проверять главную, каталог, одиночную карточку, тяжёлую административную страницу и REST-endpoint.
wp_postmeta — не зло, но ему нужны границы
WordPress удобно хранит произвольные поля в wp_postmeta. Проблемы начинаются, когда сложные выборки одновременно фильтруют десятки meta_key и сортируют по значениям на большом объёме данных.
Если конкретный модуль постоянно делает один и тот же тип запроса, проверьте индексы и подумайте, действительно ли все данные должны жить в meta.
Индексы под реальные запросы
Индекс имеет смысл только в связке с конкретным запросом. Например, если Match Center регулярно ищет события по нескольким известным meta_key, составной индекс может значительно сократить объём чтения.
Но добавлять индексы «на всякий случай» тоже не стоит: они занимают место и замедляют запись. Изменения базы нужно документировать и уметь проверять после обновления.
WP-Cron: главная скрытая очередь
Плагины любят добавлять фоновые задачи и забывать о них. Через время в расписании появляются дубли, старые hooks и задания, которые запускаются слишком часто.
Для крупного проекта полезен health-check: количество задач, просроченные события, дубли и последнее успешное выполнение ключевых процессов.
Разделяйте cron-задачи
Импорт событий, очистка аналитики, отправка уведомлений и проверка affiliate-ссылок не должны быть одной огромной задачей. Разделение упрощает диагностику и снижает шанс, что одна ошибка остановит весь фон.
Кэшировать нужно результат, а не проблему
Кэш хорошо подходит для часто повторяющихся тяжёлых вычислений: вспомогательные меню, агрегированные рейтинги, части Match Center и отчёты.
Но если базовый запрос делает полный скан огромной таблицы, кэш лишь прячет проблему до первого промаха. Сначала оптимизируйте источник.
Старые данные нужно удалять
История коэффициентов, click analytics и технические логи растут постоянно. Retention-политика должна появляться одновременно с функцией, а не через год после запуска.
Удаление лучше делать небольшими batch-операциями, чтобы очистка сама не стала причиной долгой блокировки базы.
Не подключайте модуль на каждой странице
Если PWA, аналитический график или библиотека уведомлений нужны только в одном разделе, их CSS и JS не должны грузиться везде. Условное подключение ресурсов часто даёт более предсказуемый эффект, чем минификация ещё нескольких килобайт.
Defer и lazy loading
Некритичный JavaScript можно отложить, изображения и iframe ниже первого экрана — лениво загрузить. Но применять правила нужно осторожно: главный hero, логотип или элементы LCP не стоит бездумно убирать в lazy load.
Core Web Vitals
Оптимизация WordPress не заканчивается зелёным серверным графиком. Пользователь ощущает LCP, INP и CLS. Поэтому после backend-работы проверьте реальные шаблоны на мобильном соединении и слабом устройстве.
Внешние API и таймауты
Публичная страница не должна ждать сторонний API при каждом открытии. Данные лучше синхронизировать заранее, а фронтенду отдавать локальное состояние. Для webhook и postback нужен отдельный endpoint, который не влияет на рендер страницы.
Диагностика важнее догадок
Когда система разрастается, полезно видеть в одном месте состояние cron, API, таблиц, индексов, affiliate-ссылок и последних ошибок. Такой Health Monitor не ускоряет сайт сам по себе, зато резко сокращает время поиска причины.
Опыт BetCraft
В BetCraft отдельный этап развития был посвящён Performance & Core Web Vitals: индексы для Match Center, кэш вспомогательных данных, условная загрузка ресурсов, defer, lazy loading, очистка старой истории и контроль cron.
Если вы только выбираете основу коммерческого проекта, полезен также чек-лист как выбрать WordPress-тему для коммерческого сайта.
Частые вопросы
Нужен ли Redis каждому affiliate-сайту?
Нет. Object cache полезен при определённом профиле запросов, но не исправляет плохую модель данных. На небольшом сайте разницы может почти не быть.
Стоит ли чистить postmeta вручную?
Не без понимания происхождения данных. Удаление «лишних» строк может сломать плагины. Сначала определите владельца meta_key и используйте штатный механизм очистки.
Можно ли ускорить всё одним плагином кэша?
Он может сильно помочь фронтенду, но фоновые задачи, тяжёлые административные запросы и внешние API потребуют отдельной работы.