🐱 🦊 🐼 🦝 🐰 🦉

Кто сегодня с нами? 🐾

Животные меняются при загрузке страницы

Главная / Блог / Оптимизация скорости загрузки статических ресурсов с помощью Cloudflare Workers

13.05.2026 14 мин чтения 2342 слов

Оптимизация скорости загрузки статических ресурсов с помощью Cloudflare Workers

Ускорьте загрузку статических файлов с Cloudflare Workers: примеры кода, чек‑лист и мониторинг через Lighthouse.

🐱

Читать проще с подсказками

Карточки, чек-листы, таблицы и примеры помогают быстро найти нужный ответ.

✅ чек-листы 📈 SEO-практика ⚡ быстро

Скорость загрузки статических файлов напрямую влияет на Core Web Vitals, пользовательский опыт и позиции в поисковых системах. Cloudflare Workers позволяют обрабатывать запросы на границе сети, управлять кэшем и заголовками, а также внедрять динамическую логику без изменения исходного кода сайта. В этом гиде рассматривается практический путь от подготовки до мониторинга, включая кодовые примеры и чек‑листы.

Используйте Cloudflare Workers для динамического кэширования статических ресурсов, корректной установки заголовков Cache‑Control и ETag, а также для реализации fallback‑логики. Следуйте подготовительным шагам, проверяйте результаты с помощью Lighthouse и Cloudflare Analytics, и регулярно мониторьте показатели производительности.

Что такое Cloudflare Workers и как они влияют на загрузку статических ресурсов

Cloudflare Workers – это JavaScript‑функции, которые запускаются в дата‑центрах Cloudflare, расположенных по всему миру. Благодаря такому размещению запросы обрабатываются «на границе» сети, то есть ближе к пользователю, чем сервер вашего сайта. Это устраняет одну из главных причин медленной загрузки статических файлов: задержку от маршрута до origin‑сервера и его обработки. Edge‑вычисления позволяют выполнять проверку, модификацию, агрегацию и кеширование контента, прежде чем он попадёт в браузер, что сокращает RTT и количество round‑trip.

Преимущества Edge‑обработки:

Снижение латентности. Запрос обрабатывается в ближайшем дата‑центре, поэтому время до первого байта падает до десятков миллисекунд.
Персонализация без лишних запросов. На edge можно менять заголовки, добавлять токены, менять путь к CDN‑ресурсу, не отдавая запрос origin‑у.
Гибкая политика кеширования. Можно задать TTL, правила по User‑Agent, геолокации, а также динамически генерировать «обновлённые» версии файлов.
Защита от DDoS и bot‑атак. Workers могут фильтровать трафик, блокировать подозрительные запросы и отдавать статический «пустой» ответ.

Как это отражается на Core Web Vitals:

FCP и LCP выигрывают от более быстрой доставки CSS, JS и изображений. Edge‑кеш и раннее редирект‑обработки уменьшают время до первого байта, а значит и до первого контента.
CLS улучшается, если на edge можно заранее определить размеры медиа‑ресурсов и отдавать корректные атрибуты width/height, предотвращая сдвиги.
LCP‑потенциально снижается на 30–50 % при правильной настройке TTL и предзагрузке критичных файлов, что особенно важно для мобильных устройств с медленным соединением.

Таким образом, Cloudflare Workers превращают статические ресурсы из «пассивных» файлов в «умные» ответы, которые доставляются быстрее, адаптируются к пользователю и поддерживают метрики Core Web Vitals на уровне, необходимом для хорошей позиции в поиске.

?️

Подготовка проекта к использованию Workers

Перед тем как подключить Cloudflare Workers к проекту, нужно подготовить окружение и определить, как именно будут обрабатываться запросы к статическим ресурсам. Установка Wrangler – официального CLI‑инструмента, который упрощает развертывание, а настройка аккаунта гарантирует, что все запросы будут направлены в нужный регион. Далее определяем правила маршрутизации: в wrangler.toml указываем routes, где Workers будет перехватывать запросы к *.js, *.css и другим статическим файлам. Наконец, выбираем тип хранилища. KV подходит для простых кэшей и небольших файлов, Durable Objects – для сложных сценариев, где нужна синхронизация состояния между несколькими воркерами.

