Over at Marketing Technology Blog, Doug Karr has written a post about a proposed change in Google's ranking algorithm that would take into account page load times. Under the new system, sites whose pages load faster would get a boost.
In the WebProNews interview cited by Doug, Google engineer Matt Cutts says that the change is backed by several Google engineers who believe speed should be a differentiating factor. Doug says that he is skeptical of Cutts' claims, arguing that it is spin, and the more likely reason is that Google is not wanting to make the investments in bandwidth and computational infrastructure to do more sophisticated forms of crawling.
I have to disagree respecfully with Doug's hypothesis because the assumptions don't match Google's operational profile. If you look back on the trajectory of Google's path to success in search, it is tied largely to their devotion to a couple of simple principles:
It's also the motivation behind the Caffeine indexer, which is being slowly rolled out to its data centers. By their own admission, rankings don't shuffle that much, but the algorthms behind the indexer get their results more quickly, which has real value both to Google and searchers.
Although Google is arguably the 800 lb gorilla of search, and it has been remarkably adept at leaving its competition in the dust over the past decade or so, it also has to compete in a volatile marketplace.
The cost of migrating to a different search engine is miniscule compared to similar migrations in automobile makes or operating systems. Change a bookmark or download a new browser toolbar, and you're done. Google won't have the luxury of marketplace inertia like the Big Three automakers or Microsoft.
To me, Doug's theory would make a lot more sense if Google was a company that was counting on market inertia for survival. A company that has a lot of cash and is hellbent on staying ahead of the competition isn't about to sit on its laurels and let it's crawling algorithms stagnate. Google has an engineer's mindset, not a the mindset of a miserly accountant.
I think the more appropriate interpretation is this. If your job is to develop a system of algorithms that determine how useful a page is for someone who is interested in a set of concepts, one has to take into account the question, "In what ways does a site suck?"
Google has attacked the content problem relentlessly, trying its best to weed out sites which attempt to weasel in higher rankings without providing real usefulness to the user. Now Google is turning its eye toward presentation. In other words, is the payload for the content being delivered to the user in a way that doesn't require relatively large amounts of time? This approach is innovative because it places value on the web searcher's time.
Another place where I disagree with Doug is the question of cost improving speed. Achieving faster page load times doesn't necessarily require that you invest in high end technologies that are used by the big sites. The tools for measurement and remediation are out there, and in many cases they are free (as in beer).
For the case of measurement, Yahoo provides YSlow, and Google offers PageSpeed. These tools give you quickly produced report cards that can help you decide where to channel your efforts.
Some low hanging fruit include turning on HTTP compression on your web server and slimming down the content of a page to what's really necessary. Minfying JavaScript with tools from Yahoo or Google is easy to do and helps with load times as well.
The next steps usually involve reducing the number of HTTP requests by doing things like asset rollups, where JavaScript and CSS files are bundled together, and using CSS sprites, which combine several frequently used graphics into a single image that are then displayed via CSS properties.
Moving your static assets to a content delivery network isn't all that astronomical anymore. You can use low cost CDNs like SimpleCDN or Amazon's CloudFront. If you have fine-grained control over your web server, take a look at how your server uses HTTP caching headers to ensure browsers are making the best use of their caches.
My advice to worried webmasters would be this:
In the WebProNews interview cited by Doug, Google engineer Matt Cutts says that the change is backed by several Google engineers who believe speed should be a differentiating factor. Doug says that he is skeptical of Cutts' claims, arguing that it is spin, and the more likely reason is that Google is not wanting to make the investments in bandwidth and computational infrastructure to do more sophisticated forms of crawling.
I have to disagree respecfully with Doug's hypothesis because the assumptions don't match Google's operational profile. If you look back on the trajectory of Google's path to success in search, it is tied largely to their devotion to a couple of simple principles:
- be better than anyone else at delivering timely and relevant search results
- if state-of-the art tech isn't up to the task, build something new that does the job
It's also the motivation behind the Caffeine indexer, which is being slowly rolled out to its data centers. By their own admission, rankings don't shuffle that much, but the algorthms behind the indexer get their results more quickly, which has real value both to Google and searchers.
Although Google is arguably the 800 lb gorilla of search, and it has been remarkably adept at leaving its competition in the dust over the past decade or so, it also has to compete in a volatile marketplace.
The cost of migrating to a different search engine is miniscule compared to similar migrations in automobile makes or operating systems. Change a bookmark or download a new browser toolbar, and you're done. Google won't have the luxury of marketplace inertia like the Big Three automakers or Microsoft.
To me, Doug's theory would make a lot more sense if Google was a company that was counting on market inertia for survival. A company that has a lot of cash and is hellbent on staying ahead of the competition isn't about to sit on its laurels and let it's crawling algorithms stagnate. Google has an engineer's mindset, not a the mindset of a miserly accountant.
I think the more appropriate interpretation is this. If your job is to develop a system of algorithms that determine how useful a page is for someone who is interested in a set of concepts, one has to take into account the question, "In what ways does a site suck?"
Google has attacked the content problem relentlessly, trying its best to weed out sites which attempt to weasel in higher rankings without providing real usefulness to the user. Now Google is turning its eye toward presentation. In other words, is the payload for the content being delivered to the user in a way that doesn't require relatively large amounts of time? This approach is innovative because it places value on the web searcher's time.
Another place where I disagree with Doug is the question of cost improving speed. Achieving faster page load times doesn't necessarily require that you invest in high end technologies that are used by the big sites. The tools for measurement and remediation are out there, and in many cases they are free (as in beer).
For the case of measurement, Yahoo provides YSlow, and Google offers PageSpeed. These tools give you quickly produced report cards that can help you decide where to channel your efforts.
Some low hanging fruit include turning on HTTP compression on your web server and slimming down the content of a page to what's really necessary. Minfying JavaScript with tools from Yahoo or Google is easy to do and helps with load times as well.
The next steps usually involve reducing the number of HTTP requests by doing things like asset rollups, where JavaScript and CSS files are bundled together, and using CSS sprites, which combine several frequently used graphics into a single image that are then displayed via CSS properties.
Moving your static assets to a content delivery network isn't all that astronomical anymore. You can use low cost CDNs like SimpleCDN or Amazon's CloudFront. If you have fine-grained control over your web server, take a look at how your server uses HTTP caching headers to ensure browsers are making the best use of their caches.
My advice to worried webmasters would be this:
- Don't panic now! This is something that hasn't been made official yet. It's not going to kill your site right away, but it should give you pause as to whether your site is the best it could be.
- Don't panic later! By its own admission, Google takes into account hundreds of factors. Your page's speed is just one of them. You don't have to be the fastest page out there. You just have to be faster than pages of similar content and quality.
- Use the free profile tools to find out where your site's bandwidth usage is suboptimal.
- Use common sense to make sure that the bad metrics truly are relevant to your site. For more information on this, take a look at Jeff Atwood's critique of YSlow from a couple years ago.
- Spend some time looking over your page templates to identify what can be fixed.
- Fix the things you can.
Comments for Will Speed Kill Your Website?
Leave a comment