6

It's often stated that when tiling the background of a web page with background-image, that performance is better with an image of larger dimensions due to it needing to be tiled less frequently. For a while I've been making them 8x8 px, or multiples of 8.

But does anyone have links to data that prove this is the case across a range of browsers, taking in rendering times, or CPU load at various points of page rendering?

Andy Hume
  • 40,474
  • 10
  • 47
  • 58

3 Answers3

6

I'd imagine it matters very little in these modern browsers you listed in your comment:

IE 8/9, and latest versions of Firefox/Safari/Chome/Opera

However, I have heard of a bug in IE8 when it comes to an image of exactly the size 1px * 1px:

Internet Explorer 8 doesn't perform the repeat of a 1x1 pixel semi-transparent background image correctly when any other element on the page is using the "-ms-filter" drective for the alpha transparency:

-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";

See: http://nemesisdesign.net/blog/coding/ie8-1x1px-semi-transparent-background-bug/
and the demo: http://static.nemesisdesign.net/demos/ie9-1x1px-semi-transparent-background/

So, 8x8 seems like a good enough size to use. I'd be surprised if anyone on the Internets has cared enough about this to rigorously benchmark it.

I did find this, which discusses the subject:
http://blogs.adobe.com/dreamweaver/2011/02/optimal-css-tiled-background-image-size.html

Make sure to also read the comments.

To sum it up, I'm going to quote myself from months ago:

I'd imagine it matters very little in [the] modern browsers [IE 8/9, and latest versions of Firefox/Safari/Chome/Opera] you listed in your comment.

thirtydot
  • 224,678
  • 48
  • 389
  • 349
  • 1
    "The smallest download that browsers can do is 1K bytes". That seems like completely the wrong way to explain that. Does he mean, try and keep it below 1KB to avoid multiple packets being sent. THAT makes sense, but the way he's written makes it sound as though browser will always download 1k for any size response. That can't be true, surely? – Andy Hume Feb 08 '11 at 12:38
  • That particular sentence is worded badly - what is meant is that if you download a 200 byte image, it still takes an almost identical amount of time as a 1KB image, because it will still take one packet to send. I did provide a nicer version of that wording, expressing the intent behind it (see the MTU link). – thirtydot Feb 08 '11 at 12:42
  • 1
    Interesting thought, but that's not the way it works. Packets aren't padded out to the MTU size or anything... it's the *maximum* transfer unit, not minimum. Not like storing files in a hard drive, taking up a minimum of 4096 bytes no matter how small. Shorter is still better, as far as transmission time is concerned, though the marginal cost of a second packet is way more than the marginal cost of one extra byte in the first packet. The OP wasn't interested in data transfer though, just rendering speed (apparently). – Peter Hansen Jul 22 '11 at 01:11
  • @Peter Hansen: Yeah. I usually know what I'm talking about, but even my own bullshit detector is lighting up when reading what was there before in the second part of my answer. I've edited it to de-emphasise that part. – thirtydot Jul 22 '11 at 09:07
1

In some email clients the image won't repeat unless the background image is at least 25X25 so I've settled on that as my default size.

peer1sucksbigones
  • 11
  • 1
0

I don't think there is an "optimum size," but the general opinion is that larger dimensions are better than small: see this question, and this one too.

Community
  • 1
  • 1
Kyle
  • 65,599
  • 28
  • 144
  • 152
  • Sure, I'm aware it's the general opinion. And I'm sure it's true as well. What I'm after specifically is data and examples that prove it. – Andy Hume Feb 08 '11 at 12:16