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.
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
HeaderRule 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:
Chapter 1, Understanding Ajax Performance, by Douglas Crockford
Chapter 2, Creating Responsive Web Applications, by Ben Galbraith and Dion Almaer
Chapter 7, Writing Efficient JavaScript, by Nicholas C. Zakas
Chapter 8, Scaling with Comet, by Dylan Schiemann
Chapter 9, Going Beyond Gzipping, by Tony Gentilcore
Chapter 10, Optimizing Images, by Stoyan Stefanov and Nicole Sullivan
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.
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.
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.
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.
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
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:
bookquestions@oreilly.com |
For more information about our books, conferences, Resource Centers, and the OâReilly Network, see our web site at:
http://www.oreilly.com |
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 permissions@oreilly.com.
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.
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.
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.