多个图像与精灵表答案

【问题标题】：Multiple Images vs spritesheet多个图像与精灵表
【发布时间】：2011-08-07 12:21:53
【问题描述】：

“简单”问题。

对站点元素使用大型 spritesheet 是否比使用多个图像更好？我的意思是，额外的 CSS 图像处理（背景定位大图像并对其进行裁剪）是否补偿了较少的 HTTP 图像请求？

【问题讨论】：

【解决方案1】：

number of concurrent HTTP/1 connections to a host 被限制为大约 6 个。假设延迟为 100 毫秒，则发布的 sprite 中大约 60 个图像至少需要一秒钟的时间来下载（可能更多，因为需要生成 HTTP 请求和响应，并且已解析）。

由于 sprite 图像的大小与单个 sprite 大致相同，并且图像处理速度非常快（我估计所有 60 个图像加在一起的时间远低于

总之，使用精灵通过 HTTP/1 处理徽标和小图像。

HTTP/2 旨在不再需要变通方法。最重要的是，可以通过同一个 TCP 连接同时处理多个请求。此外，标头压缩旨在压缩冗余标头，例如 User-Agent 或 Accept。

【讨论】：

我想知道这是否仍然适用于新的HTTP/2 标准和改进的并行下载。另外，如果您使用多张图片，您只能在当前滚动高度下载您需要的图片。
@Cristy 添加了对 HTTP/2 的解释。仅在滚动后下载一个小图标可能很危险，因为您现在在每个页面加载时都强制执行至少一个 RTT（而且通常更多），更不用说您的图标只会在 JavaScript 之后加载，并且网站将如果用户在失去 Internet 连接后滚动，则中断。

【解决方案2】：

通常最好使用许多小图像的精灵。

每张图片都会创建额外的 http 请求，这需要时间。特别是在 HTTP 1.0 中，每个新请求都需要等待之前的响应。

对于非常大的图片 - 它主要取决于传输一组图像所需的时间与来自 HTTP 协议的时间开销的比率。如果开销不大并且您认为如此大的图像会降低您的应用程序的速度 - 您可以使用多个图像，如果相关的话 - 使用 css sprites。

【讨论】：

但是如果你有一个包含元素的 1024*1024px 图像并且你有大约 30 个元素，你必须在一个单独的 div 中绘制该图像 30 次，并且每次都有另一个背景位置。渲染不是很慢吗？
如今我们拥有四核 CPU 和大量 RAM。你怎么看？
当然，在某些情况下，css sprites 不是最好的主意——例如，对于照片库，没有人会将它们组合成一张更大的图片。这是有限制的。但它是一个软的，所以如果你有非标准的需求，你需要自己做一些测试
我认为画廊不使用精灵是很明显的。
我在回复中添加了段落

【解决方案3】：

是的，对于任何合理的图像尺寸，它都会更快。

绘制较大图像的一部分并不比绘制整个较小图像慢。这不像浏览器正在绘制整个图像并删除未显示的部分，它只是绘制正在显示的图像部分。它只是从内存中复制像素，如果像素在内存中靠近或在更大的图像中分散开，则无关紧要。

较大的图片加载较小的图片需要更长的时间，因此较小的图片会开始显示得更快，但大图片的加载速度要比所有小图片加起来快得多。即使在图像开始显示之前您必须等待更长的时间，所有图像都会立即显示，而不是一次弹出一个。

【讨论】：

【解决方案4】：

当然，这样更好。与对更多文件的许多请求相比，浏览器将只请求文件。

为许多在您的设计中容易重复的小图像使用精灵（ex 的图标）。对于大型照片，如果是照片库，这不是一个好主意。

【讨论】：