Level: Introductory Peter Seebach (crankyuser@seebs.plethora.net), Writer, Freelance
07 Jul 2005 Page bloat is so common most users don't even wonder anymore why their favorite Web sites take so long to load; they just wait it out. The cranky user takes on long download times this month, and offers tips and incentive for doing better next time.
Recently I very much wanted to find out the hours of a large video
store. It was Sunday evening and my friend and I were already in the car
and driving there in the optimistic hope of obtaining the last season's collection of Buffy the Vampire Slayer. Conveniently, my cell phone is equipped with a fairly useful Web browser capable of downloading data at just over 10 kilobits per second.
Unfortunately, we got to our destination long before I could successfully glean the store's hours from its Web site.The site was simply overrun with trivial, bloated pages. By the time I parsed through them all on my portable device I probably could have walked to the video store rather than driven.
At the very least I would like the essential information up front: phone number, location, and hours still do make a difference when running a business on physical time. At best I want to see that site, and others like it, pruned of the page bloat that made my Web search useless.
This month I'll explain the downsides of putting too much information
on your Web pages and offer some tips to put a lid on page bloat.
Think mobile!
For anyone who builds a Web site, the first consideration is who will use it. If you build a site for a retailer, take it for granted that some users will scan its pages for a physical address; and some will do that on portable devices.
You might think a machine with a processor that runs solidly at over 100 MHz, and 32 MB of RAM can easily display a reasonably large page, but this isn't always the case. My cell phone's built-in browser frequently gets about 200 KB into a page before displaying the message "This page is too large to be displayed." Certainly, a more flexible browser would help -- I would happily sacrifice much of the phone's otherwise unused storage to display larger pages -- but the fundamental problem, in my opinion, lies with the page design. Why does the store locator page chew up 200 KB? What do I get for my trouble? An HTML form could give me the information I need with just 2 KB.
Pretty equals pricey
A major component of page bloat is all the add-ons that supposedly make pages pretty. I learned this first-hand when an online community that I participated in
developed a PDA version that stripped out all the tables, layout, graphics, rollover menus, and other extras that slowed down the Web version
for mobile users. Even with a 3-GHz computer on broadband, I felt the performance difference. For page loads that took 10 or 20 seconds in the glitzy version, the time was cut in half.
 |
Tip: Try it in CSS
Used correctly, Cascading Style Sheets (CSS) can dramatically reduce the size of your pages. If you specify rendering hints once and then incorporate them by reference throughout a page, you can make a huge difference in page size.
|
|
The use of images for buttons is one of the consistent nuisances of the Web. Images are orders of magnitude larger than the text for most buttons, inaccessible to many users, either illegible or too big on small browsers, and require separate HTTP transactions to download. And frankly, I haven't seen many graphicly designed buttons that are worth all the trouble.
In general, the more code you put into making the page look a certain way, the more time a user spends wondering why the page hasn't loaded yet. For example,
the store locator page that started me on this month's topic was packed with large menus carefully rendered in alternating color schemes. Every menu had a substantial chunk of extra code to change the way it looked, which I suppose
someone thought made the Web site seem exciting and daring. The net result was a painful display of angry fruit salad.
Exercise caution when coding for effect. Remember the price you'll pay
in download time and ask yourself whether the effect is really worth it.
Animated annoyances
The more your page moves, the more annoying it is. Animated pop-up menus are consistently awful. Never mind that they don't work on devices (such as my phone) that don't handle JavaScript. They're just plain annoying. One nice thing about a well-designed Web page is to see what you're looking for because the page has been rendered. Having parts of the page render and disappear without warning is obnoxious.
With an actual HTML-form pop-up option object, I at least have some visual cue that there's to be a menu. JavaScript-based menus that pop up when the mouse comes near them, or even when I click on something, are less helpful. Worse, they always show up at exactly the wrong time. I am probably clicking on your menu because I thought it was a link to something I wanted. I want that page, the one I just tried to click on the link to, not the weird, animated menu on this page.
Animated menus also encourage the catastrophically bad behavior of including hundreds of links on a page. In a browser that doesn't bother to render the menus as pop-ups this can leave me with 10 screens full of menu items to scroll past on my way to a single line of text. Likewise, animated menus make a page much bigger than it appears. The unusable store locator's angry fruit salad effect came partially from a very large collection of menus that were probably not intended to all render at once.
Server-side slowdown
Strictly speaking, server-side processing isn't bloat to the end-user. It's
not my problem whether I'm getting a static page or one generated through
a couple thousand database accesses. But, in fact, dynamic pages tend to be
slower to load because they're slower to generate. The server can't cache
the page and just throw it out over the wire.
Even if a page must be dynamically generated (say, if it contains search
results), it's still beneficial to limit the scope of dynamic content. Every
database lookup or external program run is a bit more system load on every
single page view. Worse, every database lookup or external program run is a
potential point of failure. The only thing more frustrating than a page that
fails to load due to an error in a database lookup is a page that fails to
load due to an error in a totally unnecessary database lookup.
False consensus effect
It may seem that most users have browsers that can easily handle all these large pages I'm complaining about. That's true; most users do. However, I suggest a couple of good reasons to not casually dismiss the exceptions.
The first issue is that users who have limited capabilities are among those most likely to be in a hurry or under stress. If I'm using my cell phone's Web browser, it's because I'm out of the house trying to get something done; this is the time when it matters most to me that a page be accessible and responsive. The second issue is the question of bandwidth. Even with bandwidth as cheap as it is, many companies are concerned about the difficulty of keeping their servers up under load. Reducing the amount of load is a good start on keeping up with it, don't you think?
At the heart of the problem is the tendency of Web developers to test on high-end workstations with Ethernet connections to unloaded test Web servers. This is unrealistic at best. Often, even developers making an effort to test with less powerful systems are still subject to the false consensus effect, tending to see broadband and powerful computers as much more common than they are. It's easy to think of a small machine as one with only a 1.8-GHz processor, 512 MB of RAM, and a 1024 x 768 true-color display (after all, those specs are all worse than the ones on a laptop I got two and a half years ago!) but the fact is that many users -- especially mobile ones -- are still working with far less.
In conclusion
Page bloat hurts both developers and users. It will continue
to cause problems until developers firmly weigh the benefits of
proposed page enhancements.
Even if you must code for effect, at least decide up front which pages absolutely must work well and code them for simplicity. Keep pages, such as contact information and retail store locators, small and
simple enough to render cleanly on any browser. The sanity you save may be your own.
This week's action item: Try a few common tasks (order pizza or check for store locations and hours) on a restricted browser; turn off your browser's JavaScript, use a cell phone, whatever it takes. For extra fun, try it on dial-up. Are these tasks as easy and convenient as you think they should be? Why, or why not?
Resources
About the author | 
| | Peter Seebach has been using computers for years and is gradually becoming acclimated. He still doesn't know why mice need to be cleaned so often, though. Contact Peter at crankyuser@seebs.plethora.net |
Rate this page
| 
