这取决于您的图像大小和格式。如果图像足够大,使用 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 好东西正在工作,那么链接到它与内联或捆绑的决定是不费吹灰之力的。