Despite my day-to-day being SEO, ever since Google introduced page speed as a ranking factor, I've become a bit obsessive about finding ways to squeeze every bit of performance possible out of a site.

For an unrelated analysis I've been doing (that I may also release), I collated the top 2,200 sites in the UK by organic traffic within 22 different industries.

It sprung to mind that I could utilise some direct data from CrUX alongside additional insights from the PageSpeed Insights API for the origin of all the sites and see how they correlate with each sites organic performance.

And if you don't know what CrUX is...

The Chrome User Experience Report (CrUX) gives various user experience metrics gathered from real-world Chrome users. The data it provides is freely available and queryable from a BigQuery database.

At the time of writing, the only downside is that not all tools are updated to use Google's new core web vitals metrics.

So it's currently missing some newer metrics such as CLS (cumulative layout shift) and LCP (largest contentful paint) that Google will soon use within their ranking algorithms.

But I have included the first paint, DOMContentLoaded as well as the user-centric performance metric FCP (first contentful paint) found within older CrUX tables.

User-centric performance metrics?

User-centric performance metrics are essential site speed measurement metrics. Improving these is important as they provide a noticeable benefit to users. Examples of these metrics are:

• FCP (first contentful paint)
• LCP (largest contentful paint)
• FID (first input delay)
• TTI (time to interactive)
• TBT (total blocking time)
• CLS (cumulative layout shift)

LCP, FID and CLS together form what Google calls core web vitals. Those that visit Google Search Console frequently will see these metrics reported in the report found in the left sidebar.

I'll update the data found in this blog post with core web vitals once API's have caught up with the changes.

So, for the rest of this post, I'll be running through some key insights from the data alongside some data viz.

Site speed and organic visibility do not correlate

One key thing that I found was no correlation between site speed and ranking performance.

When split down by industry, the correlation still wasn't there.

Is the lack of correlation a surprise?

The correlation data above isn't something you or I should be surprised about. It was exactly what I expected the outcome to be.

Google has mentioned on multiple occasions it is a small ranking factor, and I wouldn't be focusing on site speed for the potential ranking benefit anyway.

The fact is, highly trafficked domains didn't get popular by focusing on site speed. However, providing an excellent experience for users undoubtedly helped.

Still, I'm sure every hosting company out there will still be professing the massive benefit their hosting will have on organic performance.

Now, onto more interesting data.

What are the average speed metrics by industry?

In this data, you can see ecommerce sites have the lowest first paint, FCP and DOMContentLoaded timings of all sites.

I imagine this is because ecommerce sites focus more on site speed, given they know it directly impacts their conversion rate.

As a well done to the top performers in ecommerce, here are the fastest most highly trafficked ecommerce sites:

Another interesting insight from the above is that you can also see that the average DOMContentLoaded timing tends to be much slower on news and media sites, which isn't surprising given their site is ridden with ads that impact site speed.

Ads on the Metro when you first visit the site..... ????

Which industry has the slowest site speeds?

Rather than looking at averages to decide the slowest, I used the PageSpeed insights API, which gives a good overall origin score categorising sites as either slow, average or fast.

This was to prevent a really slow site from bringing down the overall average for each industry.

I've used this data to categorically say that the industry you're most likely to have a slow experience with is news and media closely followed by gambling:

What is quite interesting here is just how few mobile sites are considered fast.

Of the sites that are fast on mobile, ecommerce is again leading the way.

Whilst the bar is set relatively high via PageSpeed Insights to achieve a 'fast' site on mobile devices, I'd have hoped for more.

As you'd expect, we start to see fewer slow sites show up and a more significant increase of sites with an average speed on desktop.

Just as we praise the fast sites, we must also highlight the slow ones. Here are the ten slowest sites in news and media weighted by how much organic traffic they receive.

The Daily Mail tops the list as one of the most highly trafficked news sites is with an impressive average FCP of 5.1 seconds and a DOMContentLoaded time of almost 12 seconds.

Which again, shouldn't be a surprise to anyone who visits the site...

What I do quite like about this data is that Google, who spend a lot of time promoting the benefits of site speed, has had their very own news domain on the list...

And the fastest sites?

You can also see law & government sites are the fastest sites around, followed by e-commerce, which we previously saw performed well based upon average speed metrics.

Here are the load timings of the fastest sites for law & government.

It looks like gov.uk sites must have a great tech team to ensure an excellent experience for users!

How are they getting such good speeds?

From taking a quick look, there are a few things that are causing gov.uk sites to be fast:

• They're mostly text-based with minimal imagery

Content type analysis from Pingdom

