I am confused about the use of images on sites.

The websiteoptimization.com's web site speed report has an Image file size warning for my tiny site that includes 18 small images. Actually most sites (including Goverment and the BBC) I have done a speed report on have these warnings . It seems not many people follow the reports advise? Obviously the use of images are important part of a website. It seems designers decide it is better to use the images they want, even if it means having a too high file size as suggested by the report?

I have been asked to put more photos on my site, I replied that I am already exceeding my limit and they say 'No.. don't worry everyone has fast Internet connection these days, and no one uses dial up anymore'. What do you say?

Is it also true that each page has it's own downloading speed relating to it's own file size? meaning that the file size of the entire site does not effect the individual page? If so why is the Speed report not specific to each page?

What option do webshops that have every product they sell displayed as an image on their site have?

I am aware of reducing the file size of images and saving for web but this does not seem to solve the problem altogether.

Cheers

I can't use the speed report -- I just get a 403 error -- but bear in mind that site exists to make you think your website is slow. That way, you might buy their services or book.

So if you were them, would you set a sensible threshold? Or would you set a stupidly low threshold, so that almost every website failed? Which option generates more business for them? Hmm...

Although speeding up your site is a Good Thing, you have to keep it in perspective. It's good to keep your file size under control, but file size is less important than response time.

Think about it: what does it really matter if your images take 40 seconds to download? The web page is still there; the text is still there. The metric of "time to complete page load" is not actually that important. What really matters is "time until the page is usable". Users don't mind a page that carries on loading images in the background; but they do get annoyed by a blank page!

Yahoo has done a lot of work on response time. They created a tool to help: Yslow. Not all of the advice is applicable for most websites -- a CDN is probably out of your price range, and E-Tags are irrelevant unless you're using a CDN -- but implementing even their easier suggestions can reduce your site's response time. Reducing HTTP requests is especially important, as is using GZIP (your server probably does this already).

Make sure that you always specify height and width for your images. That way, the browser knows how much space to set aside for them, and can carry on rendering the page while they download. Also, try to avoid using the <img> element for anything purely decorative; use CSS backgrounds instead. Because these are non-content items, browsers assign them a low priority.

One last thing: it doesn't matter how efficient your pages are, if your web server is overcrowded! A slow web server will doom your website to slow response times (as I've recently discovered...!).

To put it simply.

When you view a website, a bunch of files are downloaded to your browser. If the files are big, this will take longer. If you are running on broadband then the files will need to be very big before you notice any slow down. However, if you are on dreaded dial up the difference between a 30kb image and a 10kb image is BIG.

The rule of thumb for me at least is as follows.

If code can be written in an optimised way. Write it that way.

With images, I reduce the quality of the image until I notice a difference. I then go back to where it looked good and save it. I also compare file sizes between various formats to make sure that the image is as small as it can possibly be.

As long as your images are optimised your site will be fine.

Thanks I will try and use the tool.



Great, none of mine have them.



Will learn more about this.

Cheers

Yes, unless doing so incurs a significant maintenance burden.

For example: trying to pare down the number of your <div>s can be counter-productive. By honing your code to the absolute minimum, you may lose flexibility (because you lack styling hooks, for example).

In return, you gain only an infinitesimal improvement in speed.

When I wrote about code optimisation I had html tables in mind but mainly excessive javascript usage. I see sites using 4 different frameworks to do something that 1 could achieve. Considering how a dial up user must download each one it will significantly slow them down. The same goes for php/asp/etc scripting. If the code isn't optimised then server is doing more work than it needs to which will mean that when you get a traffic spike the server will deny many more people than it needs to.

Oh, I'm all in favour of optimising code.

In particular, I like to optimise code so that:

1. It's smaller and runs faster (user benefit).
2. It's easier to read (developer benefit).
3. It improves my productivity (developer benefit).

Note, however, the potential conflict in those objectives. Most of the time, optimised code scores on all three counts; sometimes, however, you must compromise between optimising-for-speed and optimising-for-productivity.