为什么使用精灵表而不是单个图像？答案

【问题标题】：Why use a sprite sheet rather than individual images?为什么使用精灵表而不是单个图像？
【发布时间】：2011-11-08 12:11:15
【问题描述】：

我在一些网站上注意到的一件事是，他们使用包含许多小图像的 BIIIIIIIG 图像，然后使用 CSS background-position 来定义每个图像的坐标，而不是使用单个图像。

这是我所在的位置：

使用大精灵表的缺点

需要加载一张大图才能只显示一张小图
需要为每张图片编写（或生成）带有类的长样式表
包含大量类定义的混乱 CSS 可能会影响性能
如果更改了一张图片（或添加了另一张图片），则图片和与之关联的 CSS 都可能会遇到缓存问题
需要具有适当样式的<div> (display: inline-block; width: 32px; height: 32px; background-image: url('spritesheet.png');)，这会增加另一个类。
还有很多我不记得了，现在我正在输入它们。

使用大精灵表的优点

...呃...还没有。

事实上，这里唯一接近专业人士的是，当我将工作表切割成单独的图像时，生成的文件夹在磁盘上占用了 3Mb（由于每个文件 即使有 HTTP 请求的开销，也能显着节省空间。

基本上，我的问题是：有没有人有任何优点可以在单个图像上使用大表？

【问题讨论】：

从服务器检索“大”图像（被缓存）几乎总是比多个请求获取所有单独的图像更快。
你的缺点都不是真正的缺点。
stackoverflow.com/questions/2082829/… 这里是专业人士
对于在许多页面上重复元素的大型网站来说，这是一个最小的优势。否则就是浪费时间。

标签： html css image css-sprites

【解决方案1】：

目的是减少 HTTP 请求。此外，有时压缩后的精灵会比原始图像轻。

最近我有一个网站，其中包含很多透明渐变（白色到反式，灰色到反式）以及透明图像上的一些黑白。通过将它们全部放在一个精灵中并将 png 中的颜色减少到 8 种，我可以让精灵的文件大小比原始图像小（只是……节省了大约 0.5%）。将 HTTP 请求的数量从 10 个减少到 1 个意味着网站加载速度更快（如果测量从第一次连接到所有数据传输的时间）。

在这种情况下，发现了可测量的增长。

我同意，虽然有可能搞砸并最终得到比所需更大的精灵，尤其是在您不使用 PNG 压缩的情况下。

两年后的注意事项——如果你使用 SSL，你应该研究一下 SPDY（我的笔记在接下来的两年里会提到 HTTP 2.0 而不是 SPDY！）。 SPDY 否定了精灵的好处。

【讨论】：

好的，但是如果图像在多个页面中使用，但不是一次全部使用，那么让单个图像逐渐导致它们都在缓存中不是更好吗？跨度>
当然，这完全取决于您在做什么。一般来说，总有一些东西可以在页面的某个地方进行精灵。我通常只会精灵 4 个小图像，然后留下其余的。 PNG 是我认为值得这样做的唯一格式，因为空白空间压缩到几乎为 0。（与 JPG 或 BMP 相反）
我一定会签出 SPDY

【解决方案2】：

你所说的缺点并没有多少真的是缺点。

当您加载一张大图像时，它仅包含图像所需的不同属性之一（颜色表、mime 类型等，例如：想象一下，如果您使用的是渐进式 jpg 格式，一个 spritesheet 将允许图像扫描一次，而许多会显着减少加载时间）而不是在 100 个不同的文件中拥有相同的信息，它会减少大图的文件大小。

此外，只有一个 http 请求（或两个，取决于您拥有多少 spritesheet。）但如果处理得当，每个页面加载只有一个。

如果您在 CSS 中使用 bg 图片，那么您已经制作了 css 选择器，因此无需额外工作，只需复制/粘贴 url。

我从未遇到过按 ctrl+F5 无法解决的精灵表缓存问题。

在任何情况下，它都不需要具有适当样式的 div。这不是<img> 标签替换方法，它主要用于背景图像。就像按钮和图标集一样。

