Load Time, the UX Factor: Facts and Measures

Post from June 21, 2007 (↻ September 23, 2020), filed under Web Development.

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

This post is partially outdated.

Load time of websites seems to remain our industry’s stepchild: One script library here, an unoptimized logo there, plus a complementary video and a 75 KB analytics script on top, voilà, “take this, visitor, 540 KB pleasure for you while I don’t care that these 540 KB will take 1 minute and 18 seconds of your time to download” (based on an optimal 56 Kb/s connection).

The vision is real-time surfing, not spending bandwidth improvements. Here are some things to consider for efficient websites.

Facts

1. 10 seconds is about the limit for keeping the user’s attention focused on a dialogue, according to Jakob Nielsen and other studies. This still holds true, and you might know your own reaction on wait. Consider it boring subjective time, and you’ve got a mix that lets users leave, happily.

2. At the moment, almost 20% of U.S. households still use a narrowband Internet connection, according to Leichtman Research Group (via WebSiteOptimization.com).

3. The average web page size increases by 20 KB per year, according to this author’s empirical data [I don’t know what I meant here]. Users keep on being forced to wait, albeit slightly less due to increasing connection speeds.

Measures

First, please monitor your site’s load time.

1. Most importantly, develop and adhere to a philosophy that keeps things simple and that emphasizes (less to no) latency as an important UX factor. People don’t like to wait, and bad load time is an attribute and problem of your website, not of the Internet.

2. Use HTML elements according to their semantics. Switching from table to CSS layouts might save 50% to more than 60% HTML file size. (Expect easier site maintenance, too.)

3. Question all page elements. Is it really necessary to include your full bio with high-res photographs (nothing against photos, quite the contrary) on every page? Do you really need these (unprofessional) “Valid…” buttons? Do you really need that long Delicious bookmarks list in the sidebar? And so on.

   If you’re unsure: Test your site with users (especially when you don’t usually do any testing); in case of emergency just ask a friend or sibling to contact you via your site or to comment on a post (and sound the alarm when he or she cannot because of the omnipresent blogroll). Guerrilla testing’s better than no testing at all.

4. Now that you abandoned certain page elements, optimize and compress the rest using some

   • graphics optimizer,
   • HTML compressor,
   • CSS compressor, and
   • JavaScript compressor.

5. Enable and optimize caching, though I’ll hand you over to Mark Nottingham and the (somewhat strange) Vancouver Webpages now.

You might want to check your website’s performance again and probably continue reading over at Christian Heilmann and Martin Kliehm. Load time and its impact are a serious matter, and there’s almost nothing more beautiful than a website that loads quickly.

(In case you wonder about this site’s performance—its server’s probably several thousand kilometers away. Let’s track this, too.)

Update (August 18, 2008)

I cannot but point out two recommendable books on that matter as well: On the one hand the “classic” from Steve Souders, High Performance Web Sites (I should write more about the book), on the other hand recently published Website Optimization by Andy King, who reveals some more performance facts on the book website.

About Me

I’m Jens Oliver Meiert, and I’m a web developer and author. I love trying things (sometimes involving philosophy, art, or adventure). Here on meiert.com I share some of my views and experiences.

If you have a question or suggestion about what I write, please leave a comment or a message.

Comments (Closed)

1. On June 25, 2007, 12:38 CEST, Martin Kliehm said:

   Hi Jens, thanks for the sum-up and the link to my performance article. Just yesterday I blogged about the performance rules Nate Koechley gave in his presentation in London two weeks ago. Some of them are new, others just deepen the understanding for performance optimization.

2. On June 29, 2007, 22:51 CEST, Jacques said:

   Just a note on the “optimal” 56 Kb/s. Optimal means all the lanes of the highway are open for just the one traveller. In practice dial-up users NEVER get that throughput as ISPs farm out bandwidth to all their customers. In some developing regions, even if one rents 56 Kb/s, on a busy day throughput is in single digits.

   My Law of Internet Access Waiting Time states that a user will wait according to the Degree of Desperation. Yes, if I REALLY need that info, I’ll wait 10 minutes for a 100KB document to load. But when surfing such users will go away to a site that’s quicker.

3. On July 2, 2007, 11:32 CEST, Laurens Holst said:

   For optimising PNG files I recommend PNGGauntlet.

   It works really really well. It can also automatically convert GIF and JPG images to PNG if the PNG version is smaller, which is usually the case for GIF, and the 1-bit transparency still works in IE even when converted to PNG.

   Using PNGGauntlet to reduce image sizes and move from GIF to PNG can easily cause an overall image size reduction of 10-20%. Try it out on your site’s images directory.

   Now that I’m talking about PNG, might as well mention TweakPNG which allows you to add a bKGD background colour to your PNGs. This is very useful if you want to use PNGs with an 8-bit alpha channel to get transparency, because IE will not show the page’s background colour for those but the colour specified in this field instead (and default to gray if absent).

Read More

Have a look at the most popular posts, possibly including:

• WCAG, HTML, and CSS: Maybe the Standards Need a Break
• A Plea for Better Software: Provide Auto-Save

Looking for a way to comment? Comments have been disabled, unfortunately.