A few weeks ago I blogged on the need for speed and enabling http compression within IIS and Apache. There have been recent posts on how http compression and crawl rate are related and how speed is now a ranking factor, albeit a small one. While crawl speed is important the effect of site speed on conversion rate can be far more devastating.
Recently we had a client that ran a live chat application that caused a load delay of around 8 seconds. We obviously got in touch quickly to let them know about the delay but they were unsure of the effect that would have. A load delay of this kind won’t affect the load speed for the crawler, (although WMT did pick it up which we will look at a little later) so really we didn’t have a leg to stand on, until we tested conversion rates.
What we saw was a sharp decline in the “add to basket” goal with an accompanying loss in sales over the first two weeks. Once they saw this they quickly removed the functionality and replaced it with quicker software but the damage was done, they lost 35% of their monthly sales in that month.
This was notably picked up in the WMT which indicates that they do check the load speed of all the Javascript elements that make up the page whether they are hosted on the domain or not. This is crucially important when choosing a software that requires javascript execution. Everything from click tracking to analytics use javascript integration and if they run slowly rest assured your site speed takes a hit from Google’s point of view.
What options do you have for site performance?
There are many different services that enable you to monitor true site performance. When you choose yours make sure that you work out if it just executes a webrequest for the page or actually requests each javascript and fires them in the same way as a browser would. In our case the webrequest would have returned everything OK when it clearly wasn’t. If you find that the software does check it all make sure you can exclude it from your analytics tracking or it will skew your direct traffic figures fairly dramatically.
The Lesson I learned
Obviously we check the credentials of a hosting company when choosing hosting but from here on I’ll be checking the response speeds of all javascript BEFORE adding it to the page, if there is an issue im going to choose another provider that’s quicker, because time is really money, especially on the web.
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
In the absence of load speed improvements (technical issues or no budget) what you can also do is limit the amount of pages a search engine is allowed to crawl.
For example on one of my client sites we recently blocked all search results pages from being crawled with a line in robots.txt. This means that whatever crawl ratio a search engine has assigned to your site is more likely to be fully used instead of wasted on low-value pages.