Optimal CSS Tiled Background Image Size

I have recently analyzed several web pages for Dreamweaver customers that complained about slow page loading times. A trend that I have noticed is images used for tiling backgrounds with a width or height of 1 pixel. I have even seen some 1×1 images used for tiling. Yikes!

“Tiling” refers to using a CSS background image that repeats in the X and/or Y directions to fill a page or element.

While it’s generally best to make images as small as possible, one exception to that rule is for tiling images. The smallest download that browsers can do is 1K bytes, so the best size for tiling image files that can be made to be under 1K in size is “as close to 1K without going over”. This can significantly reduce the amount of tiling that Dreamweaver and browsers need to do, which improves page loading performance.

For example, consider a 1×1 image versus an equivalent 10×10 image. The size of both images is under 1K, so the download time is the same, but the smaller image is tiled up to 100 times more than the larger image, which requires more time to render.

This argument also applies to non-tiled images, but those can easily be combined in a single file using the CSS Sprite technique.

18 Responses to Optimal CSS Tiled Background Image Size

  1. Thanks for this useful information

  2. Pingback: Tweets that mention Optimal CSS Tiled Background Image Size « Adobe Dreamweaver Team Blog -- Topsy.com

  3. Andy Hume says:

    Hi Randy,

    “The smallest download that browsers can do is 1K bytes”.

    Can you explain that, and why it is the case? This isn’t inherent in TCP, right? So what are browsers doing that mean 1K is the minimum. Seems absurdly high.

    Also, are you able to post your test data for the the background-image size tip. It’s been an anecdotal best-practise for years, but it would be great to see the real impact of different sizes on rendering times.

    Cheers,
    Andy.

  4. Piskvor says:

    You say “The smallest download that browsers can do is 1K bytes” – that is a rather interesting claim. Could you provide the source for this claim? (In my whole career as a web developer, I have never encountered this specific limit, on any level of the OSI model, for any HTTP user-agent) Without anything to back up your claim, I would be forced to conclude that you just made that “fact” up.

  5. Randy Edmunds says:

    @Andy, @Piskor: I was trying to provide a simple guideline for designers to follow, but you are correct that my wording made it sound like it is a technical fact. Ooops! :)

    Thanks @stefsull for this link that describes it in much more technical terms:
    http://en.wikipedia.org/wiki/Maximum_transmission_unit

    So, I think keeping tiled image file sizes (that would otherwise be much smaller than 1K) “around 1K” is a better guideline (i.e. don’t worry about keeping it under exactly 1024 bytes).

    Thanks for the feedback,
    Randy

  6. Andy Hume says:

    Phew. Thanks for clarifying. :)

    Regarding the background-image sizes, I’d love to see what the real impact is on rendering with different tile sizes across various browsers. But I guess it’s a fiddly one to measure accurately without really low level access to browsers.

    Cheers,
    Andy.

  7. Piskvor says:

    @Randy: Although your effort is in good faith, you are giving advice that is misleading. You are mixing together several communication layers, assuming that the browser will only ever download one image, and conflating a TCP packet size with file size; note also that MTU is __maximum__ transmission unit – not minimum, as you claim.

    So, here’s a simplified explanation of a webpage load, made with HTTP over TCP over IP (which is to say, the usual way): When you decide to visit a webpage, and enter the URL into the browser, the browser will open TCP connection(s) to the site, and send HTTP requests for its various parts – first the page itself, then whatever related resources (images, JS, CSS, etc.). The connection is actually an abstraction created on top of individual TCP/IP packets, which can have – at most – the size specified by maximum transmission unit (that’s your MTU, right there). If you are opening a new TCP connection for every HTTP resource, then getting the response to be smaller than MTU may get you (even with HTTP headers) a response that can be sent in a single TCP packet instead of in several.

    Many years ago, the browser would indeed open a new TCP connection for every resource (e.g. an image), and your tip would be kind of useful then – as a response *smaller* than MTU would be sent in a single packet (note “smaller”, not “around 1K”). However, that was *more than a decade* ago – even the oldest browsers (and web servers) in use today are using more advanced techniques like “connection keepalive” and “pipelining”: those allow to keep the connection open after a resource is downloaded, and use this connection for more downloads.

    This improvement, which was massively adopted sometime around 2002, makes such low-level “improvements” pointless – the browser only sets up the connection(s) *once* (after which it behaves like a stream of bytes, regardless of the number of requests that are passed on top of that), and although multiple packets are sent through a given TCP connection, the latency in further TCP setup/teardown is removed altogether (which obsoletes the need to craft your images in such a specific way).

    However, this ages-old information that “MTU-sized TCP response == faster load”, which used to be somewhat correct, is still passed around as a myth, even though it is not correct any more (due to widespread adoption of more efficient mechanisms). In 1998, this “size tweak” may have been useful advice. In 2011, it is pure misinformation, even though you apparently meant well.

  8. Piskvor says:

    Hi Randy,

    It seems that I have missed your main point – I thought it was “because of technical limitations in networking code of browsers, 1KB images are optimal byte size” (which doesn’t make any kind of sense), whereas your main point actually seems to be “images with larger pixel dimensions are more efficient for tiling operations”. Alas, I have understood that to be only a footnote to the main message.

    Perhaps removing that part about “minimum possible byte size” would emphasize that your main concern is the tiling speed when the image is downloaded? The byte size of the image _download_ is not really related to the tiling efficiency, correct?

    While I understand that 1KB could be a useful guideline for getting reasonable pixel dimensions vs. reasonable byte size, the (incorrect) justification by “browser limitations” will apparently distract some people away from the point you were trying to make (to an ultimately pointless rant about the nonexistence of such limitation ;-)).

    Cheers,
    Piskvor

  9. Randy Edmunds says:

    @Piskor
    Thanks for the very detailed information. You clearly understand the mechanics of the TCP layer much more than I do.

    > The byte size of the image _download_ is not really related to the tiling efficiency, correct?
    Correct. The point I was trying to make is that increasing the size of the tiled image up to a certain point improves tiling efficiency *without* trading off a slower download time. If I understand your argument, there will always be a trade off, but it’s not significant with the number of bytes we’re talking about here.

    @Andy, as far as real data on various browser, I posted some (very rudimentary) test pages:

    http://redmunds.host.adobe.com/performance/1x1_bgimage/test1x1.html
    http://redmunds.host.adobe.com/performance/1x1_bgimage/test2x2.html
    http://redmunds.host.adobe.com/performance/1x1_bgimage/test10x10.html
    http://redmunds.host.adobe.com/performance/1x1_bgimage/test100x100.html

    I used the biggest screen I could find (1920×1200) and maximized my browser window. I do not see any rendering lag in most browsers (FF3.6, Chrome9, Safari4/5), or on my Motorola Droid Android 2.2.1 (845×480).

    But, IE7 has problems. Interesting that they seem to have optimized the 1×1 tiling case, so that prompted me to add the 2×2 page (which is hoorendous until cached). I even see a lag on the 10×10 case.

    Randy

  10. Hi Randy,
    I may be missing something here, but what is the purpose of using a 1×1 pixel image as background? I’d think authors could use the color of that one pixel image as a background-color in lieu of a background image…

  11. I’m answering my own question here. I guess they’d do that in case the color of that *one* pixel cannot be matched via a color value(?).

  12. Randy Edmunds says:

    @Thierry I think it’s done for a partially transparent background. 1×1 is an extreme case, but I do see it. More common is a 1x[whatever] gradient image.

  13. Edward says:

    Thanks Randy and everyone who commented. I plan on using a background method like this in my next design. Now, I’ll be a little more educated about it. @Randy On a quick side note, do you know where I could get some CS5 badges/stickers to put on my MBP?

  14. Randy Edmunds says:

    @Edward I’ll let you know if I come across any stickers.

  15. Ken says:

    I just found a bug with background tiles smaller than 32×32 (at least 8×8 and 16×16 4-color GIFs) in Firefox 3.6.22 on Mac OS X 10.5.8 Intel: mousing over a FORM element when a page is not zoomed (in or out) triggers a misaligned re-tiling around the element. Yuck. So I’ll certainly be avoiding small tiles going forward.

  16. Any thoughts about the impact of tiling background images and the power drain for mobile devices? I understand that smaller file sizes are preferable from the bandwidth perspective, but what about battery drain when processing a tiny tiled image? I realize that striking a balance should always be the goal, but I’m looking for some facts about tiling and its impact battery life – if any exists.

  17. Pingback: What's the minimum size of a TCP packet

  18. Pingback: What’s The Minimum Size Of A TCP Packet | Click & Find Answer !