La generación de documentos PDF desde el servidor sigue siendo uno de los desafíos más recurrentes en el desarrollo de plataformas comerciales, especialmente cuando el entorno de despliegue impone restricciones de tamaño, memoria o tiempo de ejecución. Quien haya trabajado con funciones serverless en plataformas como Vercel o AWS Lambda sabe que una decisión aparentemente trivial —elegir entre un motor de navegador completo o una librería ligera de renderizado— puede definir la experiencia de usuario, el costo operativo y la estabilidad del sistema. En los últimos años, dos aproximaciones han dominado la conversación: Puppeteer, que controla una instancia oculta de Chromium, y @react-pdf/renderer, que compila directamente a primitivas PDF sin necesidad de un navegador. Ambas tienen fortalezas claras y limitaciones igual de claras, y la elección correcta depende de factores como la complejidad del diseño, la necesidad de soporte multilingüe y el tipo de infraestructura donde se ejecuta el código.

Puppeteer ofrece fidelidad total con el mundo web: cualquier layout que puedas construir con HTML y CSS —incluyendo tablas anidadas, grid, media queries y tipografías externas— se reproduce exactamente igual en el PDF. Esto lo convierte en la opción natural cuando ya existe una plantilla HTML para correo electrónico o vista previa y se desea reutilizarla para la factura. Sin embargo, el precio es elevado: Chromium pesa alrededor de cien megabytes, y lanzar un navegador desde cero añade entre uno y tres segundos de latencia. En entornos serverless, ese tamaño puede superar los límites de empaquetado, y las funciones de arranque en frío se alargan hasta cinco o seis segundos si además hay que descargar el binario. Para mitigar el problema existen versiones reducidas como @sparticuz/chromium, pero el consumo de memoria sigue siendo alto —picos de 400 a 600 MB por invocación—, lo que obliga a vigilar los límites de la función y a considerar rutas dedicadas con mayor capacidad. En muchos proyectos, la solución más pragmática ha sido mover la generación a un servicio interno en una VPS ligera y exponerla como API desde la infraestructura serverless, un patrón que se alinea con las arquitecturas de microservicios que implementamos en aplicaciones a medida para clientes con requisitos regulatorios complejos.

Por el contrario, @react-pdf/renderer prescinde por completo del navegador. Es un renderizador que convierte componentes React en instrucciones directas de PDF, usando su propio motor de layout basado en flexbox. El tamaño total de la librería es inferior a dos megabytes, y la generación de documentos de varias páginas rara vez supera los quinientos milisegundos. Esto lo convierte en la opción ideal para plataformas desplegadas en Vercel, Cloudflare Workers o cualquier función serverless donde el tiempo de respuesta sea crítico y el diseño de los documentos sea estructurado —facturas con líneas de detalle, totals, notas de IVA— sin necesidad de maquetación compleja. La contrapartida es que el conjunto de propiedades CSS soportadas es limitado: no hay grid, ni pseudo-selectores, ni posicionamiento absoluto. Si el diseño requiere elementos superpuestos como sellos o marcas de agua, o si la plantilla HTML ya existe y es compleja, la adaptación a @react-pdf puede ser costosa. En esos casos, es preferible mantener Puppeteer aunque implique gestionar un binario pesado.

Un aspecto que a menudo se subestima es el soporte de alfabetos no latinos. Muchas librerías asumen que con la tipografía incorporada basta, pero al generar facturas en ruso, ucraniano, búlgaro o griego aparecen cuadros de reemplazo. Con Puppeteer, la solución teórica es instalar las fuentes del sistema en el servidor; en la práctica, los entornos serverless no garantizan su disponibilidad, y la configuración se vuelve frágil. @react-pdf/renderer, en cambio, permite registrar fuentes personalizadas de forma explícita (por ejemplo, Roboto con cobertura cirílica) y almacenarlas como activos estáticos del proyecto. Basta con registrar la fuente una vez al arrancar el módulo y asignarla en el estilo raíz del documento; a partir de ahí, cualquier texto en cirílico se renderiza correctamente. Este detalle ha sido decisivo en proyectos que atienden mercados del este de Europa, donde la correcta visualización de caracteres no es un lujo sino un requisito legal. En servicios cloud aws y azure, la portabilidad de estas decisiones es esencial, especialmente cuando una misma aplicación debe funcionar tanto en funciones serverless como en contenedores gestionados.

La experiencia demuestra que no existe una herramienta universalmente superior. La decisión debe basarse en el contexto de despliegue y en la naturaleza del documento. Si el equipo ya mantiene una plataforma sobre Vercel y las facturas son estructuradas, @react-pdf/renderer reduce la latencia, simplifica el empaquetado y elimina los dolores de cabeza con el binario de Chromium. Si, por el contrario, la infraestructura corre sobre una VPS o un clúster de Kubernetes, y los documentos requieren maquetación compleja —tablas con columnas condicionales, saltos de página precisos, tipografías variables—, Puppeteer ofrece una libertad que ninguna librería de renderizado directo puede igualar. La clave está en entender que cada enfoque resuelve un subconjunto de problemas, y que forzar uno donde no encaja genera sobrecostes de mantenimiento y rendimiento.

En Q2BSTUDIO, cuando abordamos proyectos de software a medida para sectores como e-commerce, logística o facturación electrónica, evaluamos estos tradeoffs desde el primer día. No solo importa la tecnología de generación de PDF, sino cómo se integra con el resto del ecosistema: pipelines de pedidos asíncronos, sistemas de colas como BullMQ, almacenamiento en AWS S3 o Azure Blob, y notificaciones al cliente final. En ocasiones, la solución óptima combina ambos motores según el tipo de documento: facturas normales con @react-pdf y albaranes complejos con Puppeteer, todo orquestado desde una capa común de servicios. Además, la experiencia con alfabetos no latinos y con la gestión de fuentes nos ha llevado a desarrollar patrones reutilizables que luego aplicamos en otros contextos, como la generación de informes automatizados para ia para empresas o dashboards exportables a PDF desde Power BI.

La generación de PDF en servidor es un campo donde los pequeños detalles marcan la diferencia entre una solución robusta y una que genera incidentes en producción. Conocer a fondo las capacidades y limitaciones de Puppeteer y @react-pdf/renderer permite tomar decisiones informadas, evitar sorpresas desagradables con los límites de las funciones serverless y garantizar que los documentos lleguen a los clientes en el formato correcto, con la tipografía adecuada y en un tiempo aceptable. En un mundo donde cada milisegundo cuenta y cada fallo de renderizado puede traducirse en una queja o un problema legal, invertir en la elección correcta desde el principio es una de las decisiones más rentables que puede tomar un equipo de desarrollo.