Why Your PDF Pipeline Is Slower Than It Needs To Be

Every backend engineer has been there. The client wants invoices. Reports. Certificates. Statements. "Just generate a PDF," they say, like it's a print() statement. So you reach for the standard toolchain: render HTML with Jinja2, spin up a headless Chrome instance, call page.pdf() , and pray it doesn't OOM on the 500th document in the batch. It works. Until it doesn't. The headless browser tax Here's what actually happens when you generate a PDF through a headless browser: Spawn a Chromium process (or connect to a pool) Create a new page context Load your HTML + CSS + assets Wait for fonts, images, layout Call the print-to-PDF API Serialize the PDF bytes Tear down the page context For a single invoice, this takes 2-5 seconds. For a batch of 10,000 monthly statements, you're looking at hours of compute, gigabytes of RAM, and a deployment that needs its own dedicated infrastructure just to print documents. The worst part? Chromium is rendering a full web page — JavaScript engine, DOM, C