Thread

Hello good people of the HTTP world!
Being how this cool community has plenty of more-than-just-ee-developers I thought to ask…
It all started with me staring into Photoshop file and deciding how to slice things up while keeping the ‘fancy’ effects through out the design.

The dilemma was:
Less HTTP requests
-Keep the fancy emboss effect and use CSS to move/position segments of the 1 single larger image....or
Less of a file size(s)
-Slice into multiple smaller images and resort to more markup and empty objects(spans div…whatever it takes)

I have seen more and more designs where the slicing techniques have been completely abandoned or replaced with 1 blob of a background image; I suppose the days of dial-up connections are long gone but still….
What do you prefer and why?
Thanks for the discussion!

I think it all depends really. Slicing things up can sometimes be a pain to get working across all browsers with the problems that we all face day to day. Sometimes one background image is just easier and if it works then as long as the user gets the experience you want them to receive and it works okay then I wouldn’t worry too much about it personally.

Most people don’t turn off images on sites so as long as nothing goes wrong with your CSS and you don’t accidentally delete the background image then I personally don’t think it’s too much of a problem. As you say most people have fairly quick internet now so it shouldn’t be too much of a problem. That being said the image size whether one image or small sliced images will probably still be the same so they will have to wait no matter what if they do have to wait.

Best wishes,

Mark

Thanks Mark!
One thing I like with slicing approach is the re-usability of images…eg. rounded edges, borders/frames but it is so much easier to just use one image. This is especially handy with liquid and/or elastic designs…seeing an image of 1600x600px just seems ‘heavy load’.
I would be curious to know if more http requests manifest in ‘slower’ experience than loading larger images thought less requests…‘to slice or not to slice’ 😊
Thanks!

...seeing an image of 1600x600px just seems ‘heavy load’.

I don’t recall hitting a site recently with that size image. Whew. Forget CSS. Go with one image and a very large image map.

😉

I would be curious to know if more http requests manifest in ‘slower’ experience than loading larger images thought less requests…‘to slice or not to slice’ 😊

There are just too many variables, so I don’t worry much about it, opting for a “middle road” stance; slicing a little here and there, adding other graphic elements that make sense, but trying to avoid going crazy with a heavily laden page.

The variables include CSS, Javascript, XHTML, PHP, MySQL queries, graphics, server capability, bandwidth, and probably a few more. Some sites that may get a lot of traffic might opt for fewer elements, smaller graphics, but other sites with less traffic and more focus on bells and whistles may require more of everything.

I’ve had a few sites with nearly two dozen graphic elements of 5k or less get Digg hits and Slashdot hits. In one case the server buckled, and in another case the server sailed through just fine despite the massive number of hits.

So, I guess I aim for a middle road; a balance that suits me, the site, the intended user, server capability, etc.

Thank you Ronnie,
Image maps… 😊 nice one.
There was a site recently showcased here….no pun intended, I like the design just trying to ‘catch up with the new kids on the block’.
Sometimes I worry (too much) about handing of the design then being blamed for something that would require a total re-design 😊.
Being how my day life is in network admin I see a lot ‘hits’ recoded on sites in large number simply because of number of objects (images, js etc) are loaded per visit. This is different from ‘site stats’ of a webmaster but never the less interesting. For example, my firewall will record site.com = 150 hits (IF this site has 150 images on a landing page) even if the user visits the site 1 time .
Even worse, if the same site has some questionable content tagged as ‘porn,spam,advert…’ these numbers of hits will tag the site so strictly that it even may be blocked. So one ‘alt’ tag of ‘sexy-beast’ can be boosted by the fact that there is 50 images involved in lets say navigation menus.
Well, anyhow…thanks for your thoughts!

When you first posted the question above the site you have linked to above (well the image of the background of the site) is exactly the site I was thinking of in my head whilst I was posting! 😉

...seeing an image of 1600x600px just seems ‘heavy load’.

I don’t recall hitting a site recently with that size image. Whew. Forget CSS. Go with one image and a very large image map.

😉

I would be curious to know if more http requests manifest in ‘slower’ experience than loading larger images thought less requests…‘to slice or not to slice’ 😊

There are just too many variables, so I don’t worry much about it, opting for a “middle road” stance; slicing a little here and there, adding other graphic elements that make sense, but trying to avoid going crazy with a heavily laden page.

The variables include CSS, Javascript, XHTML, PHP, MySQL queries, graphics, server capability, bandwidth, and probably a few more. Some sites that may get a lot of traffic might opt for fewer elements, smaller graphics, but other sites with less traffic and more focus on bells and whistles may require more of everything.

I’ve had a few sites with nearly two dozen graphic elements of 5k or less get Digg hits and Slashdot hits. In one case the server buckled, and in another case the server sailed through just fine despite the massive number of hits.

So, I guess I aim for a middle road; a balance that suits me, the site, the intended user, server capability, etc.

A server going down due to massive traffic is much dependent on what the server is doing, how many sites it has on it, how much it has in free resources etc than the way a site is designed. And it doesn’t have much, if anything to do with images, and how they’re sliced, it’s the MySQL queries almost always that overload the server.

Also, slicing images does not reduce bandwidth requirements. you’re still downloading the same amount of data, just in pieces.

I’d have to agree with JT.  The bottleneck on probably 99% of servers using the php/mysql combo is mysql.  That’s why a lot of high traffic sites use two separate servers for mysql that are mirrored, one for reading the other for writing heh.
The time of slicing up an image is long gone.  Even cell phones can load a page fast enough for that to not be an issue anymore.

Just my two cents 😊.