DocRaptor ist ein kompetentes Produkt. Es verpackt Prince, die Goldstandard-Engine für HTML-zu-PDF, in eine gehostete REST API mit Retries, asynchronen Jobs und ordentlicher Dokumentation. Es gibt DocRaptor seit über einem Jahrzehnt, und für viele Teams ist es die offensichtliche Wahl, wenn sie “Prince nicht selbst betreiben” möchten.

gPdf hat eine andere Form. gPdf nimmt überhaupt kein HTML an; es nimmt strukturiertes JSON und rendert direkt am Cloudflare Edge zu PDF. Die Listenpreis-Lücke bei 100.000 Seiten/Monat lautet 5 USD/Monat (gPdf Basic) vs. 89 USD/Monat (DocRaptor Basic), also ungefähr 18x. Diese Lücke ist kein Einstiegspromo. Sie ist strukturell. Dieser Beitrag erklärt, warum die Struktur diesen Preis erzeugt und wo beide Werkzeuge wirklich passen.

Die zwei Architekturen nebeneinander

Ebene	DocRaptor (HTML → PDF)	gPdf (JSON → PDF)
Eingabe	HTML + CSS (mit Prince-Erweiterungen für Paged Media)	`DocumentRequest` JSON
Renderer	Prince (kompilierte C++-Engine)	Eigene Rust-Engine, zu WebAssembly kompiliert
Hosting	Zentralisierte DocRaptor-Server (US-Rechenzentrumsregion)	Cloudflare Workers, jeder CF-Colo (300+ Städte)
Cold Start	Serverseitiger Worker-Pool	V8 isolate boot, einstellige Millisekunden
Compute pro Render	Layout-Pass über HTML/CSS, danach paginiert Prince	Direkter Satz, kein Layout-Interpretationspass
p50 pro Render	ca. 250 bis 800 ms Wall Time (Netzwerk + Render)	ca. 3 bis 8 ms (Netzwerk + Render)
Output-Determinismus	Hoch (Prince ist ausgereift)	Byte-identisch (gleiches JSON → gleiche Bytes)

Wenn Sie diese zwei Spalten als “allgemeiner HTML-Drucker” gegenüber “zweckgebauter Dokumenten-Renderer” lesen, haben Sie die Architekturentscheidung bereits verstanden. Alles andere - Latenz, Kosten, sogar Feature-Listen - folgt aus dieser einen Wahl.

Die Prince-Steuer

Prince ist gut. Es erledigt aber auch eine Aufgabe, die die meisten Rechnungs-, Beleg- und Label-Workflows nicht brauchen: CSS Paged Media für beliebiges HTML implementieren, das ein Benutzer hineinwirft. Dazu gehören Seitenumbruchregeln, laufende Header, Fußnoten, Querverweise und generierte Inhaltsboxen.

Diese Allgemeinheit hat Laufzeitkosten. Um ein beliebiges HTML-Dokument zu paginieren, muss die Engine:

HTML parsen und validieren
die CSS-Kaskade parsen und auflösen, möglicherweise inklusive Prince-eigener Erweiterungen
einen Renderbaum bauen
ein Multi-Pass-Layout ausführen, besonders bei Tabellen über mehrere Seiten oder balancierten Spalten
Querverweise über Seiten hinweg auflösen
PDF-Objekte ausgeben

Die meisten dieser Pässe sind die Kosten dafür, HTML als Eingabe zu akzeptieren. Wenn Ihre Eingabe bereits strukturierte Daten ist - was fast immer der Fall ist, denn Ihre Rechnung existiert irgendwo als JSON-Objekt, bevor Sie sie in HTML verpacken -, bezahlen Sie diese Pässe bei jedem Render in Compute und Latenz, ohne dass sie dem Output Wert hinzufügen.

gPdf überspringt den Layout-Interpretationsschritt vollständig. Das JSON DocumentRequest spezifiziert das Seitenlayout bereits strukturiert: { pages: [{ size, elements: [...] }] }. Der Renderer setzt Elemente, paginiert Tabellen und Listen deterministisch und gibt PDF aus. Es gibt keine CSS-Kaskade, kein Float-Layout und keinen Querverweis-Auflösungspass.

