Invoice Rendering at 1M PDFs/Month: Puppeteer vs. Playwright vs. Typst vs. React-PDF, Measured

The Threshold Where Invoice Rendering Becomes Infrastructure

Every billing platform crosses the same line. At 10k invoices/month, PDF rendering is a feature: a Lambda, a Chromium layer, done. At 1M/month — with month-end bursts that hit 100+ documents/second and a contractual 99.9% delivery SLA — it becomes a distributed system with its own capacity model, failure taxonomy, and cost center.

The engine choice you make at 10k is the one you live with at 1M, so it is worth measuring properly. Below are the results of a reproducible harness comparing Puppeteer, Playwright, Typst, and React-PDF on a fixture that looks like a real invoice, not a Hello World div.

Methodology caveat, stated up front: these numbers come from a 4 vCPU / 8 GB container on AWS Fargate (x86_64), engine versions Puppeteer 23 (Chrome 131), Playwright 1.49 (Chromium 131 / Firefox 133 / WebKit 18.2), Typst 0.13, and @react-pdf/renderer 4.1. Latency distributions are from 20,000 sequential samples per engine after 2,000 warm-up iterations. Your fonts, CSS, and fixture will move these numbers. Re-run the harness before you commit to a bill of materials.

The Benchmark Fixture: Three Pages, Sixty Lines, Two Fonts

The fixture matters more than the engine. Ours renders a standard EU-compliant invoice:

• 3 A4 pages at 60 line items, with a repeating table header on each page.
• Embedded logo (PNG, 40 KB), QR payment code (SVG), and a VAT summary block.
• Two embedded webfonts (Inter Regular + SemiBold), subsetted, loaded from disk — never from a CDN in the hot path.
• break-inside: avoid on the totals block, @page margins, and a page X of Y footer.
• All assets inlined as data: URIs so the renderer performs zero network I/O.

That last bullet is the single largest latency win available to browser-based renderers, and it is free.

Why p95 Is the Only Latency Number That Survives Contact With Finance

Mean latency is a vanity metric for document pipelines because billing traffic is bimodal. Steady state is a trickle; the last 48 hours of the month are a thundering herd. Your capacity plan is dictated by the tail, your autoscaler reacts to the tail, and your SLO is defined by the tail.

We measured four statistics, but p95 drives every architectural decision below:

Table 1: Render latency, 3-page invoice, warm process

Puppeteer and Playwright are within 3% of each other — unsurprising, since they drive the same Blink engine over nearly identical CDP surfaces. Playwright's slightly higher overhead comes from its extra protocol layer and context management (browser.newContext() creates an isolated but heavier world than Puppeteer's createBrowserContext()). If you are choosing between them for PDF generation alone, you are choosing an ergonomics and operational tooling story, not a performance story.

Typst is 29× faster at p95 than Chromium. That is not a micro-optimization; it is a different computational category.

Table 2: Memory per page and per concurrent render

That last row is the most common production mistake we see: spawning a fresh browser per document. It costs ~290 MB and ~400 ms of startup per PDF and collapses your density from 45 concurrent renders to 10.

The Cost Model That Actually Matters

Here is the finding that surprises every platform team: marginal compute for 1M PDFs is single-digit dollars. 1M documents × 0.25 s of vCPU time is 69 vCPU-hours. At Fargate's $0.04048/vCPU-hour, that is $2.81.

Your invoice will not be $2.81, because raw compute was never the cost driver. The drivers are:

1. 24/7 warm-pool provisioning. You cannot scale to zero when your p95 SLO is sub-second and your cold start is 3–8 seconds.
2. Burst headroom. Month-end requires ~4× steady-state capacity, and you pay for it whether you use it or not.
3. Tail-driven overprovisioning. p99 for Chromium is 950 ms — nearly 4× p50 — so you size for tail, not mean.
4. Engineering and on-call. Zombie Chrome processes, OOM kills, and font regressions do not fix themselves.

Table 3: Realistic monthly run-rate at 1M documents/month

