building for speed

I am, by nature, a cluttered person. My tiny apartment is about as densely packed with books, magazines, CDs, photographs, electronics, and shoes as is practically possible and socially acceptable.

Living in such a small apartment keeps me disciplined. I'm constantly evaluating my decisions about what I keep and what goes out on the street. Do I really need 15 Avengers videotapes, which take up a cubic foot? Should I buy the DVDs instead? Or toss them altogether? These are the sorts of questions I ask myself regularly.

You have to bring the same kind of rigor to your web site. Web pages have a tendency to expand over time, with more and more links and promotions piling on. And as sites get more sophisticated with dynamic elements and complex applications it's more difficult to keep them running quickly.

Speed is crucial to site success, but it's easy to let it slip.


Speed is crucial to site success, but it's easy to let it slip. This is why every person on your team needs to evaluate every aspect of the site that they touch. So many things affect speed the backend code, the design, the features you include, the servers you buy that everyone's role offers opportunities for speed savings and waste.

"You need everyone to come together and work on site speed," says Pamela Statz, former production manager for HotWired and Lucasfilm. "You can't do it alone."

Speed affects all web disciplines, including

  • Design

  • Engineering

  • Production

  • Infrastructure

design and site speed More than any other factor, the need for speed has shaped what it means to design for the web. There are many constraints on web design: It must be usable, it must be compatible with different browsers and platforms, it must be technically feasible with HTML.

top 10 reasons your site is so stinkin' slow

  1. Pages are just too big and take too long to transfer. Too many graphics, too many scripts, and too much multimedia add up to a long wait for users.

  2. Images are too big and take too much time to transfer. They should be cropped and/or compressed to reduce K-size.

  3. Nested tables in the HTML code confuse the browser, preventing it from drawing or forcing it to re-draw the page.

  4. "Rich media" ads that use Java-based programs take too long to load.

  5. Too many ads on the page slow it down because of their size and sometimes because of the scripts that pull them in.

  6. Width and height aren't specified for images and tables. This forces the browser to either wait for every element to load before drawing the page or to "guess" how much room to leave. If it guesses wrong, the entire page must be redrawn.

  7. Site isn't compatible with all common platforms and browsers, causing the site to sputter and choke for some users.

  8. Servers lack the strength needed to quickly generate results for many simultaneous users. Increasing both the number of servers and their processing power can help.

  9. Bandwidth is insufficient for the number of visitors you're receiving, especially during peak hours.

  10. Inefficient backend code puts way too much strain on the servers, especially for application-based sites like retail stores, banking centers, or even database-driven news sites.


But it's speed, more than anything, that has shaped design aesthetics for the web. Download times put a sharp limit on the number and size of images (or animation or video) a site can use. And certain types of images are smaller and faster than others.

So the best web designers have adapted their style to the medium, using skinnier graphics and other speed-friendly techniques (color, words, placement, pacing) to convey meaning and emotion within a site that's also usable and fast. (See designing for speed, p. 92.)

engineering and site speed Unlike designers, who think of speed only when they're designing for the web (and not, for instance, when they're designing a magazine), engineers are always thinking about speed.

Speed is always on the engineer's mind, because it's important in all kinds of software. Lag-time is never suffered gladly by users, so the aegis is always on engineers to make programs run faster. A wasted second is a problem to be solved.

It's important to bring engineering in early when you're talking about site speed. In fact, you should bring them in early on all product development, because they can identify (among other things) where time can be saved.

Engineers almost always think about speed when they're evaluating a product proposal, according to Noah Mercer, former CTO of Nextdoor Networks: "We'll look at a product specification and say, 'Well, this feature's going to be really inefficient or really slow. So can we do without it? Can we change it? Are there other ways the product could function that would make it happen faster?'"

Sometimes, there's a solution, Mercer says. But sometimes there isn't: "If the answer is 'No. It absolutely has to be this way,' then you look at what it's going to cost you to support that functionality for a specific number of users. And it becomes a business decision at that point."

production and site speed Efficiency is the name of the game in web production. Production managers are always thinking of ways to save time both for themselves and the user.

The best web designers have adapted their style to the medium, using speed-friendly techniques to convey meaning.


Production-wise, templating is perhaps the best way to improve speed. "Plan your web site in terms of what can be templated," says Pamela Statz. "Can you use the same design page after page? Can you reuse assets?"

If you reuse images, animation, and stylesheets throughout your site, the user's browser will only have to download them once. So subsequent pages will load much faster, even though they have the same elements.

infrastructure and site speed The servers that host your site, and the bandwidth available to them, have a direct impact on the speed of your site. So for large-scale sites, especially, it's smart to have a capacity plan in place before you start designing or coding. You should know how many concurrent users you expect at launch, and how you'll scale up.

But don't get too far ahead of yourself. Scaling up too quickly can waste money and time. "As Donald Knuth said, 'premature optimization is the root of all programming evil,'" laughs Greg Dotson, Chief Information Officer of Guru. "Left to our own devices, engineers think, 'This isn't gonna be fast enough if I have a million users!' But you're never going to have a million users! And if you do, you can always throw another server at the problem. Hardware is cheap."

Speeding up your site?

designing for speed, p. 92

preparing images for the web, p. 208

improving site speed, p. 218




The Unusually Useful Web Book
The Unusually Useful Web Book
ISBN: 0735712069
EAN: 2147483647
Year: 2006
Pages: 195
Authors: June Cohen

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net