Hello there.

For this "experiment" of mine, images were saved along the exact following:

1. Save for Web...
2. Select .GIF

* I used the Google (Australia) logo. I randomly used the slice tool and ended up with 8 slices. The files added up to 29.7 KB.
* Then I used the slice tool again to slice the image into...one slice. This image added up to 7.29 KB.

(With defaults settings for "Save for Web..." under .GIF when saving for BOTH.)


Oh and go ahead and rebut my claims. This topic is open for discussion! I think I poorly did this experiment, so hopefully someone can try it.

Further:
* Image slicing is not necessary for image maps.
* http://yoursite.nu/mbtopic.php?id=274
* (I've read somewhere that it is also not necessary to slice images for link rollovers, hopefully the pros at Astahost can help me haha)

This post has been edited by Vue: Apr 16 2007, 06:16 AM

Well in some instances using slices help, because different forms of imagery can be compressed separately
in different ways for maximum compression. For instance, with flat, non-gradated colors, you could use GIFs
optimized with pallets limited to only a few colors; whereas, with more photographic/rendered/gradated images
a JPEG compression would be more fitting. So if you split the flat colored-shapes from the photos, then you
would have a faster loads page then if you didn't slice. Also, some people use slices so that the viewers don't
have to wait for one big image to load. When see little parts filling in and loading, they might be more likely
to stick around and wait for the page to finish loading. It is the same idea as with interlaced/progressive images.
They load in layers of quality so that the viewer can see that something is happening, even if they are a little
larger in files size than the non-interlaced images.

Thank you for replying very much, you included something I forgot (which is really obvious hahaha) about the amount of colours in particular areas of the image.

However, isn't it the responsibility of the webmaster to make sure that the website loads reasonably? Because not everybody has speedy broadband.

Haha sorry, I feel like my head's set to "debate" mode. Thank you again for your reply.

Yes, a webmaster should make the page load as speedy as possible. And that is one reason why seeing little bits of the sits load (instead of waiting for one huge image),
might keep those 56k people around during the load time. I think it is important to keep load time in mind during the design process and the slicing/coding process.
For example, having text going across a large photo (in the design stage) would look weird if it was sliced across the text, but would yield a large image if it wasn't sliced.

There is always to path in here.

1. make the picture small enough or compressed enough to make it load a little faster for 56kbps and let the user stare at the blank image spots.
2. make it larger by using interlaced graphics but let the 56kbps view the photo fraction at a fraction at a time.

Depends on how patience your visitors are. I prefer number 2 if i cant avoid images.

Hah. That's me. XDD I'm hoping my parents will switch to something faster soon though, because unlike all of us here, some care squat about us dial-up users.

So yes. foolakadugie is quite right about the colours, but in my opinion, it's pointless to slice such a small image up anyways. It will load fast enough on even the slowest connection (I have not even heard of any company or organization offering 28.8kbps dial-up services, but if you have, surprise me). It's only for those huge images that will take over a whole minute to load that needs a nice slicing. It's good to see that a page is actually loading something, albeit slow. At least we know that the page isn't broken or that it will take ten minutes to load.

The best way to happily accomodate all Internet connection speeds is to just limit the number of images you have on your site; don't use them if you don't have to. If you can reproduce a button or a header in text using HTML and CSS without images, then do that instead.

Serena