Der Versandlabel-Workload in einem Absatz
Jede Bestellung erzeugt ein PDF, jedes PDF wird genau einmal auf einem Thermodrucker gedruckt, und der Ausfallmodus bei langsamer Generierung ist nicht “die Seite lädt langsam”, sondern “die Abholung im Lager steht hinter Ihrer Label-Rendering-API an”. Versand ist ein Workload, bei dem p99-Latenz die Produktmetrik ist, deterministische Ausgabe zählt, weil Nachdrucke alltäglich sind, und Barcode-Qualität - gemessen an GS1-Toleranzen für die X-dimension statt an Pixeln - darüber entscheidet, ob Scanner das Label im ersten Durchlauf lesen.
PDF-Stacks auf Basis von Headless Browsern haben mit allen drei Punkten gleichzeitig zu kämpfen: Kaltstartkosten häufen sich bei Lastspitzen, Raster-Barcodes verlieren auf kleinen Thermolabeln an Qualität, und Font-Rasterisierung driftet zwischen Chromium-Versionen. Ein “byte-identischer Nachdruck” ist damit praktisch nicht erreichbar.
Warum gPdf passt
Ein 4x6-Thermolabel ist klein (576 x 864 Pixel bei 203 dpi), hat wenige Elemente (Textblöcke plus 1 bis 2 Barcodes und optional ein Carrier-Logo) und entsteht in hohem Volumen. Ein mittelgroßer 3PL rendert etwa 50.000 bis 500.000 Labels pro Tag. Genau für diese Last ist gPdf gebaut. Der Renderer:
- Kompiliert das Layout einmal - Seitenkoordinaten, Font-Kaskaden und Barcode-Geometrie werden zur Anfragezeit aufgelöst, nicht über eine Browser-Layout-Engine.
- Vektorisiert jeden Barcode - Module werden direkt in den PDF-Stream gezeichnet, sodass ein 30 mm breiter GS1-128 bei 203 dpi oder 600 dpi sauber lesbar bleibt, ohne dass Sie eigene DPI-bewusste Rasterlogik schreiben müssen.
- Bettet NotoSans CJK und Latin ein - dieselben Anfragedaten rendern einen chinesischen Carrier-Namen korrekt, ohne dass Sie Fonts auf einem Render-Container bereitstellen.
p99 bleibt in unserer Referenzlast konstant bei 8 ms (1.000 Aufrufe des obigen Beispiels in EU-WEST), unabhängig davon, ob ein einzelnes Isolate ein Label oder 10.000 Labels gerendert hat.
Volumen- und Kostenrechnung
Ein typischer mittelgroßer 3PL liegt bei etwa 50.000 Labels/Tag, also rund 1,5 Mio. Labels/Monat. Im Basic-Plan (5 USD/Monat für 100.000 Seiten, 0,00005 USD pro zusätzlicher Seite) ergibt das:
1,5 Mio. Seiten x 0,00005 USD = 75,00 USD Mehrverbrauch
+ Basic-Plan Grundpreis = 5,00 USD
──────────────────────────────────────────────
Summe = 80,00 USD/Monat
Derselbe Workload mit Puppeteer auf Lambda liegt bei typischen Lambda-Concurrency-Einstellungen im Bereich von 200 bis 400 USD/Monat, noch bevor Kaltstartkosten während Lastspitzen berücksichtigt werden.
Black Friday: ein durchgerechnetes Beispiel
Lastspitzen sind der Workload, bei dem Edge-Rendering seinen Wert am deutlichsten zeigt. Ein Retail-Kunde mit 200 % des normalen Label-Volumens in der ersten Stunde des Black Friday - zum Beispiel 100.000 Labels in 60 Minuten, durchschnittlich 1.700 Labels/Minute mit Burst-Spitzen von 5.000 Labels/Minute - bleibt innerhalb eines einzigen Cloudflare-Workers-Region-Pools, ohne Kaltstartaufschlag. Derselbe Workload auf einem Puppeteer-Warm-Pool, der auf Durchschnittsverkehr dimensioniert ist, erzeugt bei den zusätzlich gestarteten Burst-Containern Kaltstarts von 1,5 bis 2,5 s. Diese Verzögerung spürt der Abholplatz im Lager bei jedem einzelnen Label.
Wo Sie weiterlesen sollten
- Die JSON Render API beschreibt jedes Feld, das im Label-Beispiel oben verwendet wird.
- Für die technische Tiefe zur Barcode-Geometrie lesen Sie den Beitrag zur GS1-128-Genauigkeit.
- Ersetzen Sie eine iText-Label-Pipeline? Lesen Sie gPdf vs iText für Logistik-Labels oder die vollständige TCO-Analyse für Versandlabel von 100.000 bis 100 Mio. Seiten/Monat.
- Für den Vergleich mit einem Chromium-basierten Stack lesen Sie gPdf vs Puppeteer.