Das Ergebnis: Dieselbe einseitige Rechnung, die auf DocRaptor etwa 300 ms braucht, rendert auf gPdf in etwa 3 ms. Wir sind nicht schneller, weil wir ein schnelleres Prince geschrieben haben. Wir sind schneller, weil wir das meiste, was Prince tun muss, gar nicht tun.

“Zu billig, um wahr zu sein” ist ein echter Einwand in der Beschaffung

Das lohnt sich direkt anzusprechen, weil es in fast jedem B2B-Verkaufsgespräch vorkommt.

“5 USD/Monat für 100.000 Renders. DocRaptor kostet 89 USD. Anvil kostet 0,10 USD/PDF, also 10.000 USD für dasselbe Volumen. Was stimmt mit Ihnen nicht?”

Drei ehrliche Gründe, warum wir diesen Preis verlangen können:

1. Wir betreiben keinen Browser

DocRaptor amortisiert Prince-Infrastruktur über Kunden. gPdf amortisiert einen Cloudflare Worker, der auf Workers Bundled ungefähr 0,50 USD pro Mio. Requests kostet. Mit JSON-förmiger Eingabe braucht unser Renderer ungefähr 1,5 ms CPU pro Render. Rechnen Sie 50 % Marge darauf, und Sie sind weiterhin im Bereich von Cents pro tausend Renderings. Die Arithmetik ist der Preis.

2. Wir betreiben keine Control Plane

Es gibt keine asynchronen Jobs, keine Callbacks, keine Retry Queue, keine Dokumentenspeicherung, keine Preview-Link-UI und keine Multi-Tenant-Datenbank. Jeder Render ist ein einzelner Round-trip zu einer zustandslosen Funktion und zurück. Damit fällt die gesamte Betriebsoberfläche weg, die viele “PDF API”-Unternehmen einpreisen und die zugleich ihren Preis rechtfertigt.

3. Das Modell sortiert die Workloads aus, bei denen wir Geld verlieren würden

Wenn Ihr Dokument wirklich HTML-zu-PDF braucht, etwa ein 60-seitiger Rechtsvertrag oder ein komplexer CSS-Grid-Report, stoßen Sie im ersten Arbeitsstunde am JSON-Modell an und gehen ohnehin zu DocRaptor. Wir müssen diese Workloads nicht defensiv einpreisen, weil sie sich selbst aussortieren. Wir müssen nur für den langen, schmalen Tail von “strukturierte Daten zu Dokument” kalkulieren, wo die Kosten pro Render tatsächlich winzig sind.

Zusammen: 5 USD pro 100.000 Seiten sind kein Loss Leader. Es sind tatsächliche Cost of Goods Sold plus Marge. Wir können diesen Preis dauerhaft halten, weil der zugrunde liegende Compute wirklich so günstig ist, wenn Sie keinen Browser ausliefern.

Wo DocRaptor die richtige Wahl ist

Wir versuchen, keine eigennützigen Vergleiche zu schreiben. In diesen Fällen gewinnt DocRaptor wirklich:

Ihre Eingabe ist HTML, das Sie nicht vollständig kontrollieren. Benutzergenerierte Reports, Vorlagen von Dritten, Markdown aus einem CMS, das zu HTML gerendert wurde. Sie wollen keinen JSON-Mapper für beliebige Eingaben schreiben.
Sie brauchen CSS-Paged-Media-Features, die Prince unterstützt. Laufende Header/Footer pro Kapitel, komplexer Fußnoten-Reflow, benannte Page-Selektoren, generierte Inhaltsverzeichnisse oder Indizes. gPdf hat strukturierte Äquivalente für die häufige Teilmenge, aber wenn Sie in @page :left-Selektoren leben, ist Prince Ihr Freund.
Sie haben ein Content-Team, das HTML/CSS schreibt, nicht JSON. Erzwingen Sie keinen JSON-Autorenworkflow für ein Nicht-Engineering-Team. Es wird Sie dafür hassen.
Async + Callbacks + Dokumentenspeicherung als Service. DocRaptor speichert generierte PDFs und gibt Ihnen signierte URLs zur Auslieferung. gPdf ist strikt zustandslos: Ihr Code speichert das Ergebnis.

