Benchmark

Render-time benchmark

By the Dynamic Document API team · Measured on 19 October 2026 · Last updated 19 October 2026

How long does it take to turn HTML, Markdown or a web page into a PDF? We rendered six everyday documents 100 times each against our production API in the EU and timed every render on three clocks: in the renderer, in the API and on the calling machine. At the median, a one-page invoice took 124 ms in the renderer and 336 ms end to end. The documents, the script and the raw data are public, so you can check every number and run the test yourself.

Results

Time in the renderer

total_ms: from the moment the job is queued until the finished file is stored, measured by the render worker. This is the number our product pages quote.

End to end, as the caller saw it

client_ms: from sending the request until the last byte of the file arrived on a laptop in Germany. The last two columns split the median: what the API itself added (authentication, validation, handing the job over, streaming the file back) and what the network added (round trips and the download).

API and network are medians of the per-render differences api_ms − total_ms and client_ms − api_ms. Medians do not add up exactly.

Where the time goes

The renderer reports each stage of every job. Medians in milliseconds:

Template: filling the HTML or Markdown with the JSON data. Rendering: Chromium loading, laying out and printing the page. Finishing: PDF clean-up or PNG encoding. Storage: writing the file to object storage in the region. The total also holds a few milliseconds of hand-over between the stages. The web page capture additionally spent 726 ms (summed) on fetching the page's assets, in parallel and inside its rendering time.

What the numbers say

• Pages are cheap; each render has a fixed part. Twenty times the pages took 2.2 times as long: 124 ms for one page, 200 ms for five, 276 ms for twenty, so each further page added about 8 ms. Most of a render is the same work whatever the length: loading the page in Chromium, laying it out, writing the file.
• For small documents, the network is the largest part of the wait. Of the 336 ms the caller waited for the invoice, the renderer accounted for 124 ms. The rest was the API (69 ms) and the way there and back (120 ms). Calling from a server close to the region shortens exactly that part; this benchmark already reused its HTTPS connection.
• The tail comes from the network, not the renderer. In the renderer, p95 stayed within 1.6 times the median for every document. End to end, the report's p95 was 1,380 ms against a median of 469 ms, because a few downloads were slow. If you need predictable times, measure close to where your code runs.
• An image is not cheaper than a PDF. The 1200 × 630 PNG took 396 ms: a pixel-exact screenshot, then 54 ms of PNG encoding, and a 455 KB file to store and download.
• A web page capture is as fast as the page. Rendering our own homepage took 2.8 s at the median: Chromium loads its fonts, images and scripts and waits for the page to settle. When you control the content, sending the HTML is much faster than sending its URL.
• No queueing at this load. With one render at a time, a renderer picked up every job within 9 ms at p95. How queue time behaves when many renders arrive at once is a different test (see the limits below).
• Templating is not the bottleneck. Filling a template with 128 table rows or 38 products took 2 ms or less at the median.
• Plan for retries. 2 of 600 requests lost their connection before a response arrived. Send an Idempotency-Key with every render and retry on network errors: a retried request then returns the first result instead of rendering twice.

How we measured

The documents

Every document carries everything it needs in the request: no remote fonts, images or stylesheets, except the web page capture, which loads the page the way a browser does. All names and figures in the sample data are invented.

The procedure

• One at a time. Each render was a synchronous POST /v1/renders with delivery.type = binary, so the response was the file itself. The next request started only after the previous one had returned, and at least 3 seconds after it started.
• Interleaved. Each round rendered all six documents once, in an order shuffled per round, so a slow minute affected every document alike. The first two rounds warmed up and are not counted.
• Unique requests. Every request had its own Idempotency-Key and a unique value in its data, so nothing was answered from a cache.
• A reused connection. One HTTPS connection was kept alive, as a long-running service would do. A plain authenticated API call (GET /v1/renders?limit=1) took 107–123 ms from the laptop: the floor under every end-to-end number.
• Three clocks. client_ms on the laptop; api_ms from the API's Server-Timing header; total_ms and the stages from the render record (GET /v1/renders/{id}).
• Percentiles are linear interpolations between the closest ranks (Python's statistics.quantiles, inclusive method, the same as NumPy's default), rounded to whole milliseconds.
• When: 19 October 2026, 12:33–13:05 UTC, engine 2026.4 (Chrome 153.0.8010.47), with a live key: no watermark, and every render counted towards our own plan.

What this benchmark does not show

• Behaviour under load. One caller, one render at a time. Many concurrent renders can wait longer for a renderer; that is what load tests are for, and this is not one.
• Your network. End-to-end times are from one laptop in Germany during one half hour. From another continent, or over mobile data, the network share is larger.
• Your documents. Large remote images, web fonts or slow scripts make rendering slower. The six documents here are typical, not exhaustive.
• Other services. We measured only our own API. We do not publish measurements of other vendors, because we could not run them under the same conditions.
• The future. These are the numbers of engine 2026.4. We plan to repeat the run on new engine versions and list every run below.

Our product pages quote a median of 216 ms. That figure is the median over 1,664 successful renders on engine 2026.4, a mix of different documents. This benchmark fixes the documents instead, so you can see how the time depends on the document.

Run it yourself

The script needs Python 3.9 or newer and nothing else. Download it with the six documents, unpack it and run it with an API key of your workspace. The key is asked for without echoing it, or read from DYNAMIC_DOCUMENT_API_KEY; it is not written anywhere.

python3 render_time.py check --out check          # 6 renders, files saved for a look
python3 render_time.py run --rounds 100 --client "your laptop, your city"
python3 render_time.py report results/*.csv

A run of 100 rounds makes 612 renders including the warm-up. With a live key they count towards your plan; a free test key works too, but adds a watermark (a little extra finishing time) and is limited to 10 renders a minute on the Free plan, so the run takes about 70 minutes.

Questions

Data, chart and citation

• Raw data (CSV, 600 renders): one row per render with all three clocks and every stage
• Summary (JSON): percentiles per document
• Chart (SVG)
• Script and documents (ZIP)
• This page as Markdown, for language models and your own notes

The data and the chart are licensed under CC BY 4.0: use them in your own articles, comparisons and slides, as long as you name Dynamic Document API and link to this page. A suggested citation:

Dynamic Document API (2026). Render-time benchmark, October 2026. https://dynamicdocumentapi.com/benchmarks/render-time/

Runs

Questions about the method, or a document you would like to see measured? Write to support@dynamicdocumentapi.com.