Model: 1M docs/month, 3-page fixture, peak burst 100 docs/s for 6 hours at month-end, 99.9% availability, 24/7 warm floor.

At 1M/month the delta between Typst ($300) and Chromium ($1,900) is $1,600/month — about $19k/year. That is real, but it is smaller than one senior engineer. The decision should be driven by expressiveness, correctness, and compliance, not by that line item. Where the delta becomes existential is at 100M/month, where it is $160k/year and the Chromium pool no longer fits in a single autoscaling group's comfort zone.

Production Code: Typed, Pooled, and Leak-Free

Playwright: browser reuse with guaranteed cleanup

The non-negotiable rules: reuse one Browser, create a fresh Context per document, and close both in a finally block. Disable JavaScript — an invoice template does not need it, and every millisecond of JS execution is latency plus attack surface.

import { chromium, type Browser, type BrowserContext, type Page } from 'playwright-core';

interface RenderOptions {
  html: string;
  timeoutMs?: number;
  signal?: AbortSignal;
}

export class InvoiceRenderer {
  private browser: Browser | null = null;

  private async getBrowser(): Promise<Browser> {
    if (this.browser?.isConnected()) return this.browser;
    this.browser = await chromium.launch({
      args: ['--no-sandbox', '--disable-gpu', '--disable-dev-shm-usage', '--font-render-hinting=none'],
      env: { ...process.env, FONTCONFIG_PATH: '/opt/fonts' }, // deterministic font resolution
    });
    return this.browser;
  }

  async render({ html, timeoutMs = 15_000, signal }: RenderOptions): Promise<Buffer> {
    const browser = await this.getBrowser();
    const context: BrowserContext = await browser.newContext({
      javaScriptEnabled: false,
      offline: true, // hard-fail any accidental remote asset fetch
    });
    const page: Page = await context.newPage();

    try {
      if (signal?.aborted) throw new Error('render aborted');
      await page.setContent(html, { waitUntil: 'load', timeout: timeoutMs });
      await page.evaluate(() => document.fonts.ready); // never skip this

      const pdf = await page.pdf({
        format: 'A4',
        printBackground: true,
        preferCSSPageSize: true,
        timeout: timeoutMs,
      });
      return Buffer.from(pdf);
    } finally {
      await page.close().catch(() => undefined);
      await context.close().catch(() => undefined);
    }
  }

  async shutdown(): Promise<void> {
    await this.browser?.close().catch(() => undefined);
    this.browser = null;
  }
}

Typst: compile a JSON-driven template with a typed contract

Typst inverts the model. Instead of styling DOM, you compile a document program. The template receives typed JSON, and the CLI invocation is bounded by a timeout.

#let data = json(read(sys.inputs.dataPath))
#set page(
  paper: "a4",
  margin: (x: 18mm, y: 16mm),
  footer: context align(center)[
    #set text(size: 7.5pt, fill: rgb("#6b7280"))
    Page #counter(page).display() of #counter(page).final().first()
  ],
)
#set text(font: ("Inter", "DejaVu Sans"), size: 9pt, lang: "en")

