Большие сайты на WordPress — как это работает про хайлоад и бигдату?

Многие говорят про то что WordPress или WooCommerce это про тормоза и он в целом для маленьких сайтов. Но что если это ложные утверждения?

Задаем контекст про абстрактный крупный сайт

Представим типовой и относительно нагруженный сайта

• например блог — 10 000 постов или даже пусть 1 000 000 постов
• или можно также представить магазин — 1 000 000 или 100 000 000 товаров
• допустим трафик — 10 млн. человек в день или около 300 000 000 в месяц
• для интереса представим что все это с интерактивом — 50% из этих посетителей — авторизованные пользователи — сайт должен уметь отвечать быстро всем — как гостям, так и авторизованным пользователям

Это очень средние цифры — чтобы было от чего оттолкнуться, и представить что у вас вот такой относительно крупный сайт.

В целом все эти цифры можно поделить на Х, или умножить на 10 — суть стратегии не поменяется.

У нас простые цели:

• сделать быструю работу сайта — страницы должны открываться со скоростью в 100-200 мс.
• сайт должен выдерживать большой трафик и не падать — от 1 млн. чел. в день
• он должен четко обрабатывать запросы как гостей, так и авторизованных пользователей
• админка при этом также должна не ломаться с учетом большого количества данных

Что в этом случае делать?

Базовая стратегия

Для работы крупного сайта на WordPress (как и любого сайта, не только про WP) необходимо обеспечить несколько ключевых условий:

• Первое и самое главное — грамотная команда
  • техлид который понимает суть высоких нагрузок
  • админы (DevOps) — которые понимают как обеспечивать HL & SRE
  • разработчики — которые понимают хотя бы основы про высокие нагрузки
• Второе — понимать все уровни кеширования и острова интерактивности
  • как обеспечить кеширование 99% страниц через веб сервер
  • дизайн сайта с учетом что 99% страниц отдаются через кеш, а 1% — это интерактив
• Третье — туча технических деталей
  • Page Cache: Полностью статическое кэширование страниц (Apache, Nginx FastCGI Cache, CloudFlare EdgeCache)
  • Выделенные серверы или облачные контейнеры: VPS, dedicated серверы или облачные платформы (AWS, Google Cloud, DigitalOcean)
  • Балансировка нагрузки: Распределение трафика между несколькими серверами
  • Масштабируемость: Возможность быстро добавлять ресурсы при росте трафика
  • Мощный MySQL/MariaDB сервер: Отдельный сервер для базы данных с оптимизированными настройками. Master-slave репликация для распределения нагрузки на чтение.
  • Object Cache: Redis или Memcached для объектного кеширования WordPress
  • CDN: Content Delivery Network для раздачи статики (Cloudflare, CloudFront)
  • Queue-системы: Обработка тяжелых задач в фоне через очереди (RabbitMQ, Redis Queue)
  • Системы мониторинга — uptime & performance
  • Резервное копирование: Регулярные бэкапы базы данных и файлов
  • Failover-системы: Автоматическое переключение на резервные серверы при сбоях
  • PHP 8+: Использование современных версий PHP с JIT-компиляцией
• Четвертое — бывает много других проблем — и команда из п. 1 должна уметь их решать

Все эти правила не уникальны только для WordPress. Эти правила работают для любых проектов про Highload & BigData.

Быстрый фронтенд — 100-200 мс. на TTFB

Есть 3 варианта как сделать фронтенд быстрым:

• Просто страничный кеш — если 99% посетителей гости
• Страничный кеш + HTMX — если много посетителей авторизованы
• Headless CMS + отдельный фронтенд — для сложных сценариев

Вариант 1: Просто страничный кеш

Это самый простой и эффективный вариант. Суть в том, что веб-сервер (Nginx или Apache) отдает полностью закешированные HTML-страницы, даже не обращаясь к PHP.

Как это работает:

• Первый запрос генерирует страницу через WordPress и сохраняет HTML в кеш
• Все последующие запросы получают готовый HTML напрямую с диска
• Время отклика: 10-50 мс вместо 500-2000 мс

Подходит для блогов, новостных сайтов, лендингов — где большинство контента статичное.

Это можно сделать через CloudFlare EdgeCache либо через Apache/Nginx. Пример решения на Апаче описан тут https://wpcraft.ru/blog/cloudflare-to-wp-super-cache-apache-htaccess

Вариант 2: Страничный кеш + HTMX