Установить Wrangler: npm i -g @cloudflare/wrangler
Авторизоваться в Cloudflare: wrangler login
Создать новый проект: wrangler generate my-worker
В wrangler.toml прописать account_id и zone_id
Определить маршруты: routes = ["example.com/static/*"]
Выбрать хранилище:
- KV – kv_namespaces = [{binding = "STATIC", id = "..." }]
- Durable Objects – durable_objects = [{name = "STATIC", class_name = "StaticHandler"}]
Проверить доступность маршрутов через wrangler dev

Кэширование статических файлов через Workers

Создайте новый Worker в Cloudflare Dashboard и назовите его, например, static-cache.
Внутри fetch(event) проверьте, является ли запрос статическим (по расширению файла: .js, .css, .png, .jpg, .svg).

Для таких запросов попытайтесь вернуть ответ из Cache:

const cacheKey = new Request(event.request.url, { cachePolicy: 'no-store' });
const cache = caches.default;
let response = await cache.match(cacheKey);

Если кэш пуст, выполните обычный fetch, запишите ответ в кэш с заданным TTL (например, 86400 с) и верните его клиенту:

if (!response) {
  response = await fetch(event.request);
  const cacheResponse = response.clone();
  cacheResponse.headers.set('Cache-Control', 'public, max-age=86400');
  event.waitUntil(cache.put(cacheKey, cacheResponse));
}
return response;

Для динамических запросов (GET без расширения, POST, PUT и т.п.) пропустите кэш и просто return fetch(event.request).
Проверьте работу в DevTools → Network: первый запрос к статическому ресурсу должен иметь статус 200, второй – 200 (from cache). В Cloudflare Dashboard → Workers → Logs можно увидеть, сколько раз ответ пришёл из кэша.

addEventListener('fetch', event => {
  const url = new URL(event.request.url);
  const staticExt = /\.(js|css|png|jpg|jpeg|gif|svg|ico)$/i;
  if (!staticExt.test(url.pathname)) return event.respondWith(fetch(event.request));

  const cacheKey = new Request(event.request.url, { cachePolicy: 'no-store' });
  const cache = caches.default;

  event.respondWith((async () => {
    let response = await cache.match(cacheKey);
    if (!response) {
      response = await fetch(event.request);
      const cacheResponse = response.clone();
      cacheResponse.headers.set('Cache-Control', 'public, max-age=86400, immutable');
      event.waitUntil(cache.put(cacheKey, cacheResponse));
    }
    return response;
  })());
});

Пример кода для Workers

В Cloudflare Workers запросы обрабатываются через fetch‑событие. Чтобы ускорить отдачу статических файлов, задаём Cache‑Control и ETag, а при сетевых сбоях – возвращаем запасной вариант из KV.

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  // только GET‑запросы
  if (request.method !== 'GET') return fetch(request)

  try {
    // попытка получить из сети
    const networkResponse = await fetch(request)
    if (!networkResponse.ok) throw new Error('Network error')

    // копируем тело для расчёта ETag
    const cloned = networkResponse.clone()
    const body = await cloned.arrayBuffer()
    const hash = await crypto.subtle.digest('SHA-256', body)
    const etag = btoa(String.fromCharCode(...new Uint8Array(hash)))

    // создаём ответ с заголовками кэширования
    return new Response(body, {
      status: networkResponse.status,
      statusText: networkResponse.statusText,
      headers: {
        ...Object.fromEntries(networkResponse.headers),
        'Cache-Control': 'public, max-age=31536000, immutable',
        'ETag': etag
      }
    })
  } catch (e) {
    // fallback: отдаём из KV (привязано в настройках Workers)
    const fallback = await MY_KV.get(request.url, 'arrayBuffer')
    if (fallback) {
      return new Response(fallback, {
        headers: {
          'Cache-Control': 'public, max-age=86400',
          'ETag': 'fallback'
        }
      })
    }
    // если даже fallback не найден – возвращаем 503
    return new Response('Service unavailable', { status: 503 })
  }
}

