Alright. So your images are now as small and fast they can get. Let's quickly cover one way to make them seem faster without focusing on file sizes.
When you save images in an "Interlaced" (GIFs and PNGs) or "Progressive Loading" (JPG) format, Netscape or IE displays your pictures as fast as they can. First, they draw a rough approximation of the picture, then fill in details later. Sloppy as it sounds, this improves the user experience, because basic page elements get assembled quickly. Users can interact with the page read your text content and such before the loading process is completely finished.
In the mid-90's Paleoithic Era of the Web, designers used the "lowsrc" attribute of the <img> tag for similar reasons. Browsers can load a super-compressed version of an image first, then load the "real" file later. The lowsrc approach which requires downloading twice as many images has been all but abandoned in favor of the progressive-loading technique.
If you're slipping into the radical optimization mindset (have you entered the 5K contest yet?), you've no doubt noticed that progressive or interlaced images are sometimes a little bigger kilobyte-wise. In this case, learn to live with it there's more to making a page "optimized" than just download size.
In fact, there are 3 kinds of speed to think about on the Web:
- Download Speed
- Render Speed
- Visual Accessibility
A user makes the split-second decision between clicking through or heading back based upon a combination of these three types of speed. A good designer needs to find a way to balance the three elements, not unlike balancing a house of cards, to create the ideal download.
Knowing when a page has rendered enough to be useful (as opposed to a concrete ceiling of 10 KB or a "no more than three graphics per page" rule) gives a designer the layout latitude necessary to create a successful page. As long as users don't ask, "Hey, how big is this page, anyway?", the page is doing its job.