One of the sites that inspired me to really jump into the deep end and take this long, strange and rewarding journey related to image optimization was Google Maps. It’s obviously map-related, and if there is a mapping site/service out there which consumes more bandwidth per day than Google Maps (due to the volume of site traffic), I’ve likely yet to see it.
I revisited the Google Maps site this weekend to see what improvements have been made to the service from the perspective of image optimization. I began by looking at a few graphics that are standard for most views:
Unoptimized 147×935 pixel .png sprite graphic – 20,065 bytes
Optimized 147×935 pixel .png sprite graphic – 20,017 bytes
Unoptimized 59×492 pixel .png sprite graphic – 2,767 bytes
Optimized 59×492 pixel .png sprite graphic – 2,286 bytes
Unoptimized 20×374 pixel .png sprite graphic – 2,554 bytes
Optimized 20×374 pixel .png sprite graphic – 1,569 bytes
Unoptimized 37×34 pixel .png sprite graphic – 665 bytes
Optimized 37×34 pixel .png sprite graphic – 531 bytes
Unoptimized 142×131 pixel .png sprite graphic – 8,493 bytes
Optimized 142×131 pixel .png sprite graphic – 8,086 bytes
I took a very conservative approach to those images, leaving the number of image colors alone and simply defragging each file using PNGSlim. Modest results for those five images…as 33.7 KB of imagery was reduced to 31.7 KB in cumulative size, an improvement of six percent. Still, 2 KB per visit, multiplied times the number of visits with a clear browser cache on a daily basis, and you are talking about quite a bit of bandwidth savings over time!
Obviously though, the great and elusive “white whale” of image optimization associated with the Google Maps site are those millions upon millions of 8-bit .png image tiles! I’ve snooped around their tiles before to see what might be possible, but I figured I would give it another go.
I decided to look at the default tiles that appear when viewing Palo Alto, California, USA in Google Maps in my browser window at 1024 pixels wide. 16 image tiles. 365 KB in cumulative file size. I then decided to perform two simple experiments:
1. Run all pre-existing image tiles as-is through PNGSlim’s batch .png optimization process.
2. Convert all image tiles to 6-bit (64 colors), then use PNGSlim to defrag the images further.
Experiment #1 was easy enough. Not much work or effort on my end, except for the fact that the naming convention Google uses for its tiles weren’t working in PNGSlim, for some reason. I subsequently had to temporarily change each file’s name, run the procedure, then change all file names back to their original names. The end results were interesting. Those 16 optimized images were able to be reduced to 329 KB in cumulative size, an improvement of 9.87 percent.
Coincidentally, I also decided to run several of those image tiles through punypng as well, to see what results that tool might achieve. punypng was able to generate file size reductions of approximately 5.5 percent…roughly half the savings of using PNGSlim.
Experiment #2 is a bit more controversial. Google Maps tiles in my sample group were using anywhere from approximately 40-170 colors in them. However, my contention is that 64 colors should be PLENTY of colors 99.9% of the time. I tried a similar experiment with OpenStreetMap tiles approximately two years ago, and their staff had similar doubts about 6-bit color. “Not enough colors” was what I was told in response…so I asked for them to send me a few tiles that they believed would require more than 64 colors. I re-ran the experiment again, and showed them 64-color versus 256-color tiles, and there was no discernable difference between the two…other than a substantial decrease in file size.
My same contention with Google Maps tiles holds true. I believe 64 colors is more than enough to display their imagery, and re-ran my optimization procedures accordingly. Those same 16 sample image tiles of Palo Alto, saved to no more than 64 colors and then optimized using PNGSlim, resulted in a cumulative file size of 253 KB, an improvement of 31 percent from the original tiles, and an additional 23 percent improvement from the tiles using 8-bit color when processed using PNGSlim.
CONCLUSION: If Google did nothing but run their image tile inventory through PNGSlim, they could immediately achieve download/display and bandwidth savings of approximately ten percent. However, if they could also be “sold” on the value of converting all their tiles to 64 colors (or less), they could likely achieve a 30+ percent reduction in download/display time and bandwidth…which would likely mean an average savings of bandwidth in an HOUR that would far-exceed all of the bandwidth consumed by this GraphicsOptimization blog site in the typical YEAR. 
I’m not sure if Google will take any of this to heart! However, if they are ever looking for a little help in this department, I can’t think of a better way to make a King Kong-sized dent in global bandwidth consumption than to spend a few months working to put their map imagery on a diet. Then once we got their Maps tiles in-order, we could start chipping away at their StreetView imagery, their Google Earth imagery, etc. One step at a time though…
