Elegir una API de generación de PDF parece sencillo hasta que empieza la evaluación. Hay alrededor de 40 proveedores, las páginas de marketing suenan parecidas y las diferencias reales solo aparecen después de unos miles de documentos en producción.

Esta es una lista que puede llevar a una evaluación de proveedores: independiente del vendedor y basada en incidentes reales que los equipos encuentran durante compras, producción y posmortems. Son ocho preguntas. Si no obtiene respuestas claras a todas, todavía no tiene suficiente información para elegir.

1. ¿Cuál es el formato de entrada: HTML, JSON o un DSL de plantillas?

Es la pregunta más importante. La respuesta determina qué escribirá su equipo y qué tendrá que depurar a las dos de la mañana.

HTML/CSS (Puppeteer, DocRaptor, Prince): familiar, infinitamente flexible, caro en tiempo de ejecución y difícil de volver determinista.
JSON / datos estructurados (gPdf): barato de renderizar, idéntico byte a byte, pero exige escribir un pequeño mapeador desde su modelo de datos al modelo de documento.
DSL de plantillas (PDFKit, ReportLab, Apache PDFBox): control total y responsabilidad total; su equipo escribirá paginación, maquetación y fallback de fuentes.

No hay una respuesta incorrecta en abstracto. Hay una respuesta incorrecta para su equipo. Pregunte a ingeniería en qué modelo preferiría depurar un bug de paginación de tres horas.

2. ¿Cuál es la latencia de arranque en frío y es predecible?

Algunos renderizadores arrancan en microsegundos: normalmente WASM o binarios nativos. Otros arrancan en segundos, sobre todo los basados en Chromium. La diferencia no se ve hasta que llega un pico de tráfico.

Pregunte al proveedor:

“¿Cuál es su latencia p99 para la primera solicitud a un worker frío?”
“¿Cuánto tiempo pasa desde mi última solicitud hasta que un worker vuelve a estar frío?”
“¿Publican una página de estado con datos de arranque en frío?”

Si no pueden responder a la primera pregunta con un número, asuma que la respuesta es mala.

3. ¿Cómo se modela el coste por renderizado?

Tres variantes, ordenadas por la frecuencia con la que sorprenden a los equipos:

Precio por página (Anvil a 0,10 USD/PDF, DocRaptor a 89 USD/100.000): predecible, fácil de presupuestar y caro a escala.
Planes de suscripción con excedente (gPdf a 5-12 USD/mes + 0,00005 USD/página adicional): barato en cualquier volumen, pero más difícil de proyectar para un uso que aún no ha probado.
Precio basado en cómputo (Puppeteer autohospedado en Lambda): usted asume directamente la factura de cómputo, incluidos arranques en frío y memoria de Chromium.

Calcule su factura REAL en tres niveles de tráfico: actual, 5x y 50x. La forma de la curva de coste importa más que el número destacado en la página de precios.

4. ¿La salida es determinista?

Determinismo — misma entrada -> mismos bytes — suena académico hasta que se necesita.

Lo necesita cuando:

compara PDF en CI para detectar cambios no previstos en plantillas;
conserva documentos bajo factura electrónica o normativa fiscal, donde el PDF almacenado y el PDF regenerado deben coincidir;
calcula un hash del PDF para integridad de archivo;
versiona la salida renderizada para revisión legal.

Los renderizadores basados en navegador (Puppeteer y cualquier opción Chromium) NO son deterministas entre versiones de parche. Los renderizadores binarios nativos, como Prince o gPdf, suelen estar mejor situados. Pregunte explícitamente: “¿Cambiarán mis bytes de salida si publican una actualización del renderizador?”.

5. ¿Cómo gestiona las fuentes, especialmente CJK y RTL?

Esta pregunta ha costado más carreras que casi cualquier otra en el mundo PDF.

El modo de fallo se repite: lanza en su mercado local y las fuentes se ven bien. Seis meses después entra en un mercado que usa una escritura para la que su renderizador no tiene glifos. El PDF empieza a emitir cuadros □□□□. El cliente escala el problema. Su equipo dedica dos sprints a añadir fuentes a un Dockerfile.

Pregunte:

“¿Qué escrituras vienen incluidas sin configuración adicional? ¿Latin, CJK, cirílico, devanagari, árabe, hebreo?”
“¿Qué ocurre cuando aparece un glifo desconocido: fallback o tofu?”
“¿Puedo añadir fuentes personalizadas en la solicitud o tengo que desplegarlas antes?”
“¿Soportan shaping de texto RTL?”

Una buena respuesta suena así: “Incluimos NotoSans CJK y un conjunto de fallback Noto; los glifos desconocidos caen a Noto Symbols”. Una mala respuesta es: “Sí, soportamos fuentes”.

6. ¿Qué perfiles de cumplimiento soporta?

Si su empresa podría llegar a:

