DocRaptor es un producto competente. Envuelve a Prince, el motor de referencia para convertir HTML a PDF, en una API REST alojada, con reintentos, trabajos asíncronos y documentación correcta. Lleva más de una década en el mercado y, para muchos equipos, es la opción obvia cuando no quieren ejecutar Prince por su cuenta.

gPdf es otra clase de herramienta. No acepta HTML en absoluto: toma JSON estructurado y renderiza PDF directamente en el edge de Cloudflare. La diferencia de precio de lista a 100.000 páginas/mes es 5 USD/mes (gPdf Basic) frente a 89 USD/mes (DocRaptor Basic), alrededor de 18×. Esa diferencia no es una promoción inicial. Es estructural. Este artículo explica por qué esa estructura produce ese precio y dónde encaja realmente cada herramienta.

Las dos arquitecturas, lado a lado

Capa	DocRaptor (HTML → PDF)	gPdf (JSON → PDF)
Entrada	HTML + CSS (con extensiones Prince paged-media)	JSON `DocumentRequest`
Renderizador	Prince (motor C++ compilado)	Motor Rust propio, compilado a WebAssembly
Hosting	Servidores centralizados de DocRaptor (región de centro de datos en EE. UU.)	Cloudflare Workers, en cada colo de CF (más de 300 ciudades)
Arranque en frío	Pool de workers del lado servidor	Arranque de isolate V8, milisegundos de un dígito
Cómputo por renderizado	Pasada de maquetación sobre HTML/CSS, luego Prince pagina	Composición directa, sin pasada de interpretación de maquetación
p50 por renderizado	~250-800 ms de tiempo total (red + renderizado)	~3-8 ms (red + renderizado)
Determinismo de salida	Alto (Prince es maduro)	Byte-idéntico (mismo JSON → mismos bytes)

Si lee esas dos columnas como “impresora HTML genérica” frente a “renderizador de documentos diseñado para ese trabajo”, ya entendió la decisión arquitectónica. Todo lo demás — latencia, coste e incluso listas de funciones — se deriva de esa única elección.

El impuesto Prince

Prince es bueno. También hace un trabajo que la mayoría de flujos de facturas, recibos y etiquetas no necesitan: implementar CSS Paged Media — reglas de salto de página, encabezados continuos, notas al pie, referencias cruzadas y cajas de contenido generado — para HTML arbitrario que el usuario pueda entregarle.

Esa generalidad tiene un coste en tiempo de ejecución. Para paginar HTML arbitrario, el motor debe:

Parsear y validar el HTML
Analizar y resolver la cascada CSS (posiblemente con extensiones propias de Prince)
Construir el árbol de renderizado
Ejecutar maquetación en varias pasadas (especialmente para tablas que cruzan páginas o columnas que se equilibran)
Resolver referencias cruzadas entre páginas
Emitir objetos PDF

La mayoría de esas pasadas son el coste de aceptar HTML como entrada. Si su entrada ya son datos estructurados — y casi siempre lo son, porque su factura existe como objeto JSON antes de envolverla en HTML — paga esas pasadas en cómputo y latencia en cada renderizado, y no añaden valor a la salida.

gPdf se salta por completo la interpretación de maquetación. El JSON DocumentRequest ya especifica la composición de la página de forma estructural: { pages: [{ size, elements: [...] }] }. El renderizador compone los elementos, pagina tablas y listas de forma determinista, y emite el PDF. No hay cascada CSS que resolver, maquetación de floats que calcular ni pasada de resolución de referencias cruzadas.

Resultado: la misma factura de una página que tarda ~300 ms en DocRaptor tarda ~3 ms en gPdf. No somos más rápidos porque hayamos escrito un Prince más rápido; somos más rápidos porque no hacemos la mayor parte de lo que hace Prince.

“Demasiado barato para ser real” es una objeción real en compras

Conviene abordarla directamente porque aparece en casi todas las conversaciones B2B.

“5 USD/mes por 100.000 renderizados. DocRaptor cuesta 89 USD. Anvil cuesta 0,10 USD/PDF, es decir, 10.000 USD para el mismo volumen. ¿Qué les pasa?”

Tres razones honestas por las que podemos cobrar esto:

1. No ejecutamos un navegador

DocRaptor amortiza infraestructura de Prince entre clientes. gPdf amortiza un Cloudflare Worker, que cuesta cerca de 0,50 USD por millón de solicitudes en Workers Bundled. Con entrada en forma de JSON, nuestro renderizador consume alrededor de 1,5 ms de CPU por renderizado. Añada un margen del 50% y todavía está en el rango de centavos por mil renderizados. La aritmética es el precio.

2. No ejecutamos un plano de control

No hay trabajos asíncronos, callbacks, cola de reintentos, almacenamiento de documentos, interfaz de enlaces de previsualización ni base de datos multi-tenant. Cada renderizado es un único viaje de ida y vuelta a una función sin estado. Eso elimina toda la superficie operativa que la mayoría de empresas de “PDF API” presupuestan, y esa superficie también es la que justifica su precio.

