Benchmark

Renderzeit-Benchmark

Vom Team von Dynamic Document API · Gemessen am 19. Oktober 2026 · Stand 19. Oktober 2026

Wie lange dauert es, aus HTML, Markdown oder einer Webseite ein PDF zu machen? Wir haben sechs alltägliche Dokumente je 100-mal über unsere Produktions-API in der EU gerendert und jedes Rendering mit drei Uhren gemessen: im Renderer, in der API und auf dem aufrufenden Rechner. Im Median brauchte eine einseitige Rechnung 124 ms im Renderer und 336 ms Ende zu Ende. Dokumente, Skript und Rohdaten sind öffentlich: Sie können jede Zahl prüfen und den Test selbst wiederholen.

Ergebnisse

Zeit im Renderer

total_ms: vom Einreihen des Auftrags bis zur gespeicherten Datei, gemessen vom Render-Worker. Diese Zahl nennen auch unsere Produktseiten.

Ende zu Ende, aus Sicht des Aufrufers

client_ms: vom Absenden der Anfrage bis zum letzten Byte der Datei auf einem Laptop in Deutschland. Die letzten beiden Spalten teilen den Median auf: was die API selbst beitrug (Authentifizierung, Prüfung, Übergabe des Auftrags, Zurückschicken der Datei) und was das Netzwerk beitrug (Hin- und Rückweg und der Download).

API und Netzwerk sind Mediane der Differenzen je Rendering, api_ms − total_ms und client_ms − api_ms. Mediane ergeben in der Summe nicht genau den Gesamtwert.

Wohin die Zeit geht

Der Renderer meldet für jeden Auftrag jede Stufe. Mediane in Millisekunden:

Vorlage: HTML oder Markdown mit den JSON-Daten füllen. Rendern: Chromium lädt die Seite, setzt sie und druckt sie. Abschluss: PDF aufräumen oder PNG kodieren. Speichern: die Datei in den Objektspeicher der Region schreiben. Die Summe enthält zusätzlich einige Millisekunden Übergabe zwischen den Stufen. Die Webseite als PDF hat außerdem 726 ms (aufsummiert) für das Laden ihrer Dateien gebraucht, parallel und innerhalb der Renderzeit.

Was die Zahlen zeigen

• Seiten sind günstig, jedes Rendering hat einen festen Anteil. Die zwanzigfache Seitenzahl dauerte 2,2-mal so lange: 124 ms für eine Seite, 200 ms für fünf, 276 ms für zwanzig. Jede weitere Seite kostete also etwa 8 ms. Der größte Teil eines Renderings ist unabhängig von der Länge: die Seite in Chromium laden, setzen, die Datei schreiben.
• Bei kleinen Dokumenten ist das Netzwerk der größte Teil der Wartezeit. Von den 336 ms, die der Aufrufer auf die Rechnung wartete, entfielen 124 ms auf den Renderer. Der Rest war die API (69 ms) und der Weg hin und zurück (120 ms). Ein Aufruf von einem Server nahe der Region verkürzt genau diesen Teil; die HTTPS-Verbindung hat dieser Benchmark bereits wiederverwendet.
• Ausreißer kommen aus dem Netzwerk, nicht aus dem Renderer. Im Renderer blieb p95 bei jedem Dokument unter dem 1,6-Fachen des Medians. Ende zu Ende lag p95 beim Bericht bei 1.380 ms gegenüber einem Median von 469 ms, weil einige Downloads langsam waren. Wer verlässliche Zeiten braucht, misst dort, wo der eigene Code läuft.
• Ein Bild ist nicht günstiger als ein PDF. Das PNG mit 1200 × 630 Pixeln brauchte 396 ms: ein pixelgenauer Screenshot, danach 54 ms PNG-Kodierung und eine Datei von 455 KB zum Speichern und Herunterladen.
• Eine Webseite ist so schnell wie die Seite selbst. Unsere eigene Startseite brauchte im Median 2,8 s: Chromium lädt Schriften, Bilder und Skripte und wartet, bis die Seite zur Ruhe kommt. Wenn Sie den Inhalt selbst haben, ist das HTML zu schicken deutlich schneller als die URL.
• Keine Warteschlange bei dieser Last. Mit einem Rendering nach dem anderen hat ein Renderer jeden Auftrag bei p95 innerhalb von 9 ms übernommen. Wie sich die Wartezeit verhält, wenn viele Renderings gleichzeitig kommen, ist ein anderer Test (siehe Grenzen unten).
• Die Vorlage ist nicht der Engpass. Eine Vorlage mit 128 Tabellenzeilen oder 38 Produkten zu füllen, dauerte im Median höchstens 2 ms.
• Wiederholungen einplanen. Bei 2 von 600 Anfragen brach die Verbindung ab, bevor eine Antwort kam. Schicken Sie mit jedem Rendering einen Idempotency-Key und wiederholen Sie bei Netzwerkfehlern: Die Wiederholung liefert dann das erste Ergebnis, statt ein zweites Mal zu rendern.

So haben wir gemessen

Die Dokumente

Jedes Dokument bringt alles, was es braucht, in der Anfrage mit: keine externen Schriften, Bilder oder Stylesheets. Ausnahme ist die Webseite als PDF, die die Seite lädt wie ein Browser. Alle Namen und Zahlen in den Beispieldaten sind erfunden.

