Quick Technology Index

Share Button

Review of High Performance Web Sites

A Fantastic but Dangerous Book

Let’s jump right to the interesting part.  Why is this book dangerous?  It’s dangerous because it directly tells developers that their systems are slow because the front end web pages are slow and not because of the back end.  It says this in many places.  The book states this is typical “across most web sites” (page 4).  As evidence, it offers an analysis of AOL, Amazon, CNN, eBay, Google, MSN, MySpace, Wikipedia, Yahoo!, and YouTube, which are the top ten web sites in the U.S.  Because of this book, right now, thousands of developers throughout the world are busy trying to optimize their web pages in hope of getting their systems to run faster.  Yikes!

It’s true that most web pages just post relatively static information and the only way to get those pages to go any faster is to follow Steve’s performance tuning advice.  So Steve’s statement is true based on this fact alone, but it’s misleading.  Waiting for static information to load from these kinds of web pages (like any of the web pages at Practicing Safe Techs) is not what consumes much of the day for the average computer user.

It’s also true that most of the web pages on those top ten sites are bottlenecked on the front end.  This is because all of those sites serve out very easy to parallelize data or have colossal backend infrastructure that is designed to effectively cache the entire database. 

Pause for a moment to compare your company to these top ten companies.  Consider Google, which has 200 clusters each with 5000 machines in each cluster.  Does your company have a backend with over a million machines?  No.  Now consider eBay.  In your company, can you easily isolate each transaction from all other transactions?  (At eBay, each auction is effectively independent of all other auctions unlike, say, an enterprise system where transactions have to compete for shared resources - like production machines - before being booked.)  Consider Wikipedia, YouTube, and CNN.  In your company, could you easily divide up the database and distribute that information across multiple machines?  Probably not.

Most companies have thousands of static content web pages, but it’s the web pages that perform backend operations that really drive everyone nuts.  The techniques that Steve describes are about trimming off microseconds from web page load time.  If that’s really your company’s performance problem, then you should purchase as much of your company’s stock as you can afford.  It’ll probably be in that top ten list that Steve analyses for his next edition.


OK – What about the actual tuning advice?

The primary content of the book is really good.  The book is clear, brief, and well-considered.  It’s so short that it will actually get read.  That clarity is immediately obvious in the table of contents, which serves as a great checklist for web developers.  Are there any DNS lookups we could get rid of?  Can we parallelize any requests?  Do we have any Java Script or CSS that we could move around to speed things up?  It’s a good sign when merely your table of contents has a lot of value.

At the end of the book he analyzes the top ten web sites to see how they could speed things up.  What a hoot!  Talk about “reviewing the Gurus.”  This book should be entitled “why our big company should have hired Steve Souders instead of letting Yahoo get him.”

If you're a reasonably experienced web developer, the information in this book will look a lot like the documentation for Firefox's Firebug, and Yahoo!'s YSlow utilities, which Steve discusses in the text. But for guys like me, who do not hang out in YSlow all day, the book is a great summary of basic performance tuning low hanging fruit. I have to admit that I learned a number of tricks that I never knew. (Of course, now that I've read the book, at client engagements I'll pretend I always knew all of these tricks. Clients like hanging out with consultants who know everything and can never be told anything new. There's nothing quite as pleasant as that.)

If you’re a project manager, give this book to your developers once you are in the FINE tuning stage of the project (which frequently never arrives).  If you’re in the GROSS tuning stages, then don’t let them anywhere near this book since they’ll start focusing on the wrong problems.  Bearing this in mind, this book really is the best and most enjoyable front end tuning guide I’ve seen so far.