Limit Use of Images - Speed Week, Day 2
This will probably be a no-brainer for most of us but the easiest way to improve the speed of a website is to limit the number of images on the page.
There are still sites out there where it's obvious a graphic designer has let rip with Photoshop before slicing up their creation to make a web page. In the (recent) past I've worked on sites where the customer has been desperate to change the way the menu works as adding a new "button" meant they had to pay the original graphic designer to create a new one. They always seem to think this is normal !
The menu on the website I'm currently re-working relied on no less than 21 images! There are 7 main menu items — each onne an image. Each image also has a hover-over and pressed state image. The menu was almost always the last thing to appear on the page and the client assumed it must be the fault of the JavaScript that created the drop-downs menus coming from each main menu item. In fact it was simply because of the number of images needed. It now uses text instead and has made a massive dent in the page load time.
Whereas the original homepage loaded 48 images the new version only has 18. This might still seem a lot, but the more you remove the less "designed" the site might feel and so a compromise needs to be found. The trick is to simply remove the unnecessary images. That normally means the images that are nothing but type and can easily be replaced with plain text.
Other images to go from the website were the numerous uses of spacer.gif. CSS can now do the job of tables and spacer images and save some page weight in the process.
If you find yourself using a lot of icon-like images on your page (as codestore does) then it's probably worth using CSS Sprites. In explaining the need to reduce the number of images to my client I talked about how the browser can only request X number of images in one go and the server can only respond with X-n images at once (more on that later in the week). They don't all get delivered at once and so a queue forms and page load time increases drastically.
Another way you can improve page load time is to make sure all the images you do use have their dimensions set properly. If the browser doesn't know how big an image is it has to load it to find out. It needs to know this so it can render the page properly. Some browsers wait to see how big all images are before displaying the page whereas IE will display the page and then it will appear to jump all over the place as the images load and dimensions are recalculated. Although the actual load time doesn't change it's the perception of the user that it's taking longer to load and settle.
To see if you have images with no dimensions install the Web Developer Toolbar for Firefox. With your page open disable stylesheets (makes the next step easier) by pressing Ctrl+Shift+S. Now choose Images > Outline Images > Images Without Dimensions from the toolbar. Those with the red border need fixing!
Skip to the 
You can subscribe to an individual
Not that there isn't a good reason to use CSS, how much weight and time is added by using a shim (spacer.gif) when laying out a page. It's one very light graphic that'll get called once and cached. If I was doing some work on a page layout to speed it up, it'd be right down the list of problems.
Getting people to put in dimensions in their img tags is a big bug bear of mine though. Aaarghh!! It's so easy and makes a huge amount of difference to the perceived performance of a site. It's just lazy not too.
Good tips, especially the CSS "sprite" technique. I must look into that some more. It's a terrible name though, nothing to do with sprites.
Spacer gifs might be very small and cachable but if you've used 20 of them that's still 20 HTTP requests to the server that you could easily live without. Even cached images involve a GET request to the server. The more requests there are the longer the page as a whole takes to load.
The browser shouldn't be making 20 http requests to the server for the same url on the same page. I've just done a quick test with firefox and on a sample page with 25 identical images and nothing else you get 2 requests, one for the page and one for the image. This is how I always thought it worked and I'd be very surprised if this wasn't the case for all browsers.
Damn. I should have guessed that. Oh well. Even one less image is worth it ;o)
Always the contrarian, I am...
I make a point to never add the dimensions of an image unless I have to. The reason being is that, almost invariably, the actual image and the stated dimensions go out of sync at some point. Thus, the images get distorted, and the page gets real ugly, real fast.
I could make a point of taking guesses at which images will never change, and apply the dimensions to it, but I'm playing with fire if I do that.
What I'd love to see is for the server to know how big the image is at the time the page is loaded, and insert that information into the image tag of the HTML automagically. But, at least for Domino, thats' probably much easier said than done.
We rebuilt our corporate website about a year ago and the new site design came from our advertising department with no input from anyone with web design experience (that would be yours truly) and is set to resemble a magazine layout of sorts. The layout required a fixed container size and three "columns" that contain text, pictures, or a mixture of both. The problem we ran into was in getting the advertising department to understand that if they replaced a graphic in the center column that was the width of the column with one that was 10 pixels larger, that it would break the layout of the site.
Brian, Lazy, Lazy, Lazy ;)
I think if you are happy to allow your images to change size without tidying up the layout, then you probably have more things to worry about than putting in the dimensions of graphics. If you are looking at the truly polished professional public facing stuff that Jake does, I think it's essential. The only caveat I can think of, off the top of my head, is content graphics that are not part of the design. Even then, if you want to go the extra mile you can still get the server to work it out.
Interestingly if you are using image resources in domino and actually embedding them in a form, then you do get the dimensions automagically. But who wants to live with Domino generated HTML, blugh!
Most graphics formats in use size and dimension information in the first few bytes of data and in theory the server could even put that into the http headers. This means that the image doesn't need to be fully loaded for the dimensions to be known. However as you note, it needs to be in the img tag for the layout engine of the browser to do it's magic before all the images have been requested.
Again - I assume we're on Domino.
If you use image- or file resources that are embedded in a Notesdocument's Rich Text Field, you might run into problems with browser caching again.
The Domino server will insert something (can't remember exactly if it's a no-cache or an expires right away code) that blocks the browser from caching the file.
If you want to tweak that behaviour, you need to look at the article on Response header rules on notes.net: {Link}
Anyone have rendering benchmarks for the various graphic formats? My guess is that GIF may not be the fastest format and that PNG may be better given certain requirements (no animation, lower colour depth, transparency required).
I've read a few articles that contradict each other (GIF vs. PNG) and even one that advocates using JPG files. If graphic files represent the bottleneck then a closer look at the formats and usage may prove helpful if you're trying to shorten the load time.
@Micheal, on any desktop machine built in the last decade (conservative estimate), the processor performance will put any question of decompression and rendering of graphics out of consideration for web apps. You can decompress any still image orders of magnitude faster than you can get it off the network, even a very fast local network.
Choose the best format for the file. The definition of "best" is a balance between image quality and file size. JPEG was designed for and works best with photos or images with a similar level of complexity. Gif handles smallish diagrammatic images better, images with large contiguous blocks of the same colour. Png has similar characteristics as gif, but can handle more colours and has an alpha channel. Play with different formats 'til you get a feel for what works best for different types of images that you deal with. In edge cases I'll still have a look to see what different formats look best for a particular image. Tools like Photoshop allow you to preview what different compression formats and ratios will give you, making this easy.
spacer gifs are the tool of the devil
Don't quote me on this, but I believe it speeds things up to split up your images to different hostnames regardless if they are on the same server or not.
This page would be that little bit faster if you spelt one as one not onne. ;-)
Very funny Martin. But your comment (and this reply) have just added a whole load more weight and that extra n now seems insignificant.
n n n n n n n
For those of you wondering, having the same image with multiple dimensions on a page does not result to multiple http requests. I found this out by calling a test page with the same image displayed in different sizes.