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 🙂
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.
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.
Wow dude, I think you might be onto something here!
Jess
Some interesting statistics, that actually stand to be quite obvious when you think about them.
Good article.
AMEN! The only reason I visit any website is to get whatever information I’m looking for as quickly as possible.
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.
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.
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.
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.
I use Definitehits to deliver my traffic. It is a great website traffic service. You can pay for unique visitors for your website daily and its very cheap too. You can check it out here: http://www.definitehits.com
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.
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.
This is interesting, please post more often! Is there a place to donate to your site?