Streaming Benchmarks

This page holds the technical details behind the plain-language claims on the Svelte Streamdown comparison and the LLM Streaming guide. If you only want the summary: on most content Svelte Markdown does less work per frame, on a single open code block, on citation-heavy text, and on HTML blocks Svelte Streamdown does less, and every number below can be reproduced from the repository.

What is measured

Main-thread work per animation frame, in milliseconds. For each frame the harness adds up:

1. The time spent synchronously when the content changes.
2. The time spent in deferred work before the next frame renders.
3. A forced style and layout pass, so the cost of the DOM a renderer produced is charged to that renderer.

A frame that takes longer than 16.7 ms cannot be shown at 60 frames per second; those are counted as frames over budget.

Wall-clock time is deliberately not the metric. A renderer that defers work to the next frame looks instant if you only time the content assignment, and any per-frame measurement collapses to the display’s frame period if you time the whole frame.

How it is measured

Two safeguards keep the numbers honest:

• Parity check. Every 25 frames and at the end, the streamed token tree is compared field by field with a fresh one-shot parse of the same text. All 210 runs reported zero mismatches.
• No double counting. When a frame overruns, the next frame’s window starts where the previous one ended.

Results

Median of five iterations. Ranges span the two suites. The ratio is their total work divided by ours, so a value above 1 means Svelte Markdown did less work.

Page weight

Element counts at the end of each stream, identical across all runs:

Caveats

• Citations are not a like-for-like comparison. Svelte Streamdown rendered none of the reference-style links in that document; Svelte Markdown rendered 258. Resolving them is part of our cost.
• HTML blocks are not a like-for-like comparison. By default Svelte Streamdown shows raw HTML as plain text, and the benchmark keeps that default. It builds none of the <div> and <details> elements that Svelte Markdown renders.
• Some documents are parsed in full on every update. This trades speed for correct output. It applies to documents with Windows line endings (\r\n), and to documents that currently end inside an unfinished HTML tag, comment, or element. The HTML blocks row above includes this cost.
• Code fences differ in structure. Svelte Streamdown wraps every line in its own element. Svelte Markdown emits one text node per line with no wrapper elements.
• Large documents include a full layout every frame. The harness forces a layout of the whole document each frame, which both renderers pay. At 384 KB that pass is most of the frame. Svelte Markdown’s own parsing and rendering work stays nearly flat: about 1.4 ms per frame at 24 KB and 1.9 ms at 384 KB.
• Milliseconds are machine-specific. The ratios are the claim. Absolute totals moved by tens of percent between captures on the same machine.
• One workload family. Cumulative string updates at a fixed rate. Your transport, content, and device will differ.

Where the time goes

One traced run per scenario, Svelte Markdown only, in milliseconds per frame:

An open list is re-lexed in full on every frame by design, which is why parsing dominates there.

Reproduce it

pnpm build
pnpm preview --host 127.0.0.1 --port 4173 --strictPort

# in another shell
STREAM_COMPARE_URL=http://127.0.0.1:4173/test/stream-compare pnpm perf:stream-compare

pnpm build
pnpm preview --host 127.0.0.1 --port 4173 --strictPort

# in another shell
STREAM_COMPARE_URL=http://127.0.0.1:4173/test/stream-compare pnpm perf:stream-compare

Useful options:

node scripts/stream-compare-attribute.mjs records a browser trace and CPU profile for one scenario and prints the per-frame breakdown.

The raw logs, JSON, and per-change A/B results are archived in the repository under .agents/.plans-closed/stream-vs-streamdown/evidence/.

Related

• Svelte Streamdown vs Svelte Markdown
• LLM Streaming
• Headless Parser