Does The Speed Of Your Website Have Any Effect On Your Google Ranking?

Share this on:

Good question, Google have been telling us that speed is taken in to consideration. They say this is because faster pages mean a better user experience, but they don't go into specifics. Is it how fast the data is received? Or, is it how fast the page renders? Or is it how soon you can start interacting with the webpage? You would think that all those factors would be important but we can only speculate without any data.

But the people at describe some tests they did in this article.

They used 2,000 random search queries and extracted the top 50 result producing a dataset of 100,000 page loads. A good dataset.

They then analysed the data and, surprisingly, found no correlation between ranking page load time or render time! This seemed to be contrary to the impression we get from the information Google puts out.

But they did find a correlation between "Time To First Byte" (TTFB) i.e. the time it took to receive the first byte of information from the web server. They speculate that this is because it is a figure that is easy to obtain, and it is a good proxy for the overall performance of the web-server.

So I looked at TTFB for the top ranked sites for my keywords (ie the keywords I am interested in ranking for). I did this by running a script that connected to each of the sites and timed how long it took to get the first byte of information. I then automated the script to run every five minutes and left it for a couple of hours. (For the geeks amongst you this article talks about the Linux tools I used to do this)

I then looked at the average times to get the first byte of information, and there did seem to be a correlation.

So here is a list of TTFB timing in order of position in search results:

  1. 0.159
  2. 0.152
  3. 0.572
  4. 0.678
  5. 0.514
  6. 0.138
  7. 0.302
  8. 0.537
  9. 0.510
  10. 0.623
  11. 1.553
  12. 0.698
  13. 0.163
My figures agree with what suggest to a certain extent ( though obviously with a tiny dataset compared to theirs), but there is quite a bit of deviation.

The average time for this site is 0.626 so actually faster than quite a few in those top places. So speed isn't by any means the whole story.

Seeing this made me think that, though there was room for improvement, TTFB isn't absolutely crucial.

But to see where I might be able to make improvements I did further timings of my own site: the time for the front page, time for a blank page ( both delivered by my content management system) then the time for the front page as just a flat html file then just a blank page from the server root.

  • Front page via CMS: 0.628
  • Blank page via CMS: 0.166
  • Front page as a text document: 0.148
  • Blank page as just text document: 0.143

So it looks like rendering the front page takes up quite a lot of the time before the server replies

So i needed to look there. I tried testing the speeds of my other web pages and discovered to my surprise that they were much faster.

So there was a culprit on the front page that was slowing things down.

I edited the page a bit at a time seeing how each change effected the page speed, I thought it might be the carousel with it's images, but no that didn't make much difference.

Then I tried the calls that grab the latest blog posts. EUREKA, it was those, I had been making the call "uncached", a schoolboy error, this meant every time the page was loaded the call would have to be made to find the posts again. Whereas if I had cached the results it would have been much faster. So I made the calls cache their results and hey presto the the page speeded up from 0.626 to 0.2xx a HUUUGE improvement.

So this might explain the dip in my rankings when I first started the daily journal. The Journal has its own page so I added a new feed to the front page, to add "freshness" to it, i.e. it the front page would be changing every day with the teasers for the new Journal entries. And I forgot to make it a caching call.

So that is now remedied and we shall see what effect it has.

What does a Leeds' web developer do when it's raining outside?

What web tasks did I do today?:

9 hours 45 minutes Looking in to the speed of a website in relationship to SEO and writing scripts to check websites TTFB speeds
32 minutes Ordering a new scanner and USB hub
17 minutes Email
4 minutes Organising Evernote notes

Total: 10 hours 40 minutes

An interesting day of discovery today, and I'll be interested to see what effect the changes I made have on my ranking.

Exercise: 45 minutes of press-ups, dips, sit-ups and arm curls.

Tomorrow: It would be nice to try and write a few blog posts in advance, so I can get ahead of myself for the first time and build in a bit of slack.

Share this on:
Mike Nuttall

Author: Mike Nuttall

Mike has been web designing, programming and building web applications in Leeds for many years. He founded Onsitenow in 2009 and has been helping clients turn business ideas into on-line reality ever since. Mike can be followed on Twitter and has a profile on Google+.