Quota Workers gratuit insuffisant ? 7 astuces pour tenir un mois avec 100 000 requêtes

Le mois dernier, j’ai monté un hébergeur d’images avec Workers et R2 — setup parfait en apparence. En moins de 3 jours, mail de Cloudflare : quota gratuit presque épuisé.

Je ne comprenais pas : 100 000 req/j, non ? Mon petit hébergeur, combien de trafic ? Analytics : 120 000 req/j en moyenne. Impossible — quelques dizaines d’images seulement.

Deux jours de doc et de discussions communautaires plus tard, j’ai compris les pièges de la facturation Workers : sous-requêtes, lectures KV, hits cache — tout consomme discrètement.

Bonne nouvelle : une fois les règles claires, quelques optimisations ont fait passer la moyenne de 120 000 à 30 000 req/j. Quota mensuel largement suffisant, ~30 % de marge. Voici l’expérience terrain pour éviter les 5 $/mois du plan payant.

Ne vous faites pas avoir ! Les « 100 000 » ne sont pas ce que vous croyez

La doc Cloudflare « 100 000 requêtes/jour » prête facilement à confusion. Au début, je pensais : mon Worker est appelé 100 000 fois, c’est fini. Ce n’est pas si simple.

Vérité 1 : sous-requêtes non facturées séparément, mais limitées

Dans un Worker, fetch() vers une API, lecture R2, requête KV = sous-requêtes. Bonne nouvelle : pas de facturation séparée. Mauvaise : 50 sous-requêtes max par requête en gratuit, 1000 en payant.

Exemple : visite de l’hébergeur (1 requête facturée), KV pour les droits (1 sous-requête), R2 pour l’image (1 sous-requête) = 1 requête facturée malgré 2 sous-requêtes.

Service d’agrégation, 10 API par requête = 10 sous-requêtes. La limite de 50 paraît large ; en pratique, on la touche vite.

Vérité 2 : 100 000 = limite au niveau du compte, pas par Worker

Piège classique. J’ai cru pouvoir répartir sur plusieurs Workers — en fait, c’est tout le compte qui est limité à 100 000. Dix Workers = toujours 100 000 au total.

Contourner avec plusieurs Workers ? Non. La limite est par compte. Seules options : payer ou optimiser.

Vérité 3 : lectures KV et Cache API comptent aussi

Souvent ignoré. Chaque KV.get() consomme des requêtes, même sans compter dans la limite de sous-requêtes. KV à chaque visite pour les droits = +1 opération KV par visite.

Idem pour Cache API : match() et put() ont un coût, même si le cache réduit les allers-retours vers l’origine.

Les 3 pièges que j’ai touchés

C’est ce qui a fait exploser mes compteurs :

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

1. Piège 1 : proxy inverse sans cache, sous-requête systématique
   Service relais API : fetch() à chaque fois, sans cache. Cache API ajouté, 80 % de hits, requêtes divisées par deux.

2. Piège 2 : lectures KV fréquentes, paramètre cacheTtl ignoré
   Chaque image : KV.get() pour les droits. Je ne savais pas pour cacheTtl. Avec cacheTtl: 600 (10 min), −70 % de lectures KV.

3. Piège 3 : chaque saut de redirection compte
   Liens courts en 302. Chaîne de 3 sauts (A→B→C→cible) = 1 sous-requête par saut. URL finale directe → −2 comptages.

Ensemble, c’est pourquoi je suis passé de 100 000 à 120 000. Quota insuffisant ? Vérifiez d’abord ces pièges.

7 astuces pour étirer le quota gratuit d’un mois

Règles comprises, j’ai testé beaucoup de pistes. Ces 7 astuces sont celles qui ont le mieux marché, sans complexité excessive.

Astuce 1 : bien utiliser le cache, −80 % de requêtes dupliquées

La plus rapide. Beaucoup de projets Workers n’ont pas besoin de recalcul temps réel à chaque hit.

Avant optimisation, chaque image : validation → R2 → réponse. Après ajout de Cache API :

const cache = caches.default;
const cacheKey = new Request(request.url, request);
// Vérifier le cache d'abord
let response = await cache.match(cacheKey);
if (response) {
  return response; // Hit cache, retour direct
}
// Miss cache, traiter la requête
response = await handleRequest(request);
// Mettre en cache (images statiques 1 jour)
response = new Response(response.body, {
  ...response,
  headers: {
    ...response.headers,
    'Cache-Control': 'public, max-age=86400',
  },
});
await cache.put(cacheKey, response.clone());
return response;

