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:

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 🙂

21 thoughts on “Why Front End Performance Matters to Everyone, Not Just the High Traffic Giants

  1. right on.

    By the way, if a developer can’t manage to get better performance, perceived performance by users is also one way to look at it. If you show animations (progress bars for instance while uploading), or use technics like ajax, users will feel that the website is there working for them and the content is coming soon enough.

  2. that’s a great point. Jakob Nielsen talks about that (progress bars, etc) as a way to improve the experience. Users will know something is happening, so they won’t be frustrated waiting for something to happen with no clue as to what’s going on.

  3. I’m all for focusing on performance as much as the next guy, but I think the key point here is how much time you should spend optimizing vs. other things. If it takes you a week to increase performance by 100ms and your sales go up 10%, you have to take the opportunity cost into account…is there a commonly requested feature you could have added or improved on that would accomplish even more? It all needs to be taken into account, and there’s a law of diminishing returns for the non-Yahoo/Google’s of the world.

  4. That’s a really good point. There’s always a balance that has to be struck when looking at any aspect of a well designed system. The good thing is, a lot of the really big performance gainers on the front end are going to be a lot easier to implement than most features, so you can attack the easy options and then get back to adding in all those fun features.

  5. It only makes sense to optimize your site if the cost of doing so pays for itself. For those big sites, that 100ms increase in performance very often pays for itself. For the small sites, the same optimization isn’t likely to be as feasible.

  6. None of the optimizations I’m talking around (since I’m not really talking about the nuts and bolts here) are really all that difficult to implement. If you haven’t, take a look at High Performance Web Sites: Essential Knowledge for Front-End Engineers. Many of the recommendations are pretty straightforward to implement (an hour or two at most) and the biggest one, reducing the number of HTTP requests, is really just a matter of approach.

    Meaning, if, as a front end engineer you say to yourself, “I’m going to minimize the number of files I serve by using fewer CSS and JS files and using CSS sprites” and you stick to that as a philosophical approach, better performance follows for all the sites you touch.

    Just using sprites will, without question, improve your performance by a lot more than 100ms. I did some tests for an internal presentation that showed the difference between using a sprite and using 15-20 individual images. I’ll see if I can dig it up.

  7. Moxley’s right, but at the same time, the optimisations that deliver the biggest benefit at any scale are not that hard or time-consuming to do. A tweak of the server here, some minification there, a different SQL execution plan, all of these are fairly obvious and easy enough to set up for any site.

    Once you get past the obvious, then sure, squeezing the extra juice out of it may become disproportionate to the resulting benefit, especially for smaller sites. The giants may also have far more complicated setups, with multiple servers in multiple locations with a CDN – with more factors, each may have tweaks applied that, together, give the extra 100ms saving.

  8. Yes, at some point you can run out of simple optimizations, but I urge anyone who’s thinking that ALL the optimizations I’ve talking about here are complicated or are the domain only of folks with huge budgets to check out High Performance Web Sites: Essential Knowledge for Front-End Engineers. The book outlines some very basic steps, that pretty much anyone can do to shave, in a lot of cases, whole seconds off of page load time.

    While I am a front end engineer by trade and I do focus on these issues, I’m still just a guy with no budget and limited time when it comes to my own sites. But still, I’m able to build front end optimized sites that generally generate YSlow scores in the 80s and 90s (as long as one’s CDNs setting include my *.cloudfront domains.) A lot of the basics are just that basics. We’re not talking about some mysterious process. It’s just a change in attitude and approach and after that the results just come naturally.

  9. This is interesting, please post more often! Is there a place to donate to your site?

Leave a Reply

Your email address will not be published. Required fields are marked *