Als u een paar honderd PDF’s per dag rendert op één backend-Lambda of een kleine Kubernetes-pod, doet de architectuur er niet echt toe. Alles werkt. Alles is snel genoeg.

Dat verandert op schaal. Zodra u tienduizenden documenten per dag uitgeeft, wat grofweg geldt voor elk e-commerceplatform, elke logistieke vervoerder, BNPL-service, payrollprovider of facturatieplatform met ook maar redelijke tractie, beginnen drie cijfers pijn te doen:

Cold-startlatency, omdat er altijd ergens iets koud is.
Regionale latency, omdat uw klanten niet naast uw origin zitten.
Compute per render, omdat u die tienduizenden keren per dag betaalt.

Deze post loopt door hoe elk van deze factoren van vorm verandert voorbij ongeveer 10.000 renders per dag, en waarom render-engines op de edge zoals gPdf in feite een andere oplossingscategorie zijn dan “hetzelfde, maar sneller”.

1. De cold-startbelasting stapelt met concurrency

Cold starts zijn niet alleen irritant; ze zijn een functie van uw concurrencycurve. Meestal ziet het patroon er zo uit:

U provisiont N=10 warme containers op basis van gemiddeld verkeer.
Een verkeerspiek van 3× raakt het systeem (Black Friday, payroll day, kwartaalafsluiting).
20 nieuwe containers cold-starten om de piek op te vangen. Elk heeft 1,5 tot 2,5 seconden nodig om Chromium / Prince / uw runtime te starten.
Gedurende die 30 seconden draaien die nieuwe containers op p99 = 2 seconden en trekken ze de globale p99 mee omhoog.
Uw downstream time-outbudget, waarschijnlijk 5-10s voor de hele orderpijplijn, wordt nu opgegeten door PDF-generatie.

Dit is prima wanneer uw verkeer vlak is. Het is hard wanneer verkeer piekt, en PDF-verkeer is vrijwel altijd piekachtig: facturen vuren rond facturatiecycli, verzendlabels wanneer vervoerders ophalen, overzichten aan het einde van de maand.

Alternatief op de edge: een Cloudflare Worker isolate cold-start in 5-20 ms, niet in 1,5-2,5 seconden. Er is geen container om te starten, geen JVM/V8 om te initialiseren, geen browser om te bootstrappen; de WASM-module laadt in een proces dat al leeft. Cold start houdt op iets te zijn waarvoor u de architectuur moet ontwerpen.

Voor gPdf specifiek is de slechtste cold start die we in benchmarks hebben gezien ongeveer 12 ms, en dat is alleen de eerste request naar een nieuw toegewezen isolate. Latere requests op dezelfde isolate slaan zelfs dat over.

2. Regionale latency is echt, zelfs bij “snelle” requests

Een roundtrip van Sydney naar een us-east-1 origin is 200 ms voordat uw code iets doet. Van São Paulo naar eu-west-1 is dat ongeveer 190 ms. Van Mumbai naar US East ongeveer 220 ms.

Dat geldt in elke richting. Een gecentraliseerde PDF-API die server-side 300 ms rendert, ziet er vanuit een klant in Sydney zo uit:

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

Voor een interactieve flow, bijvoorbeeld “toon mijn factuur voordat ik die verstuur”, is dat pijnlijk. Voor een hoogvolume backendtaak valt het minder op.

Alternatief op de edge: Cloudflare draait in meer dan 300 steden. De dichtstbijzijnde colo bij uw klant in Sydney is grofweg 5 ms verwijderd. Dezelfde render wordt:

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

Dat is een 50× verbetering voor interactieve flows. Voor backendtaken is het vaak een wash, maar interactieve PDF-previews (“laat zien hoe dit eruitziet voordat ik het verstuur”) worden gratis in plaats van haperend.

Het verborgen tweede-orde voordeel: als uw PDF-API op de edge draait, kunt u aangrenzende logica daar ook plaatsen: uw checkout-PDF-preview, uw rate limit, uw auth-check. Elk onderdeel dat u naar de edge schuift, haalt een roundtrip uit uw hete pad.

3. Compute per render is de rekening die stilletjes stapelt

Lambda-prijsrekenwerk bij 100.000 renders per dag:

Puppeteer op ongeveer 600 ms wall time, 1024 MB geheugen: ongeveer $240/maand alleen voor compute, vóór egress.
DocRaptor op het $89/100K-paginatarief: ongeveer$ 2.670/maand bij 100.000/dag (= 3 mln./maand).
gPdf op het $5/100K-paginatarief: ongeveer$ 150/maand bij 100.000/dag. Of ongeveer $5/maand als u precies op 100.000/maand uitkomt.