Der Ablauf

• Eins nach dem anderen. Jedes Rendering war ein synchrones POST /v1/renders mit delivery.type = binary, die Antwort war also die Datei selbst. Die nächste Anfrage startete erst, wenn die vorige zurück war, und frühestens 3 Sekunden nach deren Start.
• Gemischt. Jede Runde renderte alle sechs Dokumente einmal, in einer je Runde neu gemischten Reihenfolge. Eine langsame Minute traf so alle Dokumente gleich. Die ersten beiden Runden dienten zum Aufwärmen und zählen nicht mit.
• Eindeutige Anfragen. Jede Anfrage hatte einen eigenen Idempotency-Key und einen eindeutigen Wert in den Daten. Nichts kam aus einem Cache.
• Eine wiederverwendete Verbindung. Eine HTTPS-Verbindung blieb offen, wie bei einem dauerhaft laufenden Dienst. Ein einfacher authentifizierter API-Aufruf (GET /v1/renders?limit=1) dauerte vom Laptop aus 107–123 ms: die Untergrenze jeder Ende-zu-Ende-Zeit.
• Drei Uhren. client_ms auf dem Laptop, api_ms aus dem Server-Timing-Header der API, total_ms und die Stufen aus dem Render-Datensatz (GET /v1/renders/{id}).
• Perzentile sind lineare Interpolationen zwischen den nächsten Rängen (Pythons statistics.quantiles, Methode „inclusive“, wie der Standard von NumPy), gerundet auf ganze Millisekunden.
• Wann: 19. Oktober 2026, 14:33–15:05 Uhr (MESZ), Engine 2026.4 (Chrome 153.0.8010.47), mit Live-Schlüssel: kein Wasserzeichen, jedes Rendering zählte auf unseren eigenen Tarif.

Was dieser Benchmark nicht zeigt

• Verhalten unter Last. Ein Aufrufer, ein Rendering nach dem anderen. Viele gleichzeitige Renderings können länger auf einen Renderer warten. Dafür gibt es Lasttests, und das hier ist keiner.
• Ihr Netzwerk. Die Ende-zu-Ende-Zeiten stammen von einem Laptop in Deutschland während einer halben Stunde. Von einem anderen Kontinent oder über Mobilfunk ist der Netzwerkanteil größer.
• Ihre Dokumente. Große externe Bilder, Webfonts oder langsame Skripte machen das Rendern langsamer. Die sechs Dokumente hier sind typisch, aber nicht vollständig.
• Andere Dienste. Wir haben nur unsere eigene API gemessen. Messungen anderer Anbieter veröffentlichen wir nicht, weil wir sie nicht unter denselben Bedingungen ausführen könnten.
• Die Zukunft. Das sind die Zahlen der Engine 2026.4. Wir wollen den Lauf mit neuen Engine-Versionen wiederholen und führen jeden Lauf unten auf.

Unsere Produktseiten nennen einen Median von 216 ms. Diese Zahl ist der Median über 1.664 erfolgreiche Renderings auf Engine 2026.4, eine Mischung verschiedener Dokumente. Dieser Benchmark legt stattdessen die Dokumente fest, damit Sie sehen, wie die Zeit vom Dokument abhängt.

Selbst ausführen

Das Skript braucht Python 3.9 oder neuer und sonst nichts. Laden Sie es mit den sechs Dokumenten herunter, entpacken Sie es und starten Sie es mit einem API-Schlüssel Ihres Workspaces. Der Schlüssel wird ohne Anzeige abgefragt oder aus DYNAMIC_DOCUMENT_API_KEY gelesen und nirgends gespeichert.

python3 render_time.py check --out check          # 6 Renderings, Dateien zum Ansehen
python3 render_time.py run --rounds 100 --client "Ihr Laptop, Ihre Stadt"
python3 render_time.py report results/*.csv

Ein Lauf mit 100 Runden macht samt Aufwärmen 612 Renderings. Mit einem Live-Schlüssel zählen sie auf Ihren Tarif. Ein kostenloser Test-Schlüssel geht auch, setzt aber ein Wasserzeichen (etwas mehr Zeit im Abschluss) und ist im Free-Tarif auf 10 Renderings pro Minute begrenzt. Der Lauf dauert dann etwa 70 Minuten.

Häufige Fragen

Daten, Diagramm und Zitat

• Rohdaten (CSV, 600 Renderings): eine Zeile je Rendering mit allen drei Uhren und allen Stufen
• Zusammenfassung (JSON): Perzentile je Dokument
• Diagramm (SVG)
• Skript und Dokumente (ZIP)
• Diese Seite als Markdown (Englisch), für Sprachmodelle und eigene Notizen

Daten und Diagramm stehen unter CC BY 4.0: Verwenden Sie sie in eigenen Artikeln, Vergleichen und Präsentationen, solange Sie Dynamic Document API nennen und auf diese Seite verlinken. Ein Vorschlag zum Zitieren:

Dynamic Document API (2026). Renderzeit-Benchmark, Oktober 2026. https://dynamicdocumentapi.com/de/benchmarks/renderzeit/

Läufe

Fragen zur Methode, oder ein Dokument, das wir messen sollen? Schreiben Sie an support@dynamicdocumentapi.com.