Mermaid.js 太慢了？Pele：零依赖、快 500 倍，用 CSS 变量换主题不用重渲染

10 月 16 日前后，一个叫 Pele 的开源项目登上了 Hacker News，拿下 460 分、41 条评论。它干的事很聚焦：把 Mermaid 语法直接渲染成 SVG。官网 pele.run 上摆着一张对比表，数字相当激进——包体积 gzip 后 230 kB（Mermaid.js 的 1.6 MB 的约六分之一），渲染 0.05 到 0.3 毫秒（号称快 500 倍），直接依赖 0 个（Mermaid.js 是 23 个）。先把丑话说在前面：这些数字全部是项目自报，官网没有说明测试条件，本文也没有独立验证。但 HN 评论区 460 个赞说明了一件事：Mermaid.js 的笨重，早就让很多人不耐烦了。

Pele 是为 Obsidian 开发的——"developed for Obsidian to render diagrams quickly and match your theme"（为 Obsidian 而造，为了快速渲染图表并匹配你的主题）。作者是 kepano（Obsidian CEO Steph Ango），仓库在 github.com/obsidianmd/pele。名字取自夏威夷神话里的火山与火焰女神 Pele。用法简单到只有两行：

npm install pele

import { render } from 'pele'; const { svg } = render(`flowchart LR A[Mermaid text] --> B[SVG]`);

把 Mermaid 文本丢给 render()，拿回 SVG 插进页面。项目自称支持 Mermaid 12.1.0 内置的全部图表类型。

对比表：先看数字，再谈怎么读

	Pele	Mermaid.js
包体积（gzip）	230 kB	1.6 MB
渲染时间	0.05–0.3 ms	6–82 ms
直接依赖	0	23
小屏	自适应布局	缩放图表
主题	CSS 变量	主题配置

（以上全部引自 pele.run，为项目自报，未独立验证。）

"500 倍"这个数字该怎么读？先做一道算术：0.05–0.3 毫秒对 6–82 毫秒，取各自区间的极端值，倍数从 20 倍到 1600 倍不等，"up to 500×"（最高 500 倍）是营销上最顺口的取法。HN 评论区和交叉报道里都有人提醒：官网没有说明测试的是什么图表、在什么设备上、怎么测的。yougonews 的报道写得很克制——"the website's comparison alone does not establish how Pele performs across different devices, diagram types or production workloads"（仅凭官网的对比，无法说明 Pele 在不同设备、图表类型和生产负载下的表现）。读这类数字的正确姿势是：把它当作"数量级"的信号，而不是实验室精度——即便打个对折，几十到上百倍的差距依然说明两边的实现根本不在一个重量级。

它为什么能快：取舍比优化更重要

Pele 快的真正原因不是把同一件事做得更精，而是把事情变小了。kepano 在 HN 评论区亲自解释了设计取舍："I designed Pele to only follow its syntax not its layout."（我设计 Pele 时只跟它的语法，不跟它的布局。）

这句话值得展开。Mermaid.js 的"重"，重在两处：一是它要兼容一个庞大的布局引擎体系——新版 Mermaid 12.1 已经内置了三个布局引擎；二是它依赖浏览器排版引擎做文本测量（比如 SVGGraphicsElement.getBBox()），这就是为什么 mermaid-cli（mmdc）渲染一张图要拖一个 Chromium 实例。HN 评论区里用户 bilibali 的吐槽很有代表性：他的静态网站构建脚本把 markdown 里的 mermaid 代码块换成渲染好的 SVG，"it is very heavy for this purpose (needs an entire chromium instance for the rendering)"（为这个目的实在太重了，渲染要起整个 Chromium 实例）。Pele 的取舍是：只实现 Mermaid 的语法解析，自己做轻量布局，直出 SVG，不依赖浏览器环境。语法兼容、布局自研——这就是"零依赖"和"0.05 毫秒"两个数字的共同来源。

从架构上看，Pele 做的减法很彻底。Mermaid.js 的渲染管线大致是：解析语法 → 布局引擎排布 → 依赖浏览器 DOM 测量文本 → 生成 SVG。每一步都在为"通用"付费：三个布局引擎要兼容，文本测量要调浏览器 API，23 个直接依赖里有相当一部分是为这些能力服务的。Pele 把管线压缩成：解析语法 → 自研轻量布局 → 直接拼 SVG 字符串。它不需要 DOM，不需要 Chromium，甚至不需要浏览器——纯计算。这就是 0.05 毫秒这个数字在物理上成立的原因：一次渲染的耗时，已经从"浏览器排版"量级掉到了"字符串拼接"量级。当然，这也意味着它的布局能力天花板由自研引擎决定，不再享受上游布局引擎生态的红利。