Когда у вас много авторизованных пользователей, полное кеширование страниц невозможно — каждому пользователю нужен персонализированный контент. Здесь на помощь приходит концепция «островов интерактивности».

Как это работает:

• Основная страница кешируется и отдается всем пользователям одинаково
• Персонализированные элементы (имя пользователя, корзина, уведомления) загружаются отдельными HTMX-запросами
• Эти запросы быстрые, потому что они загружают только маленькие фрагменты HTML

Примерно тоже самое что в.1, но для интерактивных островов используется HTMX. Мы это делаем через наш плагин https://wpcraft.ru/catalog/htmxer

Можно также использовать AlpineJS или аналоги.

Вариант 3: Headless CMS + отдельный фронт типа NextJS или AstroJS

Это самый сложный, но и самый гибкий вариант. WordPress используется только как бэкенд для управления контентом, а весь фронтенд строится на современных JavaScript-фреймворках.

Как это работает:

• WordPress предоставляет данные через REST API или GraphQL
• Фронтенд (Next.js, Astro) генерирует статические страницы или использует Server-Side Rendering
• Можно использовать все преимущества современных фреймворков: ISR, Edge Functions, оптимизацию изображений

Подходит для сложных веб-приложений, где нужна максимальная гибкость и производительность, но требует значительно больше ресурсов на разработку.

Есть описание такого кейса тут: https://wpcraft.ru/blog/wordpress-nextjs

Если брать AstroJS — будет примерно также.

Плюсы:

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

Минусы:

• сильно дороже ) нужно как минимум 2-3 фронтенд разработчика
• весь фронт придется писать почти с нуля — использовать готовые стартер темы не получится
• придется искать более дорогих разработчиков и нужен очень крутой техлид

Внешний поисковый движок

Это может быть Algolia, ElasticSearch, OpenSearch, Мантикора или куча других вариантиов.

Любой поиск и особенно фасетный — должен работать на основе поискового движка

То как это делать — зависит от каждого конкретного проекта и всегда по разному.

Начинать лучше с Algolia — а когда команда наберет опыта — можно пробовать любые другие движки поиска.

Та же Алголия имеет бесплатный тариф даже на 1 000 000 записей.

Типа 10 000 000 или 100 000 000 — для такого решения — не большая проблема.

Сложно бывает когда идет выход за 1 млрд записей — но там обычно уже есть сильная команда и она это умеет решать.

Главное понимать что ни одна БД SQL — не справляется с этими задачами легко. Везде и всегда про крупные сайты это решается через поисковые движки.

Оптимизация админки

• настройка объектного кеширования — redis или memceche
• тюнинг хуков — под большие таблицы как у wp vip — всегда решается исходя из узких горлышек
• все что про поиск — придется кастомизировать под поисковый движок — берем торомозящую таблицу и заворачиваем поиск на поисковый движок
• в очень редких случаях — приходится переписывать UI под REST API & ReactJS — но это примерно в 1% случаев

Тут важно отталкиваться от узких горлышек — и решение всегда подбирается под проблему.

Переход в декомпозицию сервисов через Strangler-паттерн

Когда проект растет и становится сложнее, монолитная архитектура WordPress может стать узким местом. Strangler-паттерн позволяет постепенно выносить отдельные функции в микросервисы, не останавливая работу основного сайта.

Как это работает:

• Выбираете функцию, которая создает наибольшую нагрузку (например, обработка платежей, рассылки, сложные расчеты)
• Создаете отдельный сервис на любом удобном стеке (PHP RR, Nginx Unit, PHP Swoole, Node.js, Python, Go, Rust)
• Постепенно перенаправляете трафик с фронта на новый сервис
• Старый код остается как fallback, пока новый сервис не проверен в бою

Это особенно полезно для функций, которые плохо работают в WP или требуют специфических библиотек.

Итого

WordPress вполне может справляться с высоконагруженными проектами и большими объемами данных, если следовать правильным архитектурным решениям. Ключ к успеху — это грамотная команда, современная инфраструктура, многоуровневое кеширование и готовность выносить критичные функции в отдельные сервисы по мере роста проекта. Миф о том, что WordPress только для маленьких сайтов — это результат неправильной реализации, а не ограничение самой платформы.

Все эти проблемы встречаются на любых проектах и про любые стеки и технологии.

Везде они решаются плюс минус одинаково.

Тут описаны лишь базовые аспекты. А о том как они реализуются — написаны 100500 книг. Запихать 100500 книг в 1 пост — не реально.

Но вот как дорожная карта и навигатор — надеюсь это будет иметь пользу.