Monday, April 28, 2008

Web 3x and Web Lite

Earlier today, I read this interesting article about the growth of web pages. In short, average web page size has tripled in the last five years.
Yes this swell in page size corresponds very nicely with everyone's favorite cliche, Web 2.0. It is obviously not a coincidence. More features and interactivity is going to be mean more initial download, which is the very coarse metric being used here. What may have been four web pages may now be one Ajax-ified one, whose weight is three times as much. More interesting tidbits.

  • Average page weight: 310 KB
  • Average total JS: 68 KB
  • Average # of external JS files: 7
  • Average # of unique external JS files: 6 (gotta love duplicates!)
  • Average total CSS: 15 KB
  • Average total image pixels: 49,144
  • Percentage of HTTP requests dedicated to images: 75%

That last stat is not really as bad as it seems. Images are (can be) loaded in parallel. There is a limit of connections per domain, however (generally two.) A common trick is if you have to load 20 images all from the same server, trick the browser. Make the first two images from images0.mydomain.com, the next two from images1.mydomain.com, etc. Obviously images0 and images1 point to the same IP address, but you get the gist. The browser will load all of the images in parallel (or close to it.) The one disadvantage is you can lose some browser caching. The browser will think that http://images0.mydomain.com/foo.gif and http://images1.mydomain.com/foo.gif are different images.

The other interesting thing talked about in the article, is that broadband speed has more than kept up with page bloat, err Web 2.0. However, not everybody has broadband, and you are basically suffering now more than ever if you do not. These studies are only talking about home users, what about mobile phones? If you are an iPhone user on EDGE, how do you like 310 KB pages?

It seems likely that we will start seeing "lite" versions of websites in the future. We kind of see this for mobile devices, i.e. m.mydomain.com or mobile.mydomain.com. At some point, will we start directing dial-up users to the lite sites? If you were a dial-up user, how would you feel about that? I'm from the South, so it kind of feels like segregation to me: "equal but separate." 

2 comments:

Anonymous said...

I've been discussing with a friend about lite versions of websites. He believes that HiJax and CSS for handheld vs screens it's enough, and no lite versions should be needed.

I agree that is true in most of the cases, but sometimes you'll want to provide users on mobile devices different content or experience than to regular ones.

But if you do websites the right way, you shouldn't need a lite version.

Unknown said...

I agree with you and your friend, but I think a "lite" sites have some advantages. You are able to specialize the functionality quite a bit on both the lite and full versions of your site.

Let me make an example of Facebook. They could strip things down to what people are most interested in: news feeds from their friends, inbox, events, etc. No or minimal graphics. Obviously no Apps. The data and functionality presented on your Home would be different than in the full version. Ideally they would be able to still advertise on that page, otherwise you risk people using the lite version to avoid ads... That's actually a big problem with lite versions, since often the junk you'd like to strip out are ads...

Once you go lite, you can also forget all about progressive enhancement like HiJax is designed for. It simplifies the development and testing of your main site and frees your designers and product managers. Some might say that is a bad thing!

The other nice thing is that it really forces you to create a more (forgive me for the term) service oriented app. After all, you surely want your full and lite versions to re-use more than just the database. They obviously aren't going to re-use the presentation code, but everything else would be nice. You'll find yourself loosely coupled without even trying.