Just for kicks, I cleared my cookies & caches and loaded up Wikipedia’s “Frog” article fresh to see what the breakdown of network bandwidth would look like…
645,947 bytes of data content are transferred, not counting any HTTP headers:
| 72.5% | content images |
| 10% | JavaScript code |
| 7.5% | style sheets |
| 5.5% | HTML web page < the important stuff |
| 4.5% | UI images |
This would take about 90 seconds to download on a 56kbit connection. It’s easy to forget what low-bandwidth feels like for those of us with broadband, but people outside cities may not have good broadband, and mobile devices are often stuck on pretty slow networks too. Compare regular Wikipedia against our mobile gateway on your mobile phone sometime; even a fancy browser like the iPhone’s will feel like molasses trying to load the full site, while loading things up lickety-split from the more minimal mobile gateway.
Fairly simple compression improvements could save 128kb of that:
- 64k by gzipping JS and CSS files that are currently served uncompressed
- another 64k through smarter compression of thumbnails (animated GIF optimization, use of JPEG for some PNG thumbs)
That would save approximately 18 seconds of download time for our hypothetical low-bandwidth user.
Details at mw:Wikipedia_data_size_test…
Brion, what are the hypothetical GBpm savings of automatically converting images to the correct format on upload and compressing all of these files across all sites? And in dollars?
Perhaps you could post the wikipedia reflow visualization from here. I think it has lots to do with this post (hence this comment) but giving it its own post would be great to show it to the wiki community via your blog and Planet Wikimedia.
That reflow visualization is pretty awesome!
Reflow’s impact on performance is a bit more nebulous to define, and will affect CPU and memory more than network. But it certainly shouldn’t be discounted either.