压缩 SVG - 并看清每一个字节去了哪里

这完全取决于文件从哪里来，其影响远大于画的是什么。我们测了四个：一个 Illustrator 风格的导出从 1,091 字节降到 401 字节，小了 63%。一个 Figma 风格的导出从 730 降到 525，小了 28%。Lucide 的下载图标只有 4%，我们自己的站点徽标更是只有 2%。

因为它在到我们手里之前就已经优化过了。那个 Lucide 文件是 291 字节的纯几何数据，没有注释、没有元数据、没有编辑器属性，坐标也很短 - 优化器根本找不到任何能在不改变画面的前提下删掉的东西。好的图标库交付的文件本来就已经贴着下限。

在那个 Illustrator 导出上：删除元数据块省了 216 字节，坐标取整省 131，注释省 94，默认属性省 61，未使用的定义省 51，XML 声明省 38，转换 style 属性省 29。而在 Figma 导出上情况完全不同 - 省下的 205 字节中，有 141 字节仅仅来自未使用的定义。

因为它导出的是自己内部使用的图层结构。画框和图层名会变成没有任何东西引用的 id 属性，而为画板定义的剪切路径和渐变，也常常残留在一个根本不指向它们的文件里。这些 id 在文件里就是死重量，删掉它们是 Figma 导出上单项最大的收益。

几乎总是安全的，但有一个例外值得知道。我们只删除文件里没有任何东西引用的 id，并且会检查 url(#…) 的值、href 属性以及 <style> 内部的 CSS。我们看不到的是你页面上针对那个 id 的外部 CSS 或 JavaScript - 如果你从外部给一个内联 SVG 设样式或写脚本，请关掉这一步。

通常不该，这也是它成为唯一默认关闭的那一步的原因。<title> 是图形的无障碍名称：屏幕阅读器念出的就是它，没有它，这张图对任何没在看屏幕的人来说就是匿名的。而节省通常只有几十个字节，这笔交易并不划算。

对普通图稿而言，三位小数不会。在一个 24 单位的图标上，三位小数相当于其宽度的约四万分之一，任何显示器或打印机都显示不出来。如果在很小的 viewBox 上把滑块拉到零位小数，你会看到形状发生跳变 - 每个文件旁边的预览正是为了抓住这种情况。

有两条途径。每个文件都并排显示优化前后的缩略图；此外我们的测试套件会把若干真实导出文件的两个版本都栅格化，逐像素比较，最多只允许几级抗锯齿偏移。任何会改变画面的步骤，在发布之前就会在这项比较中被拦下。

它的浏览器打包版会拖进一整棵 CSS 解析器和一套我们只会用到十分之一的插件架构，而这些会落到每一位访问本页的用户头上。这里的实现只包含在真实场景中带来大部分收益的那些步骤，别的一概没有，所以整个优化器只在你放入文件时才下载。

会，而且这一步不是可选的。脚本、事件处理器、远程图片引用和外部样式表导入都会从每个文件中剥离，面板会列出它找到了什么。这一点在这里比在我们其他 SVG 工具里更重要，因为这个工具会把源码交还给你，去粘贴进你自己的页面。

有，只是差距会缩小。你的服务器几乎必然会在传输时对 SVG 做 gzip 或 brotli，而压缩确实很擅长处理重复的缩进。它做不到的是删掉一个 216 字节的元数据块，或者缩短八位小数的坐标 - 那些内容仍然要被压缩和解压，在传输中仍然要花掉字节。