Cloudflare Workers Cache 2026: Edge Caching Revolutie

Elke request die uw Workers-app raakt, voerde code uit - zelfs wanneer de response al uren niet was veranderd. Die serverless-taks is nu verleden tijd. Cloudflare's Workers Cache lancering op 6 juli 2026 draait de architectuur om: cache draait nu vóór uw Worker en serveert gecachte responses zonder een milliseconde CPU-tijd te verbranden.

De Architectuuromkering Die Alles Verandert

Traditionele edge caching behandelde Workers als middleware. Een request komt binnen, de Worker draait, en de Worker beslist of er uit cache of origin wordt opgehaald. Zelfs cache hits riepen nog steeds de Worker aan, wat CPU-facturering en extra latency betekende bij elke request.

Workers Cache draait die flow om. Een gelaagde caching-laag zit nu voor de Worker. Als er een gecachte response bestaat, serveert Cloudflare deze direct vanaf de edge en uw Worker draait nooit. Nul CPU-tijd gefactureerd.

Dit is belangrijk voor server-rendered apps. Frameworks zoals Astro, Next.js, Remix, SvelteKit en TanStack Start duwden Workers van "slimme proxy" naar "echte origin." De afweging was het betalen van een "serverless rendering penalty" bij elke request, zelfs wanneer duizenden gebruikers dezelfde pagina opvroegen.

Met Workers Cache wordt het render-on-demand, cache-at-edge patroon financieel realistisch voor high-traffic SSR.

Worker-Eigendom, Niet Zone-Eigendom

De verschuiving gaat niet alleen over snelheid - het gaat over eigendom. Dit is uw Worker's cache, niet de zone's cache. In plaats van jongleren met zone-level regels, schakelt u in met een simpele Wrangler config:

tomlCopy
[cache]
enabled = true

En dat is de hele schakelaar. Geen gespring meer tussen Cache Rules, Page Rules en bestandsextensie-lijsten in zone-instellingen. Cache-gedrag reist mee met de Worker waar deze ook wordt uitgerold: custom domains, workers.dev, service bindings, preview URLs, Workers for Platforms tenants en named WorkerEntrypoint classes.

Die enabled = true regel vertelt Cloudflare om cache te controleren voordat uw Worker wordt aangeroepen. Het daadwerkelijke caching-gedrag komt nog steeds neer op de HTTP headers die uw Worker teruggeeft. Zie het als deelnemen aan het systeem, en het vervolgens besturen met standaard cache-semantiek.

Cache config wordt portable en version-controlled direct naast uw app code, zoals beschreven in Cloudflare's configuratie docs.

Twee-Laags Regionale Architectuur

Cloudflare's globale netwerk beslaat 337 steden met 13.000+ interconnecties. Workers Cache gebruikt een twee-laags structuur over dat netwerk.

Een lagere cache zit dicht bij gebruikers. Als die mist, controleert de request een hogere aggregatie-cache voordat Cloudflare überhaupt overweegt uw Worker te draaien. Die bovenste laag bundelt cache fills over regio's, wat typisch veel betere hit ratios oplevert voor globaal gedistribueerde apps.

Zo ziet dat er in de praktijk uit: een gebruiker in São Paulo en een gebruiker in Singapore die dezelfde resource opvragen, triggeren niet beide Worker executions. De eerste request vult de bovenste laag, en latere requests uit andere regio's kunnen die geaggregeerde cache raken. U krijgt betere globale cache-efficiëntie zonder regionale infrastructuur te bouwen of multi-region invalidation te beheren.

Stale-While-Revalidate Werkt Eindelijk Goed

Een sterke SSR caching setup komt meestal neer op TTL plus background refresh:

textCopy
Cache-Control: public, max-age=300, stale-while-revalidate=3600

