WP: автоматизация кэша и прогрева для Cloudflare и Yandex CDN

Утро, понедельник, редактор жмёт «Опубликовать» в WordPress, а вы смотрите на графики, как на прогретую плиту: всё шипит, скакнул TTFB, пользователи из регионов видят сайт через секунды три, а кто-то вообще словил пустую страницу. На кухне остывает кофе, в чате маркетолог пишет «ну что там по скорости?», а сервер делает вид, что его это не касается. Если узнаёте себя, вам пора подружить сайт с CDN и научить автоматику двигаться быстрей вас. Кэш не обязан греться руками, особенно когда у вас редакционный конвейер, акции в магазине и сезонность, как у тюльпанов 8 марта.

Секрет скучен, но полезен: правильно настроенный кэш плюс автоматический прогрев и очистка решают 80% проблем с дерганой скоростью. Cloudflare и Yandex CDN берут на себя тяжёлую работу, а сценарии в make.com шевелят кэш в нужные моменты. По цифрам это совсем не мелочь: Cloudflare APO для WordPress умеет кэшировать даже HTML и сокращает время до первого байта примерно на 72% и ускоряет первое «существенное» отрисованное изображение на 23%. А если не греть кэш заранее, то посетители первые минуты после публикации фактически бета-тестируют ваш бэкенд. Зачем так жить, если можно нажать пару галочек, собрать сценарий и спокойно допить кофе.

Make AI агент, инструменты для автоматизаций — Автоматизация прогрева кэша легко ложится в сценарии make.com, вместе с уведомлениями и мониторингом

Что именно мы автоматизируем и почему это важно

В WordPress есть несколько слоёв кэширования, но для фронта решают два: страницы и статика на краю сети. Аппаратная память CDN ближе к пользователю, чем ваш сервер в Москве или Питере, и именно отсюда берётся ощущение «летает». Проблема в том, что сразу после обновления контента CDN ещё не знает про новые страницы, а значит первые заходы летят на ваш origin. Если публикаций много или одновременно меняете тему, меню, кастомные блоки, то любая минута без прогретого кэша превращается в лотерею. Автоматика нужна, чтобы между событием в WP и состоянием CDN не было дырки: чистим строго то, что изменилось, и тут же прогреваем маршрут из критичных URL, без фанатизма и без DDoS своего же сайта.

Cloudflare хорош как универсальный щит и ускоритель, у него много точек присутствия, умные правила и APO для WordPress, которое кэширует HTML аккуратно и умеет подчищать его при малейшем обновлении. Yandex Cloud CDN нравится тем, что держит контент ближе к российской аудитории, поддерживает экранирование источников, сегментацию, гибкие HTTP-настройки и адекватную аналитику. Комбинации бывают разные, но главное помнить простую вещь: один хостнейм — один CDN. Не пытайтесь посадить две CDN последовательно на один и тот же домен, закончится чёрной магией заголовков и потерей кеш-хитов, это не тот трюк, который хочется дебажить в пятницу вечером.

Cloudflare APO для WordPress без танцев с бубном

Если у вас Cloudflare, берегите пару часов жизни и сразу включайте APO через официальный плагин WordPress. Получите HTML-кэширование на краю, и это ощущается моментально, особенно на мобильном интернете и в регионах. Дальше настраиваем разумные правила: не кэшируем wp-admin и всё, где есть личные кабинеты, корзина и оформление заказа в WooCommerce, обходимся без кэширования запросов с авторизационными cookie типа wordpress_logged_in и woocommerce_cart_hash. TTL для HTML можно держать около часа, а для статики смело выставлять сутки и больше, CDN всё равно умеет обновлять её по версии файла. На уровне API нас интересует точечная очистка: при изменении записи чистим URL самой записи, главную, пагинации и соответствующую рубрику. На худой конец, когда меняется тема или глобальный элемент, выполняем глубокую очистку и после этого обязательно прогреваем маршрут, чтобы не поднимать сервер на колени.

Yandex Cloud CDN: когда ближе — значит быстрее