#table(
  columns: (1fr, 3fr, 1fr, 1fr, 1fr),
  inset: 6pt,
  stroke: (bottom: 0.5pt + rgb("#e5e7eb")),
  table.header([*#*], [*Description*], [*Qty*], [*Unit*], [*Amount*]),
  ..data.lines.map(l => (
    [#l.pos], [#l.description], [#l.qty],
    [#l.unit], [#l.amount],
  )).flatten(),
)

#align(right, text(weight: "bold")[Total: #data.total])

import { execFile } from 'node:child_process';
import { promisify } from 'node:util';
import { mkdtemp, writeFile, readFile, rm } from 'node:fs/promises';
import { tmpdir } from 'node:os';
import { join } from 'node:path';

const execFileAsync = promisify(execFile);

export async function renderInvoiceTypst(payload: InvoicePayload): Promise<Buffer> {
  const dir = await mkdtemp(join(tmpdir(), 'inv-'));
  const dataPath = join(dir, 'data.json');
  const outPath = join(dir, 'invoice.pdf');

  try {
    await writeFile(dataPath, JSON.stringify(payload), 'utf8');
    await execFileAsync(
      '/usr/local/bin/typst',
      [
        'compile',
        '--root', '/srv/templates',
        '--font-path', '/opt/fonts',
        '--input', `dataPath=${dataPath}`,
        '/srv/templates/invoice.typ',
        outPath,
      ],
      { timeout: 5_000, maxBuffer: 1024 * 1024 },
    );
    return await readFile(outPath);
  } finally {
    await rm(dir, { recursive: true, force: true });
  }
}

React-PDF: stream to object storage without buffering

React-PDF renders in-process, so heap growth is your only real failure mode. Never await renderToBuffer() inside a loop — stream straight into S3.

import { renderToStream } from '@react-pdf/renderer';
import { pipeline } from 'node:stream/promises';
import type { Writable } from 'node:stream';

export async function renderInvoiceReactPdf(
  invoice: InvoicePayload,
  sink: Writable,
): Promise<void> {
  const stream = await renderToStream(<InvoiceDocument data={invoice} />);
  await pipeline(stream, sink); // flat memory regardless of page count
}

Pitfalls That Cost Us Three Incidents

• `waitUntil: 'networkidle0'` is a latency tax. Inline your assets and use 'load'. We measured a 180 ms p50 regression from networkidle0 alone on the same fixture.
• Fonts are the #1 source of non-determinism. Chromium resolves fonts via fontconfig; a base image change can silently swap your typeface and break snapshot tests. Ship a locked /opt/fonts and pin FONTCONFIG_PATH.
• `page.close()` is not optional. Leaked pages are the mechanism behind almost every "Chrome container OOMs after 40 hours" postmortem.
• Never use `--single-process`. It looks like a density win; it is a crash amplifier that serializes your renders.
• Chromium PDF output is not byte-stable across versions. Snapshot tests must compare extracted text and layout geometry, not file hashes.
• Accessibility is a procurement blocker. Tagged PDF (tagged: true in Puppeteer/Playwright) gives you a partial PDF/UA story; React-PDF and Typst currently require post-processing or manual tagging. Budget remediation cost for regulated customers.

Decision Matrix

Operational Checklist Before You Ship

1. Inline all assets; assert zero outbound network in the render path.
2. Pin engine version, font set, and base image digest in the template service.
3. Alert on p95 and p99, never mean; also alert on renders/second drift.
4. Recycle the browser process every N renders (we use 5,000) as a leak backstop.
5. Load-test at 4× month-end peak with the real fixture, including the 60-line table.
6. Store rendered PDFs keyed by template hash + payload hash for idempotency.
7. Emit a per-render trace span with page count, byte size, and engine version.

Sources & Technical References

• Puppeteer — Page.pdf() API reference: https://pptr.dev/api/puppeteer.page.pdf
• Playwright — page.pdf() and browser context documentation: https://playwright.dev/docs/api/class-page#page-pdf
• Chrome for Developers — Headless mode architecture and flags: https://developer.chrome.com/docs/chromium/headless
• Typst — Official language and standard library reference: https://typst.app/docs/reference/
• Typst — CLI compile and --input documentation: https://typst.app/docs/reference/cli/
• React-PDF — Rendering and streaming API: https://react-pdf.org/
• W3C — CSS Paged Media Module Level 3: https://www.w3.org/TR/css-page-3/
• MDN — @page at-rule and print CSS: https://developer.mozilla.org/en-US/docs/Web/CSS/@page
• ISO 19005-2 — PDF/A-2 archival conformance: https://www.iso.org/standard/50655.html
• ISO 14289-1 — PDF/UA-1 universal accessibility: https://www.iso.org/standard/76186.html
• W3C — Web Content Accessibility Guidelines 2.2: https://www.w3.org/TR/WCAG22/
• AWS — Fargate vCPU and GB-hour pricing: https://aws.amazon.com/fargate/pricing/