2026-10-29
SVG 是文本而不是像素，所以压缩 SVG 改的是代码，不是画质。清掉编辑器留下的元数据、把坐标小数位收一收、删掉没被引用的 defs 内容，一个 180KB 的图标可以掉到 20KB 以内，肉眼看不出区别。弄错了代价更大：路径偏一个像素、渐变直接消失、动画卡在第一帧。这篇讲清楚哪些能删、哪个数字最关键、上线前怎么验。原理部分和位图的差别在 /blog/lossy-vs-lossless-compression 里讲过，SVG 属于完全无损那一侧。
导出设置是冗余的重灾区。Illustrator、Figma、Inkscape 默认会把编辑器信息写进文件，浏览器渲染时一个字节都不看。
判断标准只有一条：浏览器画这张图时用不到它，就可以删。不确定就留着，一个多余的 id 几十字节，删错了整张图就废了。
坐标精度是省字节的大头。多数导出默认给每个点写六位小数，收到两位之后，24 到 128 像素的图标在屏幕上没有可见差别，文件却小一大截。
同一份 300KB 的地图插画，六位小数改成两位通常能减掉三分之一。这个数字比删元数据有效得多，也更容易翻车，改完一定要看渲染结果。
一次性的活儿用第一种。目录里躺着几十个图标，用第二种。项目长期在改，用第三种，让工具替你记住这件事。
内容由脚本或后端动态改的文件不要过优化器，id 被改了就取不到节点。用户在编辑器里二次编辑的模板同理。已经跑过一遍 SVGO 的文件收益很小，通常只剩下 10% 到 20%，为这点体积承担风险不划算。
如果你的页面慢是因为图片体积，先确认瓶颈确实在 SVG 而不是位图，判断顺序在 /blog/image-compression-web-performance-guide。混合资源的处理思路见 /blog/compress-png-without-losing-quality。
不会。SVG 里没有像素数据，缩放依然清晰。真正会变的是几何形状：坐标被四舍五入之后，图形边界会移动不到一个像素的距离，曲线密集的图上这个位移偶尔能被看出来。
从设计软件直接导出的文件通常能减掉 40% 到 70%，因为编辑器元数据和六位小数占比很高。已经处理过的文件一般只剩 10% 到 20% 的余量。
不能像位图那样给一个目标值。位图可以靠调质量连续逼近目标大小，SVG 只能删掉离散的冗余内容，压到某个下限就没得删了。真有硬性上限的话，剩下的是简化路径或减少锚点，属于改设计，不是压缩。
默认配置偏保守，多数图标没问题。会出事的主要是这几个场景：文件带滤镜或蒙版、id 被外部 CSS 或 JS 引用、以及依赖 viewBox 之外的尺寸信息。这几类先备份再跑。