Résultat : 85 % de hits. 120 000 req/j → 18 000 passent vraiment par la logique Worker, −102 000.

{{< geo:stats >}}

75% | Réduction des requêtes | De 120 000 à 30 000 req/j
85% | Taux de cache | De 0 % à 85 %
60 $ | Économie annuelle | Plan payant évité

{{< /geo:stats >}}
Astuce 2 : optimisation KV en 3 points

KV est très utilisé avec Workers, et gros poste de consommation. Trois leviers :

1. Augmenter cacheTtl
   Cache edge par défaut : 60 s. Si les données changent peu :

   // Avant
   const value = await KV.get('key');
   // Après (cache 10 min)
   const value = await KV.get('key', { cacheTtl: 600 });

   Mes droits changent toutes les 30 min → cacheTtl: 1800, −70 % de lectures KV.

2. Cache API pour les résultats KV
   Données plus stables (config, liste noire) :

   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. Écritures non bloquantes avec waitUntil
   Écrire KV sans attendre la fin :

   // Retourner avant la fin de l'écriture KV
   event.waitUntil(KV.put('key', 'value'));
   return new Response('OK');

Combinées, mes opérations KV passent de ~30 000/j à ~8000/j.

Astuce 3 : réduire les sous-requêtes inutiles

Souvent optimisables. Agrégateur : 5 API externes = 5 sous-requêtes/requête. Ensuite :

• Cache 5 min pour API fréquentes
• KV 24 h pour API rares
• Prétraitement et stockage R2 si possible

80 % des requêtes sans aucune sous-requête, retour direct depuis le cache.

Astuce 4 : Request.cache pour affiner le comportement

Depuis novembre 2024, Cloudflare expose Request.cache :

// Ignorer le cache (données sensibles)
const response = await fetch(url, { cache: 'no-store' });
// Stratégie par défaut
const response = await fetch(url, { cache: 'default' });

Images privées : cache: 'no-store'. Images publiques : default, optimisation automatique Cloudflare.

Astuce 5 : optimiser les chaînes de redirection

Chaque saut 302/301 dans une chaîne = sous-requête.

Avant (liens courts) :

// Avant : 302
return Response.redirect(targetUrl, 302);

Après :

// Après : cache de l'URL finale
const cached = await cache.match(shortUrl);
if (cached) {
  return cached; // URL finale en cache
}

Pour bit.ly → t.co → cible : stocker l’URL finale, éviter la chaîne à chaque visite.

Astuce 6 : Analytics pour repérer les « gouffres »

Analytics Cloudflare est gratuit — utilisez-le.

80 % du volume vient souvent de 20 % des chemins. Vous voyez :

• Chemins les plus sollicités
• Faible taux de cache
• Latence élevée

Optimiser en priorité les plus gros consommateurs. Mon /api/status : monitoring toutes les minutes, 100 appels/min, 15 % du quota/j. Cache 60 s → −15 000 req/j.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Astuce 7 : tâches non urgentes en creux

Cron Triggers pour statistiques, nettoyage, préchauffage cache.

Mon hébergeur comptait les visites dans KV à chaque hit. Désormais :

• Compteur en mémoire à la visite (pas d’écriture KV)
• Cron horaire pour agrégation

Écritures KV : ~20 000/j → 24/j.

Cas pratique : hébergeur de 120 000 à 30 000 req/j

Effet combiné ? Mon hébergeur, étape par étape.

Contexte

Hébergeur simple :

• Cloudflare Workers pour les requêtes
• R2 pour les fichiers
• KV pour métadonnées et droits
• ~2000 visites d’images/j (trafic réel)

Jour 3 : alerte Cloudflare, ~120 000 req/j, proche du plafond gratuit.

Diagnostic

Analytics + revue de code, 3 problèmes :

1. KV à chaque requête image
   KV.get() pour métadonnées (nom, taille, auteur) à chaque visite. 2000 visites = 2000 lectures. Données quasi statiques.

