Eine PDF-API auszuwählen wirkt leicht, bis man beginnt. Es gibt viele Anbieter, die Marketingseiten klingen ähnlich, und die echten Kompromisse zeigen sich erst nach tausenden Dokumenten in Produktion.

Diese Checkliste ist für Vendor-Evaluierungen gedacht. Sie ist herstellerneutral und basiert auf realen Vorfällen aus Einkauf, Betrieb und Post-mortems. Acht Fragen; ohne klare Antworten auf alle ist die Entscheidung noch nicht belastbar.

1. Welches Eingabeformat: HTML, JSON oder Template-DSL?

Das ist die wichtigste Frage, denn sie bestimmt, was Ihr Team schreibt und nachts debuggt.

HTML/CSS (Puppeteer, DocRaptor, Prince): vertraut, sehr flexibel, teuer zur Laufzeit, schwer deterministisch zu machen.
JSON / strukturierte Daten (gPdf): günstig zu rendern, byte-identical, benötigt aber einen Mapper vom Datenmodell ins Dokumentmodell.
Template-DSL (PDFKit, ReportLab, Apache PDFBox): volle Kontrolle und volle Verantwortung für Pagination, Layout und Font-Fallback.

Es gibt keine universell richtige Antwort. Es gibt eine falsche Antwort für Ihr Team. Fragen Sie Engineers, in welchem Modell sie einen dreistündigen Pagination-Bug debuggen möchten.

2. Wie hoch ist die Cold-Start-Latenz und ist sie vorhersehbar?

WASM und native Binaries starten oft in Mikrosekunden. Chromium-basierte Renderer brauchen teils Sekunden. Der Unterschied wird bei Traffic-Spitzen sichtbar.

Fragen Sie nach p99 für den ersten Request auf einem kalten Worker, wann ein Worker wieder kalt wird und ob Cold-Start-Daten auf der Statusseite stehen. Ohne Zahl sollten Sie pessimistisch planen.

3. Wie wird der Render-Preis modelliert?

Typische Modelle:

Preis pro Seite: planbar, aber teuer bei Skalierung.
Abo mit Overage: oft günstig, aber usage muss geschätzt werden.
Compute-basiert: Sie zahlen Lambda, Container, Chromium-Speicher und Cold Starts.

Rechnen Sie aktuelle Last, 5x und 50x durch. Die Kostenkurve zählt mehr als der beworbene Einstiegspreis.

4. Ist die Ausgabe deterministisch?

Gleiche Eingabe, gleiche Bytes. Das braucht man für PDF-Diffs in CI, Steuer- und E-Invoice-Aufbewahrung, Archiv-Hashes und juristische Reviews.

Browserbasierte Renderer sind über Chromium-Versionen hinweg oft nicht deterministisch. Native Renderer sind hier besser. Fragen Sie direkt, ob sich Bytes nach Engine-Updates ändern.

5. Wie werden Fonts, CJK und RTL behandelt?

Fonts werden häufig erst spät zum Produktionsproblem. Im Heimatmarkt ist alles gut; im nächsten Markt fehlen Glyphen und im PDF erscheinen □□□□.

Fragen Sie nach eingebetteten Schriften, Verhalten bei unbekannten Glyphen, Custom Fonts pro Request und RTL-Shaping. Eine gute Antwort nennt NotoSans CJK und klare Fallback-Regeln.

6. Welche Compliance-Profile gibt es?

Wenn EU-Rechnungen, PDF/A-Archivierung, XML-Anhänge oder digitale Signaturen denkbar sind, fragen Sie nach nativem Support. “Danach mit einem Tool konvertieren” heißt: Sie besitzen nun eine zusätzliche Pipeline.

Gute Antworten sehen aus wie { profile: "PDF/A-3b" } oder { einvoice: { format: "factur-x", xml: "..." } }.

7. Ist Rendering stateless? Wo landen Dokumente?

Stateless Rendering nimmt den Request, gibt das PDF zurück und speichert nichts. Sie steuern Persistenz selbst. Für regulierte Workloads ist das meist richtig.

Stateful Rendering speichert PDF beim Anbieter und gibt eine signierte URL zurück. Praktisch, aber ein Dritter besitzt Kopien Ihrer Dokumente.

8. Was passiert bei Fehlern?

Jeder Renderer fällt irgendwann aus. Wichtig sind strukturierte Fehler, Idempotenz, Gebühren für Fehlschläge, Statusseite, Webhooks, p50/p99 nach Region und Synthetic Probes.

gPdf im Überblick

#	Frage	gPdf-Antwort
1	Input	JSON `DocumentRequest`
2	Cold Start	5-20 ms, V8 isolate, kein Browser
3	Kosten	$0/$5/$8/$12 pro Monat; $0.00005/Seite Overage
4	Determinismus	Byte-identical bei gleicher Engine-Version
5	Fonts	NotoSans CJK + Latin fallback eingebettet
6	Compliance	PDF/A-1b/2b/3b/4 + Factur-X / ZUGFeRD
7	Stateless	Ja, keine Dokumentenspeicherung
8	Fehler	Public Status Page, strukturierte Fehler, idempotent

Wo gPdf nicht gewinnt: Wenn Ihr Input echtes HTML ist und nicht refaktoriert werden kann, sind DocRaptor oder Prince oft besser.

Kurzfassung

Fragen Sie nicht nach der “besten PDF-API”. Stellen Sie diese acht Fragen, bewerten Sie die Antworten und wählen Sie nach Ihrer echten Last. Für Rechnungen, Belege und strukturierte Dokumente lässt sich gPdf im Playground schnell prüfen.