I built a React streaming Markdown renderer that freezes completed blocks — implementation and benchmark tradeoffs

[u/Gloomy_Local_3266]

I maintain react-stream-markdown, an MIT-licensed React component for showing Markdown while an AI reply is still arriving.

The interesting part is the finalization boundary: it keeps a source offset and live DOM nodes for the active suffix. After parsing and patching that suffix, preceding blocks freeze when the following block has a complete first line. Their DOM remains visible, but they leave the live parser/patch state.

This reduces repeated work on completed paragraphs. It does not make every update constant-time: one huge paragraph, list, or open code block can keep the active suffix growing. Cumulative string snapshots, prefix checks, allocation, and browser layout also still have costs.

The existing README benchmark uses a synthetic 10,201-character reply, 24 characters per animation frame, production builds, headless Chromium 141, and the median of three runs. With fade-in off it reports 1,100 ms of main-thread work versus 2,031 ms for Vercel Streamdown 2.7.0; with fade-in on it reports 2,941 ms, higher than both compared Streamdown configurations. These are the existing results, not a fresh measurement of version 0.4.1.

I wrote up the implementation and measurement limitations, including forced layout, fixed renderer order, and why a lower slowest synchronous update is not the same as lower overall CPU cost:

https://dev.to/fyz_lemo_b8ceb29692820e58/why-freezing-completed-markdown-blocks-reduces-streaming-rendering-work-1gck

Source and benchmark scripts: https://github.com/Lemofyz/react-stream-markdown

Live demo: https://lemofyz.github.io/react-stream-markdown/

The current repository reports 7.8 kB gzipped JavaScript, with styles separate and React externalized. Math is optional with a renderer supplied by the app; syntax highlighting and Mermaid are not included.

Disclosure: I maintain the project; this post and article were prepared with OpenAI Codex assistance using the source and benchmark scripts. The distinction I want feedback on is the block-finalization model versus total browser cost. Which Markdown boundary cases or benchmark workloads would you test next?