Does a Faster Loading Site Rank Better?

[vangogh]

It will if some prominent Googlers have their way.


At PubCon, Matt Cutts from Google said there is strong lobbying in Google to introduce a new ranking factor into the algorithm. The new ranking factor has to do with how fast a site or page loads.

from Site Speed, Google’s Next Ranking Factor (http://searchengineland.com/site-speed-googles-next-ranking-factor-29793).

There's a video on the other side of the link that's worth watching. The video is about 4 1/2 minutes and the part on site speed starts around 2 1/2 minutes in.

People want fast loading websites and Google is now thinking maybe sites that do load quicker should get a little boost in ranking and maybe a very slow site doesn't need to be presented so readily to users.

This isn't something that's necessarily in the algorithms now, but my experience is that once Matt Cutts starts talking about things like this they do tend to happen. Odds are site and page load times are going to become in a factor that affects ranking in the near future.

One thing that this will mean is that having clean code is going to become even more important. It's another thing to tip the scales in favor of using css over tables, and if you're planning on designing a web page you should know how to code it well. When I say well I mean very well. We're talking hand coding over WYSIWYG editors, which leave bloated code everywhere. It will also mean you'll want to reduce images and http requests where you can, minify and compress your javascript, and a whole host of other things to make your pages load faster.

This all works for me since that's been my development philosophy since I first started teaching myself web design and development.

How about you? How fast does your site take to load?

[Spider]

...It's another thing to tip the scales in favor of using css over tables... In case you were wondering, I heard you!

[vangogh]

Funny. I almost used your name there. :) You've asked the question in the past and I knew this was partly a new answer for you.

[Spider]

Okay, now that this subject is back on the table (ahem!) .... what is fast enough and what is too slow and how can we measure it?

[vangogh]

Good questions


what is fast enough and what is too slow?

In the context of Google and any ranking benefit or loss I can't give you an answer since this isn't something that is going on yet. It's more something that's likely to happen in the coming months.

In general though there have been lots of studies about how long real people will wait around for your page to load. The quicker the better, but I believe there's a cutoff at around 8 seconds where if your page hasn't loaded by then most people will already be on to the next site. I think I've also seen studies indicated you should have your pages load in less than 4 seconds.

Another common measurement is to have your page weight (the total file size of everything on the page - code, images, etc) under 30kb.

I apologize for not having any stats to actually back the above up right now, but I'll see if I can find some. Ultimately the faster the better. My own opinion is that not matter how fast your page loads someone will want it to load faster. I think real people are never satisfied with page load times. We want instant. I think most of us would like the page to finish loading around the same time we're releasing the mouse button on the link that took us to the page.


how can we measure it?

There are a number of tools out to measure how fast your page loads and also help you determine where it's slowest.

