DocRaptor è un prodotto valido. Incapsula Prince, il motore HTML-to-PDF di riferimento, in un’API REST hosted, con retry, job asincroni e una documentazione solida. Esiste da oltre dieci anni e per molti team è la scelta naturale quando non vogliono gestire Prince in proprio.

gPdf ha una forma diversa. Non accetta HTML: prende JSON strutturato e renderizza il PDF direttamente all’edge Cloudflare. Il divario di listino a 100.000 pagine/mese è 5 USD/mese (gPdf Basic) contro 89 USD/mese (DocRaptor Basic), circa 18×. Non è una promozione di lancio. È strutturale. Questo articolo spiega perché l’architettura produce quel prezzo e dove ciascun prodotto ha davvero senso.

Le due architetture, fianco a fianco

Strato	DocRaptor (HTML → PDF)	gPdf (JSON → PDF)
Input	HTML + CSS (con estensioni Prince paged-media)	`DocumentRequest` JSON
Motore	Prince (motore C++ compilato)	Motore Rust custom, compilato in WebAssembly
Hosting	Server DocRaptor centralizzati (area data center USA)	Cloudflare Workers, ogni colo CF (300+ città)
Cold start	Pool di worker lato server	Avvio di un isolate V8, millisecondi a una cifra
Calcolo per render	Passaggio di layout su HTML/CSS, poi paginazione Prince	Composizione diretta, senza interpretare il layout
p50 per render	~250–800 ms wall-clock (rete + render)	~3–8 ms (rete + render)
Determinismo output	Alto (Prince è maturo)	Byte-identico (stesso JSON → stessi byte)

Se leggete queste due colonne come “stampante HTML generica” contro “motore di documenti progettato per questo scopo”, avete già capito la decisione architetturale. Tutto il resto, dalla latenza ai costi fino all’elenco delle funzionalità, discende da quella scelta.

La tassa Prince

Prince è ottimo. Sta però facendo un lavoro che la maggior parte dei processi per fatture, ricevute ed etichette non richiede: implementare CSS Paged Media, quindi regole di interruzione pagina, intestazioni ricorrenti, note a piè di pagina, riferimenti incrociati e box di contenuto generato, per HTML arbitrario che l’utente potrebbe passargli.

Quella generalità ha un costo a runtime. Per paginare HTML arbitrario, il motore deve:

Parsare e validare l’HTML
Risolvere la cascata CSS, eventualmente con estensioni proprie di Prince
Costruire l’albero di rendering
Eseguire un layout multi-pass, soprattutto per tabelle che attraversano più pagine o colonne da bilanciare
Risolvere riferimenti incrociati tra pagine
Emettere oggetti PDF

La maggior parte di questi passaggi è il costo di accettare HTML come input. Se il vostro input è già composto da dati strutturati, come quasi sempre accade perché la fattura esiste già come oggetto JSON prima di essere avvolta in HTML, pagate quei passaggi in calcolo e latenza a ogni render senza aggiungere valore all’output.

gPdf salta del tutto il passaggio di interpretazione del layout. Il JSON DocumentRequest specifica già il layout della pagina in forma strutturata: { pages: [{ size, elements: [...] }] }. Il motore compone gli elementi, pagina tabelle e liste in modo deterministico ed emette il PDF. Niente cascata CSS da risolvere, niente layout float da calcolare, niente passaggio di risoluzione dei riferimenti incrociati.

Risultato: la stessa fattura di una pagina che impiega ~300 ms su DocRaptor impiega ~3 ms su gPdf. Non siamo più veloci perché abbiamo scritto un Prince più veloce — siamo più veloci perché non facciamo la maggior parte di ciò che fa Prince.

“Troppo economico per essere vero” è un’obiezione reale negli acquisti

Affrontiamola direttamente perché emerge in quasi ogni conversazione commerciale B2B.

“5 USD/mese per 100.000 render. DocRaptor costa 89 USD. Anvil costa 0,10 USD/PDF, quindi 10.000 USD allo stesso volume. Dov’è l’inghippo?”

Tre ragioni oneste per cui possiamo addebitare questo:

1. Non gestiamo un browser

DocRaptor ammortizza l’infrastruttura Prince tra i clienti. gPdf ammortizza un Cloudflare Worker, che costa circa 0,50 USD per milione di richieste su Workers Bundled. Con input in forma JSON, il nostro motore impiega circa 1,5 ms di CPU per render. Aggiungete un margine del 50% e siete ancora nell’ordine dei centesimi per mille render. L’aritmetica è il prezzo.

2. Non gestiamo un control plane

Niente job asincroni, niente callback, niente coda di retry, niente storage di documenti, niente interfaccia per link di anteprima, niente database multi-tenant. Ogni render è un singolo andata e ritorno verso una funzione stateless. Questo elimina l’intera superficie operativa che molte aziende di “PDF API” mettono a budget, la stessa superficie che giustifica il loro prezzo.

