← На главную

Cloudflare Workers Cache: строка кода экономит CPU

06.07.2026 13:02 · hackernews

Cloudflare запустила Workers Cache — кэш, который встаёт перед Worker'ом и настраивается одной строкой в Wrangler и знакомыми Cache-Control-заголовками. Когда кэш включён, каждый кешируемый запрос сначала проверяет кэш Cloudflare. Если есть свежий ответ, Cloudflare возвращает его напрямую — Worker не запускается, и вы не платите за CPU. Если промах — Worker выполняется, и если ответ кешируемый, Cloudflare сохраняет его для следующего запроса. Теперь запрос из любой точки мира может быть обслужен из кэша. Вся конфигурация — один блок в wrangler.jsonc.

Это решает главную проблему server-rendered приложений на Workers. Раньше нужно было либо пререндерить всё на сборке (быстро, но любое изменение требует полного ребилда), либо рендерить каждый запрос (актуально, но дорого). Workers Cache даёт третий путь: рендер по запросу, кэширование ответа и обновление по TTL. Ключевая часть — stale-while-revalidate. Когда кэш истекает, Cloudflare сразу отдаёт устаревшую копию (с заголовком Cf-Cache-Status: UPDATING), а Worker в фоне обновляет кэш. Пользователь не ждёт.

Поддерживается HTTP Vary — для одной URL можно хранить разные варианты в зависимости от заголовков (Accept, Accept-Language и т.д.). Работает как описано в RFC 9110 и 9111, без белого списка заголовков.

Кэш принадлежит Worker'у, не зоне. Нет Zone-конфигурации, Cache Rules, Page Rules — только заголовки Worker'а. Кэш следует за Worker'ом: работает на workers.dev, в preview URL и в Workers for Platforms (изолирован для каждого пользователя). Очистка кэша через ctx.cache.purge() затрагивает только entrypoint текущего Worker'а.

По умолчанию включено региональное двухуровневое кэширование. Нижний уровень — в ближайшем к пользователю дата-центре, верхний — агрегирует промахи по всей сети. Первый запрос откуда угодно заполняет верхний уровень, и все последующие запросы (даже из дата-центров, не видевших этот URL раньше) получают ответ без запуска Worker'а. Настройка не требуется.

Самый мощный сценарий — кэш между entrypoint'ами одного Worker'а через ctx.exports. Вы можете собрать Worker как цепочку маленьких entrypoint'ов: аутентификация, нормализация, дорогой бэкенд. Для каждого в wrangler.jsonc можно включить или выключить кэш. Например, gateway-вход (должен работать на каждом запросе — кэш выключен) вызывает inner-вход (кэш включён). При кэш-хите inner-вход не выполняется. При этом работает мультитенантность: ctx.props (например, userId) становятся частью ключа кэша, так что ответы разных пользователей не перемешиваются. Cloudflare заявляет, что это уникальная возможность для авторизованных API.

Фреймворк Astro уже получил встроенную интеграцию: адаптер @astrojs/cloudflare подключает Workers Cache автоматически, настраивает заголовки и Cache-Tag для инвалидации. Cloudflare работает с другими фреймворками.

В дашборде Workers Observability теперь видна статистика по кэшу: hit ratio, breakdown hits/misses/updates/bypasses. Это на том же дашборде, что и логи и CPU. Важно про биллинг: на кэш-хит Worker не выполняется, CPU не тарифицируется, но запрос учитывается как стандартный. На промахе — запрос + CPU как обычно. Нет отдельного SKU или платы за гигабайты кэша.

В планах: умнее совмещать Smart Placement и верхний уровень кэша (сейчас на полном промахе запрос может путешествовать дважды), увеличить лимиты на размер ответа (сейчас 512 MB для всех планов), добавить API ctx.cache.invalidate() для пометки ответов как устаревших (вместо полного удаления), интеграции с другими фреймворками. Workers Cache доступен всем Worker'ам на любом плане уже сегодня.

Читать оригинал →