Preface

Vigilant: alertly watchful, especially to avoid danger

Anyone browsing this book—or its predecessor, High Performance Web Sites—understands the dangers of a slow web site: frustrated users, negative brand perception, increased operating expenses, and loss of revenue. We have to constantly work to make our web sites faster. As we make progress, we also lose ground. We have to be alert for the impact of each bug fix, new feature, and system upgrade on our web site’s speed. We have to be watchful, or the performance improvements made today can easily be lost tomorrow. We have to be vigilant.

Vigil: watch kept on a festival eve

According to the Latin root of vigil, our watch ends with celebration. Web sites can indeed be faster—dramatically so—and we can celebrate the outcome of our care and attention. It’s true! Making web sites faster is attainable. Some of the world’s most popular web sites have reduced their load times by 60% using the techniques described in this book. Smaller web properties benefit as well. Ultimately, users benefit.

Vigilante: a self-appointed doer of justice

It’s up to us as developers to guard our users’ interests. At your site, evangelize performance. Implement these techniques. Share this book with a coworker. Fight for a faster user experience. If your company doesn’t have someone focused on performance, appoint yourself to that role. Performance vigilante—I like the sound of that.

How This Book Is Organized

This book is a follow-up to my first book, High Performance Web Sites (O’Reilly). In that book, I lay out 14 rules for better web performance:

  • Rule 1: Make Fewer HTTP Requests

  • Rule 2: Use a Content Delivery Network

  • Rule 3: Add an Expires Header

  • Rule 4: Gzip Components

  • Rule 5: Put Stylesheets at the Top

  • Rule 6: Put Scripts at the Bottom

  • Rule 7: Avoid CSS Expressions

  • Rule 8: Make JavaScript and CSS External

  • Rule 9: Reduce DNS Lookups

  • Rule 10: Minify JavaScript

  • Rule 11: Avoid Redirects

  • Rule 12: Remove Duplicate Scripts

  • Rule 13: Configure ETags

  • Rule 14: Make Ajax Cacheable

I call them “rules” because there is little ambiguity about their adoption. Consider these statistics for the top 10 U.S. web sites[1] for March 2007:

  • Two sites used CSS sprites.

  • 26% of resources had a future Expires header.

  • Five sites compressed their HTML, JavaScript, and CSS.

  • Four sites minified their JavaScript.

The same statistics for April 2009 show that these rules are gaining traction:

  • Nine sites use CSS sprites.

  • 93% of resources have a future Expires header.

  • Ten sites compress their HTML, JavaScript, and CSS.

  • Nine sites minify their JavaScript.

The rules from High Performance Web Sites still apply and are where most web companies should start. Progress is being made, but there’s still more work to be done on this initial set of rules.

But the Web isn’t standing still, waiting for us to catch up. Although the 14 rules from High Performance Web Sites still apply, the growth in web page content and Web 2.0 applications introduces a new set of performance challenges. Even Faster Web Sites provides the best practices needed by developers to make these next-generation web sites faster.

The chapters in this book are organized into three areas: JavaScript performance (Chapters 1–7), network performance (Chapters 8–12), and browser performance (Chapters 13 and 14). A roundup of the best tools for analyzing performance comes in the Appendix A.

Six of the chapters were written by contributing authors:

These authors are experts in each of these areas. I wanted you to hear from them directly, in their own voices. To help identify these chapters, the name(s) of the contributing author(s) are on the chapter’s opening page.

JavaScript Performance

In my work analyzing today’s web sites, I consistently see that JavaScript is the key to better-performing web applications, so I’ve started the book with these chapters.

Douglas Crockford wrote Chapter 1, Understanding Ajax Performance. Doug describes how Ajax changes the way browsers and servers interact, and how web developers need to understand this new relationship to properly identify opportunities for improving performance.

Chapter 2, Creating Responsive Web Applications, by Ben Galbraith and Dion Almaer, ties JavaScript performance back to what really matters: the user experience. Today’s web applications invoke complex functions at the click of a button and must be evaluated on the basis of what they’re forcing the browser to do. The web applications that succeed will be written by developers who understand the effects of their code on response time.

I wrote the next four chapters. They focus on the mechanics of JavaScript—the best way to package it and load it, and where to insert it in your pages. Chapter 3, Splitting the Initial Payload, describes the situation facing many web applications today: a huge JavaScript download at the beginning of the page that blocks rendering as well as further downloads. The key is to break apart this monolithic JavaScript for more efficient loading.

Chapters 4 and 5 go together. In today’s most popular browsers, external scripts block everything else in the page. Chapter 4, Loading Scripts Without Blocking, explains how to avoid these pitfalls when loading external scripts. Loading scripts asynchronously presents a challenge when inlined code depends on them. Luckily, there are several techniques for coupling inlined code with the asynchronous scripts on which they depend. These techniques are presented in Chapter 5, Coupling Asynchronous Scripts.

Chapter 6, Positioning Inline Scripts, presents performance best practices that apply to inline scripts, especially the impact they have on blocking parallel downloads.

I think of Chapter 7, Writing Efficient JavaScript, written by Nicholas C. Zakas, as the complement to Doug’s chapter (Chapter 1). Whereas Doug describes the Ajax landscape, Nicholas zooms in on several specific techniques for speeding up JavaScript.

Network Performance

Web applications aren’t desktop applications—they have to be downloaded over the Internet each time they are used. The adoption of Ajax has resulted in a new style of data communication between servers and clients. Some of the biggest opportunities for growth in the web industry are in emerging markets where Internet connectivity is a challenge, to put it mildly. All of these factors highlight the need for improved network performance.

In Chapter 8, Scaling with Comet, Dylan Schiemann describes an architecture that goes beyond Ajax to provide high-volume, low-latency communication for real-time applications such as chat and document collaboration.