Die header vertelt Cloudflare om gecachte content 5 minuten te serveren, en daarna stale content tot een uur te blijven serveren terwijl een background refresh wordt gestart. Gebruikers blijven instant responses krijgen, en uw Worker draait typisch eens per refresh cycle, niet eens per gebruiker.

max-age=300 is het "verse" venster waar responses serveren zonder revalidatie. Na 5 minuten neemt stale-while-revalidate=3600 het over: Cloudflare geeft de stale response direct terug terwijl ook uw Worker op de achtergrond wordt aangeroepen om de cache te verversen.

Als SSR traag heeft gevoeld door cold-cache spikes, is dit patroon de oplossing. Cloudflare's aankondiging noemt het expliciet als manier om Worker invocations te verminderen terwijl content vers blijft.

Cache-Tag Invalidation voor Granulaire Controle

Alles purgen is de snelste manier om uw hit rate te vernietigen. Workers Cache ondersteunt tag-based invalidation:

javascriptCopy
export default {
  async fetch(request, env, ctx) {
    const response = await renderProductPage(request);
    return new Response(response.body, {
      headers: {
        'Cache-Control': 'public, max-age=3600',
        'Cache-Tag': 'product:123, category:electronics, homepage-featured'
      }
    });
  }
}

Wanneer product 123 verandert, purge alleen die tag:

javascriptCopy
await ctx.cache.purge({ tags: ['product:123'] });

Cache-Tag neemt komma-gescheiden waarden, dus één response kan tot meerdere invalidation groups behoren. Wanneer ctx.cache.purge draait met een tag, invalidateert Cloudflare elke gecachte response met die tag over het hele netwerk. Cloudflare zegt dat dit globaal binnen 150ms compleet is, gebaseerd op de instant purge aankondiging.

Voor e-commerce, CMSes en elke app met verbonden content kunnen wijzigingen exact invalideren wat moet veranderen, zonder hele cache-lagen te wissen.

Per-Entrypoint Caching voor Composable Architecturen

Workers Cache forceert geen alles-of-niets benadering. Config kan variëren tussen uw default export, named WorkerEntrypoint classes, service binding calls en ctx.exports loopback calls.

Een veelvoorkomend patroon is een gateway Worker die auth afhandelt (cache het niet) en routeert naar backend Workers die dure pagina's renderen (cache ze agressief). Elk stuk krijgt caching die past bij zijn rol zonder beveiliging of versheid te compromitteren. Als uw project er al uitziet als een microservice-stijl Worker setup, kunt u elk component onafhankelijk afstemmen.

Het Kostenmodel Vereist Zorgvuldige Analyse

Workers Cache verandert facturering op manieren die geld kunnen besparen of u kunnen verrassen. Cache hits tellen als standaard Workers requests ($0.30 per miljoen na 10M inbegrepen) maar factureren nul CPU-tijd.

Cloudflare's pricing documentatie geeft een concreet voorbeeld: een Worker die 100 miljoen requests per maand afhandelt met gemiddeld 7ms CPU per request daalt van $45.40/maand naar $34.20/maand met een 80% cache hit rate. Dat is ongeveer 25% totale factuurreductie en 84% lagere CPU overage kosten.

De besparingen komen van CPU-tijd, niet request aantallen. Als uw huidige setup static assets door Workers routeert "gratis," kan Workers Cache inschakelen kosten verhogen. Teams die hier groot winnen hebben meestal hoge hit rates en CPU-zware Workers. Als uw Worker licht is en uw hit rate laag, kan de wiskunde de andere kant opgaan. Modelleer uw eigen traffic voordat u breed uitrolt.

AI Inference aan de Edge Wordt Goedkoper

Voor AI workloads kan het cachen van tokens en embeddings GPU compute charges verminderen bij herhaalde queries. Als uw Worker een inference API aanroept, vermijdt het cachen van veelvoorkomende prompts redundante compute.

