Johannes Beus

(Author)

Published: 15.09.2020

Modified: 04.01.2023

The loading speed of websites will be an official Google ranking factor next year and as the process of optimising isn’t simple, you should start now.

To help you, here’s a quick summary of the most important findings from our analysis:

Summary of key page-speed findings

• 29% of the loading times in the UK are not acceptable, according to Google’s expectations: they are above the maximum of 2.5 seconds.
• The trend, however, is pointing in the right direction. The proportion of fast websites has increased by 2 percent in recent months.
• Accessing websites from the UK is not as fast as it could be. Leading Europe are Switzerland, Sweden, Norway and Germany.
• Jimdo shows that cloud-based CMS can deliver very good Core Web Vitals values. But open source can also do this too – Typo3 is only a little slower.
• No CMS is slower than Wix. It’s the wooden spoon holder in the CMS category. In last place behind WordPress, it shows that cloud based solutions aren’t always fast.
• Lightspeed delivers an extremely fast shop system. Shopify is only in the bottom half of the list. The WordPress add-on WooCommerce is the slowest shop system.
• The programming language is not crucial for web technologies: there are fast frameworks in Ruby (on Rails), PHP (Yii & Laravel), Python (Django) and other languages. Only Angular is really slow.
• AMP does not automatically lead to fast websites. Only around 70% of the AMP pages meet the Core Web Vitals standards.

If you have more time, here is the complete analysis with all the data and numerous other interesting findings on loading times, fast and slow systems and the connections behind them.

Why is website loading time important?

The user experience is one of the most important factors in the success of websites. Loading times are the foundation of a good user experience because if the visitor has to wait (too) long for a page to load, they will jump and look for another source.

In a study, Google found that an increase in the loading time from one to three seconds leads to a 32 percent increase in the bounce rate. If the loading time increases to five seconds, the probability that the visitor will leave the page increases by as much as 90 percent.

How is website performance measured?

There are a variety of tools and approaches to making the user experience on websites measurable. With the Core Web Vitals, Google provides three standardized and comparable key figures. These core web vitals will also become a ranking factor in the next year (2021), so they will have a direct influence on the position of a page in the Google results.

We have already shown the background, various measurement methods and ways to improve the three core web vitals in another article. So here’s just a quick reminder:

• Largest Contentful Paint (LCP) – the time it takes for the largest section of content to load. Good: less than 2.5 seconds.
• First Input Delay (FID) – the time until the user can interact with the page. Good: less than 0.1 seconds.
• Cumulative Layout Shift (CLS) – An indicator of how much the layout shifts during loading. Good: less than 0.1.

In this analysis, we used the value for Largest Contenful Paint (LCP), with the exception of the first diagrams which show all three measurements. Of the three Core Web Vitals, this is the elementary value for measuring the loading time of the page.

United Kingdom – 29% of sites not fast enough

For the first step, we analysed how website accesses from the UK performed for the three Core Web Vitals key figures. Google has defined three areas for each:

• Good (green) if the value is within Google’s expectations,
• In need of improvement (yellow) if it is above expectations, but not yet deviating too far from them and
• Bad (red) if the measured value is well off the targets.

On this basis, here are the results for the UK based on the three Core Web Vitals.

With Largest Contentful Paint (LCP), 70% of all results are already good. Google rates 12.9 % of the results as bad. LCP is the key figure of the Core Web Vitals, as it most directly reflects the actual loading time.

The First Input Delay (FID), i.e. the time until the interaction, has the best values: 90% of the accesses are already good and only 2% are rated as bad by Google. If you still have some work to do here you’ll have to hurry so as not to be left behind.

With Cumulative Layout Shift (CLS), the shift of the layout during the loading process, it is noticeable that websites either pass this test (green) or fail completely (red) – there are only a few cases where only improvement is needed. (yellow).

Positive trend: websites are getting a little faster every month

To understand how the loading times have changed in the last few months, the next evaluation shows the monthly changes for the Largest Contentful Paint over recent months:

The progress is not rapid, but there is a slight positive trend. Since November 2019 the number of bad measurements has decreased by around 2 percentage points and the good measurements have increased from 73% to 75%. The direction is positive: websites are getting a little faster every month.

Tablets are just bad desktops

We come to the next analysis where we separate the evaluation according to device type: desktop, mobile phone and tablet. Here are the results:

Unsurprisingly, websites load faster on a desktop than on a mobile phone. An often wired internet connection and more computing power are decisive here. The difference between desktop and mobile phone is less than expected, however.