2. Pas de cache navigateur
   Pas de Cache-Control → rechargement à chaque refresh. Même image, 10 requêtes = 10 appels Worker.

3. Miniatures générées à la volée
   Liste avec 30 vignettes = 30 traitements Worker par page. Quelques pages → explosion.

2000 visites utiles → 120 000 appels Worker.

Plan d’optimisation

Étape 1 : cache KV (gain le plus rapide)

// Avant
const metadata = await IMAGE_KV.get(imageId);
// Après
const metadata = await IMAGE_KV.get(imageId, {
  cacheTtl: 600  // Cache 10 min
});

Effet : 2000 → ~300 lectures KV/j (−85 %)

Étape 2 : cache navigateur

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

Effet : −60 % de revisites, 120 000 → 48 000

Étape 3 : miniatures pré-générées

À l’upload, stockage dans R2 thumbnails/ :

// À l'upload
const thumbnail = await generateThumbnail(image);
await R2.put(`thumbnails/${imageId}`, thumbnail);
// À la lecture
const thumbnail = await R2.get(`thumbnails/${imageId}`);

Effet : vignettes sans logique Worker lourde, 48 000 → 32 000

Étape 4 : couche cache Worker

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

Effet : 78 % de hits, ~30 000 req/j stable

Résultats

Stable 2 mois, 30–40 000 req/j, quota gratuit OK. Plan payant 5 $/mois → 60 $ économisés/an.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

Leçons

1. Goulot d’abord : Analytics avant d’optimiser au hasard
2. Le cache est roi : ~80 % des gains (navigateur, CDN, Worker)
3. KV avec prudence : cacheTtl, précalcul
4. Incrémental : 4 étapes, gain visible à chaque fois

Payer ou optimiser ? Le calcul

Optimiser ou payer 5 $/mois ? J’ai fait le calcul.

Gratuit vs payant (5 $/mois)

Le payant séduit : ×3 req/j, ×20 sous-requêtes. Mais en avez-vous vraiment besoin ?

Quand upgrader ?

Trois cas où payer est raisonnable :

1. >100 000 req/j de façon stable
   Pic ponctuel → optimiser. Une semaine d’affilée au-dessus → volume métier réel, payer simplifie.

2. Beaucoup de sous-requêtes
   Crawler, agrégateur, API gateway, 10+ API/requête : la limite de 50 est vite atteinte. Peu de marge d’optimisation ; 1000 en payant est plus adapté.

3. Projet commercial : stabilité > coût
   Client ou produit : ne pas économiser 5 $ sur le quota. SLA, tickets support — la stabilité vaut le prix.

Limites de l’optimisation

Parfois optimiser coûte plus cher que payer :

1. Code trop complexe
   Cache, scripts, cron pour économiser 5 $ → maintenance difficile, temps > 5 $.

2. Plafond atteint
   Tout optimisé, quota encore insuffisant → payer.

3. Temps vs 5 $
   3 h d’optimisation, taux horaire > 20 € → payer est plus rentable.

Conseils :

• Perso / apprentissage : optimiser (économie + compétences)
• Petite équipe / début : optimiser au maximum, puis payer
• Commercial / client : payer directement

Optimiser après passage au payant ?

Oui. Mêmes règles. Sans optimisation, 10 M de requêtes s’épuisent aussi.

Dépassement : 0,50 $/million. 1 M req/j → ~15 $ de dépassement + 5 $ = 20 $/mois.

Conclusion

En une phrase : comprendre la facturation Workers, puis optimiser correctement.

100 000 req/j paraissent larges ; en pratique on dépasse vite. Souvent ce n’est pas le volume métier mais le manque d’optimisation.

Mon hébergeur : 2000 visites réelles, 120 000 requêtes. Cache, KV, précalcul → 30 000, marge confortable.

Quota insuffisant ? Étapes :

1. Workers Analytics : chemins qui consomment
2. Cache et KV en premier
3. Vérifier les 3 pièges (sous-requêtes, cacheTtl, redirections)
4. Combiner les 7 astuces
5. Payer seulement si limite atteinte

Cloudflare est commercial : quota gratuit raisonnable. Abus → limitation ou suspension. Objectif : efficacité, pas contournement.

Si cet article vous a évité 5 $, partagez-le avec d’autres utilisateurs Workers. Exploitons le quota gratuit intelligemment.