Interview with Web optimization expert Andy King

Written by Adrian Holovaty on March 10, 2003

Andy King, author of the new book Speed Up Your Site: Web Site Optimization, was kind enough to chat with me over e-mail about Web optimization -- making pages load and work efficiently -- and how it applies to news/information sites and weblogs.

Andy founded WebReference.com and Javascript.com, two of the most respected Web development sites. He's written a wealth of articles on Web development, optimization, scripting and design -- many of which, as I look back, I specifically recall reading and printing out over the years. If you haven't checked out Andy's book, you really should. He's made three chapters available online.

The interview:

OK, so you're willing to do this interview with me about how your optimization tips apply specifically to news Web sites. *Are there* any optimizations that are particularly relevant to news sites? Is the typical news-site design particularly vulnerable to a certain type of bloat?

News sites generally dispense news in the form of text: headlines and decks, which then point to full stories. The three main problems I've seen with news sites (which include blogs) are old-style formatting, large decks and overuse of graphics and advertising. Some news sites still use tables, font tags and single pixel GIFs, which can be inefficient. Switching to high-level CSS selectors and CSS layout control can make a big difference in size and speed. Even without updating to CSS layout you can optimize your (X)HTML to help cure the slow-loading blues.

Headlines should be descriptive, short and sweet. Decks (or "blurbs" as we call them) should be concise and summarize the story in a sentence or two. On blogs the deck is sometimes the story itself, but users skim at first, so long decks can slow them and your pages down. Overuse of images is common, especially for graphic rollovers, but can kill 56Kbps connections due to all the HTTP requests. Most home users in the US are still at 56Kbps or less (67.5% as of Jan. 2003 according to Nielsen//NetRatings), so it is a good idea to design for speed. You can now substitute CSS rollovers and be confident that the most of your users will see them.

Overuse of advertising? I certainly agree with you there. How much is too much?

At a certain point users will reject a multitude of banner ads. I'd say after three or four good-sized banner ads you start to get to the point of diminishing returns. At 10K or so each (some rich-media ads can be much larger), that is 30 or 40K to deal with. On slower connections, this can bog down your pages, especially when the dimensions are not specified. I prefer seeing one or two ads, and some studies I've read agree.

Adam Smith's "invisible hand" will ultimately determine this. It's the classic tradeoff: In the short run, sites can make more money per page view with more ads. But over time they'll lose users who bail out of their slow-loading pages. That is, unless you switch to text ads like Google's AdWords.

Let's move on to content matters. Some news sites (e.g. the New York Times) split lengthy stories over several pages. From an optimization perspective, what do you think of this practice?

I think it is a good idea for longer stories. Breaking up longer stories can ensure that each page will load in under 8.5 to 10 seconds (about 30-34K total for 56Kbps modems). But you don't want to "overchunk" your content. After about the fourth or fifth page we found that readership falls off dramatically. For shorter stories, users prefer everything on one page. Ideally you'd provide a "chunked" story and a one-page printable version.

How short is too short? How "chunked" is too chunked?

Ah, the paging versus scrolling issue. This is a complex topic with lots of variables at play. There are a number of studies out there, and some rule-of-thumb guidelines. Nielsen has softened his "users don't like to scroll" stance, as we've become used to some scrolling.

For longer texts (4 to 6 screens), some studies have shown that users read faster paging from screen to screen and more importantly find information faster paging, rather than scrolling one long document. However, a SURL study found that paging through short pages took significantly longer to read than a "full" or "scrolling" condition.

A screen-full of text seemed to perform best (the author estimates that the optimum page length is about 700 words). I've seen recommendations up to 2 to 3 screens for the length you want to make individual pages in a longer document.

Here are two places to find out more:

Is your "8.5 to 10 seconds" guideline more applicable to a news home page, or a specific story page? Have you found users tolerate longer download times for one over the other?

When researching the book I found that the consensus was that without feedback, make your pages load in under 8.6 seconds (I rounded down a bit :). This is an average, but a good guideline. I've even seen studies recommending 4-6 seconds, where attitudes towards the site bottom out at 8 seconds. Familiarity, perceived complexity, feedback, and age are some of the factors that can lengthen the acceptable delay. In their second "Need for Speed" study, Zona Research recommended shaving load times by 0.5 to 1.5 seconds for dynamic sites. That's where the name of Chapter 1 came from, "Response Time: Eight Seconds, Plus or Minus Two" (a somewhat tongue-in-cheek homage to Miller's classic work).

I recall reading a study that found that once users arrive at a "destination" page they will tolerate longer delays. Say, for example a multimedia Flash presentation. But for most pages like home pages and gateway pages you've got to make them load quickly. Users don't read your home or gateway pages; they're looking for something interesting to click on. For news stories, as they are mainly text, users expect them to load quickly.

What's the best way of presenting photos related to a news story? Embedding them in the story? Presenting thumbnails that link to larger versions? Isolating them into photo galleries?

Thumbnails that link to larger versions. For news stories, you can often get away with larger thumbnails, as there are usually only one or two images -- unlike, say, a photo site.

Do you advocate creating "high-bandwidth" and "low-bandwidth" versions of sites?

Yes, for high-bandwidth sites of course. Most of the major news sites I tested offer streamlined text-only or low-graphics versions. Some offer RSS feeds, which are very efficient to view in news readers. Ideally you'd design your pages to be so fast that you wouldn't need a "light" version.

Rich markup, such as abbr and acronym, adds a good deal of semantic meaning to HTML documents -- but, obviously, at the cost of extra code. Is it worth it?

Yes, I'm all for marking up your text semantically with these content-based style tags and styling with CSS rather than festooning font tags or using physical style tags like <big> or <blink>. You can take this too far, of course.

How far is too far?

By doing things like <div class="mainnavigationbar activestate etc."> and using verbose HTML/XML tagging.

I noticed Chapter 13 of your book touches on "PDF Optimization." When should news sites use PDF, and when shouldn't they? And, from an optimization perspective, what are your thoughts on the practice of some newspapers to offer everything in PDF instead of HTML?

We show how to optimize PDFs in the Multimedia Chapter because they have become so popular on the Web (Google has indexed over 20 million PDF files). There are a lot of fat, unoptimized PDFs out there. For white papers and research reports they work well, where you need precise control over layout, fonts, and printing. For normal news stories, HTML is smaller and faster to display. For a newspaper, offering only PDFs defeats the purpose of HTML. I'd at least recommend offering both, and consider auto-generating your PDF files.

In your WebWord interview, you called Yahoo the "most highly optimized home page" you've seen. Can you think of any news sites that do a particularly good job of keeping their pages optimized? It's OK to say no.

No, just the opposite. I tested ten of the top news sites for you; they average over 145K for their home pages. Some are nearly 200K, and all could use some optimization. Perhaps they think we're all on broadband. But for home users, 67.5% of us are still plugging away at 56Kbps or less, as my Bandwidth Report shows:

http://www.websiteoptimization.com/bw/

There are some notable exceptions, however. Wired is much improved after their CSS redesign. Their 26K home page (HTML) loads pretty quickly, but could still stand some more optimization. I prefer the news aggregation sites and blogs. They usually load faster with more recent news, and have more personality.

OK, final question. For journalists, the Web has always promised seemingly infinite storytelling space -- something newspapers, TV stations and radio stations have never had. Yet, just as online journalists are beginning to take advantage of the medium, folks like you are saying, "Gotta keep the pages lean. Gotta make it download fast." Obviously, that limits the sorts of things journalists can do. To what degree should online journalists let optimization considerations limit their work?

You touch on a great point. The Web is only limited by the hard drive(s) your site is stored on, print is strictly limited by story inches. Have you noticed a tendency to ramble on a bit online? If you want to retain your readership you've got to curb that urge, at least on your front page. The way around that dilemma is to give them tight descriptive teasers that link to longer stories.

Writing compelling headlines and decks, or "blurbs" as we call them, is an art form in itself. At WebReference we used to see who could "out-blurb" each other in one or two sentences. The folks at ClickZ.com are especially good at this. I always look forward to seeing what they come up with next.

Once inside the story proper, the same things you learned in school apply. Just because your writing palette is virtually limitless doesn't mean you have to fill it up. I'd say a good guideline when you are writing is to always keep your readers in mind. This is a huge topic, so for all bloggers and journalists I would recommend two books: "Hot Text: Web Writing that Works" and "Wired Style." They're both excellent reads and will improve your writing for the Web.

Comments

Posted by Jay Small on March 11, 2003, at 3:54 a.m.:

Good interview, great subject matter. I like it when a design discussion gets below generalities.

Posted by Andrew on March 11, 2003, at 5:25 a.m.:

It's great to see Andy's book getting exposure. With just about every developer possessing a speedy connection, optimization is far too often glossed over or ignored altogether.

Posted by anonymous on March 14, 2003, at 4:44 a.m.:

your forgot to mention Content Encoding: based http compression, a la mod_gzip.

all modern browsers support this very well, and it can speed up page load time

_considerably_, even over broadband.

Posted by Bryan Crumpler on April 27, 2003, at 10:40 p.m.:

Great article! Fantastic info all loading in a matter of seconds! My freelance biz, WhosThatGuy.com, is dedicated to producing modem-friendly websites considering the modem still beats out broadband by a LONG shot. By 2008, the number of broadband users will only be somewhere around 55%, and I can only imagine how much companies will lose out over the next 5 years by employing web firms & web designers with only Dreamweaver-esque skills, knowing little to nothing about the coding or intricacies of web optimization. The bottom line is the users want information... If it can be encased in a sleek, fast-loading design, so be it. Web optimization will always be needed until they hit 8-track status.

Posted by Edward Vielmetti on January 26, 2006, at 4:46 a.m.:

Andy has a new Bandwidth Report out at http://www.websiteoptimization.com/bw/0601/

US Broadband is at about 65% of home users, and China will have the most total broadband subscribers (90% growth rate!) by the end of the year.

Comments have been turned off for this page.