Workers-Free-Kontingent reicht nicht? 7 Tipps, damit 100.000 Anfragen einen Monat reichen

Letzten Monat habe ich mit Workers ein Bildhosting auf R2 gebaut – auf dem Papier perfekt. Nach nicht einmal drei Tagen kam die Mail von Cloudflare: Ihr Free-Kontingent ist fast aufgebraucht.

Ich war verwirrt: Täglich 100.000 Anfragen, oder? Mein kleines Host mit ein paar Dutzend Bildern – woher 120.000/Tag in Analytics? Zwei Tage Docs und Community später wurde klar: Subrequests, KV-Reads, Cache – alles frisst still Kontingent.

Die gute Nachricht: Mit ein paar Hebeln von 120.000 auf ~30.000/Tag. Monatlich reicht das Free-Tier mit ~30 % Reserve. Dieser Artikel fasst die Praxis zusammen – vielleicht sparen Sie die 5 $/Monat für den Paid-Plan.

Nicht täuschen lassen: „100.000“ bedeuten nicht, was man denkt

In der Doku klingt „100.000 Anfragen/Tag“ einfach: mein Worker wird 100.000-mal aufgerufen – fertig. So ist es nicht.

Wahrheit 1: Subrequests – nicht extra bezahlt, aber begrenzt

fetch() zu APIs, R2, KV = Subrequests. Sie kosten nicht separat, aber im Free-Tier max. 50 Subrequests pro Request (Paid: 1.000).

Beispiel Bildhosting: 1 abrechenbare Anfrage, KV-Rechtecheck (1 Subrequest), R2-Bild (1 Subrequest) = 2 Subrequests, 1 Abrechnung.

Aggregationsdienst mit 10 APIs pro Hit = 10 Subrequests – das Limit ist schneller erreicht als gedacht.

Wahrheit 2: 100.000 pro Account, nicht pro Worker

Mehrere Worker teilen sich ein Kontingent. Zehn Worker = weiterhin 100.000/Tag gesamt. Umgehung über viele Worker scheitert; Ausweg: optimieren oder Paid.

Wahrheit 3: KV und Cache API zählen mit

Jeder KV.get() verbraucht Anfragen (ohne Subrequest-Zähler, aber Kontingent). Rechteprüfung bei jedem Hit = +1 KV-Operation pro Besucher.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Cache match() / put() kosten ebenfalls – auch wenn sie Origin entlasten.

Die 3 Fallen, die mich auf 120.000 trieben

1. Reverse Proxy ohne Cache – API-Proxy, jedes Mal fetch() zur Origin. Cache API → 80 % Treffer, Anfragen halbiert.
2. KV ohne cacheTtl – pro Bild KV.get(). Mit cacheTtl: 600 (10 Min.) −70 % KV-Reads.
3. Redirect-Ketten – Shortlink mit 302, drei Hops (A→B→C→Ziel) = drei Subrequests. Finale URL direkt → zwei gespart.

Wer knapp am Limit ist: zuerst diese drei Punkte prüfen.

7 Optimierungstipps – Free-Kontingent länger nutzen

Nach dem Verständnis der Regeln haben sich diese sieben Hebel in der Praxis bewährt.

Tipp 1: Cache – bis zu 80 % weniger Duplikat-Anfragen

Viele Worker brauchen nicht bei jedem Request Live-Logik. Mein Bildhosting vorher: Prüfung → R2 → Antwort. Nachher mit Cache API:

const cache = caches.default;
const cacheKey = new Request(request.url, request);
// Zuerst Cache prüfen
let response = await cache.match(cacheKey);
if (response) {
  return response; // Cache-Treffer
}
// Miss: Request verarbeiten
response = await handleRequest(request);
// Cache setzen (statische Bilder 1 Tag)
response = new Response(response.body, {
  ...response,
  headers: {
    ...response.headers,
    'Cache-Control': 'public, max-age=86400',
  },
});
await cache.put(cacheKey, response.clone());
return response;

85 % Treffer: von 120.000/Tag nur noch 18.000 echte Worker-Pfade (−102.000).

Tipp 2: KV-Dreiklang

KV ist praktisch und teuer in Anfragen. Drei Hebel:

1. cacheTtl erhöhen – Standard 60 s am Edge:

   // Vorher
   const value = await KV.get('key');
   // Nachher (10 Min. Cache)
   const value = await KV.get('key', { cacheTtl: 600 });

   Rechte alle 30 Min. aktualisiert → cacheTtl: 1800, KV-Reads −70 %.

2. KV-Ergebnis in Cache API – für langsam ändernde Daten (Config, Blocklisten):

   const cacheKey = `kv-cache:${key}`;
   let cached = await caches.default.match(cacheKey);
   if (!cached) {
     const value = await KV.get(key);
     cached = new Response(value);
     await caches.default.put(cacheKey, cached.clone());
   }
   return cached.text();

3. waitUntil für Writes – Antwort nicht auf KV-Schreiben warten:

   event.waitUntil(KV.put('key', 'value'));
   return new Response('OK');

Kombiniert: KV-Operationen von ~30.000 auf ~8.000/Tag.

