我想知道是否有人对背景图像进行过任何测试。我们通常创建一个至少在一个方向（x 或 y 或两者）重复的背景。
示例
假设我们有一个在 X 方向上重复的渐变背景。渐变高度为 400px。我们有几种可能性。我们可以创建尽可能小的图像（1 像素宽和 400 像素高），或者我们可以创建一个 400 像素高的更大图像。
观察
由于梯度是 400 像素高，我们可能不会选择 GIF 格式，因为它只能存储 256 种自适应颜色。如果我们的渐变很微妙，也许这就足够了，因为它没有那么多，但否则我们可能宁愿将图像存储为 24 位 PNG 图像以保留完整的渐变细节。
困境
我们应该创建一个 1×400 px 大小的图像，将水平重复n次，还是应该创建一个 100×400 px 大小的图像以加快在浏览器中的渲染并拥有更大的图像文件大小。
所以。图像大小与渲染速度？哪一个赢了？有人愿意测试这个吗？关于浏览器渲染速度和可能的小图像重绘闪烁......
渲染速度是这里的瓶颈，因为更大的图块可以放入浏览器的缓存中。
我实际上已经在主要浏览器上尝试过这个，并且至少其中一些在非常小的图块上呈现明显缓慢。
因此，如果增加位图大小不会导致文件大得离谱，我肯定会这样做。自己测试一下看看。（记住要包括 IE6，因为仍然有很多人坚持使用它）。
您可能能够在位图大小和文件大小之间取得良好的平衡，但总的来说，我会尝试 50x400、100x400、200x400 甚至 400x400 像素。
我发现浏览器的渲染性能可能存在巨大差异，如果您有一个宽度为 1px 的背景图像并重复它。最好有一个尺寸稍大的背景图像。因此，宽度为 100 像素的图像在浏览器中的表现要好得多。当您在网站的可拖动层中使用重复的背景图像时，这尤其会发挥作用。对于经常重复的背景图像，拖动性能非常糟糕。
我想指出的是，为了发送额外的几行（此处仅举例 1-2）0.8k - 1.6kb（如果你可以使用 8 位），则更像是 2.4kb - 4.0kb 24位
多 2 个像素列意味着将 blit 背景所需的迭代次数减少到 1/3，最高可达 1.6kb（8 位）或 4kb（24 位）
甚至 1 个额外的列也将所需的 blitting 减半到元素宽度的一半。
如果 56.6k 调制解调器的背景在不到一秒的时间内完成，我认为它已经足够精简了。
如果图像的小尺寸对渲染有负面影响，我相信任何体面的浏览器都会在平铺之前在内部对图像进行几次blit。
也就是说，我倾向于不使用 1 像素的图像尺寸，所以我可以在不调整大小的情况下清楚地看到图像。在大多数情况下，PNG 压缩足以以极少的文件大小成本处理此问题。
我会把钱放在图像下载的瓶颈上，而不是渲染引擎进行平铺，所以选择 1 像素宽的选项。
此外，24 位 PNG 也是多余的，因为每个通道仍然只能获得 8 位（红色、绿色和蓝色）。
我通常更喜欢介于两者之间，1pixel 宽可能会让你的渐变看起来有点不清楚，但你可以做一些像 5pixel 宽度这样的事情，它为渐变提供足够的空间来保持整个页面的一致性和清晰度.. 但我建议你可以将更多图案和图像添加到单个图像，然后使用背景定位（css sprites）来定位它们，因为下载一个 50kb 的图像与 5 个 40kb 的图像相比需要更少的时间，因为浏览器对服务器的请求更少......
我没有对此进行基准测试，但我敢打赌，在大多数现代计算机上，渲染不会成为问题，而您总是希望节省图像下载时间。我经常选择 1px 类型的图形。