Résumé

  • Quand Workers Cache est activé, les réponses servies sans exécuter le code restent facturées comme des requêtes. La règle inclut des accès aux fichiers statiques normalement gratuits.
  • Le modèle officiel riche en calcul économise 11,20 dollars avec le cache. Appliquer les règles du cache au modèle surtout statique ajoute au contraire 1,50 dollar, avec des franchises mensuelles disponibles.

Un cache évite à un programme de refaire la même chose. Chez Cloudflare, l'activer peut aussi faire entrer des requêtes gratuites dans le périmètre payant. Le processeur travaille moins ; le nombre d'unités facturables peut augmenter.

La documentation de Workers Cache expose ce mécanisme sans détour. Un résultat trouvé dans le cache est renvoyé avant l'exécution du Worker. Le temps CPU de cette réponse disparaît de la facture. La requête, elle, reste comptée au tarif habituel. Et cette règle s'applique aussi à des requêtes normalement gratuites, notamment celles qui servent des fichiers statiques.

L'expression « sans tarification séparée » mérite donc une lecture très précise. Le cache n'ajoute pas une ligne tarifaire autonome. Il modifie ce qui entre dans une ligne existante.

Le modèle à 5 dollars devient un modèle à 6,50 dollars

Le tarif public Workers Paid Standard prévoit un minimum de 5 dollars par mois pour un compte, avec 10 millions de requêtes et 30 millions de millisecondes CPU incluses. Au-delà, le million de requêtes coûte 0,30 dollar et le million de millisecondes CPU 0,02 dollar.

Cloudflare propose un exemple de 15 millions de requêtes mensuelles. Douze millions servent des fichiers statiques ; les trois autres millions exécutent du code, à raison de 7 millisecondes CPU en moyenne. Les fichiers statiques sont gratuits. Les trois millions de requêtes dynamiques et leurs 21 millions de millisecondes CPU tiennent dans les franchises. Total présenté : 5 dollars.

Appliquons à ce même trafic la règle documentée de Workers Cache, en l'activant pour l'ensemble de ce Worker. Le calcul suppose un seul compte Standard, ses franchises entièrement disponibles et aucun autre produit ou ajustement. Les 15 millions de requêtes deviennent facturables. Cinq millions dépassent la franchise, soit 1,50 dollar.

Même sans aucune réponse dynamique trouvée en cache, le CPU reste à 21 millions de millisecondes, sous les 30 millions incluses. Le cache peut encore faire baisser ce travail, mais la ligne CPU est déjà à zéro. Le total devient 6,50 dollars.

Ce second montant est notre application des règles publiées au cas statique de Cloudflare. L'écart vient de l'entrée de requêtes dans le compteur payant. Aucune hausse du prix unitaire n'est nécessaire pour produire ces 1,50 dollar supplémentaires.

Quand le calcul coûte vraiment, le cache fait économiser

Un autre exemple officiel montre l'intérêt économique du service. Un Worker reçoit 100 millions de requêtes mensuelles, chacune consommant en moyenne 7 millisecondes CPU. Sans le cache, le modèle additionne 5 dollars d'abonnement, 27 dollars de requêtes et 13,40 dollars de CPU : 45,40 dollars.

Avec 80 % de réponses trouvées en cache, seuls 20 millions de passages exécutent le Worker. Le CPU tombe de 700 à 140 millions de millisecondes. Après franchise, sa facture passe à 2,20 dollars. Les requêtes coûtent toujours 27 dollars. Total : 34,20 dollars.

Le gain de 11,20 dollars représente environ un quart de la facture initiale, alors que 80 % des exécutions ont été évitées. L'abonnement et les requêtes gardent leur poids. Une amélioration spectaculaire du travail effectué ne se convertit pas au même pourcentage en économie monétaire.

Les deux calculs se rejoignent : la valeur du cache dépend de la part du coût qu'il supprime et de la part qu'il fait apparaître. Quand le CPU dépasse largement la franchise, l'économie se matérialise. Quand le CPU est déjà inclus et que beaucoup de requêtes étaient gratuites, un autre effet domine.

Le cache concerné a son propre périmètre

Workers Cache se place avant le code du Worker. Il appartient au Worker, suit ses points d'entrée et se pilote notamment par les en-têtes de réponse Cache-Control. Les règles de cache d'une zone Cloudflare ne configurent pas ce cache. La décision commerciale porte sur ce dispositif précis et sur le trafic qui y entre.

La documentation indique aussi que les appels entre Workers, habituellement exempts de frais de requête supplémentaires dans le modèle Standard ordinaire, sont inclus dans les requêtes facturées lorsque le Worker utilise ce cache. Il faut donc identifier les Workers auxquels on applique le dispositif, plutôt que multiplier un tarif par un simple compteur d'exécutions.

Le service rend bien un travail. Ses niveaux de cache peuvent éviter de réveiller le code pour servir la même réponse à plusieurs endroits. La fusion de demandes simultanées peut également réduire les exécutions. Cloudflare continue de livrer des réponses, et son tarif conserve la requête comme unité de vente.

Pour une facture réelle, il manque encore la composition du trafic, le CPU consommé, les franchises déjà utilisées par le compte et les conditions contractuelles. Ces variables permettent de refaire le calcul ; elles ne demandent pas de deviner une intention au fournisseur.

Un acheteur a intérêt à demander deux mesures : combien d'exécutions disparaissent, et combien de requêtes entrent dans la catégorie payante. La première valorise le travail évité. La seconde détermine une autre partie du prix.

Le cache peut laisser le processeur tranquille. Il faut encore regarder ce que compte le contrat.

Sources