Pourquoi le rendu PDF à l'edge compte au-delà de 10 000 factures/jour

Si vous générez quelques centaines de PDF par jour sur une seule Lambda backend ou un petit pod Kubernetes, l’architecture n’a pas vraiment d’importance. Tout fonctionne. Tout est assez rapide.

Les choses changent à l’échelle. Dès que vous émettez des dizaines de milliers de documents par jour, ce qui correspond vite à une plateforme e-commerce, un transporteur logistique, un service BNPL, un fournisseur de paie ou une plateforme de facturation avec un minimum de traction, trois chiffres commencent à faire mal :

1. Latence de démarrage à froid, parce que quelque chose est toujours froid quelque part.
2. Latence régionale, parce que vos clients ne sont pas à côté de votre origine.
3. Compute par rendu, parce que vous le payez des dizaines de milliers de fois par jour.

Cet article explique comment chacun de ces éléments change de forme au-delà d’environ 10 000 rendus/jour, et pourquoi les moteurs déployés à l’edge comme gPdf relèvent d’une autre catégorie de solution, plutôt que de “la même chose, juste plus rapide”.

1. La taxe de démarrage à froid augmente avec la concurrence

Les démarrages à froid ne sont pas seulement une gêne : ils dépendent directement de votre courbe de concurrence. Le scénario habituel :

• Vous provisionnez N=10 conteneurs chauds à partir du trafic moyen.
• Un pic de trafic 3× arrive : Black Friday, jour de paie, fin de trimestre.
• 20 nouveaux conteneurs démarrent à froid pour absorber le pic. Chacun prend 1,5 à 2,5 secondes pour amorcer Chromium, Prince ou votre runtime.
• Pendant ces 30 secondes, ces nouveaux conteneurs servent à p99 = 2 secondes, ce qui tire le p99 global vers le haut.
• Votre budget de timeout aval, probablement 5 à 10 s pour tout le pipeline de commande, est maintenant consommé par la génération de PDF.

C’est acceptable quand le trafic est plat. C’est brutal quand il est irrégulier, et le trafic PDF est toujours irrégulier : les factures partent aux limites des cycles de facturation, les étiquettes partent au moment de l’enlèvement transporteur, les relevés partent en fin de mois.

Alternative déployée à l’edge : un isolate Cloudflare Worker démarre à froid en 5-20 ms, pas en 1,5-2,5 secondes. Il n’y a pas de conteneur à lancer, pas de JVM/V8 à initialiser, pas de navigateur à amorcer : le module WASM se charge dans un processus déjà vivant. Le démarrage à froid cesse d’être un sujet autour duquel concevoir l’architecture.

Pour gPdf en particulier, le pire démarrage à froid observé dans nos benchmarks est d’environ 12 ms, et seulement sur la première requête vers un isolate fraîchement assigné. Les requêtes suivantes sur le même isolate évitent même ce coût.

2. La latence régionale est réelle, même pour les requêtes “rapides”

Un aller-retour de Sydney vers une origine us-east-1 prend 200 ms avant que votre code fasse quoi que ce soit. De São Paulo vers eu-west-1, environ 190 ms. De Mumbai vers US East, environ 220 ms.

C’est dans chaque direction. Une API PDF centralisée qui effectue un rendu serveur de 300 ms ressemble donc à ceci depuis Sydney :

client -> us-east  : 200 ms
us-east render     : 300 ms
us-east -> client  : 200 ms
total wall-clock   : 700 ms

Pour un flux interactif, par exemple “prévisualiser la facture avant l’envoi”, c’est pénible. Pour un job backend à gros volume, ce n’est pas forcément visible.

Alternative déployée à l’edge : Cloudflare fonctionne dans plus de 300 villes. Le colo le plus proche de votre client à Sydney est à environ 5 ms. Le même rendu devient :

client -> SYD colo : 5 ms
SYD render         : 4 ms
SYD -> client      : 5 ms
total wall-clock   : 14 ms

C’est une amélioration 50× pour les flux interactifs. Pour les jobs backend, l’effet est plus neutre, mais les prévisualisations PDF interactives deviennent naturelles au lieu de paraître instables.

Le bénéfice caché de second ordre : si votre API PDF tourne à l’edge, vous pouvez y déplacer aussi la logique adjacente : prévisualisation PDF au checkout, rate-limit, vérification d’authentification. Chaque morceau déplacé à l’edge retire un aller-retour du chemin critique.

3. Le compute par rendu est la facture qui s’accumule en silence

Calcul Lambda à 100 000 rendus/jour :

