Google’s Push To Speed Up Your Web Site
Google continues to make a big push for improving your website download performance. Earlier in May Google’s Maile Ohye posted a video on the Google Webmaster Central Blog on the case for speeding up your site, tools for helping you find speed related problems, and some specific speed optimization tips. Some of the more interesting […]
Google continues to make a big push for improving your website download performance. Earlier in May Google’s Maile Ohye posted a video on the Google Webmaster Central Blog on the case for speeding up your site, tools for helping you find speed related problems, and some specific speed optimization tips. Some of the more interesting data points from the video include:
Shopzilla ran an A/B test comparing the impact of the download speed their pages had on conversion. They found that the faster pages delivered 7% to 12% more conversions than the slower pages.
Firefox ran a similar test, and saw a 15.4% increase in conversions. As with Shopzilla, speed was the only different variable in the two pages tested.
Google and Microsoft ran a test and found that an artificially introduced delay of 500 milliseconds reduced user satisfaction by almost 1%. When the delay was increased to 2 seconds the drop in satisfaction was 4%.
In a similar test, Microsoft saw that a 400 millisecond delay resulted in reduced query volume of 0.21%. They stopped the test after 7 weeks, and the query volume went back up, but not quite to the same level as it was prior to the test.
Microsoft ran another test where all they did was enable progressive rendering of their pages. This resulted in a 0.7% increase in satisfaction.
It is often the simple things that will get you. Maile found that it was helpful to enable browser caching, which only requires a little bit of server configuration. On an Apache web server it simply means adding a few lines to the .htaccess file. You can read about how to do that here.
We recently became involved with one website that had seen a drop in rankings and traffic right around the time that Google announced that speed was a ranking factor back on April 9th. Our investigation found that they had been having significant server outages as well as a fairly long average page load time (greater than 5 seconds). While it is not possible to be definitively sure that page speed is the reason for the drop, our investigation has led us to believe that this is in fact the case. We have, of course, addressed the issues and hope to see traffic pop up again soon.
On another site we saw that database optimization was a major need. Once we tweaked the way that was being done, we saw the following change in our site performance chart within webmaster tools:
As you can see, the page load time dropped considerably. Before the change the site was slower than 67% of sites, and now that number has dropped to around 52%. There is still significant room for improvement, and we will soon begin our next round of optimizations on that site.
For e-commerce sites this is likely to be an area worth investigation. Reducing the number of accesses back to a database can result in significant increases in download speed time. Unless you actively considered performance when initially developing a site, you are likely to see some significant gains in this area.
When you consider that Akamai argues that two seconds for your total page load time is the threshold of acceptability for an e-commerce web site, you’re already in deep trouble if your analytics package takes more than 2 seconds to load.
You can read more about other page speed optimization techniques here.
How Does Google use page speed in rankings?
Google has been consistently clear that site speed is only one of 200+ ranking factors, and that more traditional factors such as content and relevance (and links) remain more important factors. One clue that we can take from webmaster tools is how they define fast and slow. If you look again are the site performance chart we showed above, there is line across the chart at about 1.5 seconds. Here Google indicates that 20% of sites on the web are below that line, and the rest above it. In addition, Google has labeled all sites above the 20% line as “slow” and the sites below it as “fast.”
There are a couple of messages here. One is that Google considers your site fast only if you are in the top 20%. Today that means faster than 1.5 second page load time, but tomorrow you might need to have faster than a one second load time. As Maile said, users react to any difference in speed in a subjective way. Chances are that this is all relative too. If the entire web speeds up by half a second, user perception of what is fast will also speed up.
Does that mean that Google punishes all sites over that 20% line and rewards all sites below it? No, it doesn’t. If I were to take a moment and speculate on this, I could imagine something like:
- A small boost for sites in the top 20%
- No effect on sites between 20% and 60%
- A small negative penalty for sites between 60% and 80%
- A larger negative penalty for sites below 80%
This is pure speculation on my part, and it is likely that Google’s algorithm is much more complicated than what I laid out. For example, you can bet that the behavior of the algorithm is frequently tweaked based on user related tests. However, I’d bet the practical impact of how Google uses page speed as a ranking factor is not hugely different than what I laid out above.
In summary, page speed is something you should definitely be concerned about. The conversion metrics alone should convince you. Increasing your conversion rates by 10% or more is a compelling goal. The various indicators of user satisfaction and usage are also important to consider. Ultimately, the primary reason for addressing site performance should be the user.
It also matters from an SEO perspective. After all, given that page speed is a ranking factor, and for many sites improving your speed is relatively easy, why wouldn’t you want to take advantage of that?
Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.