SVG优化器（SVGO）是一个流行的开源工具，用于压缩SVG文件。它的工作原理是 "安全地删除编辑元数据、注释、隐藏元素，[以及]默认或非最佳值"。从Github的依赖性数字来看，SVGO是一个相当广泛使用的工具，被用于460万个存储库。作为参考，React在700万个存储库中使用。
SVGO是一个维护良好的项目，在大多数情况下，它可以安全地删除所有不必要的字符。然而，尽管它有助于减轻页面重量，但最终重要的是它是否能对性能产生明显的影响。这正是Lighthouse优先考虑 首次有意义绘制（FMP）、首次有内容绘制（FCP）和最大有内容绘制（LCP）等指标的原因，而不是静态资产的大小和请求的数量。
我们需要问的问题是：SVGO是否真的对性能产生了明显的影响？让我们来看看细节。
SVGO可以节省多少字节？
SVGO所节省的字节数在很大程度上取决于它所解析的文件以及文件的创建方式。在某些情况下，它可能会以较低的个位数百分比减少文件大小，而在某些情况下，这一数字可能高达90%。它对用Sketch和Adobe Illustrator等工具创建的矢量文件特别有效，这些工具有非常精确的数值、空格、长名称和注释。
为了对它进行测试，我在各种SVG包上试用了SVGO，并比较了在SVGO的标准默认值下进行最小化之前和之后的文件大小。如果你感兴趣，你可以查看我的分析的原始数据。
Flagkit
Flagkit是一个用Sketch创建的国家旗帜的SVG图标集。正如我们前面所说，SVGO对用这个工具导出的文件非常有效。
在对该组的所有图标运行SVGO之后，下面是压缩百分比的分布情况。
Flagkit的压缩百分比分布
平均而言，SVGO将文件的大小减少了54.8%。累计起来，对于所有的文件，它节省了大约446kB，或者说56%。如果我们要在我们的应用程序中使用FlagKit的所有图标，使用SVGO可以节省略低于半兆字节的空间。
插图
让我们对更大的东西做一个类似的分析。Illlustrations是一个美丽的SVG插图包，由Vijay Verma用Adobe Illustrator设计。
Illlustrations中的压缩百分比分布
与Flagkit相比，其压缩率并不突出，但这是意料之中的，因为这个包中的SVG文件要大得多。在这种情况下，SVGO平均节省了约24.2%，累计节省了824kB，即23.7%。
世界地图（高清
最后，我们来试试一个大的SVG文件。来自amCharts的一张高清世界矢量地图的大小约为1.3MB。
在这里，SVGO将文件大小减少到880kB，节省了大约420kB，即31.5%。
总的来说
未压缩和压缩后的文件包之间的节省量为。
- FlagKit。
- 未压缩的=793kB
- 最小化 = 346kB
- 节省=447kB
- 插图。
- 未压缩的=3.4MB
- 最小化 = 2.6MB
- 节约 = 805kB
- 世界地图。
- 未加密 = 1.3MB
- 最小化 = 880kB
- 节省 = 420kB
缺少的组件。压缩
你可能已经注意到，我们缺少了上面的一个关键步骤：压缩。互联网上的大多数静态资产和HTML页面都是使用GZIP压缩来传递的。根据W3 Techs的数据，更有效的brotli算法已经被30%的网站使用。这两种压缩算法都能够大大减少静态资产的大小。
因此，我们应该比较压缩后的前后文件大小。在本节中，我将检查通过Cloudflare CDN提供的已压缩和未压缩的文件包的大小。
注意：根据我的观察，Cloudflare CDN默认使用Brotli 3级压缩，与最大的11级压缩相比，这是很差的，但对于测试最终的文件大小来说，仍然足够好。如果你的CDN使用最好的可用压缩，大小的差异会更小。
下面是压缩后的捆绑物大小的区别（我使用的是工具 [brotli-size-cli](https://github.com/andrewiggins/brotli-size-cli)):
- Flagkit:
- 未压缩 + brotli-3 = 127kB
- 最小化+brotli-3 = 55kB
- 节省=72kB
- 插图:
- 未压缩 + brotli-3 = 592kB
- 最小化+brotli-3 = 470kB
- 储蓄=122kB
- 世界地图。
- 未净化的 + brotli-3 = 503kB
- 最小化+brotli-3=370kB
- 节省=132kB
正如我们所看到的，大小的差异要大得多。现在让我们看看这在网络性能方面意味着什么。
在应用中测试我们的发现
在我们的实验中，我们将尝试一次性加载所有这些文件，看看这个差异有多大。
我使用了 [svg-sprite](https://github.com/svg-sprite/svg-sprite)将我们所有的SVG捆绑成CSS sprites，以避免多次请求影响速度数据。我把这些精灵作为一个npm包上传，命名为 [test-svgo](https://unpkg.com/browse/test-svgo@latest/)并使用unpkg.com CDN为其提供服务。因此，所有文件都是通过Cloudflare CDN测试的，与你在生产环境中提供文件的方式相似。
对于其性能审计，谷歌灯塔，可以说是最流行的性能评分工具，使用1.6 Mbps↑/750Kbps↓节流连接，这代表了4G的底部25%和3G连接的顶部25%。这相当于谷歌浏览器DevTools中的快速3G模式。我在同一模式下测试了所有三个捆绑软件，并记录了下载它们所需的时间。以下是结果。
- Flagkit:
- 未简化 + brotli-3 = 700ms
- 最小化+brotli-3=309ms
- 节约=400毫秒
- 插图:
- 未简化+brotli-3=3.28s
- 最小化+brotli-3=2.94s
- 节约=620ms
- 世界地图。
- 未净化 + brotli-3 = 2.78
- 最小化+brotli-3=2.05s
- 节省的时间=730ms
这里的差异是否显著到足以产生影响？是的，是这样的然而，这其中有很大的注意事项。
注意事项1：SVG不会阻塞渲染
SVG图像通常是无阻塞的资源，除非你在CSS中对其进行了内联。不像CSS，通常也不像JS，它们不会阻碍页面的渲染，可以并行加载。
Google Lighthouse广泛地优先考虑与用户互动有关的指标。
从GoogleLighthouse性能报告页面提取的指标图形
因此，优先级应该是让第一个渲染尽可能快，然后依次加载页面上的其他内容。
根据这个定义，弄清楚哪些东西需要先渲染，并优先考虑这些资源，是比SVG优化更好的提高性能的方法。只有当SVG的尺寸很大，并且绝对必须在第一个折叠中加载时，优化SVG才会产生真正的影响。
注意事项2：捆绑往往不可取
是的，在HTTP1.1时代，捆绑确实是提高性能的方法，但是在HTTP2时代，一个请求的开销已经大大减少。当你捆绑SVG的时候，你也会加载一些并不急需的文件。
看看这两个来自test-svgo 项目的样本页面，A页和B页。A页使用捆绑方式加载插图，而B页则直接加载它们。页面A在一次性加载它们方面做得更好，但页面B开始渲染插图的速度更快--提供了更好的用户体验。
在我们创建的捆绑文件中，最小化产生了明显的差异，但更多的时候，我们想单独使用我们的文件，当单独加载时，最小化几乎不会对性能产生明显影响。你可以看看我们刚才看的那些页面的最小化和未最小化的版本，就知道这一点。
注意事项3：很少有人在一个页面上需要这么多SVG。
我们在做测试的时候，假设我们需要加载很多文件（或者一个大文件）来测试SVGO的能力。你有可能在页面上有多个大的插图，使用SVGO可以起到一定的作用，但是在大多数情况下，这些SVG往往是图标、标志和简单的插图。
从1.2MB到880kB是很重要的，但是从2kB到1.2kB其实并没有什么区别，即使你在页面上有几十个图标。这是因为从总体上看，即使SVGO将其减少50%，节省的费用也会少得多。
总结
SVGO是一个伟大的工具，它可以有意义地减少SVG文件的大小，但是节省的费用往往是有限的，因为SVG文件通常是很小的--而且与在CSS或JS中加载图像不同，后者会阻碍页面的渲染，SVG可以并行加载。
SVGO对于真正的大文件来说是有意义的，比如我们在本文中测试的世界地图，但是如果你的页面上有数量有限的较小的SVG，SVGO并不会提高你的性能。另外，如果你确实需要多个SVG，你很可能不需要立即加载它们。
通过仔细考虑哪些资源需要先被渲染，可以对性能产生更大的影响。
另一个反对SVGO的理由是它对维护的影响。如果你要维护两套SVG，那就很好。但是如果你在所有的文件上都运行SVGO，那么做一些简单的事情，比如修改填充物和笔画，就会变得更加困难。
总的来说，如果我们最终忽视了大局--那些真正重要的指标，比如FMP、FCP和LCP，我们就不应该担心节省千字节的问题。总而言之，在大多数情况下，在优化性能时，对SVG的最小化不应该是一个优先事项。
The postIs SVGO worth it?appeared first onLogRocket Blog.