Het kostengat verdwijnt niet naarmate u schaalt; het wordt groter. Bij 1 mln. renders per dag:

Puppeteer-infra: ongeveer $2.400/maand + operations + on-call
DocRaptor: ongeveer $26.700/maand
gPdf: $1.500/maand flat (5× van het 100K/dag-volume, aangenomen dat u volume afspreekt op het publieke prijsraster)

Een veelvoorkomende reactie: “De besparing zal in de praktijk wel kleiner zijn; er moet iets verborgen zijn.” In onze ervaring niet. De kostenfactor in PDF-generatie is de compute-footprint van de render-engine. Zodra u een Chromium-proces van 600 MB vervangt door een WASM-module van 4 MB, daalt de kostprijs per render grofweg 100×, en uw factuur volgt.

Waarom dit werkt zonder dat wij verlies draaien: de onderliggende Cloudflare Workers Bundled-prijs is ongeveer $0,50 per miljoen requests. Met onze render-engine op ongeveer 1,5 ms CPU per call ligt de cost of goods sold per render werkelijk onder een cent. We zetten daar een bescheiden marge bovenop om een duurzaam bedrijf te bouwen, en u ziet nog steeds het gat van 18×.

Wat “edge-deployed” echt oplevert

Drie dingen, geen daarvan gaat over marketing-slides:

Voorspelbare latency onder elke load

Omdat er geen bootkosten per request zijn, blijven p50 en p99 dicht bij elkaar. We zien p99 meestal binnen 3× van p50, zelfs op het hoogtepunt van een verkeerspiek. Bij Puppeteer kan p99 tijdens cold-startstormen naar 10× p50 schieten.

Eén deploybaar artifact, overal

Een .wasm-module deployt identiek naar elke Cloudflare colo. Er is geen vraag “is de Sydney-pool warm?”; elke isolate start de module binnen milliseconden en serveert identiek. Operationeel is dit echt eenvoudiger dan regionale Lambda-concurrency-reserveringen onderhouden.

Een pad naar embedding

Als u gPdf ooit binnen de perimeter van een klant wilt draaien, bijvoorbeeld hun VPC, geïsoleerde cluster of air-gapped intranet, werkt dezelfde WASM-module. Dat is het verschil tussen “we hosten SaaS” en “we leveren technologie die overal draait.”

Waar dit stukloopt

Edge is geen gratis magie; er zijn werklasten waar gecentraliseerd wint:

Renders van meerdere seconden. Als één PDF 30 seconden duurt, bijvoorbeeld enorme financiële overzichten of wetenschappelijke rapporten, bent u beter af met een langlopende container met persistente state dan met CPU-limieten op de edge.
Renders die andere databases nodig hebben. Als uw render drie OLAP-tabellen moet JOINen, wilt u de renderlaag naast de database, niet op de edge. Oplossing: doe de JOIN, stuur daarna JSON naar de edge voor de daadwerkelijke render.
Output die nabewerking nodig heeft. Watermerken, signeren, bewaren: als uw pijplijn na de render meerstaps en stateful is, wordt de stateless eigenschap van de edge-render een belasting in plaats van een voordeel.

Voor al het andere, en dat is het overgrote deel van B2B-factuur-, verzendlabel- en bonverkeer, wint edge op elke as die ertoe doet.

Wanneer u moet stoppen met uw huidige setup te tolereren

Een eenvoudige checklist. Als u drie hiervan kunt aanvinken, is de migratierekensom gekanteld:

Uw maandelijkse PDF-infrastructuurkosten komen boven $300.
Uw PDF p99-latency is hoger dan 800 ms tijdens normaal verkeer.
U hebt een cold-startincident gehad dat klanten raakte.
U hebt meer dan 4 uur besteed aan ontbrekende CJK / RTL / emoji-glyphs.
U genereert PDF’s in een interactieve flow (preview, download op het scherm).
U opereert in meer dan één geografische regio.

De eerste drie samen betekenen dat u betaalt en pijn voelt. De volgende drie betekenen dat een gecentraliseerde renderlaag productbeslissingen actief beperkt die u anders zou kunnen nemen.

Als iets hiervan bekend klinkt, rendert de Playground een voorbeeldfactuur in uw browser in minder dan 5 ms; laat die voor zichzelf spreken.