Why Front End Performance Matters to Everyone, Not Just the High Traffic Giants
Yeah, Even to You.
I suspect it's because the people that are most vocal about the subject are from places like Google and Yahoo!, but it seems to me that a lot of people think that front end performance really only matters for extremely high traffic sites. When talking about these kind of things with other engineers at conferences and the like I've heard something similar to the following a few times and it left me scratching my head:
"That stuff is for the Googles of the world. We don't really need to focus on that with what we do."
Where "what we do" has been anything from working full-time on a web app to building marketing sites for clients large and small.
Even people who really ought to know better get it wrong. When speaking about the number of files present in a CSS framework (and referencing performance rule #1), a certain CSS guru said something along the lines of "Yahoo! found that at their scale, this kind of thing becomes important. You don't need to worry about it."
Which is simply wrong.* You do need to worry about it. Just because it's Yahoo! and Google that are most vocal about these issues, it doesn't mean that their scale is the factor that makes performance important. What their scale means is that they can have dedicated performance teams and can spend time researching best practices. The benefits of better front end performance are for everyone with a web site.
Why? Well, if you approach it from the correct side of the issue (the one not focused on the size of the messenger), front end performance is really about the smallest web scale possible- the experience for a single user. (Even more importantly, many of the techniques are focused on the vitally important first time user.) While it's true that Google and Yahoo! can save big money in bandwidth by shrinking a heavily used file or two down by a couple of kb, and people with busy machines can save some cycles and connections by serving leaner sites, the real takeaway is NOT the bandwidth, processor or connection savings, it's the user experience gains. With better performance, you improve the overall experience of your site. All things being equal a site that responds more quickly to user commands is going to feel "better" than one that is sluggish.
So, if you speed up your site, people are happier with you, your brand or your service and, as the big boys have shown us, they do more.
Here are some oft-quoted numbers:
- Amazon found that +100 ms increase in response time equaled -1% sales (warning opens Powerpoint)
- Google found that +500ms response time meant a 20% reduction in searches
So, Marissa ran an experiment where Google increased the number of search results to thirty. Traffic and revenue from Google searchers in the experimental group dropped by 20%.
Ouch. Why? Why, when users had asked for this, did they seem to hate it?
After a bit of looking, Marissa explained that they found an uncontrolled variable. The page with 10 results took .4 seconds to generate. The page with 30 results took .9 seconds.
Half a second delay caused a 20% drop in traffic. Half a second delay killed user satisfaction.
- A 30% reduction in file size generated 30% more map requests
The same effect happened with Google Maps. When the company trimmed the 120KB page size down by about 30 percent, the company started getting about 30 percent more map requests. "It was almost proportional. If you make a product faster, you get that back in terms of increased usage," she said.
What's the important takeaway there?
Faster sites mean users do more stuff.
So, whatever stuff you want them to do, be it buy, browse,or blog, they're going to do more of it if you can get them there faster.
And who doesn't want that?
*and he may have misspoke, which is why I'm not outing him




