Better to show smaller image many times, or bigger image less times?

Which is more efficient for background images?

[otem]

I've come upon this issue before, and I was hoping to get some feedback as to what I should do.

I sometimes use backgrounds that I repeat vertically; imagine vertical lines like a pinstripe.

While the design differs from left to right, the patter is the exact same when moving up to down.

When saving this image I'm faced with a dilema.

Should I save the image with a height of 1px? This would result in the tiniest graphic file size, but might require more viewer's processing power to display the image many, many times on the screen.

Or, should I save the image with a height of 100px? This would result in an increased graphic file size, but might require less viewer's processing power to display the fewer images on the screen.

Any suggestions? Thanks.

[Philosopher]

Go with the smallest image and have it repeat. The image is downloaded only once and the processing power needed to repeat the image throughout the page is miniscule.

[Beagle]

If you look at how gradients are set up, you'll find they usually follow the 1 pixel model. I've used just about every size of background tile there is, from miniscule to large, and the smaller the image the faster the page loads.

[thecoalman]

The image is downloaded only once

Not sure about IE7 but from my experience IE6 won't cache images used as backgrounds in a external stylesheet. I always put background images in an invisible div to insure they get cached on the users machine.

[limbo]

The significance of a few bytes here and there is massively diminished. I tend to spend my time worrying about other parts of the project :).

However; Knowing what the optimum balance between HTTP requests (I guess this rather depends on the resolution of the screen of your user) and image dimensions would be useful...

To take thecoalman's view a bit further - for increased site-wide load speed I have taken to adding a CSS parachute include to the page head - it contains a dozen or so lines of CSS so if the page doesn't load the external sheet for some reason the page maintains 'brand'. The CSS parachute contains background colour/images, some type styling and logos.

[thecoalman]

The significance of a few bytes here and there is massively diminished.

I did it purely for cosemtic reasons, the backgrounds simply load quicker. This is actually how I noticed it because they weren't showing up quickly. It's only a split second... but noticeable to me. I can be quite anal with things like that. :P

[otem]

Thank you for your feedback.

Originally I had only thought that it might take more user end resources to display a tiny image thousands of times compared with displaying a large image a couple of times.

I was wondering if there was some kind of magic point between file size and file dimension that I should hit, like making the dimensions as large as I should while maintaining the file size below one data chunk. The more efficient the better I think, but sometimes my mind goes off on a tangent and I wanted to make sure my underlying theory was correct.

I didn't even think about issues such as caching and other factors.

You gave me a lot to thank about.

Right now, though, my understanding is the tinier the dimensions the better. Theres no need to make an image larger, especially when it will increase file size.

Thanks again.

[templeofboom]

thecoalman hit the nail on the head. IE6 doesn't cache background images. If the goal is to get every ounce of performance you can (with a reasonable amount of effort), then this tidbit of information is valuable indeed.

[Achernar]

thecoalman hit the nail on the head. IE6 doesn't cache background images.

Where did you get this info from?
I've just tested this once again (I know that sometimes IE does act very weird) with my installed IE6 (standard configuration) on my server. I was watching the log live, and background images are loaded once and for all. One remark for the bg image from the external CSS file : it was loaded as many times as it was used on the page at the time (which I was already aware of). But only on the initial load. Afterwards, no requests for it.

[thecoalman]

Where did you get this info from?

My eyes ... :) It's only a split second (assuming the image is very small) but you can see it if the background image heavily contrasts with the background color.

Just to be clear, the background image is specified in an external stylesheet. It's a relative path so perhaps that is the difference? Also I'm referring to subsequent page loads.

[Achernar]

Same here. External CSS file and relative path.

My eyes ... :) It's only a split second (assuming the image is very small) but you can see it if the background image heavily contrasts with the background color.

Could it be that it's the time that IE needs to update/render the document, not the time to load the image. Don't forget that there is also the flickering background image bug in IE. ;)

[thecoalman]

Put it in a div and it goes away..... The flickering you are referring too depending on the situation (such as using it in a css mousover affect) is because it does't cache them. Google it and you'll find plenty of references.

[Achernar]

In the particular example I was referring to, the flickering occurs on links with background-image, with no on-mouse effect, nor any CSS effect (nothing changes in the style of the links, or any other surrounding element). There is only a onclick js event attached to the link.
The reason of the flickering is that IE tries to revalidate images when the mouse hovers over them (even if there is no hover effect), and gets a 304 response. As soon as you can add an expire header ("far" in the future) to the images, the flickering disappears (unfortunately not possible in my case).

[dragsterboy]

100px sounds way better. You can use Xara 3D to create your baground like that. It shoudn't be difficult. Anybody can do it.