Site speed as reported by Google, what's the distribution?

[g1smd]

In Google WebmasterTools, there's a site speed report for each of your registered sites, graphed for the previous 90 days.

It's under

Labs

>

Site Performance

Performance overview

On average, pages in your site take nnn seconds to load (updated on dd ddd, dddd). This is faster than nnn of sites. These estimates are of www accuracy (nnn data points). The chart below shows how your site's average page load time has changed over the last few months. For your reference, it also shows the 20th percentile value across all sites, separating slow and fast load times.

I'm wondering what the wider distribution of site speeds is.

I have only a few noted here:

2.1 seconds to load. This is faster than 66% of sites.
1.9 seconds to load. This is faster than 71% of sites.

1.0 seconds to load. This is faster than 90% of sites.
0.9 seconds to load. This is faster than 92% of sites.
0.8 seconds to load. This is faster than 93% of sites.

Perhaps a few members could fill more details in?

[Habtom]

This stat is ridiculous.

The thing is Google thinks it is slow - that could be a problem. I don't know how they measure the speed too. My site, if anything, should have been slowing down as database response time increased, but Google thinks it has steadily gotten faster over the past few weeks - shedding off a few seconds, which I am happy with. But if it says it is slower than all other websites, I would have tried to quickly resolve that.

[tedster]

According to Google, the majority of the site speed data comes from browser/toolbar information collected from real users. Server response (including database processing time) would only be a section of the total time. Something like a shift in geographical distribution for visitors could conceivably have a bigger effect. More return visitors who have cached various page elements could speed things up... etc, etc.

[Habtom]

More return visitors who have cached various page elements could speed things up

tedster, you've given me a reason why Google thinks my site has gotten faster. About 60% of my visitors now are return visitors, which was just about 20% in Jan.

[tedster]

Ah yes, the beauty of a 304 status code response!

[g1smd]

With a site relaunch a few months ago, every page moved to a new extensionless URL. Crawl speed data two days after that and for the next few weeks showed ridulously fast times - presumably as most of the URLs being called were 301 redirects to the new location. After a few weeks the times rose back up to roughly where they were before.

[deadsea]

Here is the updated data and graph: [i.imgur.com...]

I corrected the data point for 3.7 seconds which I had copied incorrectly the previous time I graphed it.

Load Seconds Percentile
37.3 0
14.4 2
8.7 8
5.8 19
5.2 23
4.5 30
4.4 31
4.2 33
3.8 37
3.7 39
3.6 40
3 49
2.9 51
2.7 53
2.7 54
2.6 56
2.6 57
2.5 58
2.4 59
2.2 64
2.1 66
2 67
1.9 71
1.8 73
1.5 80
1 90
0.9 92
0.8 93
0.7 95
0.7 96
0.4 99
0.3 99
0.1 99

[bumpski]

There seems to be some question about what Google is measuring in Tools, Site Performance. It is certainly not the time Googlebot takes to load you web pages basic content. It is definitely the time it takes for the "onload" event to occur.

I say this because since the Oct. 13th Panda tweak (75% traffic loss) I felt I had lots of time and incentive to improve one of my site's performance, solely from Google WebMaster - tools - site performance - perspective.

After all this work what the visitor sees, perfomance wise, has changed very little, BUT, google's site performance indicator has gone from 3 to 5 seconds per page to 0.2 to 0.5 seconds. This is on some pretty cheap hosting also. (With GZIP compression)

This was achieved by moving almost all loading and rendering to after the onload event. Please do not think because it appears your entire page content has rendered that the "onload" event has fired! Many things delay the "onload" event. Virtually all ads, borders, navigation, etc on this site now load after the "onload" event. Google's measure is a bit of a farce, but there is one advantage to visitors to the site, they can navigate through the site at a lightning pace (should they want too!).

Below is a link to a thread with an excellent tool to see when your "onload" event occurs.
Web Page Performance tool [webmasterworld.com]
This tool, and perhaps standards, refers to this onload time as the "Document Complete" event. Look for the vertical blue line when analyzing your pages.

For my modified site this event occurs very early and then all sorts of content is loaded by javascript after this event. (I am aware of the downsides to this.)
Even this site's background image is loaded after this event. The page first might render, if the browser is fast enough, with a color that closely matches the background image, and then after the onload event the image itself is loaded and rendered using javascript and styles.

To date this appears to have done little for this site's rankings. The Oct 13th Panda tweak still dominates. But I've eliminated yet another possible factor, advertising overhead and overall load time as measured by Google.

[Andy Langton]

Google themselves say that site speed is toolbar data, and it does indeed measure onload, AFAIK.

I'm not surprised you haven't seen ranking impact, though. This has always struck me as one of Google's "missions" rather than anything that will affect a general purpose SERP. I think you'd need to be slow to the point of unusable for it to be taken into account. Plus, I think it's a potential negative factor - i.e. too slow might be bad, as opposed to a potentially positive factor - being quicker makes you rank better.

All that said, quicker sites are better, so I'm all in favour of it. But let's not join Google in pretending it's a big algorithmic thing, and settle for the reality of it, which is nice enough in itself ;)

[tedster]

I haven't seen Google "pretending" that site speed is currently a big ranking factor. Consistently the official word is that it only affects around 1% of queries in any way - and then the effect is most often only as a kind of tie-breaker.

Now webmasters and some SEO companies are another story. That's where I see a lot of pretense and FUD. Nevertheless, solid data does say that your visitor response will be much better after even a small improvement in load speed - even 1/2 second, for example.

[Andy Langton]

Pretend is the wrong word, but Google know as well as anyone that if they mention a specific ranking signal, webmasters will follow (Chinese-whispers-style!). I find this approach a bit disingenuous at times, particularly as there own way of measuring speed is so flawed!

[bumpski]

Another data point:
0.6 seconds 97%

One other thing to remember:
I'm fairly certain, even if your pages are noindexed or blocked in robots.txt, the Google Toolbar, and webmaster tools "site performance", does not care! If your visitor gets to that page, and is using the toolbar with pagerank enabled, the load time of that page will be in Google's data.

I have at least one page, that is purposely noindexed, that is also very CPU and javascript intensive. The visitor first see's an instructional warning page about the CPU usage, thus the noindex for the actual page. Google probably frowns on this structure, that actually protects my visitors! (The visitors ultimate goal is the noindexed page!)
I'm sure, historically this page has a bad load time. I'm also fairly certain this noindexed page's load time is included in the webmaster tools load time report.

What has been really annoying is Google reporting the average page load time of the site occasionally is 3 seconds, but the example pages shown below the graph, load in 0.2 seconds, per Google! At least show the guilty page(s)!

I agree, probably below about 5-10 seconds, Google ignores page load time as a ranking factor.
One other observation; when I reviewed the sites affected by Panda, in the Google Panda thread, many of them had terrible (terrible!) "onload" event times, although many appeared to render fairly quickly.