Если основная аудитория в России и СНГ, Yandex Cloud CDN отдаёт контент быстро и стабильно, а экранирование источника помогает не сжечь бэкенд при всплесках. Полезные штуки вроде правил перезаписи, безопасного доступа и компрессии включаются один раз и дальше не требуют внимания, а вот инвалидировать кэш при изменениях надо обязательно. Через API можно чистить по путям или маскам, а через CLI запускать очистку в автоматических задачах. Одна ремарка, которая экономит нервы: не забывайте перед прогревом отправлять запросы с правильным Host той витрины, для которой настраивалась CDN, иначе кэш прогреется не там, где вы думали. И да, если вы используете Cloudflare как чистый DNS, а CDN отдаёт Yandex, то в Cloudflare у записи должен быть серый облачок — режим DNS only, чтобы не возникали двойные заголовки и неожиданные обходы кэша.

Автоматизация в make.com: три ситуации, где сценарии тащат

Сценарий первый, самый частый: публикуется или обновляется запись в WordPress, а вы хотите, чтобы уже через минуту пользователи в регионах видели прогретую версию. В make.com подключаем модуль WordPress Watch Posts или ловим вебхук из плагина WP Webhooks, забираем пермалинк и собираем список связных адресов. Минимальный набор обычно включает сам пост, главную, первую страницу рубрики и, если есть, страницу автора. Далее отправляем запрос на очистку кэша в Cloudflare по API с телом наподобие {«files»:[«https://example.com/novost-1″,»https://example.com/»]} и тут же проходимся HTTP-запросами по этим ссылкам с паузой в 200-400 мс, чтобы не долбить исходник до полусмерти. По окончании шлём тихое уведомление в Telegram, мол, кэш прогрелся, хитов в ответах достаточно, живём.

Сценарий второй — ночной прогрев. Берём sitemap.xml, парсим его в make.com, отбираем верхние страницы по трафику или свежести, прогреваем отдельно мобильным и десктопным юзер-агентом, чтобы CDN не ленился и держал оба варианта. По опыту, 200-400 адресов за ночь более чем, сверх этого эффект на пользователя уже убывающий, а вот нагрузка на origin растёт вполне себе. Ошибки складываем в таблицу и повторяем попытку через 10-15 минут, не чаще. Этот сценарий особенно спасает после обновления плагинов или когда дизайнер внезапно переименовал половину меню, выждав ночь, утром всё уже на горячем кэше и никто не видит «холодных» страниц.

Бот для телеграма для уведомлений о кэше — Телеграм-бот не только болтает, но и сообщает о промахах кэша, причём без лишней драматургии

Сценарий третий — редкие, но болезненные события. Вы сменили тему, затронули шаблон header.php, подкрутили глобальные блоки или перевезли виджеты. Тут точечная чистка не поможет, нужен purge всего HTML и мягкий, ступенчатый прогрев. Сценарий в make.com дергается вручную через специальную кнопку или триггерится вебхуком «Theme switched», делает полную очистку HTML-кэша и затем прогревает маршрут партиями по 20-30 адресов с короткими паузами, постепенно проходя по всем важным страницам. Если у вас Yandex Cloud CDN, аналогично инвалидируем маской вроде /* или пачкой путей, а дальше тот же степенный прогрев, без излишних героических нагрузок. И не забываем про ограничитель параллельности в сценарии, тут жадность точно не к месту.

Детали, которые решают больше, чем кажется

Распределите роли: один и тот же домен — один CDN, какое бы искушение ни было «ускорить ещё чуть-чуть». В Cloudflare включите Cache Everything там, где у вас чистый статический HTML, а для WordPress с авторизованными пользователями поставьте правила Bypass по cookie wordpress_logged_in и woo*. В Yandex Cloud CDN заведите понятные правила TTL: для HTML 30-60 минут, для статики сутки и больше, плюс включите сжатие на уровне CDN, даже если сервер уже сжимает, не повредит. Прогрев делайте только кэшируемыми GET-запросами без лишних параметров, и не забывайте, что избыточные хитрые заголовки могут увести кэш в сторону, лучше меньше, но точнее. По оповещениям — простая нотификация в Telegram помогает держать руку на пульсе, особенно если написать в неё, сколько из прогретых URL вернули cache-hit, а сколько промахов, и дать ссылку на лог.

С цифрами всё приземлённо: минус одна секунда к загрузке страницы может стоить около 7% конверсии и примерно 11% просмотров, это не страшилка, а аккуратная математика. Поэтому целимся в стабильный TTFB и предсказуемый FCP, а для этого кэш должен быть горячим в момент, когда маркетолог нажимает «Запланировать публикацию». Если хотите точности, сравнивайте графики до и после сценариев и смотрите, как ведёт себя коэффициент cache-hit в аналитике CDN. Кстати, не гонитесь за 100% хитами, это мираж, важнее, чтобы в пиковые моменты у вас не слипся бэкенд, а пользователи не читали страницу по слогам.

Создание страницы сайта на автомате и публикация с прогревом — Автосоздание страниц плюс автопрогрев кэша — и публикации не превращаются в мини-распил сервера

Как подружить это с ежедневной рутиной

Начните с малого: один сценарий на публикацию и один ночной прогрев. В WordPress ставим плагин для вебхуков или используем встроенную интеграцию make.com, в Cloudflare создаём API-токен с правами на зону, в Yandex Cloud — сервисный аккаунт для вызовов purge. Для Cloudflare очистка по API банально проста: POST на адрес zones/{zone_id}/purge_cache, а в теле либо {«purge_everything»:true} для редких случаев, либо список файлов, так живёт ваш сервер подольше. Для Yandex Cloud CDN используйте их API метод для инвалидирования кэша по путям или CLI-команду, и храните в переменных окружения ключи, а не впрямую в модуле HTTP, это банальная безопасность, но часто про неё вспоминают после. В сценарии добавьте защёлки от циклов, например не реагируйте на автосохранения и не трогайте черновики, иначе можно красиво застрелить себе ноги частыми вызовами.

Мониторинг и оповещения не для галочки. Пара проверок в минуту через внешний пингер плюс телеграм-уведомление о резком падении cache-hit спасают от неприятных сюрпризов прямо во время рекламной закупки. Если видите, что после публикации более 30% критичных URL остаются без хита, проблема в прогреве или в правилах кэширования, сценарий стоит перепроверить. Иногда дело вообще в том, что на стороне темы внезапно добавили приватный заголовок или выставили no-cache, и тогда хоть обпрогревайся, CDN будет делать вид, что не слышит.

Частые грабли и короткие обходные тропы

Самая нелепая ошибка — прогревать URL с параметрами предпросмотра и надеяться на чудо, такие страницы никогда не лягут в публичный кэш. Второе место делят бездумные purge_everything и слишком агрессивная параллельность в сценариях, от этого сервер быстро делает «ой» и уходит в глубокую задумчивость. Третье — смешные конфликты плагинов кэширования в самом WordPress, когда один пишет заголовки одно, а другой отменяет их через миллисекунду, тут или выключаем один, или синхронизируем правила. Наконец, проверьте, что CDN действительно стоит на том домене, который вы прогреваете: если оставить оранжевое облако в Cloudflare и одновременно включить Yandex Cloud CDN, дальше начинается театр теней, где у каждого своя правда, а у пользователя пустой экран. Простая проверка заголовков через curl экономит пару часов жизни, не пренебрегайте.

Хочется готовые сценарии и понятные видео

Если хочется сесть и поехать, без изучения всей матчасти за раз, у нас есть готовые наработки. Подробные уроки про автопрогрев, очистку и уведомления, аккуратные пресеты под Cloudflare и Yandex Cloud, и набор шаблонов сценариев, которые можно поставить за вечер. С растановкой пауз, обработкой ошибок и аккуратной работой с sitemap, чтобы сервер не хрипел. Загляните сюда — Обучение по make.com, а за готовыми шаблонами и обновлениями приходите сюда — Блюпринты по make.com. Если только начинаете и хотите быстро понять, как собрать сценарии под свой стек и не застрять, регистрируйтесь в make.com, там всё запускается из браузера, без серверной магии и танцев. Ну и живое общение, примеры, адекватные советы мы собираем здесь: Хотите научиться автоматизации рабочих процессов с помощью сервиса make.com и нейросетей ? Подпишитесь на наш Telegram-канал. Старайтесь не откладывать, скорость сайта любит тех, кто ей помогает, а не мешает.

FAQ

Что такое прогрев кэша и зачем он вообще нужен
Прогрев — это преднамеренный заход на нужные страницы, чтобы CDN положил их в кэш до того, как туда придут живые пользователи. Он нужен для того, чтобы TTFB и FCP не плясали в первые минуты после публикаций, релизов и больших правок. Без прогрева первые посетители расплачиваются своим временем за ваше обновление, что обычно плохо конвертируется в продажи и удержание. Сценарии в make.com делают это без суеты и в правильном темпе, чтобы не перегружать origin. Один раз настроили — дальше работает само.

Можно ли использовать Cloudflare и Yandex Cloud CDN одновременно
На одном хостнейме — нет, это плохая идея. Либо Cloudflare как CDN, либо Yandex Cloud CDN, а второй сервис максимум остаётся как DNS или на другом поддомене. Иначе запутаетесь в заголовках, потеряете хиты и получите непредсказуемое поведение. Если хочется совместить, вынесите часть статики на поддомен с отдельной CDN, а основной HTML оставьте на другом — так будет корректно.

Как не убить сервер прогревом
Простой рецепт: ограничьте параллельность, добавьте паузы в 200-400 мс, грейте партиями по 20-30 адресов и избегайте «purge всего, а потом штурм». Прогревать стоит только то, во что реально пойдут пользователи, остальное догреется естественным трафиком. И, пожалуйста, не грейте страницы с параметрами админки или предпросмотра, это не ложится в публичный кэш и просто тратит ресурсы.

Как понять, что кэш действительно тёплый
Посмотрите заголовки ответа — CDN обычно возвращает отметку cache-hit. В аналитике Cloudflare или Yandex Cloud видно долю хитов, и если после публикации она быстро растёт, значит всё работает. Можно добавить в сценарий make.com быстрый чек нескольких URL после прогрева и присылать результат в Telegram. Если хитов нет — ищите запреты на кэширование в заголовках и метатегах, они коварны.

Что делать с WooCommerce и личными кабинетами
Эти разделы кэшировать нельзя. В Cloudflare и Yandex Cloud ставим правила Bypass по путям типа /cart, /checkout, /my-account и по соответствующим cookie. Категории и карточки товаров при этом кэшируются отлично, если у вас нет персонализированных блоков на уровне HTML. При изменении цен или акций удобнее делать точечную очистку по URL плюс лёгкий прогрев этих страниц.

Нужен ли APO, если я на Yandex Cloud CDN
APO — фишка Cloudflare для HTML WordPress, она не применима в Yandex Cloud. Если у вас Yandex Cloud CDN, используйте его кэширование страниц по правилам, это работает не хуже, просто настраивается иначе. APO хорош, когда вы полностью на Cloudflare и хотите получить максимум из экосистемы Cloudflare.

Как подключить make.com к WordPress без лишних плагинов
Можно использовать встроенное приложение WordPress в make.com, либо завести небольшой webhook посредством functions.php и Rest API, но большинству проще и безопасней поставить легковесный плагин для вебхуков. Плагин даёт удобные события вроде «запись опубликована» и фильтры, что сильно ускоряет настройку. Главное — не ловить автосохранения, они плодят ненужные триггеры.

Почему очистка кэша в Cloudflare не сработала
Проверьте права токена, зону и точные URL, включая протокол и домен. Если включили purge по списку, а страница доступна по www и без него, чистите оба варианта или держите единый канонический адрес. И обязательно убедитесь, что в этот момент у вас не стоит правило, которое запрещает кэширование этого HTML, иначе будет вечный miss, и прогрев просто некуда складывать.

Сколько URL прогревать после публикации
Обычно хватает 5-10 адресов: сама запись, главная, первая рубрика, возможно связанные теги и первая страница пагинации. Для крупных порталов список растёт, но лучше держать его компактным и добавлять ночной сценарий, который пройдётся по большему набору. Качество важнее количества, особенно когда важен первый час после публикации.