javascriptCopy
export default {
  async fetch(request, env, ctx) {
    const prompt = await request.text;
    const cacheKey = `inference:${hashPrompt(prompt)}`;

    const response = await generateResponse(prompt, env);

    return new Response(JSON.stringify(response), {
      headers: {
        'Cache-Control': 'public, max-age=86400',
        'Cache-Tag': `model:${env.MODEL_VERSION}`
      }
    });
  }
}

hashPrompt creëert een deterministische cache key van de input. Wanneer dezelfde prompt weer opduikt, kan Workers Cache het gecachte inference resultaat serveren zonder uw Worker of het downstream model aan te roepen. Entries taggen met de model versie geeft u een schone purge story wanneer u een nieuw model shipped. Edge AI endpoints kunnen herhaalde queries serveren op CDN snelheden zonder inference kosten.

Valkuilen om te Vermijden

De Vary header heeft ook echte discipline nodig. Elke unieke combinatie van varied headers creëert een aparte cache entry. Vary: Accept-Encoding is prima. Vary: Cookie blaast uw cache meestal op in per-user entries en verslaat het doel.

Ga niet uit van besparingen totdat u hit ratios hebt gecontroleerd in Workers Observability. Een 20% hit rate op een CPU-lichte Worker kan gemakkelijk meer kosten dan de oude setup. De functie is krachtig, maar het zal een verkeerde caching strategie niet vanzelf repareren.

Het Waard om te Volgen

• Smart Tiered Cache voor public cloud origins: Cloudflare lanceerde dit naast Workers Cache, wat wijst op een grotere edge-caching strategie verschuiving
• Meerkat global consensus systeem: Gebouwd op QuePaxa, dit wijst op diepere investering in distributed state aan de edge
• Framework adapter updates: Astro, Next.js en andere SSR frameworks zullen waarschijnlijk duidelijkere Workers Cache patronen shippen
• Workers Observability cache metrics: Dit is waar u op zult vertrouwen om hit rates en kostenimpact te valideren
• Cache object size limit wijzigingen: Huidige limits documentatie kan verschuiven naarmate gebruik groeit

Actie Ondernemen

Begin hier (uw eerste stap)
Voeg [cache]\nenabled = true toe aan uw wrangler.toml op een staging Worker en bekijk het Observability dashboard voor cache hit rates.

Snelle winsten (directe impact)

• Voeg Cache-Control: public, max-age=300, stale-while-revalidate=3600 headers toe aan uw zwaarste SSR routes
• Controleer responses op Set-Cookie headers die caching blokkeren

Diepgaand (voor wie meer wil)

• Modelleer huidige facturering tegen geprojecteerde hit rates met Cloudflare's pricing calculator
• Implementeer Cache-Tag invalidation voor CMS of productcatalogus updates

Nuttige Resources

• Workers Cache Configuration - Officiële setup gids voor Wrangler config en per-entrypoint instellingen
• Workers Cache API - Runtime API documentatie voor programmatische cache controle
• Workers Pricing - Huidig prijsmodel inclusief cache hit facturering
• Workers Limits - Platform beperkingen inclusief cache object groottes
• Instant Purge for All - Achtergrond over Cloudflare's sub-150ms globale purge infrastructuur

Wat Dit Voor U Betekent

Workers Cache is een van de grootste verschuivingen in Workers economie sinds de lancering. Bewegen van "cache na Worker" naar "cache voor Worker" verwijdert het kernkostenprobleem dat SSR duur maakte op schaal.

Als uw team server-rendered apps draait op Workers, is dit de functie die het platform kostenconcurrerend maakt met het klassieke CDN-plus-origin model, terwijl het simpele deploy verhaal en globale bereik behouden blijft dat teams naar Workers trok.

Het worker-owned model wijst ook naar waar edge computing naartoe gaat: portable, zelfstandige deployments die caching-gedrag met zich meedragen. Zone-level configuratie begint eruit te zien als legacy plumbing. Application-level controle is waar het naartoe gaat.