当然取舍就有代价。HN 上 lukeify 的抱怨是："Anytime I try mermaid for anything more complex than a toy diagram I always end up absolutely frustrated by the arcane and topologically poor layout."（只要图稍微复杂一点，Mermaid 那诡异的布局就让人抓狂。）kepano 的回应是官网有个 Compare 模式可以自己对比两种布局。自动布局本来就是图论里的著名难题（tptacek 在评论区补了一句："Graph layout is a famously hard problem!"），Pele 没有宣称解决它，只是换了一套自己的布局实现。有用户实测后表示反而更喜欢 Pele 的布局，也有人想要"图表视觉 diff"这种更进一步的功能——这些都是真实世界里的取舍回声。

对比表里还有一行容易被滑过去："小屏"——Pele 是"自适应布局"，Mermaid.js 是"缩放图表"。这两者的差异在手机上很直观：缩放是把整张图等比缩小，字跟着变小，最后谁也看不清；自适应布局是重新排布节点和连线，让图在小宽度下依然可读。对 Obsidian 这种移动端是主力场景之一的笔记软件，这不是锦上添花，是"图表在手机上能不能用"的区别。Pele 敢做自适应布局，恰恰因为它自研了布局引擎——布局和渲染都在自己手里，才谈得上按容器宽度重新排。

迁移成本是另一个实际问题。9dev 的经验是把文档站的图表从"mermaid + panzoom + 一些让集成样式和深色主题 work 的 workaround"整体迁过去，"Pele not only takes care of all of that, but also manages a nicer layout!"（Pele 不只搞定了所有这些，布局还更好看了！）bilibali 的静态站点构建脚本则是"当场换上"，并且"to my pleasant surprise I actually liked the ones Pele renders better than mermaidjs"（让我惊喜的是，Pele 渲染的布局我反而更喜欢）。当然也有反例的可能：nkmnz 就要求指出两种布局"系统性"的差异——这种较真恰恰是健康的：布局是主观体验，重写渲染器必然带来布局风格变化，接受之前先用 Compare 模式看三组自己最常用的图，比看 500 倍管用。

CSS 变量主题：为什么这是个优雅的设计

Pele 第二个值得讲的设计是主题机制。它不用 Mermaid 式的"主题配置对象"，而是用 CSS 变量：--pele-bg、--pele-fg、--pele-line 等等控制颜色和字体。换主题就是改几个变量的值，颜色即时生效，不需要重新渲染。

这个设计为什么优雅？因为它把"内容"和"表现"彻底解耦到了浏览器原生机制那一层。传统做法是：主题变化 → 重新跑一遍渲染管线 → 生成新 SVG。Pele 的做法是：渲染一次产出带 CSS 变量引用的 SVG，主题变化只是 CSS 层面的重绘，浏览器自己处理。对于深色模式/浅色模式切换这种高频操作，差异是"一次渲染"和"零次渲染"的区别。HN 用户 haburka 的感叹很真实："Theming mermaid and using it server side is such a nightmare."（给 Mermaid 换主题、在服务端用它，简直是噩梦。）而 9dev 已经把自己文档站的图表迁过去了："Pele not only takes care of all of that, but also manages a nicer layout!"

对 Obsidian 来说这个特性几乎是刚需：笔记软件的主题是用户随时切换的，图表必须跟着主题走。用 CSS 变量，图表主题就变成了应用主题的自然延伸，而不是另一套需要同步的配置。

为 Obsidian 而生：一个具体场景的形状

"developed for Obsidian to render diagrams quickly and match your theme"——官网这句自我介绍，信息量比看起来大。Obsidian 是个笔记软件，用户在里面写 Mermaid 图表是高频操作：打开笔记就要渲染，切主题图表必须跟着变，手机端和桌面端都要快。Mermaid.js 在这种场景下的三个痛点正好是 Pele 的三个卖点：包体积（笔记软件不能为图表功能背 1.6 MB）、渲染速度（打开笔记时的首屏体验）、主题同步（深色模式是笔记用户的刚需）。

