How I Load Test a PDF Generation API with k6, Docker, and GitHub Actions
The Problem with "It Works on My Machine" PDF generation is one of those deceptively expensive operations. You fire off a request, Puppeteer spins up a headless Chromium, renders a full HTML page, ...

Source: DEV Community
The Problem with "It Works on My Machine" PDF generation is one of those deceptively expensive operations. You fire off a request, Puppeteer spins up a headless Chromium, renders a full HTML page, and exports it to bytes. Works great in dev. Works great in staging with one user. Then someone puts it in production and a dozen concurrent requests land at once — and you discover your server is quietly crying. That was the situation with Templify, a PDF generation platform I built. The core API — POST /convert/{templateId} — compiles a Handlebars template and delegates to a job-runner service (Express + Puppeteer) to render the PDF. Each request is CPU-bound and takes 1–4 seconds depending on template complexity. Before confidently telling users the API handles concurrent load, I needed proof. Enter k6. Why k6 I've used Locust, JMeter, and Artillery. k6 wins on developer ergonomics: Test scripts are JavaScript — no YAML configs, no XML, no DSL to learn Built-in thresholds — define pass/fai