Wenn Sie in einem dieser Buckets sind, bleiben Sie bei DocRaptor. Es ist das richtige Werkzeug.

Wo gPdf die richtige Wahl ist

Das Spiegelbild:

Ihre Eingaben sind bereits strukturierte Daten: Datenbankzeilen, JSON-API-Payloads, Queue-Nachrichten.
Latenz zählt: interaktive Checkout-Flows, Echtzeit-Labeldruck, On-Demand-Statements.
Sie brauchen byte-identische Reproduzierbarkeit für Tests, Audit Trails oder E-Rechnungsaufbewahrung.
Sie achten bei jedem Volumen oberhalb weniger tausend Renderings pro Monat auf Kosten.
Sie brauchen Barcodes (GS1-128, QR, Data Matrix, PDF417, Aztec, MaxiCode) mit Submillimeter-Präzision. Prince unterstützt SVG-Barcodes technisch, aber 0,1 mm Gesamtlängenpräzision durch HTML/CSS hindurch stabil zu rendern, ist nicht trivial.
Sie brauchen PDF/A (1b/2b/3b/4) oder Factur-X / ZUGFeRD-Anhänge für Compliance.
Sie möchten keine JSON-zu-HTML-zu-PDF-Pipeline betreiben, wenn eine JSON-zu-PDF-Pipeline reicht.

Migration ist mechanisch, nicht strategisch

Eine häufige Sorge lautet: “Wechseln bedeutet, alle Vorlagen neu zu schreiben.” Meist stimmt das nicht. Die meisten HTML-zu-PDF-Vorlagen bestehen zu 20 % aus Layout, das einmal zu JSON-Struktur wird, und zu 80 % aus Dateninterpolation, die unabhängig vom Renderer gleich bleibt.

Praktischer Pfad:

Wählen Sie einen Dokumenttyp für die Migration. Beginnen Sie mit dem volumenstärksten: größte Einsparung, kleinster Blast Radius.
Nehmen Sie das Dateninterface der HTML-Vorlage, also die Variablen, die sie interpoliert, und schreiben Sie eine kleine Funktion mapToDocumentRequest(data).
Iterieren Sie im Playground, bis die Ausgabe passt.
A/B in Produktion: Routen Sie 5 % des Traffics für zwei Wochen zu gPdf. Vergleichen Sie die PDFs. Vergleichen Sie die Rechnungen.
Rollen Sie auf Basis von Daten vor oder zurück, nicht auf Basis von Bauchgefühl.

Wir haben Teams gesehen, die das in einem Sprint erledigt und im nächsten Monat 90 % ihrer PDF-Rechnung eingespart haben. Wir haben auch Teams gesehen, die erkannten, dass ihr Workload wirklich der HTML-zu-PDF-Fall war, und bei DocRaptor blieben: mit unserem Segen.

TL;DR

	DocRaptor	gPdf
Am besten bei	HTML → PDF für beliebige Inhalte	JSON → PDF für strukturierte Dokumente
Preis (100.000 Seiten/Monat)	89 USD	5 USD
p50 Render	250 bis 800 ms	3 bis 8 ms
Am Edge deployed	❌ zentralisiert	✅ 300+ Cloudflare-Colos
Async + Storage	✅ enthalten	❌ bewusst zustandslos
PDF/A + Factur-X	⚠️ über Prince-Erweiterungen	✅ integriert

Wenn Ihre Dokumente strukturierte Daten sind, die nur für einen Renderer als HTML verkleidet werden, bezahlen Sie für einen Übersetzungsschritt, der nicht existieren muss. Probieren Sie den Playground aus: Beschreiben Sie eine Ihrer Rechnungen in JSON, rendern Sie sie in Ihrem Browser in unter 5 ms und prüfen Sie, ob die Lücke zu Ihrem Bauchgefühl passt.