我想知道是否有人对背景图像做过任何测试。我们通常创建一个至少在一个方向（x 或 y 或两个方向）重复的背景。
示例
假设我们有一个在 X 方向重复的渐变背景。渐变高度为 400px。我们有几种可能性。我们可以创建尽可能小的图像（1 像素宽，400 像素高），也可以创建 400 像素高的较大图像。
观察
由于渐变高度为 400 像素，我们可能不会选择 GIF 格式，因为它只能存储 256 种自适应颜色。如果我们的渐变很微妙，也许这就足够了，因为它没有那么多，但否则我们可能宁愿将图像存储为 24 位 PNG 图像，以保留完整的渐变细节。
困境
我们应该创建一个 1×400 像素大小的图像并在水平方向上重复 n 次，还是应该创建一个 100×400 像素大小的图像以加快浏览器中的渲染速度并拥有更大的图像文件尺寸。
所以。 图像大小与渲染速度？哪一个获胜？有人愿意测试一下吗？关于浏览器渲染速度和可能的小图像重绘闪烁......
I was wondering if anyone has done any tests with background images. We normally create a background that repeats at least in one direction (x or y or both).
Example
Let's say we have a gradient background that repeats in X direction. Gradient height is 400px. We have several possibilities. We can create as small image as possible (1 pixel width and 400 pixels high) or we can create a larger image with 400 pixels height.
Observation
Since gradient is 400 pixels high we probably won't choose GIF format, because it can only store 256 adaptive colours. Maybe that's enaough if our gradient is subtle, since it doesn't have that many, but otherwise we'll probably rather store image as a 24-bit PNG image to preserve complete gradient detail.
Dilemma
Should we create an image of 1×400 px size that will be repeated n times horizontally or should we create an image of 100×400 px size to speed up rendering in the browser and have a larger image file size.
So. Image size vs. rendering speed? Which one wins? Anyone cares to test this? With regards to browser rendering speed and possible small image redraw flickering...
发布评论
评论（7）
渲染速度是这里的瓶颈，因为可以将更大的图块放入浏览器的缓存中。
实际上，我已经在主要浏览器上尝试过这种方法，至少其中一些浏览器在非常小的图块上渲染速度明显很慢。
因此，如果增加位图大小不会导致文件大小过大，我肯定会这样做。自己测试一下看看。 （记住包括 IE6，因为仍然有很多人坚持使用它）。
您也许能够在位图大小和文件大小之间取得良好的平衡，但一般来说我会尝试 50x400、100x400、200x400 甚至 400x400 像素。
The rendering speed is the bottleneck here, since bigger tiles can be put into the browser's cache.
I've actually tried this for the major browsers, and at least some of them rendered noticeably slow on very small tiles.
So if increasing the bitmap size does not result in ridiculously big file sizes, I would definately go with that. Test it yourself and see. (Remember to include IE6, as still many people are stuck with it).
You might be able to strike a good balance between bitmap size and file size, but in general I'd try 50x400, 100x400, 200x400 and even 400x400 pixels.
我发现，如果你有一个宽度为 1px 的背景图像并重复它，浏览器的渲染性能可能会有巨大差异。背景图像的尺寸最好稍大一些。因此宽度为 100px 的图像在浏览器中的表现要好得多。当您在网站的可拖动图层中使用重复的背景图像时，这一点尤其重要。对于经常重复的背景图像，拖动性能非常糟糕。
I found out that there may be a huge difference in the rendering performance of the browser, if you have a background-image with width of 1px and repeating it. It's better to have a background-image with slightly larger dimensions. So a image with a width of 100px performs much better in the browser. This especially comes into play when you use a repeated background-image in a draggable layer on your website. The drag-performance is pretty bad with an often-repeated background-image.
我想指出的是，发送额外几行的成本（此处仅举 1-2 行）0.8k - 1.6kb（如果你可以使用 8 位）更像是 2.4kb - 4.0kb 24 位
2 像素列更多意味着位图传输背景所需的迭代次数减少至 1/3，最多 1.6kb（8 位）或 4kb（24 位），
甚至 1 个额外列将所需的位图传输减半至元素的一半宽度。
如果对于 56.6k 调制解调器来说，后台在不到一秒的时间内完成，我认为它已经足够精简了。
I'd like to point out that for the cost of sending down an extra few rows (1-2 only example here) .8k - 1.6kb (if you can get away with 8-bit) more like 2.4kb - 4.0kb for 24bit
2 pixel columns more means the required iterations required to blit the background in is cut down to 1/3 for up to 1.6kb (8-bit) or 4kb (24bit)
even 1 extra column halves the blitting required down to half the element width.
If the background's done in less than a second for a 56.6k modem I reckon it's lean enough.
如果图像的小尺寸对渲染产生负面影响，我确信任何像样的浏览器都会在平铺之前在内部对图像进行几次位块传输。
也就是说，我倾向于不使用 1 像素图像尺寸，因此我可以清楚地看到图像而无需调整其大小。在大多数情况下，PNG 压缩足以处理此问题，而对文件大小的影响很小。
If small dimensions of an image have a negative impact on rendering, I'm sure any decent browser would blit the image internally a few times before tiling.
That said, I tend not to use 1 pixel image dimensions, so I can see the image clearly without resizing it. PNG compression is good enough to handle this at very little cost to file size, in most situations.
我会把钱花在图像下载的瓶颈上，而不是渲染引擎进行平铺，所以选择 1 像素宽的选项。
此外，24 位 PNG 是多余的，因为每个通道仍然只能获得 8 位（红色、绿色和蓝色）。
I'd put money on the bottleneck being the image download rather than the rendering engine doing the tiling, so go for the 1 pixel wide option.
Also the 24-bit PNG is redundant since you're still only getting 8 bits per channel (red, green and blue).
我通常更喜欢介于两者之间，1 像素宽可能会让你的渐变看起来有点不清楚，但你可以做类似 5 像素宽度的事情，这为渐变提供了足够的空间，以保持整个页面的一致性和清晰度。但我建议你可以将更多图案和图像添加到单个图像中，然后使用背景定位（css sprites）来定位因为与 5 个 40kb 图像相比，下载 50kb 的单个图像所需的时间更少，因为浏览器向服务器发出的请求更少......
I generally prefer to go in between, 1pixel wide will probably make your gradient seem a bit unclear but you can do something like 5pixel width which gives enough room to the gradient to maintain consistency and clarity across the page.. but I would suggest you can add more patterns and images to a single image and then use background positioning(css sprites) to position them because download a single image of say 50kb would take less time comapared to 5 40kb images since the browser makes fewer requests to the server...
我还没有对此进行基准测试，但我敢打赌，在大多数现代计算机上，渲染不会成为问题，而您总是想节省图像下载时间。我经常选择 1px 类型的图形。
I have not benchmarked this but I'd bet that on most modern computers the rendering won't be an issue whereas you always want to save on on the image download time. I often go for the 1px type of graphics.