Проблема: WordPress пересобирает каждую страницу с нуля
Из коробки WordPress полностью динамичен: каждый просмотр страницы запускает PHP, загружает плагины, выполняет десятки запросов MySQL и собирает HTML до того, как хоть один байт достигнет посетителя. Это нормально для горстки пользователей и катастрофично под нагрузкой, потому что параллелизм ограничен тем, сколько у вас воркеров PHP и как быстро отвечает MySQL. Когда запись репостят или запускается кампания, воркеры PHP скапливаются в ожидании базы данных, время ответа раздувается, а сайт может полностью упасть — не потому, что контент тяжёлый, а потому что одна и та же работа переделывается для каждого посетителя.
Объектный кэш Redis: перестаньте спрашивать базу данных одно и то же
Управляемый объектный кэш Redis перехватывает внутренние запросы WordPress и хранит их результаты в памяти. Меню, данные виджетов, связи терминов, значения опций и метаданные записей, которые иначе забирались бы из MySQL при каждом запросе, отдаются из Redis за микросекунды. При всплеске трафика это разница между базой данных, спокойно отвечающей на редкие запросы cache-miss, и базой данных, тонущей. Это особенно помогает залогиненным и динамическим страницам, которые не могут быть полностью закэшированы как страницы на edge, потому что даже некэшируемые страницы получают резко сокращённую работу с базой данных.
Edge-кэш CDN: отдавайте тяжёлое рядом
Большая часть веса страницы WordPress — статика: изображения, CSS, JS и шрифты, — и ничему из этого не нужен PHP для генерации. Отправка этих ресурсов на edge cdn.com.tr означает, что они доставляются из локации рядом с посетителем и больше не касаются origin после первого заполнения. Для контента, который безопасно кэшировать целиком, полностраничное edge-кэширование идёт дальше, отвечая на целые запросы, вообще не будя PHP. Совместный эффект в том, что ваш origin обрабатывает малую долю общих запросов, а те, что обрабатывает — по-настоящему динамические.
WAF: держите атакующий трафик вдали от ваших воркеров PHP
WordPress — самая атакуемая CMS в вебе, и большая часть этого давления автоматизирована: credential stuffing против wp-login.php, усиление через XML-RPC и зондирование уязвимых эндпоинтов плагинов. Без фильтра каждый из этих запросов потребляет воркер PHP и часть времени базы данных, ухудшая работу сайта для реальных пользователей даже когда атака никогда не удаётся. Edge WAF проверяет и фильтрует этот трафик до того, как он достигнет приложения, так что brute-force и злоупотребляющие шаблоны отбрасываются на edge, а ваши воркеры остаются свободными для легитимных посетителей. Это функция производительности не меньше, чем безопасности.
Стратегия purge, чтобы редакторы никогда не путались
Агрессивное кэширование работает только если редакторы ему доверяют. Паттерн, который держит всех довольными — точечный purge при публикации: когда запись создаётся или обновляется, очищайте этот URL и любые страницы списков, где она появляется, так что новый контент активен немедленно, пока остальная часть сайта остаётся быстрой в кэше. Статические ресурсы должны быть версионированы, так что обновление темы или плагина естественным образом производит новые URL, а не требует полного сброса. Из панели или cdnctl вы также можете очистить всю зону при масштабном изменении, но день за днём цель — маленькие, точные инвалидации, которые никогда не заставляют редактора гадать, почему его изменение не показывается.
Как пережить кампании и новостные всплески
Настоящее испытание — день, когда трафик множится без предупреждения: запускается кампания, историю подхватывают, приходит рассылка. С edge-кэшем, поглощающим статические и кэшируемые запросы, Redis, защищающим базу данных, и WAF, фильтрующим мусор, origin видит лишь малый динамический остаток, так что сайт остаётся живым и быстрым на тех же ресурсах, которые иначе бы не выдержали. Вы получаете запас прочности гораздо большего стека из управляемой конфигурации и можете наблюдать, как он держится, через логи и статус, вместо того чтобы узнавать об этом от разгневанных пользователей.
Как настроить, шаг за шагом
Запустите или перенесите WordPress на управляемую платформу
Создайте приложение WordPress в панели, которая развернёт для вас runtime PHP, постоянное хранилище загрузок и управляемую базу данных MySQL. Если вы переносите существующий сайт, принесите свои файлы и экспорт базы данных и направьте приложение на них, чтобы runtime, база данных и учётные данные подключились без ручного редактирования wp-config.
Включите управляемый объектный кэш Redis
Привяжите управляемый Redis к сайту и включите drop-in объектного кэша, чтобы WordPress хранил результаты дорогих запросов в памяти. Повторные запросы опций, меню, терминов и метаданных записей затем отвечаются из Redis вместо того, чтобы нагружать MySQL при каждом запросе.
Направьте домен через edge с Auto SSL
Подключите домен, проверьте apex и www и дайте Auto SSL выпустить сертификат. Теперь трафик сначала достигает edge cdn.com.tr, где применяются политики кэша и WAF, прежде чем что-либо переправляется на origin WordPress.
Включите кэш CDN для статических ресурсов
Включите edge-кэширование, чтобы изображения, CSS, JS и шрифты отдавались из ближайших edge-локаций вместо origin. Это самый значительный первый выигрыш для веса страницы, и он снимает большинство запросов с PHP полностью.
Включите WAF
Включите политики WAF, чтобы фильтровать распространённые шаблоны атак, попытки brute-force против wp-login.php и злоупотребления XML-RPC до того, как они израсходуют воркеры PHP. Это удерживает сайт отзывчивым для реальных посетителей, даже пока его зондируют.
Настройте purge при публикации
Настройте редакторов на очистку кэша при публикации или обновлении контента, из панели или через cdnctl, так что новые записи появляются немедленно, пока всё остальное остаётся в кэше. В сочетании с версионированными ресурсами это делает инвалидации точечными, а не сбросом всего сайта.
Примеры сценариев
Горячие истории репостят массово; edge-кэш и Redis позволяют сайту поглощать внезапный наплыв читателей, пока редакторы всё ещё видят свежий контент в момент публикации.
Залогиненные страницы и корзина не могут быть полностью закэшированы как страницы, так что объектный кэш Redis несёт нагрузку, сокращая работу с базой данных, которую генерируют эти динамические страницы.
Стандартный рецепт WordPress-плюс-Redis-плюс-CDN-плюс-WAF применяется к каждому клиентскому сайту, так что производительность и безопасность согласованы, а не решаются наугад в каждом проекте.
Часто задаваемые вопросы
Нужен ли мне также плагин кэширования?
Основная работа выполняется на уровне платформы: Redis обрабатывает объектный кэш, а CDN — edge-кэширование. Плагин кэша страниц может это дополнять, но следует избегать наслоения нескольких плагинов, все из которых пытаются делать полностраничное кэширование, что обычно приводит к конфликтующим инвалидациям и устаревшим страницам.
Сломает ли кэширование залогиненных пользователей, корзины или оформление заказа?
Нет, потому что эти страницы считаются динамическими и не кэшируются как полные страницы на edge. Они по-прежнему огромно выигрывают от объектного кэша Redis, который сокращает работу с базой данных за ними, никогда не отдавая сессию одного пользователя другому.
Чем объектный кэш Redis отличается от кэша CDN?
Кэш CDN хранит готовые ответы и ресурсы на edge, рядом с посетителями. Объектный кэш Redis живёт рядом с WordPress и хранит результаты внутренних запросов к базе данных, так что PHP может пересобирать динамические страницы, не повторяя запросы к MySQL. Они решают разные половины проблемы и сильнее всего вместе.
Опубликованная запись не показывает обновление. Что делать?
Очистите этот URL из панели или через cdnctl; edge всё ещё отдаёт ранее закэшированную копию. Настройка purge-при-публикации для ваших редакторов делает это автоматическим, так что новые и обновлённые записи выходят немедленно.
Блокирует ли WAF легитимные плагины или REST API?
WAF нацелен на известные шаблоны злоупотреблений и поведение brute-force, а не на обычный трафик приложения. Легитимное использование админки, плагинов и REST API проходит; если конкретный рабочий процесс когда-либо срабатывает правило, политику можно настроить, а не отключать.
Могу ли я перенести существующий сайт WordPress в это без простоя?
Вы приносите свои файлы и экспорт базы данных на управляемую платформу и проверяете сайт на платформе перед переключением DNS. Поскольку домен переходит на edge только после проверки сайта и готовности Auto SSL, окно переключения короткое и низкорисковое.