La charge étiquette d’expédition, en un paragraphe
Chaque commande produit un PDF, chaque PDF est imprimé une fois sur une imprimante thermique, et le mode de panne si vous êtes lent n’est pas “la page charge lentement” : c’est “l’enlèvement entrepôt attend derrière votre API de rendu d’étiquettes”. L’expédition est un cas où la latence p99 est la métrique produit, où le rendu déterministe compte parce que les réimpressions sont courantes, et où la qualité des codes-barres, mesurée en tolérances GS1 de X-dimension plutôt qu’en pixels, décide si vos scanners lisent l’étiquette au premier passage.
Les piles PDF basées sur un navigateur headless peinent à tenir ces trois contraintes en même temps : le coût des démarrages à froid s’accumule pendant les pics, les codes-barres raster se dégradent sur les petites étiquettes thermiques, et la rasterisation des polices dérive entre versions de Chromium. Une réimpression identique octet pour octet devient donc impossible.
Pourquoi gPdf convient
Une étiquette thermique 4×6 est petite (576 × 864 pixels à 203 dpi), avec peu d’éléments (blocs de texte, 1 à 2 codes-barres et éventuellement un logo transporteur), et à fort volume (un 3PL de taille moyenne génère 50 000 à 500 000 étiquettes par jour). C’est la charge pour laquelle gPdf est conçu. Le moteur :
- Compile la mise en page une seule fois : coordonnées de page, cascades de polices et géométrie des codes-barres sont résolues à la requête, sans moteur de mise en page navigateur.
- Vectorise chaque code-barres : les modules sont dessinés directement dans le flux PDF, pour qu’un GS1-128 de 30 mm de large reste lisible à 203 dpi ou 600 dpi sans logique de rasterisation dépendante du DPI côté client.
- Intègre NotoSans CJK + Latin : le même corps de requête rend correctement un nom de transporteur chinois sans que vous provisionniez des polices dans un conteneur de rendu.
Le p99 reste stable à 8 ms sur notre charge de référence (1 000 invocations de l’exemple ci-dessus en EU-WEST), qu’un même isolate ait rendu une étiquette ou 10 000.
Volume et calcul de coût
Un 3PL de taille moyenne fonctionne souvent autour de 50 000 étiquettes/jour, soit environ 1,5 million par mois. Sur le plan Basic (5 USD/mois pour 100 000 pages, puis 0,00005 USD par page supplémentaire), cela donne :
1,5 million de pages × 0,00005 USD = 75,00 USD de dépassement
+ base du plan Basic = 5,00 USD
────────────────────────────────────────────────────
total = 80,00 USD / mois
La même charge sur Puppeteer-on-Lambda se situe dans la fourchette 200 à 400 USD/mois avec des réglages Lambda de concurrence typiques, avant même d’intégrer le coût des démarrages à froid pendant les pics.
Black Friday : exemple chiffré
Le pic est le scénario où le rendu à l’edge montre le plus clairement son intérêt. Un client de distribution qui atteint 200 % du volume normal d’étiquettes pendant la première heure du Black Friday, par exemple 100 000 étiquettes en 60 minutes, soit 1 700 étiquettes/minute en moyenne avec des rafales à 5 000/minute, termine dans un seul pool régional Cloudflare Workers, sans coût de démarrage à froid. La même charge sur un pool Puppeteer dimensionné pour le trafic moyen produit des démarrages à froid de 1,5 à 2,5 s sur les conteneurs créés pendant la rafale, et le comptoir d’enlèvement de l’entrepôt les ressent tous.
Où aller ensuite
- La JSON Render API couvre chaque champ utilisé dans l’exemple d’étiquette ci-dessus.
- Pour le détail sur la géométrie des codes-barres, lisez l’article sur la précision GS1-128.
- Vous remplacez un pipeline d’étiquettes iText ? Consultez gPdf vs iText pour les étiquettes logistiques, ou la décomposition complète du TCO des étiquettes d’expédition de 100 000 à 100 millions de pages/mois.
- Pour comparer avec une pile basée sur Chromium, consultez gPdf vs Puppeteer.