• When they do use images, they're deferred with native lazy loading

• All assets are cached on an edge server via the Fastly CDN. You can see in their HTTP headers even HTML isn't being served from an origin server and all sits on Fastly. This means the site is basically being server statically with no database calls that could slow down the initial load.

Caching HTTP headers on HTML from Fastly

• Because everything is edge-cached, that means a fast experience for users across the globe.

Interactive timings in different countries via Fast Or Slow

• The DOM size is really small with just 378 elements on the home page.

To improve timings further, gov.uk could start deferring CSS and JS that aren't required for load alongside inlining any critical CSS.

But they're already doing pretty great.

If you're looking for tips on improving the speed on your site, make sure to check my filterable list of different ways to improve speed here.

The top 10 slowest sites for each industry

Next up, I delved into which sites in each industry are the main culprits for a slower site speed.

I wanted to pick out some of the larger sites within each industry, so I picked out the top 100 sites by organic traffic and then limited that data to the top 10 slowest sites (by FCP of the 90th percentile) for each industry.

Below are the results:

DomainCategoryFirst paint (90) msFCP (90) msDom Content Loaded (90) msSemrush trafficwww.qvcuk.comArts & Entertainment29,20029,20034,1001,508,611www.dailymotion.comArts & Entertainment7,1007,6009,2003,072,187www.netflix.comArts & Entertainment5,3005,7009,20010,706,537www.metacritic.comArts & Entertainment5,6005,6008,800787,344www.wattpad.comArts & Entertainment5,4005,4009,700783,270www.campaignlive.co.ukBusiness & Consumer Services5,7005,8008,200305,980www.inc.comBusiness & Consumer Services5,4005,30014,800438,805www.savills.comBusiness & Consumer Services5,2005,1007,300239,723www.thedrum.comBusiness & Consumer Services4,4004,4006,900385,388www.mindtools.comBusiness & Consumer Services4,3004,30012,000497,194

The top 10 fastest sites for each industry

And as the reverse of the above, here are the top 10 fastest sites for each industry, again weighted by how much traffic they receive.

DomainCategoryFirst paint (90) msFCP (90) msDom Content Loaded (90) msSemrush trafficplanetradio.co.ukArts & Entertainment1,7001,7002,9002,194,388www.digitalspy.comArts & Entertainment1,8001,8002,6007,503,336www.discogs.comArts & Entertainment1,9001,9003,0002,025,470www.gear4music.comArts & Entertainment1,9001,9003,200749,849www.ultimate-guitar.comArts & Entertainment1,7002,0002,9001,641,378www.onthemarket.comBusiness & Consumer Services1,3001,3003,7002,489,147www.propertypal.comBusiness & Consumer Services1,3001,3002,200826,748homes.trovit.co.ukBusiness & Consumer Services1,3001,3002,200348,549www.openrent.co.ukBusiness & Consumer Services1,4001,4002,600451,609www.rightmove.co.ukBusiness & Consumer Services1,4001,5003,60025,548,012

Newer sites tend to be faster

I utilised the Sistrix API, which has a handy call that specifies the age of a domain, and I found that there is a bit of a trend that newer sites tend to perform better.

Given this dataset is based upon sites that perform well organically, it shows that newer sites that perform well organically also have slightly better site speed.

This makes it seem like people are listening to Google on the importance of speed! ????

One other reason I can think of as to why this may be is older domains are more likely to have significant tech debt whilst they're stuck on older platforms.

Another is that site speed is getting easier to optimise due to plugins and CDN's that take the heavy lifting off your origin server. Newer domains that are smaller, more agile and don't suffer from tech debt can take advantage of these more quickly if they plan to from the get-go.

Whilst interesting, to concretely say newer domains tend to have a better site speed, we'd certainly need a more extensive dataset as this one is more heavily weighted towards older domains than fresh ones.

Coming soon, a CrUX dashboard

I'm planning to create a dashboard that utilises core web vitals to monitor different industries and trends monthly using the dataset I've run through in this blog post.

Very early screenshot of the speed monitoring dashboard I'm working on

Given that Google will soon be using core web vitals as a ranking factor, it'll be interesting to see if sites start to improve speed because of it.

It will also be interesting if we spot an increased correlation between speed and organic traffic after the update has rolled out.

I'm currently custom coding it, but I may use Data Studio to speed up the process.

Final words

Hopefully, you've found this post interesting. It was a fun bit of analysis that I'd like to refresh in the future.

In building this dataset, I've had a few more ideas for future posts, so make sure to follow me on Twitter if you'd like to see more.