The poor performance of tablets is interesting. One possible explanation is that tablets usually see the desktop version of websites through their larger screen – but the hardware of tablets is more comparable to smartphones. This leads to a significantly poorer loading time performance.

20th place: Website access from England needs improvement

The values measured by the end user for the Core Web Vitals only partly depend on the performance of the website: the speed, throughput and latency of the users’ Internet connection also have an influence on the result.

As a site operator, there is no way to optimise the Internet connection of your own visitors, but an analysis of the Core Web Vitals for each country shows these differences very clearly. Here is the evaluation of a selection of countries:

In China and South Korea, 82% of all websites match the performance expectations of Google – a top value and by far the world leader. This is followed by the Nordic countries (Sweden, Norway, Denmark) but also Japan and Taiwan.

Germany is in ninth place in this analysis: three quarters of all users requests already correspond to Google’s speed expectations. England is positioned at number 20 which may reflect the amount of content being consumed from outside the country, notably from the USA, and maybe from services in other parts of Europe.

Loading times in Russia and the USA are roughly comparable. The poor values ​​for Thailand and Vietnam show that Asia cannot always be equated with fast internet.

Kiribati, an island nation in the Pacific, demonstrates the effects of an extremely remote location and an internet connection via satellite: only around a quarter of all accesses are already good. Almost 60% of accesses are rated as bad by Google.

CMS: Jimdo the fastest, Wix even slower than WordPress

Content management systems (CMS) are the backbone of the Internet: most websites are operated on top of the core of such software. From the hairdresser next door to the SMB to the site with many millions of visitors every day.

We have combined our database of web technologies with the measurements of the Core Web Vitals in order to be able to evaluate the loading speeds of the most used content management systems. Let’s get straight to the analysis:

Jimdo, the website builder from Hamburg, Germany, delivers the best performance for the Largest Contentful Paint. Over 82% of accesses to websites running on Jimdo meet Google’s performance expectations.

Typo3 shows that even a self-hosted CMS can also deliver a very good performance, as second place in the evaluation shows. Anyone who has ever had to develop with Typo3 often remembers the complexity with horror. However, this does not affect the speed of this PHP-based CMS.

WordPress, by far the most widespread CMS, lags far, far behind in second from last position. Around half of all websites run on WordPress – but there are also many who use it that place little value on good loading times. Google classifies around 20% of hits on websites based on WordPress as bad, and another 21% as in need of improvement.

The fact that WordPress does not carry the wooden spoon in this analysis is thanks to the provider with the name Wix. This cloud solution only delivers around half of all accesses with a good loading time. Almost a quarter rated Google’s Core Web Vitals as bad.

This poor performance is particularly noteworthy when you consider that both the winner of this analysis (Jimdo) and the loser (Wix) have the same starting conditions: Cloud solutions in which the provider controls the entire system and can optimise every part (but obviously doesn’t always do it).

Shop systems: Shopify in the middle of the field, WooCommerce at the bottom

As early as 2006, Amazon determined that loading times that increased by 0.1 seconds lead to a 1% reduction in sales. That hasn’t gotten any better in the last 14 years. Good loading times are of fundamental importance for online shops.

The combination of our technology database and the data on loading times results in the following analysis for all shop systems that we have seen often enough in the open wilderness of the Internet:

The winner, Lightspeed, lives up to its name. Domains using Lightspeed contribute to the 93% ‘good’ rating for the Largest Contentful Paint. Only 2% are rated as bad. These are the best numbers we measured in this analysis across all evaluations.

Lightspeed has the system-related advantage that it is a cloud solution. The provider controls the entire system and can optimize all areas for speed. The open source solution osCommerce shows that very good loading times can also be achieved with self-hosted shops with a very good 84%.

The current shooting star Shopify only makes it into the lower half of the analysis. Although in principle it uses the same baseline architecture as Lightspeed (fully hosted by the provider itself), this advantage is not converted into above-average loading times.

The WordPress extension WooCommerce lags far behind in last place. Just under half of the WooCommerce shops currently meet the Google specifications. An alarming 26% are actually bad. The self-operated hosting solution with low-performance mass providers is clear here.

Web technologies: AMP slower than expected

This evaluation deals with a wide variety of web technologies: from backend technologies for creating websites to JavaScript and CSS libraries for design and interaction to Google AMP.

The following table only lists the technologies with the most identified uses in our data. Less used web technologies have been left out. Of course, only publicly accessible websites could be evaluated. Here is the analysis:

Ruby on Rails, a Ruby-based framework developed by the founder of Basecamp, is by far the leader: almost 85% of all websites with this technology deliver websites within the limits set by Google for a good rating of the Largest Contentful Paint.

But PHP frameworks like Yii (74%) or Laravel (73%) also deliver good times. So that nobody feels left out: Python is also well represented with the Django framework (75%) and ASP.NET (77%) even takes second place. What do we learn from this?  Speed ​​does not depend on the programming language, but on the implementation.

It is noticeable that AMP is not one of the fastest technologies. Accelerated Mobile Pages (AMP) are a derivative of HTML mainly pushed by Google. Numerous restrictions should mean that AMP pages load significantly faster on the mobile phone than classic HTML pages.

The results are not convincing: less than 70% of the AMP domains meet the Google requirements. Google has apparently already recognised this and will in future also bequeath the AMP privileges in the Top Stories box to sites that have fast Core Web Vitals.

AMP will no longer be necessary for stories to be featured in Top Stories on mobile; it will be open to any page.

Google Webmaster Central Blog, Evaluating page experience for a better web

The only web technology that fails to make more than half of all domains meet Google’s requirements is Angular. Ironically, a framework for front-end applications developed and provided by Google …

CDNs. Fast sites are using Fastly

Content Delivery Networks (CDNs) provide servers distributed around the world so that content can cover shorter and therefore faster transmission paths to the visitor to the site. In addition to specialists like Akamai, the major cloud providers also offer CDNs.

In essence, all CDNs work similarly. They cannot change the physical limits of their architecture either. Therefore, in the following analysis, a distinction must be made between causality and correlation:

It cannot be assumed that the faster CDNs are the cause of the lead, but that performance-oriented website operators may fall back on these CDNs.

Domains that rely on Fastly as a CDN load, on average, much faster than those that rely on other providers. Google lands in second place, but Amazon and Microsoft (Azure) are not far behind either.

The fact that Akamai is to be found further behind could have something to do with Akamai’s typical customers: these are rather large, international corporations that often operate slow legacy systems – not the best prerequisite for delivering modern and fast websites.

Fireblade, at the bottom of this analysis, does not offer a classic CDN, but a web application firewall: the application filters Internet traffic for potentially dangerous calls and blocks them. Those who have to fall back on such an architecture will, on average, also operate older and non-optimised web applications and thus already have structural disadvantages in this evaluation.

Background: what (and how) we measured

The measurement of loading speeds has a long history: from the original measurement of the beginning of the delivery of the pure HTML (TTFB, Time to first Byte) to the First Contentful Paint to the current three measured values ​​of the Core Web Vitals with the Largest Contentful Paint as central metric has changed a lot.

For the analysis, we used the official calculation base of the Google Core Web Vitals. There are essentially two different measurement methods for this: laboratory data, i.e. values ​​measured by yourself under your own laboratory conditions and field data. These are measured by a user panel. We evaluated the field data for this analysis. In SISTRIX you can access both laboratory and field data. In total, we analyzed the loading times of 18.5 million domains.

With the exception of the first three evaluations, which relate exclusively to measured values ​​from UK, the remaining analyzes include measured values ​​from around the world. Desktop, mobile and tablet values ​​are also evaluated there.

We have combined these measured values ​​with the technology detection in SISTRIX in order to be able to make statements about software solutions and technology stacks. For technology recognition, we regularly crawl large parts of the Internet and compare found features (“fingerprints”) with our list of over 1,000 relevant Internet technologies. We only included those technology-core-web-vital combinations in the final analysis that occur with a sufficient number of domains to achieve statistical significance.

Conclusion

Google is moving the user experience into the spotlight by making Core Web Vitals an official ranking factor. In our analysis we were able to show how wide the range of the values currently is. Depending on the software and technology used, everything is represented between “already perfect” and “a pile of work”.

Like so much in SEO, improving loading times has to be a continuous process. It;s not a one-time task, but an ongoing, monitored process. It will require regular attention and the goals will need to be adjusted from time to time.

Optimising loading times is not a core SEO task – and yet the change will have an impact on the organic performance of a website in search results. SEO is once again a cross-sectional function that has to bring together many areas of a company.

We ourselves have neglected the loading times of our website for a long time. In the last few weeks we have tackled the topic and have noticed how much effort (very) good values ​​require. And yet it is worth it: not only is Google happy with it, the real users in particular thank us. Therefore: don’t sleep on the topic. It’s better to start this year than postpone it to next year.