还有一层是安全。HN 评论区里有人引用 kepano 的推文：Mermaid 最新版"has a questionable safety record (see CVEs)"（安全记录存疑，见 CVE 列表），Obsidian 1.13 不得不为 Mermaid 引入新的开关和警告。图表渲染器运行的是用户笔记里的代码——可能是从网上复制来的——XSS 面就藏在这里。一个零依赖、自研解析器的渲染器，至少在供应链和攻击面上比"23 个依赖 + 浏览器排版引擎"的方案更容易审计。这不是说 Pele 已经通过了安全审计（它没有宣称），而是说"为笔记软件而造"的定位，天然要求它在体积、速度、主题之外，还得把可审计性当回事。

从 HN 帖的维护状态也能看出这是个活项目：用户 kinduff 报告 playground 的 Mermaid 预览坏了，kepano 当天就回"Thanks! Investigating..."（谢谢！正在查……）。发布三天内作者还在修 bug，这种响应速度对"要不要把构建管线押上去"的决策者来说，是比 500 倍更有用的信号。

HN 评论区里的声音：热闹，但也有审慎

460 分的帖子评论区信息量很大，挑几条有代表性的。审慎派首先盯住数字：官网对比没有说明测试条件，"up to 500×"要打折扣看。工程派关心的是"无浏览器渲染"这个能力本身——nickmain 问：Mermaid 官方库是不是至今还需要完整的浏览器环境来做 SVG 布局？如果是，Pele 对"把 Mermaid 渲染嵌入别处"就是个好消息。已经有人把它用进了静态站点构建流程（bilibali 当场就换上了），也有人 fork 了同类的 Go 实现（go-mermaid）去做终端和 WASM 嵌入。

还有一条评论特别对 vibe coding 读者的胃口，来自 dbg31415："Tools like this are so amazing because they allow Claude to edit and draw and save to a single markdown file. So practical! Version control friendly."（这种工具之所以了不起，是因为它让 Claude 能编辑、画图、存成单个 markdown 文件。太实用了，对版本控制友好。）这句话点出了 Pele 这类工具在 agent 时代的位置：agent 输出的是文本（Mermaid 语法），文本进版本控制，渲染是确定性的、轻量的、可以在 CI 里跑的。Mermaid.js 需要 Chromium 的重量，在"agent 写文档 → CI 渲染图表"这条链路上是个实实在在的摩擦。

背景里还有一条暗线：Mermaid 项目本身正在转向 mermaid.ai，kepano 在评论区被引用的推文里说它"正在失去最初的愿景"，新版还因为安全记录问题（CVEs）让 Obsidian 不得不加警告开关。Pele 的出现，一半是技术重写，一半是对上游方向的投票。

给 vibe coding 读者的 takeaway

Pele 是个小项目，但它讲清楚了一个大道理：渲染器也值得被重写。当一条工具链里最重的一环（23 个依赖、1.6 MB、拖 Chromium）被换成 230 kB 零依赖的直出 SVG，受益的不只是加载速度，而是整个工作流的可能性——静态站点构建、CI 文档管线、agent 生成的图表，都从"能跑但很重"变成了"随手可用"。

什么时候该用它，什么时候不该？诚实的建议是：如果你要的是"把 Mermaid 语法快速变成能看的 SVG"，尤其是在构建脚本、文档站、笔记插件、CI 管线这种"无浏览器环境"里，Pele 几乎是当前最轻的选择；但如果你依赖 Mermaid 官方布局的像素级效果，或者用了 Mermaid 12.1.0 之外的实验性语法，先去官网的 Compare 模式（https://pele.run/playground）亲手对比一下布局差异——"只跟语法不跟布局"意味着同一份 Mermaid 文本在两边画出来可能不一样，这是设计取舍，不是 bug。评论区里 Ancapistani 就因为"子图保持自己的方向"这一个布局细节决定切换，也有人纯粹因为深色模式好用而留下——选型的理由越具体，越不容易被"500 倍"带偏。

读它的数字时记得打折（项目自报、测试条件未说明），用它的设计时记得它的取舍（只跟语法不跟布局）。以及，如果你也在用 matplotlib 生成静态图表（比如本站的发布流水线），Pele 代表的是另一条路："文本 → SVG"的声明式图表链路。在 agent 越来越多地直接输出 Mermaid 的今天，这条路值得占一个书签。

项目官网：https://pele.run/ ；GitHub：https://github.com/obsidianmd/pele ；HN 讨论帖：https://news.ycombinator.com/item?id=50132193 （约 2026 年 10 月 16 日发布，460 分、41 评论，提交者 dchest）。