The bundling of JS and CSS files won't be necessary in HTTP/2, but what about image sprites?
Looking at the demo it seems that it already works way faster than HTTP/1.1, but won't bundling images into sprites make it even faster? I mean, won't the PNG's optimization algorithms work better when all the data is in a single file?
这取决于您的图像大小和格式。如果图像足够大，使用 sprite 不会获得太多收益，但对于小图像，即使使用 HTTP/2 也会有显着的收益。使 HTTP/2 更好的是，标头的开销要少得多，而且往返可能更少（假设服务器实现了 PUSH）。问题是，您的文件应该多小才能考虑捆绑它们？
对于位图，您指出 PNG 的优化算法有利于精灵，特别是如果它们的尺寸足够小的话。例如，虽然本文中来自 Gabriel Bouvigne的图像为 17.4 kb，但对其进行切片会产生 132 个单独的图像，总大小为 135 kb。当您添加少量但仍然存在的额外传输开销时，它接近十倍。是的，当服务器和客户端之间的带宽有限时，大小仍然很重要。
实际上，这也涉及 文本资源，例如 javascript、css 和SVG 文件。如果它们足够小并且不经常更改，您仍然可以考虑将它们捆绑在一起。例如，如果将 Angular 源代码的ng 文件夹中的 Javascript 作为单独、缩小和 gzip 压缩的 js 传输，则需要 69.6 kb。如果在 gzip 压缩之前将它们连接起来，则只有 31.9 kb。然而，这里的因素只是略高于两个，如果 HTTP/2 节省了连接时间和往返次数，它可能就不那么重要了。这进一步平衡了单独缓存资源的可能性。
最后要注意的是，如果您的小图像/图标是 SVG 矢量（它们应该！），那么它们算作文本资源。此外，SVG 矢量往往会更大一些，例如，Firefox 的 SVG 图标在 gzip 压缩时为 15.7 kb。在这种规模下，如果 HTTP/2 好东西正在工作，那么链接到它与内联或捆绑的决定是不费吹灰之力的。
我同意@dsign 的观点，这取决于。
有一种趋势是将通常在 CSS 本身中用作 sprite 的小图像类型作为 data-urls 内联。如果您将图像内联到 CSS 中，只需将它们作为单独的条目保存，这还具有每个图像优化的优势。sprite 中的一个图像的优化与其他图像不匹配......使用 PNG，您可以选择潜在的有损转换为 256 色/以下的图像，并带有 alpha 透明层，例如TinyPNG和pngquant。有些图像可以低于 16 色。当您创建组合精灵时，这些类型的优化会受到更多限制。
我倾向于简单地使用 CSS 内联或将图像分开。积极的一面是，像webpack（以及人们正在转向的其他工具）这样的工具使得这对于 web 应用程序来说是一个相当微不足道的配置问题。
如果您能够通过 HTTP/2 实现图像的服务器端推送，那么将它们分开更有可能对您有利。
