捆绑JS和CSS文件won't be necessary in HTTP/2，但是图像精灵呢？
看the demo它似乎已经比HTTP / 1.1更快地运行了，但是不会将图像捆绑到精灵中使它更快？我的意思是，当所有数据都在一个文件中时，PNG的优化算法不会更好吗？
答案 0 :(得分：11)
这取决于您的图像尺寸和格式。如果图像足够大，使用精灵就不会获得太多收益，但对于小图像，即使使用HTTP / 2也会有显着的增益。使HTTP / 2更好的原因是标头的开销要少得多，甚至可能更少往返（假设服务器实现了PUSH）。问题是，你的文件要考虑捆绑它们有多小？
对于位图，您明确指出PNG的优化算法有利于精灵，特别是如果它们的大小足够小。例如，虽然this article from Gabriel Bouvigne中的图像是17.4 kb，但切片会产生132个单独的图像，总计135 kb。当您添加一小部分但仍然存在的额外开销用于转移时，它接近10倍。是的，当服务器和客户端之间的带宽有限时，大小仍然很重要。
实际上，这也达到文本资源，例如javascript，css和 SVG文件。如果它们足够小并且不经常更换，您仍可以考虑将它们捆绑在一起。例如，如果作为单独的，缩小的和gzip的js传输，Angular的ng folder源中的Javascript需要69.6 kb。如果你在gzipping之前连接它们，它只有31.9 kb。然而，这里的因素略高于2，如果HTTP / 2节省了连接时间和往返次数，则可能没有那么重要。这进一步平衡了单独缓存资源的可能性。
作为最后一点，如果您的小图像/图标是SVG向量（它们应该！），那么它们将被视为文本资源。此外，SVG向量往往有点大，例如，gzip时Firefox's SVG icon为15.7 kb。在这个大小的情况下，如果HTTP / 2好东西正在工作，那么链接到内联或捆绑的决定是明智的。
答案 1 :(得分：3)
我同意@dsign的意思。
有一种趋势是将通常在CSS本身中用作精灵的小图像类型作为数据网址进行内联。如果您将图像内嵌到CSS中，只需将它们保存为单独的条目，这也具有每图像优化的优势。精灵中一个图像的优化与其他图像不匹配...使用PNG，您可以选择潜在的有损转换为256色/ 256色以下的图像，使用TinyPNG和{{3 }}。一些图像可以使用16种颜色。在创建组合精灵时，这些优化更加有限。
我倾向于简单地使用CSS内联或保持图像分开。积极的是像pngquant这样的工具（以及人们正朝着的其他工具）使这对于Web应用程序来说是一个相当简单的配置问题。
如果您能够通过HTTP / 2实现服务器端的图像推送，那么将它们分开更有可能对您有利。
