Html 重复网站背景图像-大小与速度

我想知道是否有人用背景图像做过任何测试。我们通常创建一个至少在一个方向（x或y或两者）重复的背景

示例
假设我们有一个在X方向重复的渐变背景。梯度高度为400px。我们有几种可能性。我们可以创建尽可能小的图像（1像素宽，400像素高），也可以创建400像素高的较大图像

观察
由于渐变是400像素高，我们可能不会选择GIF格式，因为它只能存储256种自适应颜色。如果我们的渐变很微妙，也许这是可能的，因为它没有那么多，但否则我们可能宁愿将图像存储为24位PNG图像，以保留完整的渐变细节

困境
我们应该创建一个1×400 px大小的图像，并在水平方向上重复n次，还是应该创建一个100×400 px大小的图像以加快浏览器中的渲染速度，并具有更大的图像文件大小

---

所以图像大小与渲染速度？哪一个获胜？有人想测试一下吗？关于浏览器渲染速度和可能出现的小图像重画闪烁…

我认为瓶颈在于图像下载，而不是渲染引擎进行平铺，所以选择1像素宽的选项

---

另外，24位PNG是多余的，因为每个通道仍然只有8位（红色、绿色和蓝色）。

我通常喜欢介于两者之间，1像素宽可能会使你的渐变看起来有点不清晰，但你可以做一些像5像素宽这样的事情，这会给渐变留出足够的空间，以保持整个页面的一致性和清晰度。。但我建议您可以在一张图像中添加更多图案和图像，然后使用背景定位（）由于浏览器向服务器发出的请求较少，因此下载一幅50kb的图像比下载5幅40kb的图像所需的时间要少…

如果图像的小尺寸对渲染有负面影响，我相信任何一款像样的浏览器都会在平铺前在内部对图像进行多次闪烁

---

也就是说，我倾向于不使用1像素的图像尺寸，因此我可以清楚地看到图像，而无需调整大小。在大多数情况下，PNG压缩足以以极低的文件大小成本处理此问题。

渲染速度是这里的瓶颈，因为更大的分片可以放入浏览器的缓存中

事实上，我已经在主流浏览器上尝试过这种方法，至少其中一些浏览器在非常小的平铺上呈现的速度非常慢

因此，如果增加位图大小不会导致文件大小大得离谱，我肯定会这么做。自己测试一下，看看。（记住要包括IE6，因为仍然有很多人被它困住了）

---

您可能能够在位图大小和文件大小之间取得很好的平衡，但一般来说，我会尝试50x400、100x400、200x400甚至400x400像素。

我还没有对此进行基准测试，但我敢打赌，在大多数现代计算机上，渲染不会成为问题，而您总是希望节省图像下载时间。我经常选择1px类型的图形。

我发现，如果你有一个宽度为1px的背景图像并重复它，浏览器的渲染性能可能会有很大的差异。最好使用尺寸稍大的背景图像。因此，宽度为100px的图像在浏览器中的性能要好得多。当您在网站的可拖动层中使用重复的背景图像时，这一点尤其重要。对于经常重复出现的背景图像，拖动性能非常差。

我想指出，对于发送额外几行的成本（这里仅举1-2行）。8k-1.6kb（如果可以使用8位）更像是24位的2.4kb-4.0kb

2像素列更多意味着blit背景所需的迭代次数减少到1/3，最多可达1.6kb（8位）或4kb（24位）

即使是额外的一列，也会将所需的间隙减半至元素宽度的一半

---

如果56.6k调制解调器的背景在不到一秒钟的时间内完成，我认为它足够精简。

我一直追求尽可能小的文件大小，从来没有遇到过任何问题。但这并不科学。重复：这是2^8x2^8x2^8可能的颜色，明显大于256。我完全误解了什么吗？在从一种颜色到另一种颜色的渐变中（假设只使用了两种），那么你只能得到256种离散的颜色。我想？诅咒，现在我开始怀疑自己了。转到Photoshop。这取决于你的渐变，但举一些例子：从RGB（0,0,0）到RGB（255,0,0）的线性RGB渐变只有256种颜色。RGB（0,0,0）到RGB（255255255）理论上可以有3*256个阴影，但更可能只有256个。距离较近的颜色将具有较少的色调。Paint.NET自动检测所需的位深度；有用。你对颜色的看法是错误的，除非你的渐变色从黑色变成了纯色（R、G或B）。或者从纯到白（但这一个可能有超过256个级别）。但在任何其他情况下，你最终都会得到任意数量的级别。我不是说精灵常见的内容图像。我更多地考虑的是页面背景不是精灵，也不能。对不起，可能误解了这个问题…有点误会了。你仍然可以使用精灵来实现这一点-你可以将水平平铺的背景放在一个图像上，即一个5x200像素的图像和两个5x100像素的梯度。当然。。。但它可能会进一步影响渲染。我想应该是的。嗯，我想宽度稍大一点的渐变（比如50像素）不会对文件大小产生太大的影响。也许可以尝试2的幂次（比如32或64像素宽），他经常这样做