Chapter 9, Going Beyond Gzipping, describes how turning on compression isn’t enough to guarantee optimal delivery of your web site’s content. Tony Gentilcore reveals a little-known phenomenon that severely hinders the network performance of 15% of the world’s Internet users.

Stoyan Stefanov and Nicole Sullivan team up to contribute Chapter 10, Optimizing Images. This is a thorough treatment of the topic. This chapter reviews all popular image formats, presents numerous image optimization techniques, and describes the image compression tools of choice.

The remaining chapters were written by me. Chapter 11, Sharding Dominant Domains, reminds us of the connection limits in the popular browsers of today, as well as the next generation of browsers. It includes techniques for successfully splitting resources across multiple domains.

Chapter 12, Flushing the Document Early, walks through the benefits and many gotchas of using chunked encoding to start rendering the page even before the full HTML document has arrived.

Browser Performance

Iframes are an easy and frequently used technique for embedding third-party content in a web page. But they come with a cost. Chapter 13, Using Iframes Sparingly, explains the downsides of iframes and offers a few alternatives.

Chapter 14, Simplifying CSS Selectors, presents the theories about how complex selectors can impact performance, and then does an objective analysis to pinpoint the situations that are of most concern.

The Appendix A, describes the tools that I recommend for analyzing web sites and discovering the most important performance improvements to work on.

Conventions Used in This Book

The following typographical conventions are used in this book:

Italic

Indicates new terms, URLs, email addresses, filenames, file extensions, pathnames, and directories

Constant width

Indicates commands, options, switches, variables, attributes, keys, functions, types, classes, namespaces, methods, modules, properties, parameters, values, objects, events, event handlers, XML tags, HTML tags, macros, the contents of files, and the output from commands

Constant width bold

Shows commands or other text that should be typed literally by the user

Constant width italic

Shows text that should be replaced with user-supplied values

Note

This icon signifies a tip, suggestion, or general note.

Warning

This icon indicates a warning or caution.

Comments and Questions

Please address comments and questions concerning this book to the publisher:

O’Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
800-998-9938 (in the United States or Canada)
707-829-0515 (international or local)
707-829-0104 (fax)

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at:

http://www.oreilly.com/catalog/9780596522308

To comment or ask technical questions about this book, send email to:

For more information about our books, conferences, Resource Centers, and the O’Reilly Network, see our web site at:

http://www.oreilly.com

Using Code Examples

You may use the code in this book in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from this book does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.

We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Even Faster Web Sites, by Steve Souders. Copyright 2009 Steve Souders, 978-0-596-52230-8.”

If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at .

Safari® Books Online

Note

When you see a Safari® Books Online icon on the cover of your favorite technology book, that means the book is available online through the O’Reilly Network Safari Bookshelf.

Safari offers a solution that’s better than e-books. It’s a virtual library that lets you easily search thousands of top tech books, cut and paste code samples, download chapters, and find quick answers when you need the most accurate, current information. Try it for free at http://my.safaribooksonline.com.

Acknowledgments

I first want to thank the contributing authors: Dion Almaer, Doug Crockford, Ben Galbraith, Tony Gentilcore, Dylan Schiemann, Stoyan Stefanov, Nicole Sullivan, and Nicholas Zakas. They’ve made this a special book. Each of them is an expert in his or her own right. Most of them have written their own books. By sharing their expertise, they’ve helped create something unique.

I want to thank all the reviewers: Julien Lecomte, Matthew Russell, Bill Scott, and Tenni Theurer. I extend an especially strong thank you to Eric Lawrence and Andy Oram. Eric reviewed both this book as well as High Performance Web Sites. In both cases, he provided incredibly thorough and knowledgeable feedback. Andy was my editor on High Performance Web Sites. More than anyone else, he is responsible for improving how this book reads, making it flow smoothly from line to line, section to section, and chapter to chapter.

A special thank you goes to my editor, Mary Treseler. Coordinating a book with multiple authors is an opportunity that many editors will pass over. I’m glad that she took on this project and helped guide it from a bunch of ideas to what you’re holding in your hands now.

I work with many people at Google who have a penchant for web performance. Tony Gentilcore is the creator of Fasterfox and the author of Chapter 9. He’s also my officemate. Several times a day we’ll stop to discuss web performance. Steve Lamm, Lindsey Simon, and Annie Sullivan are strong advocates for performance who I work with frequently. Other Googlers who have contributed to what I know about web performance include Jacob Hoffman-Andrews, Kyle Scholz, Steve Krulewitz, Matt Gundersen, Gavin Doughtie, and Bryan McQuade.

Many of the insights in this book come from my friends outside Google. They know that if they tell me about a good performance tip, it’s likely to end up in a book or blog post. These performance cohorts include Dion Almaer, Artur Bergman, Doug Crockford, Ben Galbraith, Eric Goldsmith, Jon Jenkins, Eric Lawrence, Mark Nottingham, Simon Perkins, John Resig, Alex Russell, Eric Schurman, Dylan Schiemann, Bill Scott, Jonas Sicking, Joseph Smarr, and Tenni Theurer.

I’ve inevitably forgotten to mention someone in these lists. I apologize, and want to thank all of you for taking the time to send me email and talk to me at conferences. Hearing your lessons learned and success stories keeps me going. It’s important to know there are so many of us who are working to make the Web a faster place.

Thank you to my parents for being proud to have a son who’s an author. Most importantly, thank you to my wife and three daughters. I promise to take a break now.



[1] AOL, eBay, Facebook, Google Search, Live Search, MSN.com, MySpace, Wikipedia, Yahoo!, and YouTube, according to Alexa.

Get Even Faster Web Sites now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.