When I was first learning to develop sites I came across a book called Speed Up Your Website. The authors of the book have a page on their site that lets you check the speed of your site, called the Web Page Analyzer (http://www.websiteoptimization.com/services/analyze/)

If you use Firefox there's an extension called Firebug (http://getfirebug.com/). You can install the extension directly from Mozilla here (https://addons.mozilla.org/en-US/firefox/search?q=firebug&cat=all&advancedsearch=1&as=1&appid=1&lver=3.5&atype=0&pp=20&pid=3&sort=&lup=). If you look further down the page there's an add on to Firebug called YSlow, which is from Yahoo and also checks for page load times with suggestions for improving yours.

Given that it's Google talking about adding site speed to their algorithms a good choice to measure site speed is Google itself. If you don't already have an account with Webmaster Tools (http://www.google.com/webmasters/tools/), you should sign up. The newest tool under Labs is a site performance tool, which will show you the time it took for your page to load and offer suggestions for making it faster.

There's also a link to install another Firefox extension, this time from Google called Page Speed (http://code.google.com/speed/page-speed/download.html).

Those aren't the only places to check site speed, but they should be enough.

And here's a link to an article (http://www.insidecrm.com/features/webmaster-turbo-kit-042108/) that mentioned lots of things you can do to improve load times with links out to detailed posts on how.

[Spider]

So, my stopwatch won't do it, huh?

I have a link to iwebtool.com and found this---

Website Speed Test (http://www.iwebtool.com/speed_test)

My test results --

Domain name ............ Size .......... Load Time ...... Average Speed per KB

frederickpearce.com .. 22.01 KB ... 0.12 seconds .... 0.01 seconds

Hmmm. Seems pretty fast to me, well under the 4 seconds you mention, VG. And that's using tables (Sorry! Couldn't resist!)

Even my too long blog archive page only took 0.15 seconds for 39.13 KB

[vangogh]

Your site does load fast. However, I think that 22.01 kb is just measuring the html. I see about 40 kb of images on your site. I'm pretty sure that test isn't really measuring things quite right. For example my site shows 13.22 KB...0.85 seconds (load time)...06 seconds (avg speed per kb) and I know my site takes longer to load than that. They might be making those measurements over a very fast network connection.

What kind of hosting do you have? Your site does load fast. I checked it at the web page analyzer and it performed well. Usually the main offenders when it comes to load times are images and http requests. You don't have a lot of either. For your site the biggest slowdown would be your header image, which I see at 29 kb. I'd be willing to be if it were optimized the file size could be cut in half.

[Spider]

Yes. Now that I look at the sizes of the files on my computer, my site's index page is 23kb and the header image is 37kb (the header image of all other pages is smaller at 29kb), the random font title image is 14k and my photo is another 7kb. (The inner pages don't use an image for the title and most don't have my photo.)

So, you are right - the iweb test is only for the html code.

Can I correctly assume - do you think - that 22kb in 0.12 seconds will work out to 88kb in 0.48 seconds, or is there something else to be considered?

You asked about my hosting. Most of my sites, including this one, are hosted at Directnic. I have found them very reliable and - it would seem - fast.

Added. You asked what kind of hosting. Just ordinary stuff - no T1s, dedicated servers or anything. Directnic offer premium hosting of various grades but I have 'bannerless hosting' which is their free hosting without ads - for which I pay a miserly $15 a year - probably the slowest of their offereings. If their premuim hiosting is any faster, it must be very fast, indeed!

[billbenson]

You might want to also look at load times from around the country and world. You might be in Texas, but your server might be in Washington State. The further away it is, the more routers you go through with the potential of slowing it down. A server near your customers is best.

It's usually a minor issue but most hosts have a number of servers in different locations. Certainly if you are in Houston and checking your site yourself to a Houston it will be faster.

Alertra Website Monitoring Service (http://alertra.com/spotcheck.php)

[Spider]

Wow, Bill! I'm adding Alertra to my list of tools. But, again, they seem to check only the html and not the images, etc. I just checked my site and all American locations were under 1 second, London UK and Frankfurt Germany were also under a second, China went out to 2.3 seconds while Australia and Hong Kong were under 2 seconds.

Times 4 to allow for images, people in Shanghai would have to wait all of 9 seconds for the whole lot, while folks in Atlanta GA got it all in under 1/10th of a second.

Pretty amazing really. I think I'm safe. May even pick up another brownie point with Google.

[vangogh]

The most important test is really visiting the site and noticing how long it takes to load. Granted that will different for different people, but when I go to your site it doesn't feel like it takes too long to load. If anything it seems to load quickly.

You couldn't just multiply based on the sizes of the file because to get each of the images your html makes an http request. One http request is made for the html and then the html makes an additional request for each image and each externally loaded javascript or css file, etc. That's for the first page. On subsequent pages you'd likely still be calling the same css file and probably the same javascript files and even some images. That second time around everything could be stored in the browsers cache so an http request doesn't need to be made.

So while you'd be going from 22 kb to 88 kb there would also be the additional time for each http request to add in.

What I've generally found to be the main things that slow down a page are larger images and a lot of http requests. That's for a static page. Once you involve a database it's often the database that is causes slower pages. One more thing to consider is when you add 3rd party applications like Google Analytics or AdSense. Your page may be loading very quickly, but the Google code could take a long time to load.

[Spider]

I see. I think I'm okay, though. No multiple css, so only one http call for the code. Should we allow render-time (is that a proper description?) - the time it takes for one's own computer to turn the code into screen stuff? One difficulty with tables (yes, I'm not supposed to use them but I haven't converted yet) is embedded tables take time for the computer to sort out which table is inside which other table, I presume. I rarely go more than 3 deep, and rarely use the fancy code 'rowspan' and 'colspan' - just simple open-table, close-table.

Two tricks I learned long ago when a 10k page was too big and slow, was to put as many of the smaller images as possible 'below the fold' so the top part could render while the bottom part was still downloading. This was also helped by sizing every image - width= height= .... thus, people could read the text even before the images displayed. Still, that's barely noticable these days with the faster transfer rates we have now.

It's all pretty amazing.

[lav]

Your site does load fast. However, I think that 22.01 kb is just measuring the html.Do we know if google will be taking images into consideration or just the code? I have to wonder if sites with video or heavy on images (like stock photo sites) will be penalised unfairly as we really expect them to load slower

[vangogh]

Do we know if google will be taking images into consideration or just the code?

Not really. There's still a bit of speculation about this. The only word we have is that some inside Google would like site speed to become part of the ranking algorithms. However since that word went out Google has also added information about your site's load time to Webmaster Tools and also posted new Analytics code that loads faster.

Given that last part I would think this would include things beyond your code. It didn't sound to me like there would be a penalty for slow loading sites. More a boost for quicker loading sites. I would also think there would this could be applied toward the end of the ranking determination. For example say someone searches for 'stock photos' you'd expect the top 10 results to be stock photo sites. Google ranks the usual suspects and then maybe tweaks the results based on speed. Maybe stock photo site #1 drops to #3 because it loads slower than the other results while stock photo site #4 ends up jumping to #2 because it loads quickly.

Just speculation on my part, but I can see how that might work.

Frederick I think your site is fine with speed. I've mentioned it above, but I'll say it again. Your site loads quickly. I don't think you could include the visitors computer into the equation since there would be no way for Google to measure that. You'd probably be looking at a baseline established by Google for how fast or slow a computer should render the page.

You do hit on one of the issues with tables. Because browsers need to read them twice your content doesn't start loading until that second pass. Often with tables you'll see a blank page until everything suddenly appears. Depends on how much nesting is going on and what's inside those tables, and where in the nested structure things are located.

[Spider]

Yes, and another thing I have found by experience (again, less noticable these days with fast transfer rates) putting everything inside one big table is really bad - that's when the whole page must be compiled and appears all at once.

I always have several separate table blocks down the page. At least, there is an open-table - close-table for the header, then a new table for the body, then another table for the bottom section. So that the header can display while the body table is downloading, and that can display while the final table is downloading. If I can, I will break the body section into two or even three separate tables.

On a page where I might have a number of book reviews, for example - let's say 10 books in 5 pairs down the page. Each pair will be in it's own separate table and not grouped in one large table. So each table can load and render down the page. Wrapping the whole thing in one table really slows things down.

But, of course, you don't want to know all that because I am not ever going to do that again - I am going to learn css!

[vangogh]

Yes, and another thing I have found by experience (again, less noticable these days with fast transfer rates) putting everything inside one big table is really bad - that's when the whole page must be compiled and appears all at once.

Exactly. You're doing tables the right way. The issue is really when everything is enclosed in one table like you mentioned.


I am going to learn css!

Woo Hoo!

[TulsaWeb]

Safari brwoser development tools has a speed checker that looks like yslow + googles Page Speed. Yet another alternative...

[KristineS]

Hmm, this is interesting. I'm kind of in favor of adding this to the algorithm because I hate waiting for slow sites to load. It annoys me.

Thanks for the hints on the speed measuring tools too. These are good sites to know.