Чек‑лист проверки после развертывания

Проверка заголовков Cache‑Control: убедитесь, что статические файлы возвращают корректные значения (max‑age, must‑revalidate, no‑cache) и что они не конфликтуют с Cloudflare Edge Cache TTL.
Проверка hit/miss в Cloudflare Analytics: в разделе Traffic → Cache сравните hit‑ratio, стремясь к >90 %. Если доля miss превышает 10 %, проверьте Page Rules, Worker‑скрипты и наличие правильных заголовков.
Тестирование CORS: посмотрите ответы на запросы из разных доменов, убедитесь, что Access‑Control‑Allow‑Origin, Methods, Headers и Credentials корректно настроены и не нарушают кеширование.
Проверка 304 Not Modified: запросы с If‑Modified‑Since/If‑None‑Match должны возвращать 304, а Cloudflare не должен игнорировать эти заголовки.
Проверка Subresource Integrity (SRI): убедитесь, что hash‑значения в атрибуте integrity не изменяются Worker‑скриптами и что браузер их принимает.
Проверка HTTPS: все запросы к статическим ресурсам должны идти по HTTPS, а Worker не должен генерировать HTTP‑ответы.
Проверка CSP и HSTS: убедитесь, что заголовки Content‑Security‑Policy и Strict‑Transport‑Security присутствуют и не конфликтуют с заголовками кеша.
Проверка preflight‑OPTIONS: запросы OPTIONS должны отвечать корректно, не вызывая лишних кеш‑miss.
Проверка логов Worker: включите логирование ошибок и просмотрите их, чтобы убедиться, что скрипт не генерирует исключения, влияющих на кеш.
Проверка TTL в Worker‑кешировании: если вы задаёте собственный TTL через Cache API, убедитесь, что он не конфликтует с Cloudflare‑TTL и не приводит к преждевременному истечению кеша.

Частые ошибки при настройке Workers