3. El modelo se autoselecciona fuera de las cargas en las que perderíamos dinero

Si su documento realmente necesita HTML a PDF — un contrato legal de 60 páginas o un informe complejo con CSS Grid — chocará con el modelo JSON en la primera hora y terminará en DocRaptor de todos modos. No tenemos que fijar precios defensivos para esas cargas porque se enrutan solas. Solo tenemos que fijar precio para la cola larga pero estrecha de cargas de “datos estructurados a documento”, donde el coste por renderizado es realmente diminuto.

En conjunto: 5 USD/100.000 no es un precio gancho con pérdidas; es el coste real de servicio más margen. Podemos mantenerlo indefinidamente porque el cómputo subyacente es así de barato cuando no se envía un navegador.

Dónde DocRaptor es la elección correcta

Tratamos de no escribir comparativas autointeresadas. Los casos donde DocRaptor genuinamente gana:

Su entrada es HTML que no controla por completo. Informes generados por usuarios, plantillas de terceros o Markdown de un CMS renderizado a HTML. No quiere escribir un mapeador JSON para entradas arbitrarias.
Necesita funciones de CSS Paged Media que Prince soporta. Encabezados y pies continuos por capítulo, redistribución compleja de notas al pie, selectores de página con nombre, tablas de contenido e índices generados. gPdf tiene equivalentes estructurados para el subconjunto común, pero si vive en selectores @page :left, Prince es su aliado.
Tiene un equipo de contenido que escribe HTML/CSS, no JSON. No imponga un flujo de autoría JSON a un equipo no técnico. Lo odiarán.
Trabajos asíncronos, callbacks y almacenamiento de documentos como servicio. DocRaptor almacena los PDF generados y le da URL firmadas para entregarlos. gPdf es estrictamente sin estado: su código almacena el resultado.

Si está en cualquiera de esos grupos, quédese con DocRaptor. Es la herramienta correcta.

Dónde gPdf es la elección correcta

La imagen espejo:

Sus entradas ya son datos estructurados (filas de base de datos, datos de API JSON, mensajes de cola).
La latencia importa: checkout interactivo, impresión de etiquetas en tiempo real, generación de estados de cuenta bajo demanda.
Le importa la reproducibilidad idéntica byte a byte para pruebas, pistas de auditoría o retención de facturas electrónicas.
Es sensible al coste en cualquier volumen por encima de unos pocos miles de renderizados/mes.
Necesita códigos de barras (GS1-128, QR, Data Matrix, PDF417, Aztec, MaxiCode) con precisión submilimétrica: Prince puede soportar técnicamente códigos de barras SVG, pero renderizarlos con precisión de longitud total de 0,1 mm a través de HTML/CSS no es trivial.
Necesita PDF/A (1b/2b/3b/4) o adjuntos Factur-X / ZUGFeRD para cumplimiento.
Preferiría no ejecutar una canalización JSON a HTML a PDF cuando puede ejecutar una canalización JSON a PDF.

La migración es mecánica, no estratégica

Una preocupación común: “Cambiar significa reescribir todas nuestras plantillas”. Normalmente no es así. La mayoría de plantillas HTML a PDF son 20% maquetación — que se convierte en estructura JSON una sola vez — y 80% interpolación de datos, que es exactamente lo mismo independientemente de qué acepte el renderizador.

Camino práctico:

Elija un tipo de documento para migrar. Empiece por el de mayor volumen: mayor ahorro y menor radio de impacto.
Tome la interfaz de datos de la plantilla HTML, es decir, las variables que interpola, y escriba una pequeña función mapToDocumentRequest(data).
Itere en el Playground hasta que la salida coincida.
Haga una prueba A/B en producción: enrute el 5% del tráfico a gPdf durante dos semanas. Compare los PDF. Compare las facturas.
Avance o retroceda con datos, no con sensaciones.

Hemos visto equipos hacerlo en un solo sprint y quedarse con el 90% de su factura de PDF al mes siguiente. También hemos visto equipos descubrir que su carga era realmente el caso HTML a PDF y quedarse en DocRaptor, con nuestra aprobación.

TL;DR

	DocRaptor	gPdf
Mejor para	HTML → PDF para contenido arbitrario	JSON → PDF para documentos estructurados
Precio (100.000 páginas/mes)	89 USD	5 USD
Renderizado p50	250-800 ms	3-8 ms
Desplegado en el edge	❌ centralizado	✅ más de 300 colos de Cloudflare
Async + almacenamiento	✅ incluido	❌ sin estado por diseño
PDF/A + Factur-X	⚠️ vía extensiones Prince	✅ integrado

Si sus documentos son datos estructurados vestidos de HTML para un renderizador, está pagando por un paso de traducción que no necesita existir. Pruebe el Playground: describa una de sus facturas en JSON, renderícela en el navegador en menos de 5 ms y vea si la diferencia coincide con su intuición.