1px width background images performance

[bzgzd]

Hi.

I have on my web page some gradient backgrounds for whole page and also for navigation menu.

I see many people use images that are 1px width and then let browser to repeat them a lot of times.

But is this not bad for browser performance? Saving little time on download but maybe when browser will need to draw that image 1200 times and another image 1000 times... maybe result will be not better. Especially when page is scrolled or something.

Are you using this 1px technique?
I am thinking to change my images to maybe 10px or even more...

[rocknbil]

<rasies hand> I am a fan of the 1px solution.

The render performance of which you speak is dependent on the computer viewing it. The number of object requests from the server and size of the objects will outweigh the importance of tiling in load time of the page.

Maybe on an old 486 . . . one might be able to tell the difference. :-) But on an old 486, you'd probably be running a 56K modem at best, and if you want to see a site *today*, it's very likely you'd have images off.

[Xapti]

You're talking about using multiple 1px images for gradients?
That's done with javascript/php? or just a buttload of files and css?
Either way, I don't consider it a good idea cause its just an extra thing that causes bloat.

[Xapti]

hate when i press the back button and it double posts...

[rocknbil]

You're talking about using multiple 1px images for gradients?

No . . . single image in both cases, say a body/div BG is 1px x 600px.

body { background: #fff url(/images/body-bg.gif) top left repeat-x; }

As opposed to a 20 px x 600 px image for the same thing. Load time versus browser having less tiles to render.

[sonjay]

I usually use something at least 20 pixels or so wide -- not because of performance considerations, but because I find it easier to work with in Photoshop, and easier to troubleshoot if the background image isn't showing up, or if it looks wonky.

Can't say I've ever noticed any performance problem either way, though.