One mermaid fence adds ~3.57 MB: full runtime inlined for a three-line diagram

[bitgorust]

Summary

A page that contains one Mermaid fence is about 136 times larger than the same page
without it. The Mermaid runtime is inlined in full, so a three-line diagram costs about
3.57 MB.

Measurement

Each source is minimal frontmatter plus one block. Rendered with 0.14.4:

Source	Rendered size
paragraph only	26,425 bytes
one stats fence	26,494 bytes
one mermaid fence, graph LR\n A-->B	3,592,529 bytes

printf -- '---\ntitle: One Diagram Page\n---\n\n```mermaid\ngraph LR\n  A-->B\n```\n' > mer.md
npx opencode-artifacts@0.14.4 render mer.md -o out.html
wc -c out.html

Why it matters

Architecture pages are exactly the pages that carry a diagram, so the cost lands on the
most common structural artifact. A 3.5 MB local file is tolerable. The same page over
GitHub Pages or a Workers KV deploy is not, and the KV value-size ceiling is a real limit
for pages that add a second runtime.

The inlining itself is correct given the strict-CSP, no-external-request guarantee. The
issue is that the full bundle ships when a small subset is used.

Possible directions

1. Register only the diagram types present in the source, using Mermaid's per-diagram
   registration rather than the full bundle.
2. Pre-render static diagrams to inline SVG at publish time and drop the runtime for pages
   with no interactive diagram.
3. Offer an opt-in runtime: external frontmatter value for deploy targets where a CDN
   fetch is acceptable, keeping inline as the default.

Option 2 also removes the current failure mode where a Mermaid syntax error is only visible
at view time, after publish.

Environment

opencode-artifacts 0.14.4, Node v24.19.0, OpenCode 1.18.9, macOS 25.5.0.