SVG 压缩

SVG 到底胖在哪里

SVG 是 XML 文本，不是像素阵列。这一个事实决定了它的优化思路跟图片完全不同：没有量化表，没有色彩抽样，没有"质量滑块"。让 SVG 变大的，几乎总是那些对画面毫无影响的字符。

一份典型导出文件里的重量分布

随便打开一个从设计软件导出的图标，按占字节多少大致是这么排的：

• 编辑器元数据。 <metadata> 块、RDF 描述、<title> 和 <desc>——里面装的往往是图层名，不是读屏软件真正需要的描述。
• 私有命名空间。 Inkscape 会写 inkscape:*，老工具会写 sodipodi:*，Adobe 家各有各的。这些对渲染毫无作用。
• 坐标精度过剩。 一个坐标写成 12.345678901234，和写成 12.346，在你手头任何一块屏幕上渲染结果一模一样。每个坐标多六位小数，乘以上千个坐标，就是实打实的体积。
• 缩进和换行。 排版漂亮的 XML 是为人的眼睛服务的，而上线之后没有人会去看它。
• 空分组和没用的 defs。 空的 <g></g> 包裹层、没有被任何元素引用的渐变、谁也没用上的裁剪路径。

以上没有一项属于"画质"。清掉它们不属于有损压缩——渲染结果逐像素相同，所以 SVG 精简经常能砍掉两位数的体积，而画面一点变化都没有。

服务器都开 gzip 了，还有必要吗

这个问题问得对。既然 Brotli 已经在传输层压过了，源文件大小还重要吗？三个理由说明它仍然重要：

第一，解析开销。浏览器得从这段 XML 构建 DOM。节点更少、属性字符串更短，主线程干的活就少——这个差异在低端手机上会先于传输体积图表暴露出来。

第二，内联场景。把 SVG 粘进 HTML 或 CSS 的 url() 之后，它就不再被单独压缩了，而是成为文档的一部分；某些构建流程还会对它再做一次 base64，那样每多一个源字节就要付出 1.37 个输出字节。

第三，可维护性。3 KB 的 SVG，人还愿意打开看一眼顺手改；40 KB 的那个，就是一团没人敢碰的糊状物。

每个选项的风险在哪

删除注释。 安全。注释不参与渲染。唯一的例外是有人用注释当构建标记——很罕见，而且你如果这么干了，你自己一定知道。

删除 metadata / title / desc。 装饰性图形安全，有意义的图形要想一想。<title> 是辅助技术朗读 SVG 时念出来的内容。如果你的图标已经有 aria-label、或者本身标了 aria-hidden，删掉毫无损失。但如果这个 SVG 本身就是内容——一张图表、一个示意图——那就留着。

坐标取整。 保留 2–3 位小数，对任何屏幕分辨率下的显示都安全。降到 1 位，在放大到很大尺寸时可能出现亚像素偏移。一个 24 px 的图标，其实保留 1 位都算奢侈。

压缩空白。 安全，但有个历史坑：当 SVG 内联在 HTML 里并继承文本流时，行内元素之间的空白会影响排版。只删除标签之间空白、不动 <text> 内容内部的空白，就可以绕开这个坑。

这个工具刻意不做的事

它不会把描边转成路径，不会合并路径，不会简化曲线。这些操作确实能进一步瘦身，但它们改变几何形状，可能让渲染结果出现你得用眼睛比对才能发现的偏移，还可能破坏基于 stroke 的动画。如果你需要这个层级的优化，请放到专门的构建步骤里做，并且能对着图做视觉 diff。

它也绝对不会动你的 viewBox——这点值得单独说清楚，因为删掉 viewBox 是"优化 SVG"最常见的翻车方式，一删完图形就不自适应了。

怎么验结果

两个检查，各十秒钟：把原文件和精简后的文件在两个标签页里并排打开，同一缩放比例下来回切换——任何几何变化都会以"图形动了一下"的形式跳出来。然后把两个文件都拖进浏览器，缩放窗口，确认精简版仍然跟着缩放，这就证明 viewBox 还在。