Неправильные правила маршрутизации: правило «/static/*» может захватывать динамические маршруты, заставляя Worker выполнять fetch‑ы к origin даже для API‑запросов. Это увеличивает латентность и расход трафика. Чтобы избежать, уточняйте префиксы и ставьте правила в порядке от специфичного к общему.
Отсутствие Cache‑Control в ответах Workers: без заголовка «Cache‑Control: public, max-age=31536000» CDN не сохраняет статические файлы, и каждый запрос приводит к fetch‑у из origin. Добавьте заголовок в ответах, чтобы Edge‑кэш хранил объекты и уменьшил нагрузку на сервер.
Перегрузка edge‑кэша из‑за избыточных fetch‑ов: если Worker делает fetch‑ы для каждого запроса, даже к уже закешированным ресурсам, это создаёт «thundering herd» и приводит к падению производительности. Используйте условный fetch с «cf.cacheEverything» и «cf.edgeCacheTTL», а также проверяйте заголовок «cf-cache-status» перед запросом.
Неэффективное использование fetch‑ов для кешируемых ресурсов: если Worker не проверяет заголовок «cf-cache-status» и всегда делает fetch, даже когда ресурс уже в кэше, это приводит к лишним запросам и увеличивает время ответа. Добавьте условие, чтобы fetch выполнялся только при «MISS».

Тестирование производительности

Перед публикацией изменений в Workers важно измерить реальную скорость и качество страницы. Используем Lighthouse и WebPageTest как базовые метрики, а затем проводим A/B‑тестирование, чтобы сравнить «до» и «после». Проверяем Core Web Vitals (LCP, FID, CLS), ведь они напрямую влияют на ранжирование и пользовательский опыт. Тесты запускаем в одинаковых условиях: одна и та же география, браузер, сетевой профиль. Результаты сравниваем в виде таблицы, чтобы быстро увидеть прирост времени загрузки и улучшения Vitals.

Соберите baseline: запустите Lighthouse (desktop, mobile) и WebPageTest для исходной версии без Workers. Сохраните отчёты.
Разверните Workers‑скрипт в staging‑окружении, используя тот же домен, но с отдельным поддоменом (например, test.example.com).
Повторите Lighthouse и WebPageTest на новой версии. Убедитесь, что URL‑адреса и параметры запроса идентичны.
Запустите A/B‑тест: распределите трафик 50/50 между исходным и Workers‑вариантом через Cloudflare Page Rules или приложение. Снимайте метрики через WebPageTest API и Google PageSpeed Insights API.
Сравните Core Web Vitals: LCP должен сократиться минимум на 200 мс, FID — до 100 мс, CLS — до 0,1. Если показатели не улучшаются, вернитесь к коду.
Проверьте, что Workers не увеличивают размер ответа: Content‑Length в заголовках должен быть не выше исходного + 5 %. Если растёт, оптимизируйте кеш‑параметры.
Проведите нагрузочный тест в Cloudflare Load Balancer, чтобы убедиться, что Workers выдерживают пиковый трафик без увеличения времени отклика.
Соберите финальные отчёты, сравните средние значения и процентное изменение. Если улучшения > 10 % в LCP и FID, Workers можно продвигать в продакшн.

Метрика	Baseline	Workers	Изменение
LCP (мс)	2100	1700	-400
FID (мс)	120	80	-40
CLS	0.28	0.12	-0.16
Speed Index	3500	2800	-700
Time to First Byte	250	220	-30

План внедрения с этапами

План внедрения Cloudflare Workers для статических ресурсов

Подготовка (1‑2 недели) – собрать исходники, определить список файлов, проверить наличие CDN‑ключей, настроить Wrangler и получить API‑токен Cloudflare. Создать KV‑store для динамических метаданных.
Разработка (3‑4 недели) – написать worker‑скрипт, реализовать стратегию кеширования (Cache‑First + Stale‑While‑Revalidate), добавить заголовки Cache‑Control, проверить работу локально через wrangler dev. Параметры тестирования: Lighthouse, Core Web Vitals.
Деплой и проверка (5‑6 недели) – задеплоить worker, привязать route к нужному пути, включить политику кеша в Cloudflare. Проверить через Cloudflare Dashboard, убедиться, что статические файлы обслуживаются из Workers, а не из origin. Сравнить время ответа до/после.
Мониторинг (7‑8 недели) – настроить Cloudflare Analytics, добавить метрики в Grafana, установить алерты на падение LCP, FCP. Периодически проверять Lighthouse отчёты и сравнивать с baseline.
Оптимизация (9+ недели) – анализировать «hot‑spots» в отчётах, менять TTL‑время, добавлять заголовки ETag, использовать Brotli/Compress. Периодически очищать KV‑store, проводить A/B‑тесты с разными стратегиями кеширования.

Что отслеживать после запуска

После запуска Workers‑скрипта важно держать руку на пульсе. Основные показатели: отношение hit/miss в Cloudflare Analytics, частота ошибок и таймаутов в логах Workers, Core Web Vitals в отчётах Lighthouse и в Cloudflare Analytics. Сравнивайте текущие значения с базовыми метриками до развертывания и задавайте пороги, при превышении которых автоматически генерируются оповещения.

Hit/miss > 90 % – убедитесь, что кэшируются все статические ресурсы.
Ошибки Workers
Таймауты Workers
LCP
Проверка заголовков Cache‑Control и ETag – убедитесь, что они присутствуют для всех статических файлов.

Метрика	Что смотреть	Где смотреть
Hit/Miss Ratio	Процент кэшированных ответов	Cloudflare Analytics → Caching → Hit ratio
Ошибки Workers	Коды 5xx, исключения	Workers → Logs → Error logs
Таймауты Workers	Время выполнения > 30 с	Workers → Logs → Timeout logs
LCP, FID, CLS	Core Web Vitals	Cloudflare Analytics → Performance → Core Web Vitals
Cache‑Control/Etag	Наличие заголовков	HTTP‑запросы в DevTools → Network

Возможные риски и как их избежать

Работа с Cloudflare Workers может значительно ускорить статические ресурсы, но при этом скрываются несколько критических рисков, которые могут обернуться падением позиций, ухудшением UX или техническими сбоями.

Перевышение лимитов Workers (запросы, время выполнения, память) приводит к отказу запросов и потере контента.
Неправильные заголовки (Cache‑Control, Content‑Type, ETag) мешают поисковым ботам правильно индексировать страницы и могут вызвать дублирование контента.
Конфликты с CSP (Content Security Policy) из‑за динамически генерируемых скриптов блокируют загрузку ресурсов, ломая функциональность PWA.

Периодически проверяйте лимиты Workers в панели управления Cloudflare и планируйте масштабирование.
Устанавливайте корректные заголовки: Cache‑Control: public, max-age=31536000, Content‑Type соответствует MIME‑типу, ETag генерируется по версии ресурса.
Внедряйте CSP через Content-Security-Policy header, явно разрешая script-src 'self' 'unsafe-eval' только для нужных ресурсов, и тестируйте в браузере с DevTools.

Вопросы и ответы

Как быстро проверить, что Cloudflare Workers корректно кэшируют статические файлы?

Откройте панель Cloudflare, перейдите в Analytics → Workers → Cache. Отправьте запрос curl –I и посмотрите заголовок X-Cache; значение HIT подтверждает кэширование. Также проверьте Cache‑Control и CF‑Cache‑Status.

Нужен ли отдельный Worker для каждой группы статических ресурсов?

Один Worker обычно справляется с несколькими группами, если правила кэширования схожи. Разделение полезно, если разные TTL, заголовки или CDN‑правила, но это не обязательное требование.

Как задать TTL для статических файлов в Cloudflare Workers?

В ответе добавьте заголовок Cache‑Control: public, max‑age=86400. TTL задаётся в секундах и может быть изменён динамически в коде, но лучше определить его в настройках страницы.

Что делать, если статические файлы обновляются чаще, чем TTL?

Установите Cache‑Control: no‑cache или max‑age=0, а в Worker добавьте заголовок CF‑Cache‑Status: MISS при каждом обновлении. При необходимости очистите кэш через API Cloudflare.

Как уменьшить размер статических ресурсов перед отправкой через Worker?

Внутри Worker можно применять gzip или Brotli. Добавьте заголовок Content‑Encoding: br и используйте сжатие, если сервер не делает это. Это обычно снижает размер на 50–70 %.

Можно ли использовать Workers для динамической генерации минифицированных CSS/JS?

Да, Worker может читать исходники, минифицировать и отдавать. Однако это увеличит время выполнения; лучше пред‑минифицировать и хранить готовые файлы в кэше.

Как проверить, что Worker не блокирует запросы к CDN?

Откройте DevTools Network, посмотрите заголовок CF‑Cache‑Status. Если Worker возвращает 200 без ошибок, запросы проходят. Убедитесь, что в коде не используется fetch к тому же домену без разрешения.

Нужно ли обновлять Worker после изменения правил кэширования?

Да, любой изменённый код или заголовки требуют redeploy. После публикации Worker обновится мгновенно, но кэшированные объекты могут сохраняться до истечения TTL.

Как избежать избыточного кэширования изображений, которые меняются часто?

Установите Cache‑Control: no‑store или max‑age=0 для таких файлов. В Worker можно добавить условие по расширению (.png, .jpg) и менять заголовок.

Какие метрики стоит отслеживать, чтобы оценить эффективность Workers?

Следите за процентом HIT/MISS в Cloudflare Analytics, временем ответа (RTT), размером передаваемых данных и количеством запросов к Workers. Это даст представление о влиянии кэширования.

Важно

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

Редакционная проверка

Материал подготовлен и проверен редакцией AX.SEO

Проверено

Автор Редакция AX.SEO

Digital-редактор • 7 лет опыта

Редакция AX.SEO готовит материалы о SEO, разработке, AI, аналитике, маркетинге и росте digital-проектов.

✓

Проверил Александр SEO

SEO-специалист • 10 лет опыта

Проверяет практическую применимость рекомендаций, корректность терминов и соответствие материала digital-тематике.

AX.SEO объясняет digital простым языком: без магии, пустых обещаний и “секретных кнопок роста”.