3. Il modello esclude da solo i carichi su cui perderemmo denaro

Se il vostro documento ha davvero bisogno di HTML-to-PDF, come un contratto legale di 60 pagine o un report complesso basato su CSS Grid, il modello JSON vi respingerà nella prima ora e andrete comunque su DocRaptor. Non dobbiamo prezzare in modo difensivo per quei carichi perché si auto-selezionano. Dobbiamo prezzare solo per la coda lunga ma stretta dei casi “dati strutturati → documento”, dove il costo per render è davvero minuscolo.

In sintesi: 5 USD per 100.000 pagine non è un prezzo civetta, è il costo effettivo del venduto più margine. Possiamo mantenerlo perché il calcolo sottostante è davvero così economico quando non si spedisce un browser.

Dove DocRaptor è la scelta giusta

Cerchiamo di non scrivere confronti autointeressati. I casi dove DocRaptor vince genuinamente:

Il vostro input è HTML che non controllate completamente. Report generati dagli utenti, template di terze parti, Markdown proveniente da CMS e renderizzato in HTML. Non volete scrivere un mapper JSON per input arbitrari.
Vi servono funzionalità CSS Paged Media supportate da Prince. Intestazioni e piè di pagina ricorrenti per capitolo, reflow complesso delle note, selettori di pagina nominati, indici e tavole dei contenuti generate. gPdf offre equivalenti strutturati per il sottoinsieme comune, ma se vivete nei selettori @page :left, Prince è lo strumento giusto.
Avete un team contenuti che scrive HTML/CSS, non JSON. Non imponete un processo di authoring JSON a un team non tecnico. Lo vivrebbe male.
Async, callback e storage documenti come servizio. DocRaptor archivia i PDF generati e vi dà URL firmati per la consegna. gPdf è rigorosamente stateless: il risultato lo archivia il vostro codice.

Se rientrate in uno di questi casi, restate su DocRaptor. È lo strumento giusto.

Dove gPdf è la scelta giusta

L’immagine speculare:

I vostri input sono già dati strutturati (righe di database, dati JSON da API, messaggi di coda).
La latenza conta: checkout interattivi, stampa di etichette in tempo reale, generazione on-demand di estratti conto.
Vi interessa la riproducibilità byte-identica per test, audit trail o conservazione di fatture elettroniche.
Siete sensibili ai costi a qualsiasi volume sopra qualche migliaio di render al mese.
Vi servono codici a barre (GS1-128, QR, Data Matrix, PDF417, Aztec, MaxiCode) con precisione sub-millimetrica: Prince supporta tecnicamente i codici a barre SVG, ma ottenere una precisione complessiva di 0,1 mm tramite HTML/CSS non è banale.
Vi servono PDF/A (1b/2b/3b/4) o allegati Factur-X / ZUGFeRD per esigenze di conformità.
Preferite evitare una pipeline JSON → HTML → PDF quando potete eseguire una pipeline JSON → PDF.

La migrazione è meccanica, non strategica

Una preoccupazione comune: “Cambiare significa riscrivere tutti i nostri template”. Di solito no. La maggior parte dei template HTML-to-PDF è 20% layout, che diventa una volta sola struttura JSON, e 80% interpolazione dati, che resta identica indipendentemente da ciò che il motore accetta.

Percorso pratico:

Scegliete un tipo di documento da migrare. Partite da quello con il volume più alto: massimo risparmio, raggio d’impatto più piccolo.
Prendete l’interfaccia dati del template HTML, cioè le variabili che interpola, e scrivete una piccola funzione mapToDocumentRequest(data).
Iterate nel Playground finché l’output combacia.
Fate un A/B in produzione: instradate il 5% del traffico a gPdf per due settimane. Confrontate i PDF e le fatture.
Procedete o tornate indietro in base ai dati, non alle sensazioni.

Abbiamo visto team completare questo percorso in un singolo sprint e ridurre del 90% la spesa PDF già dal mese successivo. Abbiamo anche visto team scoprire che il loro carico era davvero un caso HTML-to-PDF e restare su DocRaptor, con la nostra piena approvazione.

TL;DR

	DocRaptor	gPdf
Migliore per	HTML → PDF per contenuto arbitrario	JSON → PDF per documenti strutturati
Prezzo (100.000 pagine/mese)	89 USD	5 USD
Render p50	250–800 ms	3–8 ms
Distribuzione edge	❌ centralizzato	✅ 300+ colo Cloudflare
Async + storage	✅ incluso	❌ stateless by design
PDF/A + Factur-X	⚠️ tramite estensioni Prince	✅ integrato

Se i vostri documenti sono dati strutturati travestiti da HTML per un motore di rendering, state pagando per uno step di traduzione che non deve esistere. Provate il Playground: descrivete una delle vostre fatture in JSON, renderizzatela nel browser in meno di 5 ms e verificate se il divario corrisponde alla vostra intuizione.