I can help with HTTP caching and image compression settings. That's part of my day job as a website developer. You are about to learn more than you ever needed about these subjects.
PNG is slower to write but faster to download than GIF
8-bit PNG is basically the same as GIF, but the compression produces a smaller resulting file.
A full implementation of PNG can try various compression modes before choosing the one which works best for that particular set of pixels. PNGcrush does this, trying up to 100 different modes. This is heavy on processing.
Once you've found a compression profile that works well for this particular type of image, you don't need to test multiple compression modes any more.
It's still a bit slower to produce the file than the equivalent GIF compression. But the resulting file can be 40% smaller, making it a faster download experience for users.
Server-Side Caching
You can write each image you generated as a static files on the server. The URL you provide points to the static file. So every visitor is just getting a static file off your server's HDD.
Static files usually get HTTP caching headers by default, along with MIME types and so on. This means each visitor only downloads the file once.
PNG Transparency Support
IE7 and any better browser support smooth transparency.
IE6 has <2% market share in most developed nations, so that's really irrelevant.
Smooth transparency uses more filesize than on/off transparency, but reduces 'jaggies' when you have curved edges against various background colours.
8-bit PNG supports on/off transparency (aka 'index transparency') and that's even supported by IE6. 8-bit PNG also supports smooth transparency (aka 'alpha channel transparency') which is what IE6 does not support.
Smooth transparency is usually what you get when saving 24-bit PNGs. IE6 does not support that.
PNG Metadata
Files produces from Photoshop, Paint Shop Pro, even Microsoft Paint, can include data chunks which aren't needed. PNGcrush removes all data chunks which are not actually needed to display the image.
Removing the gamma correction chunk makes the image always render in normal sRGB. That's what the Internet uses. IE tries to apply any gamma correction information, which usually makes the colours different than the exact same RGB code in a web page. (Since web pages are displayed in sRGB.)
HTTP Caching
Even if you generate an image on the fly, you can tell each visitor's web browser to store that image locally. Their browser won't even request the image again, so long as it still has the local version. This means 0% server resources for subsequent views of the same image by the same user - literally.
Simplest way is to set an
Expires date which is in the future. Make sure you use the right RFC standard date format. It's a weird archaic one, think PHP has a function with a preset for generating it. The timezone has to be 'GMT' but it's actually UTC. Again, PHP has a function to do that magic for you.
Alternatively, you can set the
Last-Modified date header. Browsers will compare that date to the current time to see how old the image is. They'll then guess how long they should wait until they should check the image for changes. They're pretty clever at making a reasonable guess about this. When the guessed time comes up, they'll send a "conditional GET" which includes an
If-Modified-Since header. If your system knows the image has changed since the date of the image that browser has, your system can regenerate the image and send it back. Otherwise, you just return
206 Not Modified with no HTTP body.
You can send both of these headers, but the behaviour of web browsers is not defined. (I should think a definition is being drafted, though.)