这种方法的优点远大于缺点，证明它已被很多开发人员采用。如果这是一个糟糕的方法，那么没有人会接受它，并且在它刚开始使用时就会有人提出这些问题。

如果有人要添加更多内容，请不要害羞:)

【讨论】：

即使sprite sheet的大小是500kB，它也只会被下载一次，之后会从浏览器缓存中获取。所以，请求的数量下降得更多：D

【解决方案3】：

Google 将其描述为 here。基本上它应该减少页面加载时间。每个新的连接初始化都会增加一些延迟。在某些情况下，它还可以减少数据传输大小，从而减少页面加载时间。它适用于很少或全部一起更改的图像（主题）。这样浏览器就可以使用缓存的图片，只需要检查一个文件的变化，而不是一张一张的检查。

【讨论】：

不再推荐使用精灵。请改用 HTTP/2。

【解决方案4】：

Sprite 表是一团糟。时期。无需糖衣。它们在设计技术方面出现了巨大的倒退，这可能解释了为什么唯一喜欢使用精灵表的人是老派游戏开发人员。 Sprite 表只有一个可取之处，加载速度要快一些。除此之外，它们都是垃圾。更不用说设置的噩梦了。

在什么情况下为了运行一个简单的步行循环而必须包含 500 行代码是“可接受的”。希望一些聪明人能想出一个简单的解决方案，就像拖动一个独立的、支持 alpha 的视频格式（如 flv），但它也可以在平板电脑上运行......

如果你想写一个关于精灵有多棒的清单，我只能想知道你的设计工作有多无聊。底线是，如果一个“工具”让你更难做应该很容易的事情，那么它就不是一个好工具。扔掉吧。

【讨论】：

好吧，我最近怎么能在 2.78MB 中获得一个 200 帧、300x285 的超棒动画，而必须一张一张地下载所有 200 张图像不仅不一致（图像可能不按正确的顺序加载），而是占用 12MB。事实证明，Sprite 表非常有用。
是的，手工制作 spritesheet 无疑是一场噩梦，但是有一些工具可以从字面上自动化这方面的每一个方面。

【解决方案5】：

是 - 请求数。

大多数浏览器只会在每个域中并行下载大约 2 个资源，因此如果您提供大量小图像，用户必须等待大约一半的 HTTP 请求-响应周期。如果您使用精灵，那只是一个请求和一个响应（尽管响应更大）。

【讨论】：

现在不正确，但不久前。现在大多数浏览器都有超过 2 个连接。
对于 HTTP/1.0，Chrome 对每个域施加了 6 个连接的限制。对于 HTTP/2（almost all browsers 支持），没有限制。

【解决方案6】：

如果您有很多图像，浏览器将需要下载每一个图像。由于浏览器只能同时下载有限数量的文件，这需要时间。一张图片只会绑定一个下载槽，让页面渲染得更快。

另外，如果在许多其他页面中使用，大精灵表将已经被缓存。

【讨论】：

【解决方案7】：

这对于很多小图像特别有用，因为浏览器只需要对所有图像进行 http 请求，而不是数百张。因此，您在客户端浏览器上的网络加载速度要快得多。

问题是加载速度。只有一个 http 请求比几十个请求快很多。

【讨论】：

【解决方案8】：

此外，它还有助于保持 CSS 整洁。例如，我将精灵用于按钮（这也意味着加载悬停状态 img 不会有额外的延迟）

<button type="submit" class="vorige"><span>Vorige</span></button>

button  {display: block; width: 162px; height: 47px; background-position: 0 0;}
button:hover    {background-position: 0 94px; cursor: pointer;}
button:active   {background-position: 0 47px;}
button span {display: none}

.vorige     {background-image: url(../img/button/btn_vorige.png);}
.volgende   {background-image: url(../img/button/btn_volgende.png);}
.verstuur   {background-image: url(../img/button/btn_verstuur.png);}

因为精灵我可以省略单独悬停图像的代码：

.vorige:hover   {background-image: url(../img/button/btn_vorige_active.png);}
.volgende:hover {background-image: url(../img/button/btn_volgende_active.png);}
.verstuur:hover {background-image: url(../img/button/btn_verstuur_active.png);}

【讨论】：

一个经常被忽视的好处。