For about a year google chrome supports arithmetic jpegs (on average 7% smaller than normal jpegs).
Since firefox 3.0 (and similar geckos) and opera 9.5, these browsers support APNGs. Animated gifs can be converted to apngs with a far better compression ratio.
Unfortunately the aforementioned browsers do not advertise this support via http headers.
Given that, is there a way of changing (rewrite) the image source urls using javascript before the image even start to load the following way?
image.jpg (normal jpeg) → image.jpeg (the arithmetic encoded one)
image.gif (assuming that gifs are only used for animations) → image.apng
The rewrite would be made based on javascript browser sniffing and executed client side.
Doing the sniffing and replacing on the client side tends to bump into problems with browser’s look-ahead parsers (they will start downloading the images well before your javascript gets a chance to swap them out).
It’s not a great answer but this kind of thing is sadly best done by UA sniffing and server-side logic (and one of the strongest cases for needing some form of optimization automation on the server side). Data URI’s for embedded images pretty much fall into the same camp.
You would want to extend the same logic to include jpeg->webp for Chrome and Opera since they are generally significantly smaller than even arithmetic jpeg’s.
Unfortunately, doing it server side means that the header Vary: User-Agent must be sent, which pretty much would negate the optimization, due to lost cacheability on proxies.
IMO the sane way of doing this, would be the browser sending an appropriate header advertising the support for certain types of images. Accept-Encoding or Expect might be good candidates, if browsers could reach a consensus… or complete what they started.
Arithmetic jpegs or APNGs are no brainers, as they are lossless transformations.
With some lateral thinking, I believe that it can be done client side with javascript and with “no” delays concerning look-ahead parsers.
The trick is to use the Cookie header as a custom Accept header (assuming that no other cookies are sent to that subdomain or path), set it with javascript (for instance accept=[|jpeg|apng|jpeg,apng]) and set the header Vary: Cookie server side.
As there is a very limited number of values for the cookie, cacheability by intermediate caches shouldn’t be destroyed.
Do someone know how intermediate caches behave with respect to the header Vary: Cookie?
How about doing the detection server-side using the UA string on the html itself (assuming it is not cacheable in your case) and then just reference the different image types by different file names? That way the static resources are still 100% cacheable. This is pretty much what the accelerator solutions do but it shouldn’t be too hard to bake the logic directly into an app.
Unfortunately I’m trying to further optimize a section of a site with static pages [cacheable for 3 months], which have quite a lot of images and has google analytics. As a consequence I can’t use the cookies solution, because the images are on the same domain of the HTML pages.