emitir facturas en la UE (Factur-X / ZUGFeRD / EN 16931, obligatorio en DE/FR/IT/PL a partir de 2026),
archivar documentos bajo reglas de retención SOX, HIPAA o GDPR (PDF/A),
presentar historiales médicos (PDF/A-3 con XML adjunto),
incrustar firmas digitales (PAdES),

entonces pregunte qué perfiles de cumplimiento soporta el renderizador de forma nativa. La mala respuesta es: “puede ejecutar otra herramienta para convertirlo después”. Eso se convierte en una canalización de varios pasos que ahora es responsabilidad suya.

Las buenas respuestas suelen parecer una sola bandera. Por ejemplo, gPdf acepta settings.profile: "pdfa-3b" junto con un bloque settings.e_invoice con standard: "factur_x" y un CII XML incrustado. Integrado supone mucha menos carga operativa que añadido después.

7. ¿El renderizado es sin estado? ¿Dónde van mis documentos después de renderizarse?

Son dos preguntas relacionadas.

Renderizado sin estado significa que entra la solicitud, se emite el PDF y no se almacena nada. Usted gestiona la persistencia: S3, su base de datos o lo que corresponda. Es lo deseable para cargas con requisitos fuertes de cumplimiento, porque el renderizador nunca se convierte en custodio de sus datos.

Renderizado con estado significa que el proveedor almacena el PDF, a menudo en su CDN, y le entrega una URL firmada. Es cómodo para flujos informales, por ejemplo “enviar al cliente un enlace”, pero problemático para flujos regulados: ahora hay un tercero con una copia de cada documento que ha renderizado.

Pregunte:

“¿El renderizado es sin estado por defecto?”
“Si almacenan el documento, ¿dónde se almacena geográficamente?”
“¿Durante cuánto tiempo se retiene?”
“¿Puedo obtener una garantía escrita de renderizado sin estado para revisión de cumplimiento?”

Si la respuesta es vaga, su equipo legal o de privacidad lo convertirá en un problema nueve meses después.

8. ¿Qué ocurre cuando falla el renderizador y cómo me entero?

Todo renderizador falla alguna vez. Las preguntas son:

¿Cómo aparece el fallo? ¿Un 500 con stack trace? ¿Un 4xx con error estructurado? ¿Un PDF vacío?
¿Cuál es la política de reintentos? ¿Es idempotente? ¿Se cobran los renderizados fallidos?
¿Qué instrumentación ofrece el proveedor? ¿Página de estado? ¿Webhooks de incidentes? ¿Paneles p50/p99 por región?
¿Hay una sonda sintética? ¿El proveedor monitoriza su endpoint público o espera a que usted abra el ticket?

Una prueba rápida: visite ahora mismo la página de estado del proveedor. Si no existe, no es en tiempo real o solo muestra “all systems operational” sin detalle, ese es el nivel de transparencia de fiabilidad que tendrá después de comprar.

Como referencia, gPdf publica /status con datos de sondas sintéticas y Cloudflare Analytics de los últimos siete días.

Cómo puntúa gPdf frente a las ocho preguntas

Como este es nuestro blog y sospechará que hemos inclinado las preguntas, este es nuestro cuadro honesto:

#	Pregunta	Respuesta de gPdf
1	Formato de entrada	JSON `DocumentRequest` (datos estructurados)
2	Arranque en frío	5-20 ms (isolate V8, sin navegador)
3	Modelo de coste	0/5/8/12 USD al mes; excedente de 0,00005 USD/página
4	Determinismo	Idéntico byte a byte, garantizado bajo la misma versión del motor
5	Fuentes	NotoSans CJK + fallback latino integrado
6	Cumplimiento	PDF/A-1b/2b/3b/4 + adjuntos Factur-X / ZUGFeRD integrados
7	Sin estado	Sí, contractualmente: sin almacenamiento de documentos en ningún lugar
8	Fallo y visibilidad	Página pública de estado con tendencia de 7 días; 4xx/5xx estructurados; idempotente

Donde perdemos: P1, si su entrada es HTML real que no puede refactorizar, por ejemplo informes generados por usuarios o plantillas heredadas. Para eso, DocRaptor o Prince son la respuesta adecuada.

TL;DR

No pregunte “cuál es la mejor API de PDF”. Haga las ocho preguntas, puntúe las respuestas y elija el proveedor que encaja con su carga de trabajo real. El equipo que perdió una compra frente a un rival algo más barato y se vio sorprendido por la pregunta 5 nueve meses después diría lo mismo.

Si su carga de trabajo encaja con la forma en que está construido gPdf, el Playground tarda 30 segundos en evaluarse. Si no encaja, le diremos sin rodeos cuál es la herramienta adecuada: normalmente DocRaptor para problemas con forma de HTML, Prince para autohospedaje o Puppeteer si su entrada son páginas web realmente arbitrarias.