Tipp 3: Subrequests vermeiden

Aggregation mit 5 externen APIs = 5 Subrequests. Später: häufige APIs 5 Min. cachen, seltene 24 h in KV, Vorverarbeitung in R2. ~80 % der Requests ohne Subrequest.

Tipp 4: Request.cache nutzen

Seit November 2024 feiner steuerbar:

// Kein Cache (sensible Daten)
const response = await fetch(url, { cache: 'no-store' });
// Standard-Cache
const response = await fetch(url, { cache: 'default' });

Private Bilder: no-store. Öffentliche: default für CDN-Optimierung.

Tipp 5: Redirect-Ketten

Jeder Hop in einer 302-Kette = Subrequest.

Vorher:

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

return Response.redirect(targetUrl, 302);

Nachher: finale URL cachen, Ketten wie bit.ly → t.co vermeiden.

Tipp 6: Analytics – die „Fresser“ finden

Workers Analytics ist kostenlos. Oft 80 % der Anfragen von 20 % der Pfade. Bei mir: /api/status alle 60 s vom Monitor – 15 % des Tageslimits. 60-Sekunden-Cache → −15.000/Tag.

Tipp 7: Nicht-dringende Tasks zeitlich verschieben

Cron Triggers für Statistik, Aufräumen, Cache-Warmup. Statt pro Hit KV-Counter: Zähler im Speicher, stündlich per Cron bündeln – KV-Writes von 20.000 auf 24/Tag.

Praxis: Bildhosting 120.000 → 30.000 Anfragen/Tag

Hintergrund

• Workers für Logik, R2 für Dateien, KV für Metadaten/Rechte
• ~2.000 echte Bildaufrufe/Tag
• Tag 3: Warnung bei ~120.000 Anfragen/Tag

Diagnose

1. Jeder Bildhit → KV.get() (2.000 Reads für stabile Metadaten)
2. Kein Cache-Control → Browser fragt jedes Mal neu
3. Thumbnails live im Worker → 30 Bilder/Liste = 30 Verarbeitungen

2.000 echte Besuche → 120.000 Worker-Aufrufe.

Optimierung in 4 Schritten

Schritt 1: KV cacheTtl (schnellster Effekt)

const metadata = await IMAGE_KV.get(imageId, {
  cacheTtl: 600
});

KV-Reads: 2.000 → ~300/Tag (−85 %)

Schritt 2: Browser-Cache

return new Response(imageData, {
  headers: {
    'Content-Type': 'image/jpeg',
    'Cache-Control': 'public, max-age=86400',
    'CDN-Cache-Control': 'public, max-age=2592000'
  }
});

Wiederholte Besuche −60 % → ~48.000/Tag

Schritt 3: Thumbnails vorberechnen

const thumbnail = await generateThumbnail(image);
await R2.put(`thumbnails/${imageId}`, thumbnail);
// Abruf
const thumbnail = await R2.get(`thumbnails/${imageId}`);

→ ~32.000/Tag

Schritt 4: Worker-Cache-Layer

const cache = caches.default;
let response = await cache.match(request);
if (response) return response;
await cache.put(request, response.clone());
return response;

78 % Treffer, stabil ~30.000/Tag

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Ergebnis

Learnings

1. Engpass zuerst (Analytics), dann optimieren
2. Cache dominiert (Browser, CDN, Worker)
3. KV sparsam: cacheTtl, Vorberechnung
4. Inkrementell – jeder Schritt messbar

Paid oder optimieren?

Paid lohnt sich typischerweise wenn:

1. Stabil >100.000/Tag über eine Woche (Spitzen ≠ Dauerlast)
2. Viele Subrequests (Crawler, Gateway, 10+ APIs)
3. Kommerziell – SLA und Tickets > 5 $

Wann Optimierung Zeitverschwendung ist

• Cache-Spaghetti, Wartung teurer als 5 $
• Alles optimiert, reicht nicht → Paid
• 3 h Arbeit bei >20 €/h Stundensatz → oft Paid schneller

Empfehlung: privat/lernen optimieren; kommerziell eher Paid.

Nach Paid weiter optimieren?

Ja – 10 Mio./Monat sind auch endlich. Überlimit 0,50 $/Million; bei 1 Mio./Tag ≈20 $/Monat gesamt.

Fazit

Abrechnung verstehen, dann gezielt optimieren.

100.000/Tag wirken groß, gehen schnell auf – meist Ineffizienz, nicht zu viel echtes Traffic. Mein Host: 2.000 Besuche, 120.000 Anfragen → mit Cache und KV ~30.000.

Wenn Ihnen das Kontingent knapp wird:

1. Workers Analytics: welche Pfade?
2. Cache und KV zuerst
3. Drei Fallen (Subrequests, cacheTtl, Redirect-Ketten)
4. Sieben Tipps kombinieren
5. Erst dann Paid

Cloudflare ist ein Unternehmen – Free-Tier fair nutzen. Ziel: effizienter Ressourceneinsatz, nicht Regeln aushebeln.

Hat Ihnen der Artikel 5 $ gespart? Teilen Sie ihn gern mit anderen Workers-Nutzern.