• Puppeteer à environ 600 ms wall-clock et 1024 MB de mémoire : environ 240 USD/mois rien que pour le compute, avant l’egress.
• DocRaptor au palier 89 USD/100 000 pages : environ 2 670 USD/mois à 100 000/jour, soit 3 millions/mois.
• gPdf au palier 5 USD/100 000 pages : environ 150 USD/mois à 100 000/jour. Ou environ 5 USD/mois si vous tombez exactement à 100 000/mois.

L’écart de coût ne disparaît pas avec l’échelle : il s’élargit. À 1 million de rendus/jour :

• Puppeteer infra : environ 2 400 USD/mois + exploitation + astreinte
• DocRaptor : environ 26 700 USD/mois
• gPdf : 1 500 USD/mois à plat, soit 5× le palier de 100 000/jour, en supposant une négociation de volume sur la grille publique

Réaction fréquente : “Les économies sont sûrement plus faibles en pratique ; il doit y avoir quelque chose de caché.” Dans notre expérience, non. Le principal facteur de coût de la génération PDF est l’empreinte compute du moteur. Quand vous remplacez un processus Chromium de 600 MB par un module WASM de 4 MB, le coût par rendu baisse d’environ 100×, et votre facture suit.

La raison pour laquelle cela fonctionne sans nous mettre en difficulté : le prix sous-jacent de Cloudflare Workers Bundled est d’environ 0,50 USD par million de requêtes. Avec notre moteur qui utilise environ 1,5 ms de CPU par appel, le coût de revient par rendu est réellement inférieur au centime. Nous ajoutons une marge modérée pour bâtir une activité durable, et vous voyez encore l’écart de 18×.

Ce que “déployé à l’edge” vous apporte vraiment

Trois choses, aucune ne relevant d’une slide marketing.

Une latence prévisible sous n’importe quelle charge

Comme il n’y a pas de coût de boot par requête, p50 et p99 restent proches. Nous observons généralement un p99 dans un facteur 3× du p50 même au plus fort d’un pic, là où Puppeteer peut atteindre 10× le p50 pendant les tempêtes de démarrages à froid.

Un artefact unique, déployable partout

Un module .wasm se déploie à l’identique dans chaque colo Cloudflare. Il n’y a plus de question “le pool de Sydney est-il chaud ?” : chaque isolate démarre le module en quelques millisecondes et sert de façon identique. C’est réellement plus simple à exploiter que des réservations régionales de concurrence Lambda.

Une voie vers l’embarqué

Si vous voulez un jour exécuter gPdf dans le périmètre d’un client, son VPC, son cluster isolé ou son intranet coupé du réseau, le même module WASM fonctionne. C’est la différence entre “nous hébergeons un SaaS” et “nous livrons une technologie qui tourne partout”.

Où ce modèle atteint ses limites

L’edge n’est pas une magie gratuite. Certains workloads restent mieux servis par du centralisé :

• Rendus de plusieurs secondes. Si un seul PDF prend 30 secondes, par exemple d’énormes états financiers ou des rapports scientifiques, un conteneur longue durée avec état persistant conviendra mieux que la lutte contre les limites CPU à l’edge.
• Rendus qui ont besoin d’autres bases de données. Si votre rendu doit faire un JOIN sur trois tables OLAP, placez le moteur près de la base, pas à l’edge. Solution : faites le JOIN, puis envoyez le JSON à l’edge pour le rendu final.
• Sorties qui demandent du post-traitement. Watermarking, signature, archivage : si votre pipeline après rendu est multi-étapes et avec état, la propriété “sans état” du rendu à l’edge devient une taxe plutôt qu’un avantage.

Pour tout le reste, c’est-à-dire la vaste majorité du trafic B2B de factures, d’étiquettes et de reçus, l’edge gagne sur les axes qui comptent.

Quand arrêter de tolérer votre configuration actuelle

Checklist simple. Si vous cochez trois de ces points, le calcul de migration a basculé :

• Votre coût mensuel d’infrastructure PDF dépasse 300 USD.
• Votre latence p99 PDF dépasse 800 ms en trafic normal.
• Vous avez connu un incident de démarrage à froid qui a touché des clients.
• Vous avez passé plus de 4 heures à déboguer des glyphes CJK / RTL / emoji manquants.
• Vous générez des PDF dans un flux interactif : prévisualisation, téléchargement à l’écran.
• Vous opérez dans plus d’une région géographique.

Les trois premiers points réunis signifient que vous payez et que vous souffrez. Les trois suivants signifient qu’un moteur centralisé limite activement des décisions produit que vous pourriez autrement prendre.

Si cela vous semble familier, le Playground rend un exemple de facture dans votre navigateur en moins de 5 ms. Laissez-le parler pour lui-même.