We analyzed 5 million desktop and mobile pages to learn which factors impact page speed.

First, we established worldwide benchmarks for TTFB, Visual Complete and Fully Loaded load time metrics.

Then, we looked at how image compression, CDNs and hosting impact site loading speed.

Our data revealed some very interesting (and surprising) insights.

Here is a Summary of Our Key Findings:

1. In our analysis of 5.2 million pages, the average desktop Time to First Byte (TTFB) speed is 1.286 seconds on desktop and 2.594 seconds on mobile. The average time it takes to fully load a webpage is 10.3 seconds on desktop and 27.3 seconds on mobile.

2. The average web page takes 87.84% longer to load on mobile vs. desktop.

3. When comparing major CMSs against one another, Squarespace and Weebly have the best overall mobile page speed performance. Wix and WordPress ranked near the bottom.

4. On desktop, CDNs have the biggest impact on TTFB. However, on mobile devices, the number of HTML requests seems to affect TTFB the most.

5. Overall page size has a significant impact on desktop and mobile “Visually Complete” loading speed. Larger pages take 318% longer to visually load compared to smaller pages. We also found that gzip compression helps images load more quickly on both desktop and mobile.

6. Total page weight is the #1 determinant of Fully Loaded page speed. Light pages fully load 486% faster than large pages.

7. Wink and Gatsby are the fastest Javascript frameworks. Meteor and Tweenmax are the slowest. The fastest framework is 213% faster than the slowest.

8. Pages with very low or very high file compression have above-average page speed performance (measured via First Contextual Paint).

9. Third-party scripts significantly slow down page loading speed. Each third party script added to a page increases load time by 34.1 milliseconds.

10. We discovered that using responsive images results in the best overall image loading performance. Use of WebP was significantly less effective at reducing image load times.

11. GitHub and Weebly web hosts have the fastest overall TTFB Performance. Siteground and Wix are the slowest among the hosting providers that we analyzed.

12. China, Japan, and Germany have the fastest TTFB loading times. Australia, India and Brazil have the slowest TTFB times.

13. CDN usage was correlated with worse page speed performance. This is likely due to the fact that certain CDNs perform significantly better than others.

Benchmarks for Key Page Speed Load Time Metrics

Our first task was to establish benchmarks for important page speed metrics.

As you may know, “page speed” is actually made up of several distinct stages.

Stages of web page loading

Some of these stages occur at the server level. And others take place within the user’s browser.

And to fully understand how quickly pages load, we needed to drill down into each of these stages.

Specifically, we determined the average speed for:

  • TTFB: Time to first byte of HTML doc response
  • StartRender: When rendering begins
  • Visual Complete: User can see all page assets
  • Speed Index: How quickly a user sees a page load
  • onLoad: When all page resources (CSS, images, etc.) are downloaded
  • Fully Loaded: When a page is 100% loaded in a user’s browser

The average TTFB speed is 1.286 seconds on desktop and 2.594 seconds on mobile.

Mean TTFB speed on desktop and mobile

The average Start Render speed is 2.834 seconds on desktop and 6.709 seconds on mobile.

Mean start render speed on desktop and mobile

The average Visual Complete speed is 8.225 seconds on desktop and 21.608 seconds on mobile.

Mean visual complete speed on desktop and mobile

The average Speed Index speed is 4.782 seconds on desktop and 11.455 seconds on mobile.

Mean speed index speed on desktop and mobile

The average onLoad speed is 8.875 seconds on desktop and 23.608 seconds on mobile.

Mean onload speed on desktop and mobile

The average Fully Loaded speed is 10.3 seconds on desktop and 27.3 seconds on mobile.

Mean fully loaded speed on desktop and mobile

Key Takeaway: The average page loading speed for a web page is 10.3 seconds on desktop and 27.3 seconds on mobile. On average, pages take 87.84% longer to load on mobile devices than on desktop.

Weebly and Squarespace Have the Best Overall Speed Performance. WordPress Has One of the Worst

When it comes to page speed, which CMS is best?

To answer this question, we determined the CMS used for all of the sites in our data set. We then compared TTFB performance for each CMS that we discovered.

According to our data, Weebly and Squarespace come out on top for desktop.

CMS page speed performance rankings (Desktop)

And for mobile page speed, Squarespace is #1… with Adobe Experience Manager and Weebly rounding out the top 3.

CMS page speed performance rankings (Mobile)

What’s interesting to note is that, when it comes to mobile speed, WordPress is only the 14th best CMS that we analyzed.

WordPress ranks #14th among CMSs for mobile page speed

Another popular CMS, Wix, also rated poorly for desktop and mobile loading speed.

Wix ranks near the bottom for desktop and mobile page speed

Although WordPress powers approximately 30% of all websites, it’s clearly not optimized for page loading speed. That’s not to say WordPress is a bad CMS. It has other advantages (like ease of use, a massive library of plugins and SEO) that make it the go-to CMS for many site owners.

However, when looking strictly at website loading speed, it appears that other CMSs have a distinct edge over WordPress.

Key Takeaway: Among major CMSs, Squarespace and Weebly have the best mobile page speed performance. WordPress and Wix rank near the bottom.

Using a CDN May Help Desktop TTFB. Minimizing HTML Requests Is Key For Mobile TTFB

We analyzed the impact that various page characteristics had on TTFB (time to first byte).

Here’s what we found:

Factors that impact desktop and mobile TTFB

As you can see, using a CDN seems to improve TTFB for both desktop and mobile. However, CDNs appear to be more helpful on desktop compared to mobile. On pages loaded via a mobile device, the number of HTML requests had the greatest impact on TTFB.

While we did find a relationship between various page characteristics and TTFB times, page-level factors won’t make or break TTFB. TTFB is largely determined by the server’s response time, something we will cover a bit later.

Key Takeaway: Using a CDN and minimizing HTML requests may speed up TTFB on both desktop and mobile.

Large Pages Take 381% Longer to “Visually Complete” Load Compared to Smaller Pages

“Visually Complete” is when all of the visual content of a webpage inside of a user’s browser is loaded.

Visually complete

There may be scripts and other assets loading off-screen. But from a user’s point of view, the page is loaded.

Visually Complete is an important page speed metric because it affects a user’s subjective experience of how quickly or slowly a page loads.

As long as a user can see and use the page, it’s fully loaded… even though there may still be assets loading and rendering behind the scenes.

We discovered that page size (bytesTotal) had a significant effect on mobile and desktop Visually Complete load times.

Factors that impact Visually Complete on desktop and mobile

However, page size is more important on mobile compared to desktop.

On desktop, use of a CDN was most strongly correlated with faster Visually Complete loading speed. With page size coming in as a close second.

On mobile devices a CDN was only the 5th most important factor.

So if improving mobile loading speed is a top priority for you, I’d consider doing as much as you can to reduce the size of your pages. This may mean deleting third party scripts. Or compressing images. The exact steps will depend on your site. However, it’s clear that, when it comes to Visually Complete speeds, it’s all about HTML size.

Key Takeaway: CDNs can significantly improve Visually Complete page speed on desktop and mobile. However, CDNs have a much bigger impact on desktop loading. For mobile, total page size is the most important factor for Visually Complete load times.

Total Page Weight Is Closely Tied to “Fully Loaded” Page Speed

Finally, we looked at factors that impact “Fully Loaded” page speed.

As the name suggests, Fully Loaded is when 100% of a page’s assets are loaded and rendered.

When it comes to Fully Loaded page speed, the total size of a page is by far the most important factor on desktop and mobile.

Factors that impact Fully Loaded on desktop and mobile

The number of requests also play a role in how quickly a page fully loads.

What’s interesting about this data is that there’s a strong overlap between desktop and mobile. Unlike many of the other metrics that we analyzed, desktop and mobile Fully Loaded seem to be impacted by the same set of variables (namely, page size and total HTML requests).

However, the importance of page size and HTML requests shouldn’t come as a big surprise.

Compressing images, caching and other steps usually reduce how long it takes a page to load. But they can only go so far. At the end of the day, for a page to be “Fully Loaded” a browser has to load all of the assets on a page. And the more assets there are to load, the longer it will take for the page to load.

This is probably why CDNs don’t seem to have much of an impact on Fully Loaded page speed (3rd in overall importance on desktop, 10th on mobile). CDNs can improve image load times. But they don’t do much to help with 3rd-party scripts and other assets that can slow things down.

Key Takeaway: Total size impacts Fully Loaded page speed more than any other variable on both desktop and mobile. Large pages (>3.49 MB) take 486% longer to fully load compared to smaller pages (<.83 MB).

Wink and Gatsby are the Fastest JavaScript Frameworks for Average-Sized Webpages

When it comes to prioritizing what to load on a page (and when), JavaScript Frameworks do a lot of the heavy lifting.

This is why almost 76% of all websites make use of these frameworks to create pages that are efficient, secure, and standardized.

We first gathered benchmarks for how often each Framework was used across the web.

JavaScript framework usage

React is by far the most commonly-used JS Framework (25.3% of sites use it). TweenMax (10.3%) and RequireJS (9.5%) are also fairly popular

Next, we wanted to figure out which JavaScript frameworks performed best on small (<1,264,374 Bytes) medium (1,264,374 and 4,019,332 Bytes) and large (>4,019,332 Bytes) pages.

For small pages, RightJS came out on top.

Impact of JavaScript framework on FCP, page weight < 1,264,374 bytes

For medium pages, Wink and Gatsby performed best.

Impact of JavaScript framework on FCP, page weight between 1,264,374-4,019,332 bytes

And for large pages, Gatsby and Riot had the fastest FCP times.

Impact of JavaScript framework on FCP, page weight > 4,019,332 bytes

Overall, the choice of a JavaScript framework can make a significant impact on FCP times. In fact, for medium-sized pages, the best JS framework (Wink) loaded 213% faster than the slowest framework (Meteor).

Although there’s quite a bit of overlap for the best and worst performers (for example, Gatsby and RightJS were in the top 5 among all three page size categories), it does appear that certain JS Frameworks work best on certain sized pages.

For example, Riot is a great framework for large pages (2nd overall).

Riot is good for large pages

However, for small pages, Riot fared significantly worse (15th overall).

Riot is not good for small pages

Key Takeaway: There’s no “best” JavaScript framework for every situation. For sites with lots of small-sized pages, RightJS is your best bet. For websites with mostly large pages, Gatsby looks to be ideal.

Pages with Low or High Compression Levels Have the Fastest Load Times

Compressing page files on a server is a double-edged sword. On the one hand, compressing files significantly reduces page weight.

However, compressing files before sending them from the server entails additional work on the browser, as the client needs to decompress the files before rendering them.

As part of this analysis, we set out to answer the question: does compressing files actually improve page speed?

To answer this question, we classified FCP into three categories (Fast, Average, Slow):

Fast: 0-1000ms
Average: 1000ms-2500ms
Slow: < 2500ms

We then compared FCP speed and levels of compression among small, medium and large pages.

For small pages, lower levels of compression were associated with faster FCP load times. However, load times pick up again at very high (90-100%) compression levels.

Impact of compression on FCP, page weight < 880,337 bytes

Medium-sized pages had a similar distribution:

Impact of compression on FCP, page weight 880,337-3,625,927 bytes

Large pages had an even more extreme reverse bell curve distribution:

Impact of compression on FCP, page weight > 3,625,927 bytes

Although the exact distribution between page sizes differed, the takeaway is clear: pages with very low or very high levels of compression load the fastest.

In fact, you can see a dip in FCP performance for pages that compress a moderate amount of their files.

Dip in FCP performance for pages that compress a moderate amount of files

Specifically, pages that compress 60%-80% of their files perform the worst.

Therefore, when it comes to improving page speed, super low or super high levels of compression tend to work best. Low levels of compression reduce the work needed by the browser. And high levels of compression outweigh taxing work on the client side with a smaller payload.

Key Takeaway: Pages with very low or very high compression have better performance vs. pages with moderate levels of compression.

Third-Party Scripts Negatively Impact Load Times

Not surprisingly, we found that third-party scripts (like Google Analytics, social share buttons and video hosts) result in slower FCP times.

Third-party scripts negatively impact page load times

In fact, we found that each 3rd party script increases page load time by 34.1 milliseconds.

Our findings are in-line with others (like this) that discovered that third-party scripts have a massive impact on page speed.

Obviously, the impact depends on the script being used. Certain third-party scripts (like Hotjar) load relatively quickly. Others, including Salesforce, are notoriously slow.

In short, third-party scripts lead to longer load times. And the more scripts a page has, the slower it tends to load.

Key Takeaway: Each 3rd party script used on a page increases page load time by 34.1 milliseconds.

Responsive Images Appear to Improve Page Load Times More Than Lazy Loading and Use of WebP

Images play an extremely important role in website performance for two main reasons:

First, images take up a sizeable amount of a page’s overall size.

Second, user attention tends to focus on images that appear on a page. And if those images load slowly, this can negatively impact UX.

Because images can make or break a site’s loading speed, we decided to compare the performance of 4 different approaches to image optimization:

  • WebP: Developed by Google, WebP is an image format that can be smaller in size compared to other file formats, but still results in a similar level of image quality.
  • Optimized Images: “Optimized Images” are when different versions of an image are served depending on the user’s device, location and more. We included the use of a Content Delivery Network (CDN), Image Compression, and other Image Optimization Web Services under this category.
  • Defer Offscreen Images When images below the fold load when a user scrolls to that point on the page. Also known as “lazy loading”.
  • Responsive Images: When images dynamically adapt to browser window size.

And when we compared these various approaches for Lighthouse speed scores, Responsive Images came out on top.

Responsive images are correlated with best lighthouse speed score

We also analyzed which approach led to the most 100/100 Lighthouse scores. And the results were very similar.

Responsive images are correlated with a higher % of 100/100 lighthouse speed scores

Key Takeaway: Although the WebP may improve image compression compared to PNG and JPEGs, at this time very few sites have implemented this new image format.

GitHub and Weebly Hosting Has the Best TTFB Performance. Siteground and Wix Have The Worst

We compared the page speed performance of major web hosting providers.

Considering that server response time has the greatest impact on TTFB, we analyzed how different hosts performed on that key metric.

Specifically, we classified TTFB into three categories (Fast, Average, Slow). And we looked at the percentage that each host appeared in each category.

Here are each web hosting provider’s TTFB performance on desktop:

TTFB performance among major web hosting providers (Desktop)

Github, Weebly and Acquia were the top 3 performers for desktop TTFB. Automattic, Wix and Siteground fared the worst.

We ran this same analysis for mobile TTFB. Here are the results:

TTFB performance among major web hosting providers (Mobile)

As you can see, Github performs extremely well on both mobile and desktop. Which, considering that Github Pages only serve static resources, should come as no surprise. Which means that, in many ways, Github isn’t a 1:1 comparison to “normal” web hosts.

Seravo, Netlify and Weebly round out the top 4. Wix and Automattic are at the bottom of the list.

What’s the takeaway from this analysis?

TTFB is just one of many factors to consider when choosing a host. There’s also cost, uptime, customer support, features, and more.

That said, when it comes to fast page load times on desktop and mobile, Github Pages is by far the best option among major hosts. Wix and Automattic hosts tend to have slow TTFB times.

Key Takeaway: Among major hosting providers, Github and Weebly performed best on desktop. According to our analysis, GitHub and Seravo were the fastest mobile hosts. However, it should be noted that Github Pages only serves static pages, which gives it an inherent advantage over the other hosts that we analyzed.

China, Japan and Germany Have the Fastest TTFB Load Times

We compared TTFB loading times for 11 countries from our data set.

Here’s a country-by-country breakdown for desktop speeds:

TTFB load times by country (Desktop)

And mobile:

TTFB load times by country (Mobile)

Key Takeaway: China has the best mobile and desktop TTFB performance. Next comes Japan and Germany with fast page speeds that are above the global averages. France, UK, Canada, US, and Russia have an average page speed. Australia, Brazil, and India have speeds that are below global averages.

Pages With CDNs Perform Worse Than Those Without a CDN

One of our most surprising findings was that pages that utilized a CDN actually fared worse than those that didn’t use a CDN.

This was true for both desktop:

Use of CDN correlates with worse desktop page speed

And mobile:

Use of CDN correlates with worse mobile page speed

How could this be?

In theory, because it delivers content close to where a user is located, a CDN should improve page speed across the board.

How a CDN works

However, that wasn’t the case in our analysis.

We hypothesized that not all CDNs are created equal. In many cases, using a poorly-optimized CDN can actually slow things down.

And when we analyzed the performance of the top 18 of the top CDN providers, we did, in fact, discover a massive difference in performance.

Page speed performance among major CDNs

Specifically, we noticed that (on desktop) the best CDN performed 3.6x better than the worst CDN. Which helps explain why CDNs don’t automatically improve performance.

To make the poor performers easier to spot, we compared CDN performance to the global average.

Page speed performance among major CDNs compared to the average

We then put each CDN into one of three buckets:

  • Good (Fast % and Slow % are better than the average across all providers)
  • Average (Fast % or Slow % are better than the average across all providers)
  • Bad (Fast % and Slow % are worse than the average across all providers)

Here is a summary of performance for each provider:


Good: Airee, Amazon Cloudfront, Azure CDN, CacheFly, EdgeCast, Fastly, GitHub Pages, Google Cloud, KeyCDN, MaxCDN, Netlify
Average: CDN77
Bad: Akamai, ArvanCloud, Cloudflare, Fireblade, Incapsula, Sucuri


Good: Airee, Amazon Cloudfront, Azure CDN, CDN77, EdgeCast, Fastly, GitHub Pages, Google Cloud, KeyCDN, MaxCDN, Netlify
Average: Fireblade, Incapsula, Sucuri
Bad: Akamai, ArvanCloud, Cloudflare

Key Takeaway: Using a CDN won’t automatically improve page speed performance. Certain CDNs perform significantly better than others. Therefore, it’s important to go with a CDN that performs well on both desktop and mobile.


If you want to learn more about how this analysis was done, feel free to check out our study methods PDF.

Now I’d like to hear from you:

Which finding from this study stood out to you?


Which finding do you plan on taking action on?

Either way, let me know by leaving a comment below.

  1. Hi Brian,

    “Pages With CDNs Perform Worse Than Those Without a CDN”…

    I was NOT surprised because I’m FROM India and opens very slow sometimes here.

    I think you use CDN (You have a YouTube video on CDN, maybe in “Advanced SEO tutorial”)

    1. Hi Rintu, that could also be due to the fact that our pages are HUGE with lots of high-res images. Like the analysis found, it’s kind of hard to get around that.

      1. Hi Brian,

        For me this page loads very fast. But im curious why you choose to use 1400px wide images when they get displayed at 700px? For me at least.

        Does this make the images sharper? I think it ads allot of html size or not?

        Just curious 🙂

        1. Hi Tim, it’s because it makes them sharp no matter what the device (even on Retina displays). The downside, as you pointed out, it that they make our pages much bigger… which slows things down.

      2. So from what you’re saying Brian – there’s no choice but to choose UX over speed when it comes to images?

        Users are more likely to wait a bit longer when they know they’re getting an in-depth piece of content.

        I’m guessing image compression is a no goer as well.

        1. That’s basically what I’m saying. It’s a choice: do you want a fast page or a beautiful page? To me, I’ll take a beautiful ever time.

          As you said: people are willing to wait for something special.

          BTW, you can compress images without losing quality… to a point. We use for that.

      3. Hi Brian, your pages are huge! and since there are so many images, have you considered using the loading attribute for your images?

      4. Hi Brian thanks a lot for this guide it would be extremely helpful for me now to know and decide the best hosting platforms, frameworks and CDN’s that would give best results.
        But for my current wordpress and shopify sites I want to optimize for speed not just with plugins, amp or CDN’s but by some advanced stuff like improving render path blocking. Can you please give a guide on the advanced topics related to site speed or tech SEO or please suggest some good sources to learn these stuff in deep?
        Awaiting for the reply!!
        Either way keep up the amazing work, big fan😄😊👍👍

        1. You’re welcome. I know a little bit about site speed, but I’m probably not the best person to write about advanced topics.

      5. Hi Brian,

        Awesome Data. Hope 2.0 will include SSL provider. SSL is almost 60% culprit of TTFB.

        Was trying to improve our site TTFB on all the information available on the web.

        Found this site talk about WP Site Speed & Performance Optimization. The site Load crazily fast under 100ms.

        1. Checking woorocket. 1.5 seconds is the Time To Interactive, which is what Google uses for one third of their indexing algorithm. This was done in Cognito mode in Chrome, which excludes any extensions, to get a true reading.

          Also, Lightspeed will use a slow 4G network for testing now as a default. However, half the world is still on 3G networks. You can however create a 3G profile to to get a more accurate page load speed from half the world. Use this as your benchmark.

          Also, looking further at woorocket, they still have a few things to learn. As they reference using CloudFlare for a CDN and Kinsta for hosting. Understandable, if you haven’t really spent the hundred hours or more in researching all aspects of latency on the web.

      6. Interesting study.
        In most hosting comparison studies I found that Kinsta and Siteground performing better than wpengine.

        Another popular blogger from UK did a similar test only on hosting and found wpengine towards the bottom and wpxhosting at the top.
        This is going to add more confusion for those who are looking for a new webhost.

    2. Sorry to but in here but I feel compelled to say. I’m no expert but as far as I can determine the reason that WordPress has so many webs site around the world is because 19 years ago it was one of the first and it was free. So those that are still using it are either those that cant transfer off it very easily or those that mistakenly believe that it must be popular and so use it now. It does not help that many that still use it are reluctant to admit they are stuck with it. And that is how the myth continues that its a great web site builder. For many reasons I have found this not be the case.

    3. It also depends on your internet speed, ping etc. CDN is definitely a thing for better load time. I have checked with and w/o CDN. It increases upto 50%.


      1. “Pages With CDNs Perform Worse Than Those Without a CDN” – The answer is Yes and No, Yes – if your target audience is only from India then it is better not to use CDN because most of the CDN don’t have server in India (some do) that why you will get worst performance . If your target audience is from all over the world (Global) then using CDN is much better and it can also reduce server load and at the same time you will be protected your site from DDOS attack.

      2. I was NOT surprised because I’m FROM India and opens very slow sometimes here – It should be slow because Backlinko CDN is Stackpath or MaxCDN, they don’t have Server in India which mean the content is delivered from nearest location i.e could be from Singapore, HongKong ) & total page size of this page is 8.98MB which is really heavy.

      If Backlinko enable Lazy load page size can be reduce significantly.


      1. This is epic Brian, thanks for all you do.

        To follow up on the Siteground comment — I recently did a little testing of my own for a recent blog post. As a control, I tested WordPress + Siteground out of the box — no plugins or add-ons, just a clean WordPress install, the default theme, and the sample page.

        The page size was 51.6KB with a load time of 895ms. 100%D and 99%M on Google Page Insights. Once I started adding themes and installing plugins, a different story.

        I think it’s fair to say that SiteGround + WordPress can be lightning-fast if you know what you’re doing.

        Fascinating outcomes really. Thanks again!

        1. Hi Taughnee, thanks for sharing that! Super interesting. It’s always good to hear how things go with a controlled experiment like that. Our data set was based on real sites “in the wild”. The upside of this approach that it’s a more representative of how sites on different CMS’s, hosts etc. load in real life.

          But the downside is that it’s not totally controlled. There are confounding variables at play. So yeah, it’s interesting to see what you found from your controlled experiment. Thanks again!

          1. Thanks for the research Brian!

            This data is interesting, but it’s important to evaluate it lightly. Some of this is correllation rather than causation.

            One fact check: It mentioned that 74% of all websites make use of Javascript frameworks to create pages that are efficient, secure, and standardized. The link (which was data from 2013) actually said that 74% of websites used JQuery at the time, which is a library.

            Sorry to be nitpicky. This is a ton of data, and I’m sure it took at least 100 hours to do all this work. I got a ton of value out of this. Thanks Brian.

          2. Hi Jonny, you’re welcome. Glad you enjoyed the data. And I agree with you: considering that we looked at real sites in the wild, there may be (actually, there probably is) confounders that affect things. So everything here should be taken with a grain of salt.

          3. Both tests are valid imho. On the one hand, WordPress isn’t entirely to blame for poor performance in the wild, since it’s very easy to bloat it with themes and plugins. As a consultant I see these (bad) practices very often.
            great article btw, really helps me choose certain options or defend the ones I’ve already made.

          4. Brian and Taughnee
            Was doing same testing on siteground – blank site and real fully load with content. massive difference in speed. starting to become addicted to playing around with so many tools. but keep going back to basics. i have to say since siteground has moved to there new google data centre. remarkable difference in speed for both mobile and desktop. but still not where i want mobile to be grrr – learnt a lot from your post and the coments here, extremely interesting

        2. Hi Taughnee,

          I agree with you even we have different plugins and a theme and some scripts as well, and we are on WordPress + Siteground where our Desktop is 100% (600ms) and Mobile is 92% (2.3sec). We are using Sucuri CDN.

          and most of our client sites have a similar speed as trying our best to take care of things during the development which can hurt the speed later.

          1. There is also a huge reason to use Sucuri as a CDN – built in hacker proof firewall. I used to see as many as eight-hundred hack attempts on our development server at HostGator.

            After implementing Sucuri, the hack attempts dropped down to a few dozen at most. And then eventually just a handful per day.

            I have tested other CDN’s and yes you get faster speeds, but zero protection for your website visitors, and if you are getting DOS attacks, ask yourself, how much that alone, can destroy all business you have?

            It’s a trade off between page load speed verses complete interruption to business. I would advise looking at the other reasons for latency. Which can be easily identified, using the Chrome Dev tools built in to Google’s browser.

        3. I agree!
          I tested the same thing and I gotta say siteground is super fast and score 99 and 100, if you start adding themes you gotta play a lot with it to reach a high performance but it worth it.
          BTW- Gatsby people! That’s the future if you ask me, I love it! Just you gotta know what you are doing

      2. Siteground has the reputation to be amongst the fastest webhosting companies but I experienced the opposite myself too. Perhaps they performed better in the past but they certainly don’t atm.

        I’m actually surprised about the extreme bad performance of WP. With plugins like WP Rocket, Smush it, Autoptimize, and the likes, I didn’t expect it to end up at the bottom of the list.

        1. Hi Ramon, it could be that many WordPress owners don’t actually install those plugins in the first place. Or that all the other plugins they do install ends up slowing things down.

    1. Yeah! It´s hard to believe that Siteground was the slowest hosting provider. I would say it is one of the best I´ve ever tried. For example it´s much better than other very well know such as Bluehost. What kind of websites did you use in this research. It would be nice to have some examples of websites used in this research…

      1. Steve Teare, performance engineer at PagePipe:
        BlueHost and SiteGround both have bad TTFB. But SiteGround is worse because it fluctuates – some times out to 1.7 seconds TTFB.

        It is our experience from tuning websites for mobile speed that CDNs slowdown load times. Especially free Cloudflare. They’re the worst.

        Thanks for this research. It confirms our finds.

      1. Another awesome analysis Brian! Although I do feel you are giving WordPress a harsh evaluation. Many WordPress users do not perform any speed optimisations using plugins and/or choose a slow loading theme which will cause their WordPres site to load slowly. While I do believe the WordPress core can always be optimised better for speed, there is always room for improvement, I know for a fact that WordPress can be lightning fast. As such I feel your analysis reveals that only a quarter of WordPress users are doing the following with their sites: Using a lightweight theme (which there are plenty of to choose from), limit the amount of unnecessary plugins and only choose ones that do not negatively impact speed too much, then optimise images and site for speed using compression and speed plugins. I believe the real reason WordPress is scoring so badly in your reports is the vast amount of inexperienced WordPress users and the plethora of slow loading themes and plugins which is causing bloated websites for those that either do not care or do not know how to correct.

        1. Hi Max, thank you! That’s a good point (and one that a few others have brought up). My take is that, yes, that does partly explain the reason that WordPress rated so low in our analysis. But, as you said, it’s not fast out of the box (when compared to other out of the box solutions, like Weebly). It CAN be fast with the right optimization. But in the wild, WordPress tends to be slow.

  2. Hi, Brian!

    Every articles you write, have many images which helps the visitors to understand about the content.

    But, how you can speed the website much faster with rich of visual content? You’re so great and your site so fast!

    Please explain me.

    1. Thanks Diaz. Being a highly-visual site, our pages don’t load super quickly (according to most tools). But we do the best we can in terms of compression. So it’s good to hear that Backlinko is loading quickly for you.

      1. Only image compression? How can you explain me use software or online compressing image tools?

        The problem, I also compress the image, but the site are slow 🙁

        1. Not just image compression. We also use a great host, a light weight theme… and we have a full-time developer who does great work fine tuning things so the site loads quickly despite out massive pages.

          1. Great post as usual and some very surprising stats indeed. Squarespace and weebly better than WordPress! does that mean your migrating? I guess not as your using the sage theme which in itself is super light weight and fast not to mention highly customisable. I mean just look at your theme, looks brilliant 🙂

            Also the fact that responsive images are better than WebP when so many ‘gurus’ and even Google recommend WebP was a surprise.

            CDNs, well that didn’t come as a surprise but could that data have been skewed from the way the tests were conducted? i.e. locations? CDNs are supposed to be serving the content from locations closer to the visitor so theory would suggest a faster page load?

            As usual an epic post with some great takeaways to implement into SOP for technical SEO work especially image and compression stats you indicated. Very interesting indeed!

          2. Hi Alexzander, HA! I wouldn’t migrate away from WordPress based on site speed (unless WP was super slow). It has so many other great features that make it worth using.

            Good point there re: CDNs. I actually think that wouldn’t skew the results because the CDN should always serve the content closest to the user. Or maybe I didn’t understand your point.

    1. Thanks Ryan! I felt the same way, LOL. We do our best with page speed. But considering how many high-res images we use, the site isn’t the fastest. Working on this study made me want to make site speed a higher priority!

  3. Hey Brian – super post! Curious as to whether you’ve ever thought about going a step further and analysing any correlation between speed and serp rankings. I guess we all know it plays *some* role – but we I don’t think anyone has ever truly studied it closely. Perhaps it would be too difficult to be conclusive?

    1. You’re welcome, Andrew. Needless to say, speed is just one factor that I’d consider when picking a CMS. For example, we still use WordPress even though it’s pretty darn slow.

      1. There’s a way to have the best of both worlds with plugins like wp2static…

        You can manage your website remotely with WordPress and publish a static site.

        It’s very fast and secure.

        There are some limitations but if your site doesn’t need dynamic content, you can use 3rd party scripts to handle forms and comment modules…

        Thanks Brian! The data you pulled was revealing.

    2. I would never consider Weebly or any similar options. While WordPress might be trickier when it comes to loading speeds, it wins hand down when it comes to versatility, SEO out of the box etc. Speed alone (although this can also be dramatically improved) shouldn’t be the deciding factor. I’ve made faster websites on WordPress than others on Wix or similar platforms. it’s not what you’re using, it’s how you are using it.

  4. Thank you so much for this valuable research in to site speed. I have been wondering for quite some time now about all the information that is covered in this post. The CDN, Responsive images and Javascript framework sections really gave me clarity on how I can improve site speed for our clients


      1. I used to run a personal Squarespace website and I cam confirm that it was super fast. However, I switched to WordPress a couple of weeks ago, mainly because of the plugins, SEO, etc. Thanks for one more valuable article, Brian.

        1. Thanks George. Great point there: even though it can be slow, I still use and recommend WordPress. It just has so many great features.

  5. Weebly… Fascinating.

    Ave 10.3 sec to fully load…

    Suddenly I don’t feel that bad about my 2.6 sec any more…:)

    I still need to pay attention to reducing image weight.

    Thank you for the insights – it puts many things into perspective.

    1. Hi Peter, you’re welcome. Yeah, that number stood out to me too. It is an average, so it’s possible some massive/slow pages are driving that number up. But still: 2.6 seconds ain’t bad!

    1. I certainly hope not. Even though site performance is important, I wouldn’t base my choice of host based on that alone. There’s also reliability/uptime, support etc. etc.

  6. Hey Brian, when you talk about WordPress, are you referring to or self-hosted wordpress sites? I can get wordpress website fully loading in under 500ms. The key to achieving this is to not bloat out WP with plugins and to use hosting that specifically uses Litespeed server.

    1. Hi Oliver, we’re talking about any site that uses WordPress as a CMS. So that includes both. You’re right: I don’t think that WordPress is necessarily slow (although it has a reputation for being somewhat slow out of the box). And you’re right: it may be partially due to the fact that WP owners weigh down their site with lots of plugins etc.

      1. Ah interesting, this was my question as well..

        I used to think that wordpress was the fastest CMS. Thats kinda bad news because Ive grown to love wordpress and how it works.

        I used to use elementor but that slowed my site way down. Now I use siteorigin page builder which seems allot faster.

        Would be better to not use any site builder but if I manually have to create colums and divs with all css it would take me allot more time to build a page 🙂

        Related post plugins also slow down your site allot I think..

        1. Moving my clients’ sites to a Litespeed enabled server has been the ‘easy win’ to achieving fast load times. Even on brochureware sites that use a pre-made theme such as Divi, once the Litespeed cache is primed they can load in under 200 milliseconds.

          Litespeed reduces the TTFB really well and blows setups like NGINIX/Varnish out of the water. It also integrates nicely with WordPress and has built-in image optimisation and automatic webp image serving/lazy loading.

          I tend to code my own themes with CPTs and Custom Fields usually converting a pre-made HTML template and usually stick to around 4 maybe 5 core plugins.

          1. All it takes is one active plugin which causes slow POST admin-ajax.php requests on the front-end of the site was well as slow queries in the sites database.

          2. Thats very interesting, I havent seen anything about lightspeed servers yet. But I found one im my country. Im curious to see the difference 😉

  7. I haven’t finished reading the previous post due to the detailed explanation.

    This post concludes everything about page speed, great work.

    Please keep it up, backlinko is the best source for SEO by far.

  8. Hi,
    I loved your content but the question coming to my mind is.
    I have checked some of your blog post score in Google page speed test, it’s lower than 50 for both mobile and desktop but then also your blog post are ranking. What is it? How you are able to rank well even when the page size and speed it very much low? And on the other side Neil Patel blogpost is also ranking but which technology he is using that his 20 images ranked blog post size is not more than 500kb and 60 requests?

    1. Hi Jaya, I think the explanation is basically: site speed is a Google ranking factor. But it’s one of hundreds. So it’s possible to rank with a relatively slow site.

      1. Can you tell us how to compress the web page codes into paragraph like removing all the space and comments to decrease the web page size like Neil Patel does on his blog post?
        Please answer to this

        1. Great article, as always. Good hints. Of course, some results could be affected by various factors. For example, maybe some hosting providers have different customer base or serve a lot also in countries with slower connections. Maybe WordPress is so down in the results becouse it is usually packed with plugins that other platform don’t even have.

    1. Thanks Farhan. Same here: I was super surprised by our findings that CDNs usually lead to slower websites. But it does make sense when you consider how many sites have their CDNs set up incorrectly.

    1. Hi Laura, no problem. Happy to help. In that case, I’d recommend testing how your site performs with and without a CDN. Sometimes those built-in CDNs aren’t the best. That said, I always recommend using a CDN when possible because it’s also good for site security.

  9. Thanks Brian for all the info and statistics.

    I’ve been on a big push lately on improving site speed with all my clients. It is good to see data that isn’t specific to how exactly you should optimize your site for speed but rather what are the potential costs/benefits to speeding up your site via specific site speed optimization practices.

    I specifically found the CDN research to be most interesting.

    1. Hi Austin, that finding stuck out to me as well. It shows that these best practices (like using a CDN) have a place. But they need to be setup correctly to actually work.

  10. Hi Sir Brian, that was some interesting discoveries there! Intact I was shocked to see siteground among the bad guys 🙂 However what did your findings made of Shopify? And I would also like you to produce a comprehensive guide for WordPress on how to load faster both on mobile and desktop especially mobile. Thanks for your awesomeness.

    1. Thanks Abdul. We actually didn’t look at Shopify in this analysis. But considering how fast its growing, it would be an interesting platform to check out.

  11. Very interesting about the WordPress thing… but I think that’s largely due to many people that use it not being professionals. I’m able to get performance very high for WordPress. So in the right hands, it can make a big difference.

    1. Hey Doug, I see what you mean. But wouldn’t you say that Squarespace appeals to people that aren’t professionals? And they came out near the top.

      1. I would guess that WordPress is used by a lot of people who ‘sort of know’ what they are doing or ‘don’t know’ leading to slower load times. Squarespace however has recognised this and I am sure does a lot of the heavy lifting in terms of optimising images etc backend so the user doesn’t have to.

        Very interesting about the CDN’s however. Did Caching enter into the research at all?

        1. That could be, Tim. I’m honestly not sure what Squarespace does behind the scenes to make their sites fast (or how much they leave up to their users to figure out). Interesting point that I hadn’t thought of!

        2. I 100% agree @Tim Chorlton. My first thought was that WordPress leaves 90% of the work up to the end users, which will create a massive variance in the outcomes. Whereas a CMS like SquareSpace will drastically limit what role the user plays in the performance, and only allows them to focus on the design aspect. This keeps the quality of the pages running smoother, more lightweight, and consistent. WordPress Admins come in every shape and size, some admins think it is still ok to put long run videos as the header for mobile devices…I feel this greatly impacts the data.

          @Brian Dean, that said, unbelievably fantastic article. I felt myself completely enthralled in the page wanting to read more. This is pure brain candy for me and directly impacts my business. Thank you sir for a job well done!

      2. M8, Square Space and Weebly CMS hosting are limited their own hosting (optimized for their own software) and they have a maximum of 1-2% market share compared to WordPress +30% of all websites and over 60% of the CMS market share..

        This data is pretty skewed as WP is the most used CMS. It is super easy to get decent ratings (2-6s total load time) with WordPress by using decent/good hosting and caching plugin.

        I have over 30 WP-sites hosted and the best of them are fully loaded desktop 1.3-1.5sec and worst are around 5-6s. For mobile these same measures are around 3-4sec for the best and around 10s for the worst. No magic tricks or any high-level technical stuff used.

        1. I’m not sure how market share plays a role. So if 60% of CMS’s are WordPress, that explains why they’re slow? I don’t understand the logic there.

          And yes, WordPress can be quick when optimized correctly (which it sounds like you’ve done). But “in the wild”, WordPress sites simply aren’t fast.

          1. The logic is sound.
            A large percentage of WordPress websites are on poor quality Shared hosting services – which severely skews load times against WordPress.. What percentage of Weebly or Squarespace sites are on Shared hosting ? 0%…
            There is strong information bias in this study.

          2. Squarespace and Weebly sites are all on dedicated servers? I don’t think so.

            Also: I definitely think there are potential confounding variables that may influence why one CMS was faster than another.

            But this analysis didn’t attempt to explain why one CMS performed better than another. You need a controlled environment for that. Otherwise, you’re just guessing.

  12. Wow, very surprised the average page takes longer to load on mobile over desktop. I would’ve expected the complete opposite!

    Also interesting to see that Cloudflare performs so poorly on both desktop and mobile.

    A lot of this is over my head (I didn’t even know there were multiple JS frameworks), but I’m definitely sending this to my web developer. Great study, Brian!

    1. Hi Kyle, I think the explanation there is that most pages are basically the same size on desktop and mobile. Especially now that people are using responsive design vs. “m dot” pages. So even though it may be mobile-optimized for UX, the actual page is the same size. And when you load a big page on a mobile device, it’s just gonna take longer to load up. Hope that makes sense.

  13. Thanks Brian, for showing the actual facts about siteground. There are many gurus who recommends siteground just for the affiliate commission without even digging dip down.

    Umesh Sigh

  14. Right article @ right time. I thought of implementing Cloudflare CDN on my local business website. After reading this article I decided not to.

    4 days back, I was thinking of traffic sources and shawn from thrive themes sent an email at the right time just like your email today.

    I am surprised how this things are happening.

    Thanks Brian.

    1. You’re welcome, Avinash. I’d still strongly consider using a CDN. There are a lot of advantages of using them (like security). And if they’re setup right, they can help with site speed too.

    2. Although CloudFlare performed poorly for speed on AVG, It provides amazing security, free SSL, HTTP2 pushes, and provides caching and dynamic compression which DOES help. So you win some you lose some. I don’t work for, nor have relations with anyone there but I support the tool regardless of this report. For a free service with paid options, what it provides is well worth implementing for the very minimal loss.

      Run your own tests. Run test pre-installation, install and test again. I think you’ll be surprised.

  15. I have never even heard of some of these CDN’s before, I will have to do some research into the CDN’s I’ve never heard of and maybe make the switch.

    Also, Weebly is crazy fast for a CMS. I didn’t expect the CMS to even be in the top 10. Thanks for all the hard work!

    1. Hi Dillon, same here. I had heard of most of the big names (like Cloudflare). But a good chunk of these CDNs were new to me too.

    1. Hey Cris, we didn’t analyze Dreamhost. And they’re one of the few hosts that I don’t have personal experience with. So I don’t have much to say about them.

      1. Brian,

        So, which hosting have you tried so far? Which ones would you recommend for a startup project and, more in general, websites for small businesses (no e-commerce)?

  16. Hi Brian,
    Thanks for sharing this amazing piece of content. I have a question that what If we used Cloud or Window Hosting on our website? is it fast or not and what is your opinion about BlueHost and Godaddy Hosting?
    Looking forward to your reply.
    Hamza Hashim

    1. Hi Hamza, I’m honestly not sure that one is clearly superior to the other. To me, it’s more about the company and service than the servers themselves (although that does make a difference). If you’re sharing a server with 1000 other sites, your site’s going to be slow no matter what.

  17. I think it is important to note that when a Squarespace or Weebly site is built, the user doesn’t choose the host. These sites are self hosted on servers optimized specifically for their sites. Compare that to WordPress where the website owner often chooses their own host (usually the cheapest option) that will ultimately affect the pageload times. So WP load times are and average of all hosts, not necessarily the CMS itself.

    WP Engine is one of the fastest hosts, so WordPress sites on this host would give people much faster WP sites. Choice of host is super important if you care about site speed, so i’m glad you did rate hosts.

    Thanks again for all your insightful data Brian.

    1. Hi Mike, great point there. Especially considering how many WordPress sites are hosted on $5/month hosting plans. And yes: I always recommend that people upgrade their hosts if they can swing it. You can compress images all day long. But nothing’s going to give you a bigger boost than a solid host that’s optimized for your site’s architecture.

  18. Cracking analysis Brian. Interesting about the CDN, that will ruin a few people’s afternoons! The last few sites I designed I have used responsive images for the heroes or large carousels (4 diff sizes for each) and yes, it makes a noticeable difference certainly on the mobile score

  19. Hi Brain, most of the wordpress website is not optimised for speed. That’s why most of the wordpress website slow. But WordPress have lot of plugins for speed up website. I really enjoy to use wordpress. Because its very easy and lot of fetures. Anyway, Thanks for your valueable research.

    1. Hi Mike, that’s true: there are many WordPress sites that are super slow because they’re not setup correctly. But they also have plugins that slow things down. So to me, it might actually balance out.

  20. Siteground affordable plans upto Go Geek are slow though they have best support system to deal customer issues.

    I found wpx host also good and my site speed got better.

    Though my page is heavy and is 1.5 MB and I am trying to trim things down.

    The more feature you add like live chat and all it brings speed more down.

    Too many requests it cause.

    Also, I found Jetpack making too many requests and this is what makes people leave it.

    Though it does have great functions but there are numerous requests from one plugin.

    1. Thanks Naveen. That’s basically what we found: there are things you can do to speed things up. But at the end of the day, a big page loads slower than a smaller page.

  21. Hi Brian,

    Thanks for putting this all together! Impressive…

    Too bad that mainstream services like WordPress and also Cloudflare are significantly underperforming. For WordPress this was already clear to me: free, flexibility and noob-friendly use comes at a price after all. But if you keep your design and choice of plug-ins down to the must-haves, you still can get good speed.

    Only the stats about Cloudflare shocked me a bit… Of course, it’s available for free and not a real CDN, but this makes me rethink using it. I’ll run some tests with the other CDN’s to check out the difference.

  22. Hi Brian,

    Thank you for the valuable research you have done here. Is it possible to give you more insight on how to optimize websites with Big Data and long content? One of my clients who generate more than 500 articles a day with around 700 words on each and around 2 images.
    This is obviously a huge data to manage which might slower your website speed. Can you help me with this?

    I have just started learning MongoDB after a friend suggested to use for big data or do you have any suggestion

    1. Hi Sunita, I’m not a developer so I’m not the best person to ask about this. I do know that WordPress has a WordPress VIP service designed for content-heavy sites. I don’t know much about it but it might be worth looking into.

  23. Hi Brian, great content. Did you take into consideration the volume of content on a website when selecting the 5+ million sites? I’ve noticed that a lot of the Squarespace and Weebly sites tend to be amateur bloggers or very small businesses. They seem to inherently have a lot less content and depth than WordPress sites, which could skew the analysis.

    1. Hi Luke, thanks! We didn’t drill down that specifically. But you raise a great point that some WordPress sites can have more content. My only potential counterpoint is that Squarespace and Weebly sites tend to be really image-heavy compared to WordPress sites (which are mostly text). So I’d say that, in many cases, Squarespace and Weebly sites are actually bigger in terms of filesize than WordPress blogs.

      Plus, Wix is similar to Squarespace and it ended up ranking low in our speed rankings.

    2. Hey Brain, thank you for what you had given to the SEO community.
      But indeed, I doubt your thoughts regarding SiteGround, as I’m using their service for such a long time. Can’t believe on this, but the fact that you derived from your case study of “FIRST BYTE” is acceptable, and will research for the same.

      1. Hi Rohit, I definitely wouldn’t switch hosts based on this analysis (especially if you’re enjoying working with SiteGround). It’s more to establish benchmarks.

  24. I’m wondering if overall speed of WordPress sites is as meaningful as it seems in your data. There are various online reports about significantly different page load times for different WordPress themes. For example, Avada seems to be the most popular WP theme, but is reportedly slower than many other themes, possibly related to the depth of features included. So I have to wonder how “WordPress” sites might compare with other CMS’s if WP sites with faster WP themes were analyzed?

    Similarly, might other factors be at work here, such as whether WP sites are fully updated vs running old versions, sites that are running too many or inefficient plugins, etc.? So is it really fair to lump all WP sites together in an analysis like this? The results are interesting, but I suspect we should be careful about making any overly-broad conclusions.

    1. Hi Richard, you bring up a good point. A “WordPress” site can look completely different depending on the version, theme, plugins, hosts etc. Not all WP sites are created equal. That said: you could largely say the same for Drupal and they ranked above WordPress in our speed rankings.

  25. I was very surprised to see Siteground ranked as one of the worst hosts for speed in your study Brian. I only recently moved my site to Siteground so I hope Siteground act on your results and push for improvements!

    1. Hi Val, how has the experience been with them so far? Like I mentioned in another comment, speed is just one thing a host brings to the table.

  26. Great stuff as ever Brian.

    Certainly found certain CDNs to be slower as well.

    Glad we’ve got you in our corner though, no one has time for the kind of research you do 😉


  27. Hey Brian. Did you include Webflow in your CMS analysis? We used them to grow our blog to 150k pageviews a month and it is so powerful, and seems very quick to load, it’s just no one seems to widely recognise them yet in such tests.

    1. Hi Bradley, we didn’t include Webflow in our CMS analysis. But you’re not the first person that’s told me that they’re really happy with it. If we do a 2.0 version of this study we will definitely also look at Webflow!

  28. These results are a little surprising to me. I noticed that you didn’t discuss the location, device, and network connection these tests were run with. Can you elaborate?

    1. Hi Tom, I recommend checking out the methods PDF at the end of the post. It outlines how the study was done and the sample we used for the analysis.

      1. I missed that link, thanks!

        So, CUXR only takes newer versions of Chrome into effect (and further subsetting by users that have opted in to data collection – it’s questionable whether performance-needy users are enabling extra data transfer here). HTTP Archive is only testing on Chrome from Redmond, CA. This would leave several truck widths in the accuracy of the analysis to drive through, wouldn’t it? There are literally zero Safari/Mobile Safari page loads in this data set for one.

        Another question, how many sites/pages were in each CMS platform sample? How were you able to determine this programmatically (as I imagine you didn’t hand classify millions of URLs)?

        Thanks for this. Questions aside, we need more content like this in the world.

  29. This is a fantastic post. As to the WordPress loading speeds, are you factoring the bloat that comes from “too many plugins”?

    I find that a lot of WordPress sites which are sluggish tend to have a ton of unneeded or redundant plugins, or plugins which are left active when they are not needed – like a “duplicate page” plugin, as an example.

    1. Hi Bill, thank you! We didn’t factor that in as we wanted to compare each CMS on equal footing. That said, you’re right: part of the reason WordPress ranked low on the list may be because of plugin bloat. It’s a real problem.

  30. Hi Brian, Thanks for the in-depth analysis, Great stuff. I am working on Magento. I just wanted how good Magento is for SEO and Speed test performance.

    1. Hi Chetan, you’re welcome. We didn’t look specifically at Magento here, so I’m not sure how it stacks up vs. the platforms that we analyzed.

  31. How did Bluehost not make the list? That’s the bread and butter for most affiliate bloggers. Or did I just answer my own question?

  32. Very Interesting Brian –

    I’d love to see an update in a couple of years and see how the results of mobile speed and load times compare when 5G is fully rolled out. I’m expecting to see mobile more comparable to desktop then.

    Thanks for this!.

    Epic study!

    1. Hi Derek, you’re welcome! That would be interesting. 5G seems to be insanely fast, so that’s definitely a game changer.

  33. Are you just ignoring the actual content that is on the sites? How can you compare platforms like this without taking into account the content that each site is loading?

  34. It’s a shame only TTFB is shown for hosting provides, and that this grouping into Fast/Medium/Slow was the scoring method.

    I would’ve preferred to see the total load times and skip the binning–show average and median. Seems to me there’s enough data points that you’ll get a normal distribution and even just the average is representative. I don’t trust the binning to show a true story.

    For example, I have used both WP Engine and Kinsta. Kinsta is consistently faster for my site than WP Engine, by quite a lot. You can see some funny business on WP Engine just looking at its proportion of “Slow” bins, but it wins because only the “Fast” bin is really considered.

    Plus you have all the peeps saying they don’t believe the Siteground numbers. Makes me wonder what its total load time looks like.

    All in all, an interesting and valuable article. Being a quant sort of guy, I just want more, LOL!

    PS Might have also been interesting to look at some of this vs site traffic. In other words, what might be best providers/practices for big vs small sites.

    Relying only on TTFB may be good for SEO, but I don’t think it matters at all for user experience. So, we don’t get to see a benchmark that’s relevant to user experience.

    1. Hi Bob, one of the things that’s tough about doing these industry studies is choosing what to analyze. When you have a dataset of 5M+ pages, it’s tempting to analyze everything possible. But you quickly realize that it’s not possible and that you have to “choose your battles” (so to speak). So yeah, I agree that approach would have also bubbled up some interesting findings too.

      And I’m glad to see that you enjoyed the post!

    2. @Bob, that’s the very interesting thing with Siteground. The ttfb can be frustratingly long but total load times is barely longer. For example, ByteCheck returns 751 ms ttfb for the home page of one of my sites. The total load time for the same page is also 751 ms. Google PageSpeed gives “first contenful paint” at 2 s. That’s also the time for “time to interactive”.

  35. Great study. Very thorough. I always knew WP was sluggish, but wow… it is downright snail-like. Though, I found that theme choice can impact the speed of a WP site. It would be cool to have a WP theme comparison. Divi vs. Avada, vs. etc…

    1. Hi Steve, absolutely: WP can be slow or fast depending on how it’s setup. But according to this analysis, it tends to be slow most of the time.

    2. Yes, amazing insight.. Kinda bums me out..

      I use ASTRA theme with Origin Sitebuilder, WP Super Cache and Autoptimize.
      Everything with speed in mind..

      Would be cool if there was a self hosted version of Squarespace or Weebly!
      Or does anyone here has suggestions with self hosted CMS with ultra high speed?

  36. Hey Brian,

    You missed testing Limelight Networks’ CDN (yes, a major provider).
    They have been awarded several times at major events, so they should’ve been included in the testing. Just my two cents.

    Thanks for the analysis, there is work to be done for many of us.

  37. I have respect for your work, but this time I don’t agree this time.

    Siteground is fast and good hosting compared to many. You have compared it with Static website hosting platforms, In all case static website will outperform dynamic sites based on WordPress or other CMS.

    its also depends on the theme and plugin used by WordPress website. A good theme with right plugin can do much better than most of the CMS or services mentioned here

    Siteground has mainly WordPress sites and therefore it is unfair to compare it with githubs, netlifly etc. which are static site hosting platform.

    Also, comparing different JavaScript framework without much detail is totally wrong. Many things depend on the way they are implemented and there is lot of factors that make one application faster or slower than other.

    To me this is misleading and completely wrong presentation without knowing actual implementation of each website

    1. Hi Sanjay, you’re 100% right, comparing a traditional host to Github isn’t fair. That’s why I pointed that out twice in the post: it’s a key point.

      But I don’t agree that you can’t analyze things in aggregate. It’s not perfect by any means, but it does give you an idea of how things load in the real world.

  38. Wow, Dean, that’s some very extensive research. What disappointed me was that WordPress was so far down the list for mobile loading speed. My site’s WP lol. I will have to look into speeding it up. I will download the Pdf. Thanks for all your research, your the TOPS!

  39. Hi Brian,

    Amazing content! I think in CMSs comparison maybe could be better to split the research in two groups, the first one for self-hosted services like Wix, Squarespace etc and second one install-able CMS like WordPress, Joomla etc. In first case the optimization on pagespeed depends mostly from the solution provider, in the other case from website creator – designer and web hosting.

    1. Hi Vasilis, good point there. There’s a possibility that because WordPress is self-managed, that it’s slower. But it could also just be that WP sites are bigger and take more time to load. It would be interesting to drill down into each CMS to figure out why one is faster than another.

  40. Very interesting overview!

    But, it’s not really fair to see you say WordPress is ‘slow’ when it’s not hosted the same way as Squarespace or Wix. WP is self-hosted so the speed mostly depends on the exact host business uses… Not really a fair ‘conclusion’ it seems.

    1. Hi Adrijus, fair point there. However, the point is that, in the wild, Squarespace sites tend to load quickly. Why that happens is another discussion.

  41. If a site is already ranking well, and has terrible site speed from a CMS, do you think it’s worth using all the SEO budget for a redesign on a faster or custom platform?

    1. Hi Ryan, I’d actually use the SEO budget on content, outreach and links. If a site is ranking well I’m usually reluctant to make wholesale changes. You never know what can happen.

  42. Kinda funny that a lot of testing was done of websites built on CMS platforms. It’s very well known fact that CMS will always be much slower than any custom website.

    It’d be interesting to see the correlation between loading speeds and rankings of CMS vs custom non-CMS websites.

  43. This is an awesome report, thank you.

    I’d LOVE to see all this data filtered by CMS in each category, so it can be an “apples to apples” comparison every time.

    All of my clients use WordPress, so I can easily ignore data from providers like Github hosting and Wix/Weebly/Squarespace. But when looking at a general host’s performance (such as SiteGround or Bluehost) who hosts all types of sites, not just WordPress sites, it’s not particularly informative.

    Any way to filter/limit the data set to the approx. ~2 million WordPress sites in your list? Thanks!

    1. Hi Andrew, thank you!

      That’s something I’d like to look into in a 2.0 version of this study. That would be interesting. For the record, I 100% agree with what you’re saying with WP vs. Github. I made sure to emphasize that in the post.

  44. A large majority of my clients use WordPress. Are there plugins that can help page speed? Yet, adding more plugins, I would assume, may slow down speed as well. So would plugins not be worth it? Maybe a blog post on “Page Speed Optimization for WP Sites” would be an awesome/useful resource.

  45. Hi Brian,

    Thanks for sharing such an informative article, it will help me to improve our website speed.
    Also, how would you compare StackPath CDN with CloudFlare and SiteGround with HostGator? Please, share. Thanks again 🙂

  46. Hi Brian,

    I just want to add, How you install WordPress plays an important role in overall loading speed.
    I tested a $5 DO droplet,
    1.) with one-click WordPress image.
    2.) With Runcloud.
    3.) CyberPanal on Ubuntu 18.04 (OpenLiteSpeed+LSCache)

    Now I am settled with CyberPanal as it allow me to control OpenLiteSpeed, which can support high-amount traffic and loads quickly.
    While both (1) and (2) gives timeout in testing.

    So I guess, the priority should be how you install WordPress.

    PS: I am not related to CyberPanal in any matter.

      1. I ran some tests.

        10,000 total Client hit (60second): 30,000 hits was Sucess (100%)

        So the cheapest VPS plan (with correct config) able to handle 500 hits per second is insane right? I think it can go further than that.

  47. Hey Brian,
    this is awesome, however for me a couple of things missing. Maybe another post could dig into these.
    1. I use 3 different speed test sites. Pingdom, GTMetrix and Lightspeed. They all give wildly different load times for the same location.
    2. How can we reduce loading times in WordPress? The instructions that are given, such as “Decrease http requests” or “optimize CSS and js” are Chinese for the average blogger. I tried several optimization plugins, but several of them ruined the look of my page, e.g. it looked like an unresponsive mobile page on desktop, content reaching outside the screen.

    1. Thanks Peter. 1. I notice the same thing. I think it’s because they’re loading using different “devices”. And they score things differently. 2. I recommend hiring a developer to help you implement that kind of thing. It can be totally worth it.

  48. Impressive (and detailed) post Brian, thanks very much.

    I tried out Siteground a couple of years ago and was disappointed.

    I did some work for a client about a year ago and was impressed with the performance of their site (hosted on Siteground Starter), so much so that I moved my site to it ( which according to Ubersuggest has a mobile loading time of 3 seconds – which is pretty good as I haven’t done anything to it other than install W3 Total with default settings.

    Gotta dash as want to put Weebly to the test!

    Thanks again,

  49. hi Brian, great content again. I was surprised to know a few factors affect poorly loading speed of a webpage such as CDN, some great CMS like wordpress, weebly, wix etc.

    I have a website made using WordPress with elementor page builder and Astra theme. But its loading speed it way high in both mobile and desktop. I am using a few plugins such as w3 total cache, lazy loader, etc to improve the speed but, I didn’t get the expected result.

    Every time I analyse my website on GT metrix, Google page speed insight it showed very poor score. The errors are: too many http requests, some page coding ( js and css ) couldn’t be loaded etc.

    Do you have any idea how to fix those and improve speed?
    Probably I am not ranking high enough because of this factor.


    1. Hi Manoj, thank you. I actually recommend working with a developer to help you. It’s not a magic bullet. But they can usually get to the bottom of issues like that.

  50. You’ve discovered some really interesting insights here.

    I’d be interested in comparing different WordPress setups, because loading speed varies vastly on WP depending on theme, media/images and compression, caching, and plugin choice.

    When I was getting started building WP sites, a couple of mine took over 10 seconds to load because I was inexperienced with the above factors. Now it’s unacceptable for a site to take longer than 2.5 seconds to load in my book.

    It seems a little unfair to WP because it’s a basic skeleton that gets a bad rap because of its users.

    Wix deserves a bad rap though, because so much is built into the CMS that doesn’t allow you to optimize for speed (or SEO, of course).

    1. Hi David, thank you! Very fair point there: WP speed is more about how its setup. At least that’s part of the story.

      I say that because Squarespace is not super flexible (like Wix) and it loads really quickly. So I think that “user error” is part of the explanation for slow WP sites. But not the whole enchilada.

  51. In my opinion, it is such a difficult task to succeed a very high score on page speed if your website is service advertisements because most of the suggestions are related to minimizing number of requests or redirects, minifying JavaScript, setting an expiration and more. Basically it doesn’t work with the advertisement websites and really not sure that what it will be a solution of succeeding a high score in this consequence.

    1. Hi Jacob, there’s some truth to that for sure. It falls under the “3rd party script” thing that we looked at: they slow things down quite a bit.

      1. Certainly, but I would have assumed the top performing ones from a resource like cdnperf would have made the list instantly 😉 But great work on the article. Just wish it included them. cause any time I see KeyCDN or cachefly, I think instantly people would like bunnycdn better. So that’s why it sorta triggered me. lol

    1. Hi Mark, we weren’t able to look at sites that run on Shopify in this analysis, but we will probably look into that next time.

  52. Hi Brian,

    Any chance we can see the distribution for these scores? I really prefer to see other metrics besides average/mean. Having worked on sites large and small, I also think this analysis tends to reveal the technical skill of the developer. There might be clear advantages, but the wordpress site with 20-100 plugins is obviously going to be slower than the static site…right?

      1. The queries include the median in most cases. Might be interesting to see if there is a meaningful difference between the average and median and if it changes the rankings. Alternatively, you could include it in the top line numbers for TTFB, first content, etc.

  53. Hello Brian,
    thanks a lot for this analysis!
    I just wonder, how speed correlates with ranking 🙂 Any thoughts about that?

  54. Hey Brian,

    Though I should let you know, on the CDN image Suciri it’s actually “Sucuri”.
    Anyways, awesome post, keep it up.

    Best Regards,

  55. The wordpress rankings could be a major shock for people who have always trusted this CMS.

    But i think with plugins like AMP, companies finds a way to be better at mobile page speed.

    In the end WordPress (and CMS in general) allow people without coding knowledge to create more than decent websites for their companies.

    Thank you for this study, Brian. Would you recommend CMS as wordprees? Or you think they are outdated.

    Best regards

    1. Hi Tomas, “In the end WordPress (and CMS in general) allow people without coding knowledge to create more than decent websites for their companies.” I 100% agree.

  56. Hey Brian, this is indeed a great post! I recently created my website and have been aggressively researching on how to improve Page speed. This article is a treat for me.

    I did have one question though – for parameters like ‘Fully loaded’, don’t you think a higher loading time for Mobile pages would have a correlation with the hardware configuration as well? Desktop users may have a much more standardised hardware and OS (mostly Windows or MacOS) across the world, but the ability of a mobile device to decompress gzip files quickly, render the webpage, etc. should depend on its hardware, which widely varies from low-end Androids to high-end iPhones. Just a thought. Extremely useful analysis though. Thanks!

    1. Hi Dharmendra, thank you! Yes, I would expect that. It’s actually true for desktops too (try loading YouTube on an old PC!). But it’s more pronounced on mobile devices.

      1. Hardware is certainly part of the equation. But loading a site over a mobile/cellular network vs. a land-based connection is also a significant factor in slower load times.

        (I live and run a business from an RV, using mobile networks with all manner of hardware, including desktop computers and smartphones.)

  57. This is super helpful, thanks so much for sharing all this info Brian! Lots to digest here. The conclusions on CDNs and hosting (e.g. Siteground) are surprising, but as you mention, there are soooo many factors to consider when deciphering “why.” Love your feedback (in comments earlier) on images – choosing between “super fast” and “beautiful.” Like so many other things, it really depends on your intentions.

    1. Hi Kurt, you’re welcome! 1000%: the goal of this analysis was more to determine benchmarks. The “why” part is a completely different type of study, usually with a smaller sample size and a more controlled environment for testing A vs. B.

  58. You must put allot of work into this research.. Its hard for us to move our site. Besides working to reduce home page size to increase on page speed increases, can you recommend ways to speed up. Thank you

    1. Thanks Will. A ton of work went into this piece for sure. Compressing images is huge. In my experience, that’s the #1 thing (along with having a great host)

  59. Hi Brian,

    For the CMS page speeds – what factors were looked at to determine those? Did you compare similarly-structured sites across various CMS’s?

    Just curious, as I wonder if an easy-to-use CMS like WordPress might be more likely to attract a larger number of your average mom-and-pop shops (who may know nothing about page speed or website structuring), thus bringing down WP’s averages?

    Let me know if I’m misunderstanding this – thanks for this incredible resource!

    1. Hi Emily, we didn’t do that sort of comparison. It was simply the average page speed for each CMS.

      You’re right: it could be that WordPress users have certain characteristics that other CMS users don’t. But I’d question the fact that WP attract mom and pop shops more than Squarespace and Weebly. To me, those are geared more towards non-techie folks.

      1. Got it! And yes, that’s probably true; I was basing my thought off the fact that it’s one of the most-used CMS’s, though to your point, this doesn’t necessarily speak to the average expertise of its users.

        Thanks for clarifying, Brian!

    1. Hi Prayas, yes we use a CDN here (provided by our host). I don’t have one in particular that stands out as great, so I’d consider testing some of the CDNs at the top of our list.

  60. Great timing on this Brian. As of June 2018 we noticed a “speed update” in the algo and moved one site to WPEngine and that helped recover rankings since everything else was ok/better than competing sites (on page, off page SEO) ect.. this was the only thing we noticed the site can be better with (speed & TTFB)..

    Then when Algo hit again in June of this year noticed they turned up the Google PageSpeed insights notch once again and with mobile first indexing we even notice bad mobile score on pagespeed insights had worse rankings vs. good desktop score rankings were still ok so the scores even correlated to each index and scores. We have now taken it a step further besides WPengine because some sites have horrible themes that still won’t help. You will have to get rid of the theme as well. We are now following a process we tested and has been working by using WPengine, elementor pro, using an elementor template/elementor hello theme/wp default theme, autoptimize plugin, wp rocket lazy load and this has helped us get 60-70 mobile scores sometimes (90-100 depending how big the page is as you point out), and 90-100 scores on desktop. Hope this helps anyone using WordPress still.

    1. Hi TJ, great stuff! Thanks for sharing that. We did use WPEngine back in 2013, and didn’t have the best experience. Maybe it’s time to give them another look.

  61. This must have been so fun to design and run! Performance optimization is my bread and butter so this was a pleasure to read.

    I think this confirms a couple of really important things. Any self-managed CMS can be slow in the wrong hands if you do not know what you are doing. WordPress can be really fast if the right hosting, theme, plugins etc are chosen.

    Similarly, any CDN can slow things down if not configured properly. For example, Cloudflare and Amazon have some of the highest Points of Presence (close to 200) out of the CDNs analyzed whereas KeyCDN has among the lowest (currently 34). So this finding is really surprising and makes me think a plethora of users have some serious misconfigurations to work on!

    1. Hi Mike, thank you! I totally agree: a big chunk of whether or not a WordPress site loads quickly or not is on the user. I’ve seen WordPress sites load super slowly and somewhat quickly. But I do think, overall, WP isn’t super fast unless it’s optimized to the gills.

  62. This was a great article and has some really useful information. I hope in your projects going forward that you would consider putting Webflow into your research. I think its a great platform that has a lot to offer and is growing pretty rapidly.


    1. Hi Chris, we definitely need to include Webflow in our next analysis. I’ve heard great things about it and it would be great to get some data as well.

  63. Hi Brian,
    This study is amazing. I am mostly shocked to see that using a CDN can slow things down. I actually used a speed optimization service and they put me on Cloudflare, and now I find out it’s actually one of the worst on speeds. whomp whomp. Disappointing. Looks like I have a lot of work to do! I value speed and I try to achieve it in every way I can because I write travel guides and most of them are picture heavy. I agree with you that UX should take precedence over speed, so I’ll try to make up for it in other ways.
    Thanks for embarking on such epic research.

    1. Hi Ioana, thank you! The way I see it, speed is great. But no one visits a site because it’s fast. People visit sites like yours and mine because of the content (and in many cases, the visuals).

  64. Hi Brian,

    Keen to get your take on this – we use WP Engine for hosting and they’ve recently reached out to discuss getting using the new C2 Architecture:

    They’ve mentioned that this will make our site much faster – but for us to be eligible we would need to upgrade to a dedicated server (which presumably would be the thing the *actually* gives us the biggest shift in site speed. BUT – looking at the results from your study, I would say that our sites are actually fairly middle-of-the-pack so I’m wondering how much could really be gained from doubling our hosting costs.

    I’d also be keen to see how some of the pages included in the report are converting – we’ve been given a ton of vanity metrics about site speed and conversion rates, but if the majority of sites are performing at the same level, again, how much is *actually* gained from having a faster site!

    1. Hi Ben, my take would be to see if you could test it out with a staging version of your site. Then, see if the boost in performance is worth it. Or see if it’s easy to switch back if it’s not worthwhile. It’s one of those things that you have to test out to see how it works.

      1. While I’m a big fan of WordPress and been developing with my team all the sites on WP exclusively, I’m not surprised that you found it slow ‘on average’. Since anyone can throw up a WP site, but not anyone is aware of how to properly optimize it, it’s no wonder tons of slow sites appear. Pretty much every plugin you add, will load on every single page something, so we manually go and disable them so they load only where necessary. Time-consuming but powerful. While not always possible, we often manage to get many even visually heavy pages loading below 1s. Thanks for the research and article, Brian. Well done!

  65. Amazing data, well done, this is extremely impressive. Whilst I love wordpress I have always recognised that any CMS that stores its assets in a database that are retrieved dynamically through queries to render a page have that extra overhead. I worked on the UK Census project in 2009 and we knew performance would be a huge and so all pages were static as far as possible; data entered had to be stored in a DB but this did not affect page render speed.

    We all have so much to do now – stripping out redundant css and or making it inline, etc. I recently tried to find a decent web builder software that would build flat pages but options were limited.

    This makes reliance on WordPress hard now and also a harder sell to clients – as well as myself!

    1. Thank you, Paul. I appreciate that.

      I’m with you: I also live WordPress but it is slow. This isn’t the first analysis to find this to be the case. With enough optimization, WordPress sites can run quickly. But it’s tough due to the limitations that you pointed out.

      1. Hi, Brian, many thanks for replying 🙂 I shared the post around a number of groups on FB, getting some interesting responses. One guy mentioned the acabado theme which apparently is extremely fast on wordpress. I’ve been through a few web builders including Divi but now settled on Thrive Architect and Theme mainly because of the fantastic suite of sales oriented plugins and to keep all support issues under one roof. But I really should also find out about its speed. Thanks again for sharing this incredible info, I love this kind of detailed research but this s beyond my current resources.

  66. Nice read on a very important topic! I understood GZIP doesn’t work on any image formats except SVG files because they are text directions to draw shapes. GZIP only works by compressing repeated strings of text. JPG/PNG/GIF/WEBP are already compressed by their format’s nature which doesn’t include significant repeated bits (binary files). They aren’t further compressed by processes that contract/expand over the wire like GZIP because the CPU cost of doing this is higher than simply delivering the bigger uncompressed file. Therefore a site full of JPG’s could realize slower performance if GZIP is enabled.

    1. Hi Mirella, that’s interesting. I didn’t know that about GZIP. I thought it re-compressed those formats, which did help. But, the way you described it, it does make sense that it wouldn’t always result in a faster-loading website.

  67. I’m not sure that it makes sense to compare site speed of WordPress to Squarespace. Squarespace is an all in one platform that controls hosting. The speed of WordPress depends on the hosting that the website chooses with tons of options out there. I have a ton of sites ranking on page 1 for various keywords and I am outranking all of the other pages using WordPress. As you already know the hosting impacts the speed a lot and the hosting is what impacts TTFB. The theme is also a big impact. So when you compare speed for WordPress to Squarespace, it is misleading for those that don’t understand that they are two completely different set ups.

    1. Hi Brian, thanks for your comment. And I 100% see what you mean: in some ways, WordPress and Squarespace are different. Our main goal of this study wasn’t to analyze why one platform performed better than another. It was more to establish benchmarks about how different platforms load in the real world with a large sample size. As you said, there are lots of potential reasons that WordPress came out so low on the list: poor optimization, plugins, themes, hosting etc. But part of the reason may be that the CMS just isn’t very well optimized for speed out of the box. This would be a really interesting area for a followup.

  68. CDN performance heavily depends on whether the page is cached AT THE PARTICULAR DATACENTER NEAREST TO YOUR LOCATION.

    If no one form your neighborhood has visited the site lately, the page is not cached and the CDN goes to the origin server to load it.

    Ironically, this means that the more datacenters a CDN has – the slower TTFB can be.

    PS. Unless your site is super popular (think nytimes) and regularly opened form all locations.

  69. Fantastic information, thank you very much.

    I was wondering if you could clarify what you mean specifically by ‘Responsive Images?’ (Particularly in contrast to ‘Optimized Images.’)

    Do you mean using the “srcset” and “sizes” attributes of the or tags? Or simply using a single optimized image and scaling it using CSS?

    1. Hi Dave, you’re welcome. I’ll need to double check that with the team that did the analysis. But I believe it’s images that are scaled depending on the device, window size etc.

      1. Thanks. Checking with the team would be great. Looking for an answer to “scaled how?” as there are a couple different approaches available.

    1. Hi Omar, thank you It’s hard to say without seeing the specific site and what “huge amount of content” means. Even then, I’m not a developer so I’m probably not the best person to ask!

  70. Great post as always Brian, so really helpful information. Glad I’m with Squarespace now 🙂

    One thing, you have spelt my home country Australia wrong in the images. There’s an extra ‘i’ in there.


  71. Probably the most comprehensive article on page speed I’ve read to date. Massive gratitude for all your hard work. I’ve started migrating all WP sites as static files to Netlify and have seen massive improvement in speed, so I can personally validate some of your findings. I’m curious though, why did you choose to leave out the entire continent of Africa in your experiment?

    1. Hi Bruce, thank you! Good question there: it’s because we didn’t have sufficient data and/or that we had trouble identifying traffic from that region. It’s the same reason that we didn’t analyze data for Bluehost hosting: our tools weren’t able to reliably determine which sites were hosted with them.

  72. Always had my suspicion about most CDNs. Call me old school but always preferred well coded, fast, light websites. Great read and well presented as alway Dean. Well done.

  73. thanks for the data, but the data is just that, irrelevant, as you measured random sites, and random site dont do squat.

    if we would measure in a similar fashion my ability to perform a surgeries, i would suddenly become an expert.

    add to the mix, size is not all. no of scripts is not all.

    you got the data, if your up to the task, split it up further, and slice it to compare apples. (its gonna take a lot more time than you spent)

    i can already tell you that lot of your data is skewed by the fact that lot of sites reside on a overpriced and overcrowded environments, and this is very common. closed cms can offer ‘better’ performance but for a hefty price ($ and in usability).
    even on a single supplier you can have both(fast and slow), just because one resides on the older architecture and not been moved yet. Or one is over sold.

    and your major hosting providers are actually a ‘minor’ ones to avoid(mostly not all). they are the reason we got what we got. (and closed cms should be counted in a separate categories, they wastly differ).

    why not a bunch of other on a plate ?

    “As of January 2018, DigitalOcean was the third-largest hosting company in the world in terms of web-facing computers.[4][5]”

    and there are others.

    i could go on,

    all in all, lots of data, bad questions, bad answers.

    1. Hi Pawel, I can kind of see some of your points. But I obviously disagree with your assessment. Just because there may be confounding variables doesn’t mean that the data is invalid.

  74. Hi Brian,
    I have to say that you just made my day. 🙂 I’m a website designer that uses Weebly and I tend to have a major case of imposter syndrome for not using WordPress. But for me, Weebly is what I learned and it works perfectly for me and my clients. I’ve been able to get some good Google search rankings with the built-in SEO fields and I love their templates. This report helps me feel a bit more justified in my decision to use Weebly. I know it isn’t everyone’s cup of tea, but for the life coaches, therapists, and other solopreneurs that I tend to help, they love it. Thanks so much for this report!

  75. Hi Brian. Thanks for the article. I’m from Australia – just curious if you know of any thing my hosting partners can do to speed up the TTFB? And wondering why on average this is slower in Australia?

    1. Hi Gerson, you’re welcome. I’m honestly not sure why TTFB in Australia was slower. The best way to improve host performance is usually to get a dedicated server… or switch hosts to one that’s better and faster.

  76. Hallo all, For 15+ years I have used Irfanview for image compression. I just ran one of my images through Surprise surprise, it gave a 1.7% additional compression. Irfanview is totally free and I compress my images – it gives a choice – to 30%. That usually results in a 3 – 8 x size reduction, depending on the variebility in the image structure. Irfvanview is a desktop program and lightning fast and moreover: FREE. It also allows for features like size manipulation and color adjustments. I have tried many image software programs, but for website management with juge image content like mine, nothing beats the agility and foto management speed of Irvanview.

  77. This research report is pure gold. I’m surprised not all CDN works great. Thanks for the insights. I’m just puzzled why WPX hosting is not included in the hosting provider report comparison. Since most of us are in WordPress CMS, there’s really a lot of work to be done to optimize for the page speed.

    1. Hi Cheefoo, thank you! Re: hosting, we were limited by which hosts give that info in response headers. If they don’t provide that, it’s hard to determine who is hosting that site.

  78. Hey Brian,

    I pride myself in my analytical skills and experience in this subject matter. All sites I have work on HAS to load quickly. After 20 years of web dev and SEO experience, I concur with this article about CDN’s slowing things down and WebP not having a big effect on speed. The missing part of my quest to speed up page loads is responsive images. I have almost developed a solid workflow to scale up and include responsive images into my website builds. Glad to see that even before I saw your numbers, gut feel and experience has been steering me in the right direction! Thank you.

    Even though WordPress is ranked fairly low on your charts, I will use it to show my clients that the WordPress sites I help them launch keeps up and exceeds some of the top performers of your study. Love it!

    1. Hi Ian, great comment! And yes, you should show this to clients to show them that, unless the site is well optimized, WP is generally pretty slow.

  79. My website is relatively slow. I have tested the factors that slow it down. First of all, be aware that I use the much despised but highly under appreciated MS Frontpage, which I hacked for all its useless features, like borders and other things. Without the slowing features that I added, it is actually lightning fast. When comparing the coding, it is clear it is so much simpler that the modern online programs like WordPress, which explains its speed. So what are the factors that slow my pages down? 15 – 50 500-pixels-wide responsive thumbnails. I have tried 400 (30% smaller), but they just don’t look as nice. I first produce the automated thumbnailing of Frontpage, which I then reduce another 20% with Irvanview. I presume all programs could use a further compression after initial program reduction. Another slowing factor are the several iframes I use, but not too much. A significant slowing factor is the wowslider. I compressed the images, but that gave not more than a 10% size reduction. Another slowing factor is the floating social media menu. That is a choice. I find that having a floating menu insentisizes visitors to give likes, so for now I keep it on, even though it takes a full second to load. I tested the pages without any graphics, wowslider and menu, but with the several iframes and CSS; they load up in a second or so, while with aformentioned elements my pages take anywhere from 5 – 10 seconds to fully load.
    So, in the end, it is all about graphics and a bit java that slows the pages.
    Btw, I use Siteground and its incorporated CDN. All my pages are both rich in text and graphics (hence large), so I understand that CDN should help a bit, but from what I see here, it does not make much of a difference to get exited about one way or the other.
    I certainly liked this study, because it showed me that I have been doing things right and that Brian’s pages load up similarly to mine, while scoring high in Google. Tx, Brian for taking the trouble and sharing your findings with us all.
    Parks Man, Dr. Daan Vreugdenhil

    1. Hi Daan, I’m with you on that. We compress images here but not to the point where they look blurry or grainy. To me, it’s not worth the speed tradeoff.

  80. You can’t generalize such findings based on platforms. For example, WordPress pages can load very slowly with a bloated page builder, OR very, very FAST with the right page builder. WordPress gives many opportunities to optimize pages. Many of your other platforms don’t give access to optimization features.

    1. So what you’re saying is “other platforms don’t give access to optimization features”… yet they’re still faster than WordPress?

  81. That’s excellent, and something I have been grappling with the past couple of weeks. I ended up changing web hosts and that shaved 2s off my mobile TTFB. It also resulted in a number of other metrics speeding up (related to javascript). By the way, I am in Australia and changed to an Australian web host – but they were faster (use lightspeed), so the generalization doesn’t always hold true there. They’re just set up with server speed in mind. Other measures included using various plugins to address other speed factors. I use Joomla and virtuemart btw. I still have to sort out a plugin cache and set up the cdn, so there should still be improvements.

    1. Just to add on to what I posted above. I think its a bit unfair ranking the cms when things like optimization aren’t taken into account. As I said I use Joomla, but I found a number of great plugins like jchoptimise that help speed things up. So whilst it may not be great out of the box, it can be fixed. There are also cache plugins, which I have yet to install, but there is one for apache (jotcache), and one for lightspeed sites. Incidentally, the web hosting company I chose (whom I am in no way affiliated with is DreamIt Host. That has made a huge difference. So factors like site host and whether a site is optimized for speed (using other third party tools that are available) would have a significant impact on your CMS rankings.

  82. Siteground+Wordpress=Slow – My 30 plus websites on Siteground that load in the 1sec-2.5sec ttfb seriously begs to differ. Very unrealistic and unbelievable.

    1. Hi Scott, our data analyzed these platforms on a large scale. The data doesn’t say that it’s impossible to have a fast site on a particular host or CMS. Like you found, it’s doable.

  83. Hello Brian and thank you for this detailed article.

    I use the free Cloudflare CDN and I saw a real improvement in my speed and scores on Google pagespeed or GTmetrix when I enabled the Rocket loader option.

    This is an option that was in beta mode a short time ago and which I don’t think is used very much because it could break the website, but today it is no longer in beta mode and could well change the deal.

  84. Probably a late comment. But just thought it would be great to leave my 2cents…

    First I want to say the data is mind-blowing Brian.

    I was thinking about moving my site to site ground hosting but after seeing the data here I am a bit skeptical.

    I am also surprised by the section that shows that WordPress has one of the worst overall page speed. I would think otherwise knowing how much site is run WordPress these days

    Keep up the good work brain. Love the graphics in this article and the way they break down each statistics and make them much easy to understand.

    1. Hi Floyd, it’s never too late to leave a comment. I usually reply to all comments during the first 72 hours or so.

      Also, I’m glad you enjoyed the study!

  85. Wow, I am using WordPress with Cloudflare, I also have a few third-party scripts. I am tempted to see if my site runs quicker through my host directly. What about themes? Does that not affect loading time?

    1. Hi John, themes definitely affect loading time. We didn’t look at that specifically, but themes can make a big difference.

  86. Hi Dean
    World Domination!!! I’m in…..I love this article.
    I appreciate that you took a simple, how to article, by explaining step by step of the key findings.
    I was just actually talking with a business owner the other day and shared with him how page speed could have an astounding affect on his real estate website.
    In reality, it’s all baby steps as you go from failing to success and learning from more failures. You have to learn how to crawl before you can stand up, fall down then stand back up in order to learn to walk.
    Once again, I love your article.

  87. Yes, amazing insight.. Kinda bums me out..
    I use ASTRA theme with Origin Sitebuilder, WP Super Cache and Autoptimize.
    Everything with speed in mind..

    Would be cool if there was a self hosted version of Squarespace or Weebly!
    Or does anyone here has suggestions with self hosted CMS with ultra high speed?

    1. Hi Shelly, thank you. My take is that if your stack is working, it may be worth sticking with. It’s totally possible to have a fast WP site.

  88. Hi,
    What about bluehost, a2 hosting? Siteground, bluehost, a2 hosting are the most common hosting in asia.
    Can you give any insight on bluehost and a2 hosting?

  89. Very interesting! The counter-intuitive result about CDN is refreshing. A minor typo: the numbers in “Large pages (3.49 MB).” should be reversed.

    Personally, I’d say that large-scale studies are great at finding trends, but at the risk of introducing many confounders. What I do know is that we had had our scare with slow site speed, and did some intensive research to tune things up. In terms of the 80-20 rules, here’s a list of major things that one can do:

    1) Industry-grade hosting: Possibly the most important bottleneck to speed. Even good CDN won’t help if the server is slow in TTFB or otherwise lagging.

    2) Update PHP, MySQL/MariaDB, WP themes and plugins to the latest

    3) Choose a lighting-fast WP theme

    4) Minimize plugins and other 3rd-party scripts: this is a huge one where A/B testing can be helpful. Minimize trackback/pingback. Disable Gravatar. Limit Heartbeat API, Google Map, Facebook comment…. the list goes on.

    5) Optimize Image by filetype, size and dimension: In general, we’ve found flat design to be both more professional and more efficient on this regard. It allows one to use transparent PNG more often, resize the image to only the dimension that’s needed, and reduce the colors of a PNG to reach a minimal viability (it involves more work than automated tools like Kraken, but it’s substantially more effective as well).

    6) Enable Gzip compression (e.g., through .htaccess)

    7) Optimize WP databases

    8) Limit post revision (e.g., through wp-config.php)

    9) Effective CDN & Caching

    10) Move large downloadables offsite

    Yeah, just to say that we’ve tried a lot of things under the sun to just get the speed right (because our content typically runs from 4000-12000 words like this one). To be sure, it’s not necessary to get everything right, but everything else being equal, I’d say that the first 5 in the list probably has the most impact on an average WP site, and some of them actually don’t take a lot of time to carry out.

    1. Hi Thomas, “I’d say that large-scale studies are great at finding trends, but at the risk of introducing many confounders.”

      1000%. These large-scale studies are more to spot trends and areas for further research. It’s not to be prescriptive, because as you pointed out, there may be confounding variables at play.

  90. Very interesting starting point. I’ll be interested to dig into the methodology, and possibly sample some of the data. Things I think about are how urls were selected… how sites compared based on estimated traffic or Alexa rank… Overall site cost using something like Builtwith.

    No dispute, when you have something that is a well controlled environment like Squarespace or Weebly it’s not terribly surprising it can get more speed on average.

    Where people treat WordPress like it’s that and it’s the Wild West. And worsening when you look at premium themes development.

    With over 12yrs of working with it, I don’t find it hard to build a ridiculously fast WP site or to boost performance on most. For me the key is building with intent, rather than using another plugin to do something that requires 10 lines of code in functions.php. Then you hit 50 or 60, and your TTFB is 8-12s.

    I’d be curious to see an analysis on % of use of technology for the 5mil urls. Sample size could make a pretty significant difference.

  91. Nice study! For those on self-hosted WordPress, I recommend these two plugins in order to really boost your site speed:

    Autoptimize plugin aggregates all the files so you have fewer requests and it minifies them.

    Lazy Load By WP Rocket plugin helps you only load images and videos that are in the browser’s view (i.e. above the fold) without adding any JavaScript.

  92. Hi Brian – amazing study!
    As someone mentioned before, there seems to be an error in this phrase:
    “Large pages (3.49 MB).”

    Also, could you please explain the graph from the section “Third-Party Scripts Negatively Impact Load Times” – I’m not sure what the 0-10% 10-20% etc represent there.

    1. Hi Matei, thank you. We fixed that typo. That graph is the percentage of sites that rated “Fast, Average and Slow” and how many third party scripts they were using.

  93. Hi Brian,

    In your report it says WordPress isn’t a fast CMS. I think a lot has to do with the plugins / settings / hosting that webmasters are using. As it’s multi use CMS, it can’t be optimised for from the core for 1 specific audience.
    But it’s possible to make WordPress load fast.

    1. Hi Gregory, absolutely. It is possible to speed up WordPress sites. It’s just that, in the wild, WordPress sites don’t tend to load quickly.

  94. Great insights. I find many people also use GTMetrix and there the page speed could be A (95%) and the same website on Googles page speed could be 20/100. Not sure why the vast differences. Speed is a subjective thing. Like you said beauty over speed is a compromise as you cant have a lot of images and a site that loads 95%. It is difficult. I also find CDN did not help me much and I think you were spot on there.

    1. Hi Raaj, I think part of that difference is that they analyze pages in different ways. GTMetrix actually loads the page. I believe Google pagespeed insights only looks at the page’s code (and sometimes lighthouse scores).

  95. You said siteground are slowest and WordPress score only 25%. But really siteground is good for India and go Daddy very bad.

    What is the go Daddy score? From India.

    By the way, thanks for you PDF….

  96. Hi.brian
    Seriously, very impressive analysis.
    I have learned a lot of things from your blog.

    But in this article, if you add speed relationship with ranking factor its become more

    What do you think?

    Because every time you bring something that enhances SEO.

  97. Hey Brain,

    I was wondering about website speed increase, now I got great valuable information.

    Let me try this on all my existing clients.

    Cheers Brain looking for more.

  98. Hi Brian Great work! and extremely useful. But I have one question. Why do I still see non responsive, heavy sites rankings for high performing key phrases and no matter what I do I cannot get my site above them. I do not want to give out domain names on here but would gladly send you details directly of a particular issue I am having if possible. We are also using Shopify and I noticed from your comments that you have not had a chance to look at this platform yet. I would be interested to hear your views on it with regards to speed and response times.

    1. Hi Simon, thank you! In my experience, site speed isn’t a super important ranking signal. It can help a little, but as you’ve seen, slow speed isn’t going to tank your rankings. It’s still all about links.

      1. Taking time to setup static HTML page rules for WordPress if you are using a CDN like Cloudflare really can help improve site performance.

  99. So Brian What do you think the ideal time for Full load and Please Enable Email me Reply of My comments
    Right we came back again and search for comments

  100. Hi Brian,

    How do you define ‘responsive images’? Are they images with a resolution that works both for desktop and mobile (e.g. 1000px) and have responsive CSS (e.g. width: 100%) applied to them? Do I understand it well that ‘optimised images’ (e.g. a CDN offering 300px for mobile, 1000px for desktop) work *worse* than always offering 1000px but not spending time evaluating the user agent?

    Thanks in advance!

    1. Hi Attila, thank you! I believe it was defined as you stated: a single image that scales depending on the user agent, window size etc.

      That said, the CDN finding may or may not be related to images. We didn’t dig deep into why CDNs resulted in worse performance (besides the obvious fact that certain CDNs are better than others and that some CDNs aren’t setup correctly).

  101. Great study, Brian! I can imagine how much effort went to this.

    One thing I would make more clear (maybe next time) is what CDN is used for. Typically, it’s used for caching page assets (CSS, JS, images). Less frequently for caching HTML itself because it requires more advanced techniques for invalidating CDN cache so users get updated content.

    The earlier scenario (CDN for assets) theoretically shouldn’t improve TTFB much as the request still needs to go to the original server where HTML is generated (or served from cache). The latter, though, can improve TTFB significantly as HTML is already generated and stored on a CDN node close to the user.

    1. Hi Lubos, thank you! You’re right: this took a ton of effort from a lot of different people.

      Interesting. Maybe next time we will parse out the different loading stages and how CDNs impact (or don’t impact) it.

  102. Yes, Brian, once a Guru always a Guru. Thanks always for your robust posts.

    Many of us are hooked to WordPress. This your revelations about their low ranking in page speed will put them on their toes to do more work!

    Well done!

    1. Hi Alexander, you’re welcome. I’m definitely not anti-WordPress. We use it here at Backlinko and will continue to do so.

  103. This report really changed my opinion on how certain technologies and services perform. The ample charts provided a way to compare and contrast these offerings. Excellent work – thank you.

  104. Hey Brian,

    Thank you for sharing detailed information with us. As I am an SEO executive this information is useful for me. So keep sharing this type of content. Thank you

  105. Thanks Brian for the information, but as I analysed website hosted by our server(around 1000websites) , I found that website using WordPress is slower then bootstrap but some cases they are faster then WordPress.. so mainly it’s depends on – DNS lookup, optimisations, faster and light theme also fast CDN.
    I really tried a lot to beat speed with WordPress and successfully did it . Check and Please let me know the issues
    Thanks again

  106. Hi Brian,
    A really impressive article about page speed I have ever read. keep writing these type of articles and help people to get more knowledge. Thanks 😊

  107. It would be immensely useful to see a correlation between the statistics you gathered above and SEO performance after a certain page improved their page speed. Would it be hard for you to measure SEO KPIs for the 5 million pages you looked at now, then re-analyze the entire 5 million pages 6 months from now, and correlate their speed KPIs with their SEO KPIs?

  108. Hi Brian,
    Once again, every time i read your new post, learn something new and two question i need to ask you about how it would be impact when we using amp for mobile version only and the second thing about WebP images, giant social mediums like Facebook, Skype, Twitter don’t auto fetched this format images. so what your opinion about it.

    1. Hi Abdul, re: AMP. It speeds things up for sure. But there’s a tradeoff. To your second question, I don’t use WebP for that reason: it’s not supported everywhere yet.

  109. Hi Brian,

    interesting study. I’m new to the “gradient boosted decision tree” method. I can tell you from my own testing using, I can have swings. I remember Patrick Meehan suggesting people use the advanced option to test for 9 iterations.

    Where I differ from your results is lazy loading, WebP, and CloudFlare. I’ve found benefits with all these. And using the image analysis tool off of, which goes to Cloudinary, I have seen times where a better image format would work based on the image. (Note: tool doesn’t work with lazy loaded images.)

    Lastly, while I no longer use SiteGround, I did find them fast. I think part of it has to do with configurations. The same goes for CloudFlare.

    PS. On your PDF methodology page, the 2 column format is difficult to read. You have to scroll down one column and then back up to colulm 2.

    1. Hi Anne, thank you. I’ve noticed the same thing from GTMetrix and webpagetest. I think the variation is actually good because it represents how actual users load your website. There’s no single speed for everyone. And thanks for the heads up about the PDF. I’ll look into that.

  110. Hi brian,
    An eye opener for me. I work at Indian Express and we use akamai as a cdn provider. We are currently struggling with PLT. Can i share this with my seniors as a defacto blog on PLT benchmarking?

    1 more question.
    As a google ranking factor. What is more important
    A. Full PLT or,
    B. 1st Meaningful Paint

    Thank you so much for the article though. (\/)

    1. Thanks Shani. I’m not sure which ranking factor Google puts more weight on. They haven’t said that one is more important than another. Just that site speed as a whole is important.

  111. Hi Brian. One of your best articles. You are the only blogger I follow. It is really helpful for me. Thank you Brian. Keep sharing this kind of awesome posts.

  112. Oh, man – what a nerdy-good post. Thank you, Brian.

    As someone who *daily* peeks behind the curtains of numerous websites (almost always WordPress), the data here is mostly not shocking (although the CDN stuff was worse than I thought).

    While I’m reading I’m thinking some of the same things others have already commented on, especially how individual sites can do/use things that complicate the analysis. But I also think there’s value in the aggregate picture.

    Especially since *I* didn’t have to analyze 5M+ sites 😉

    It’s important to understand this: Page speed is *not* an all or nothing thing, whether we’re talking about how fast a given page/site is or the things you may be doing to influence that speed.

    It’s closer to an equation.

    The most frequently-argued point from above (after questioning the research methodology, anyway…LOL) involves anecdotal experience around one factor in the page speed equation.

    Let’s talk about this in context, using WordPress speed as an example.

    Brian is right that it’s less fast out of the box than some alternatives. It’s faster than others. But that’s almost completely irrelevant in the real world, where it’s only part of the picture.

    Ex 1: Jack has a very slow website. His equation looks like this:

    WordPress + low-budget shared host + inefficient/poorly-coded theme + page builder + unoptimized images + complex page design + fancy features (pop-ups, sharing tools, tracking scripts, etc.) + no caching

    Ex 2: Jill has a very fast website. Her equation looks like this:

    WordPress + quality hosting + well-coded theme + clean design + properly sized & optimized images + decent CDN (apparently not Cloudflare…LOL) & caching

    And then at the end of it all, what actually matters is how the site serves Jack, Jill and their users. If it’s working well for everyone – Backlinko is a great example here – page speed is less of a factor.

    Most of the sites we see in our business day to day are somewhere in the middle. We also do specialized work that tends to attract people like Jack.

    What we’ve found is that, with sites like Jack’s, poor user experience (stemming from both design and performance) limits how well the site serves its owner or audience.

    So while Jack hires us expecting us to simple fix things, he *also* gets an unexpected crash course in “the equation” 🙂

    1. Thanks Teresa! This is one of the best comments we’ve ever received (out of almost 30k!). You explained how site speed works better than I ever could.

  113. it was helpful to know about the types of images and which ones work well. my site is working quickly, but due to the fact that it has very few scripts, etc., and I think a regular site is different from an online store .. and speed and functionality, SDN is better to use for very large volumes of articles or products, well and try to improve everything in the speed of the site. And yes, you need to look for a good hosting service as it is the main part.

  114. Thanks a ton for this Brian. I’ve been following you for a good year or two now and have always found your articles to be incredibly detailed but moreso, particularly easy to read and absorb. You’re really one of my benchmarks when it comes to writing quality content – thanks for doing it.

  115. While it’s super interesting to see some of these aggregate stats, it has a severe lack of context which appears to have lead to poor quality conclusions. This could mean readers take-away these conclusions, without the right context, and could cause readers to make decisions that are not beneficial, or at least not correctly informed.

    Take the CDN section for example, my concern is that because you’re running a survey, you’re not accounting for the webmasters motiviation (and other factors) to choose one CDN over another, I’d wager that it’s there are demographic, marketing budget, business type, developer resource and other large differences that will influence which CDN a given webmaster would select.

    Who’s likely to use Cloudflare?
    – Websites that are running extremely slowly, so the owners Googled it and activated a CDN, Cloudflare kept coming up as a suggestion
    – They don’t have ANY budget to do any major speed optimisations
    – Cloudflare is free, so they select it

    Who is likely to use Fastly?
    – A paid CDN that tends to attract website owners with larger budgets
    – Websites likely have a dedicated dev/team who are much more familiar with the range of CDN offerings and deliberately select Fastly because they’ve heard good things
    – Websites are likely to already be optimized for speed, owing to greater budget, likely greater dev resource etc.

    ^ now you can see how this type of website-owner behavior could easily add up to aggregate stats that don’t tell the full story. You end up measuring the kind of “typical” website on Cloudflare, not the actual speed improvement possible. The two CDNs could be technically the same, but the differences in aggregate could be completely attributable to the choices webmasters make outside of the CDN.

    To put it plainly:
    website-owners choose Cloudflare because it’s cheap and easy to do. Websites remain slow despite Cloudflare, because they were slow websites to start with. Whereas on Fastly the kind of webmasters are likely to be a LOT more concerned with pagespeed, and they know a CDN is just one part of that, and put a LOT more effort in.

    To measure this properly would take an *experiment* and will be a lot more time-consuming and expensive to do.

    Here’s a rough experimental methodology:
    1) Take 1000 websites with no CDN, measure their page-speeds accross a selection of page-types (home, content-page, article, product, category, search result etc)
    2) Take 5 well known CDN providers
    3) Group the sites into 5x buckets 200 sites each, ensuring a similar *normal distribution* of existing page speeds end up in the buckets
    4) Assign a CDN to each bucket of websites and get change all the sites in that bucket to the assigned CDN, use all default settings
    5) Re-test the page-speeds
    6) Then compare the CDNs in terms of page-speed improvement

    1. Hi Kieran, thanks for sharing your feedback.

      I agree that, like any large-scale analysis that’s not experimental, there are likely confounding variables here. But I would question the fact that you’re countering data with lots of assumptions about who uses different technologies. If you have evidence that Cloudflare and Fastly are used by the demographics you’ve described, I’d like to read it.

      1. Yep example assumptions were to make a point. Don’t have the data but that’s exactly it, we can’t assume there’s no underlying demographic difference either, and aggregate stats don’t account for any of this.

      2. Based on some of the reactions I’ve seen in the comments here, there are a number of readers taking away very clear conclusions, about how they should change their website. IMO this observational study which you’ve undertaken doesn’t do enough to be transparent in highlighting these potential confounding variables in the data.

        There should be a big disclaimer somewhere like:

        “the results of observational studies are, by their nature, open to dispute. They run the risk of containing confounding biases. Example: A cohort study might find that people who meditated regularly were less prone to heart disease than those who didn’t. But the link may be explained by the fact that people who meditate also exercise more and follow healthier diets. In other words, although a cohort is defined by one common characteristic or exposure, they may also share other characteristics that affect the outcome.”


    2. Have to agree with this. And the meditation analogy is a good one.

      By now we are all used to reading health/nutrition/psychology/etc. studies that are contradicted almost immediately by another study.

      How many times have we been told that X food is bad for us, and then been told that X food is actually not so bad for us, and then been told that X food is actually good for us, and then been told that X food is actually really good for us, and then been told that, actually, X food is bad for us again?

      This is not to diminish any of the work Brian has done here, and I don’t think Kieran’s point.

      The MOST IMPORTANT point Kieran’s is making here is that you have to take this, like all studies, with a grain of salt (which is actually good for you … I mean bad for you … I mean maybe not so bad for you … I mean not as bad for you as we first thought … I mean …).

    3. Instead… Take the SAME, exact website. Then run it under everyone of the platforms/options, to see how it performs with each different environment. That provides much more valuable data to consider, as you can then see the real, direct impact. After all, 5 million desktop / mobile pages are each different, and many will have vastly different page elements (which leads to correlations that are more assumptive, then accurate fact based). I found the read of interest, but the results a rather skewed, list of assumptions.

  116. Yeah Images play a great role in website performance. Lazy images are worst for user experience. As usual great post by brian.
    Thank u for potting value in the SEO world.

  117. I’m curious about images performance. Google recommend WebP and you showed us that it isn’t good enough. But is it a good solution to connect WebP format with responsive web design and then the result will be even better?

    1. Hi Alan, I do think WebP has potential. The big issue right now is that it’s not supported by all browsers, apps etc. Plus, there aren’t many “best practices” in terms of optimizing them. I do think WebP with responsive design could work but I haven’t personally tested it.

  118. Hi Brian,
    Great findings, especially in the area of CDN. I noticed it a longtime ago when I was using cloudflare. I noticed that using cloudflare slowed down my website. I decided to do away with cloudflare CDN.
    Since then, my page loads a bit faster, though not as fast as it should because of the weight of the pages as you pointed out in your research.
    Also, I believe what @Teresa Rosche Ott said. That is the fact about page speed which I’ve read of in the past.
    I’m happy with your findings. It will help us know which areas we should improve on, though, in some cases, our hands are tied.
    Thank you for this great findings. KEEP IT UP!

    1. Hi Kelechi, that’s interesting. A few people have reached out to me saying the same thing: that CDNs slowed things down. Definitely consistent with what we found in this study.

  119. So one might be better off WITHOUT Sucuri than with them?
    Wow, I was shocked to read that.
    I’d like to hear others who have experience with Sucuri.

  120. I have never seen such an immense and action packed post on Page Speed Statistics and Metrics Brian. You are the best at what you do. Believe me am 100% email opener of your posts.

  121. Hi Brian,
    Thanks for an useful insight. I read every single word! I am curious to know how long it takes to produce an article like this? Really impressive content!

    However, I’m really not impressed with WordPress. WordPress having one of the worst overall speed performance. Ouch! On the other hand, WordPress really has a user-friendly system and some other great features that I appreciate.

    1. Hi Nanna, it takes probably 100+ hours when you count the data collection, analysis, write up, editing, visuals and charts. It’s a big project!

  122. This article is very helpful. As always you have put together a data-driven with facts. Thank you.
    I have one question:
    I have a food blog with lots of images (that are helpful), but because (like you) I want quality images rather than grainy ones so I uploaded images that were high quality and heavy. As a result, my page speed is quite bad. I did use an image optimizer (, but it wasn’t enough to make images small enough (under 100K). After reading this and the comments, I now know I can upload images in lower KB without loosing too much of a quality. So I want to go back and start changing the images with smaller sizes in my old posts.
    My question to you is:
    If I were to upload the same image with the same exact title, file name, alt description, but in smaller file sizes, would it affect my rankings? If not, what should I pay attention to?
    I am terrified of making changes that might hurt my site, but I also know that page speed is just so important.
    I would so appreciate your input. Thank you!

    1. Hi Aysegul, I’m glad you found it helpful.

      The thing is, Google’s algorithm can be weird. Making ANY change to your site can potentially impact your rankings. That said, I’d be shocked if changing images with the same metatdata affected your rankings. In fact, we recently re-compressed all of our images with a new program and it had no SEO impact at all. Hope that helps!

  123. I did a page speed check while using Cloudflare, then changed my nameservers to my hosting company, to see if it improved my site speed. Nearly all my scores improved. I wasn’t expecting that! Thank you for the heads up, Brian.

  124. I’ve been thinking about this and I think the result may be skewed against Siteground and in favor of providers like Kinsta.
    Kinsta’s plan start at 30/month on what sounded to me like virtual machines. Most Siteground customers are on the cheapest shared plan at less than 1/3 of Kinsta’s price.
    Those customers might have skewed the results.

  125. Not surprised to hear everyone talking about Siteground. I myself was surprised at that part. I’m using a clean WP installation, a custom theme with essential bootstrap framework, minimal plugins, and hummingbird to optimize things. Website is loading super fast and high pagespeed scores.

    I also use AMP for mobile, I wonder what you mean when you say there’s a tradeoff. Did you mean by comprimising the design?

    1. Hi Hemal, our data didn’t find that Siteground was inherently slow. It was just that, on a large scale, sites on that host tend to run slower than others.

      In terms of AMP, I go more into that here:

  126. Extremely helpful article. I reread it word by word and found most interesting the statistics that each third-party script slows down page loading speed so much. People rarely realize how much unnecessary scripts their WordPress websites are loading. And 34.1 milliseconds for each one is crazy! I’ve always struggled with scripts and image optimization for mobile as it has always impacted my speed score across so many projects.
    Thank you again for this article and please keep up doing and sharing your helpful findings!

  127. Hi Brian,

    Thanks for this awesome research!

    No surprise that the feature-rich CMS like WordPress are underperforming. But hey; what about CloudFlare?? I really thought this speeded up my website…? Do you think I would be better of without it? Or use one of the paid CDN’s?



    1. You’re welcome, Thomas. It can speed up websites when configured correctly. But it’s something worth testing (without and without a CDN, using different CDNs etc.)

  128. Hi Brian,

    You have tremendously explained the comparison among all the top hosting providers. But I want to add one more to your list , if you can.
    Earlier, I was using an unmanaged hosting (don’t want to mention the name here). But, recently I switched my WordPress website to Cloudways server and experiencing a great response with light on pocket pricing plans and free SSL certificate.

  129. Hi Brian.
    We use WordPress for the site with a Crisp chat system. The problem is that we can’t use CDN and AMP because of the limitations. Over the past few months we have been missing some words! Do you think this could be due to the slow down of the site?

  130. Hi Brian, thank you for your research. It made me clearer.

    I’m working with local small businesses and many of them designed their website with Wix. I always had a hard time to improve Wix SEO. When I checked their source code, I was shocked because the page title tags appear in the 5,000th line of the code.


    They use the first thousands of lines of code to define font styles. As they try to satisfy everyone, they’re sacrificing real important functions.

    Now I can show them this article when they ask me why their sites don’t rank high.

  131. Hi Brian,

    You have really done a pretty deep test. Can you do hosting wise speed test as well? That would be good for all of us. It might be controversial altought 😛

  132. I wish I can switch from WordPress to Squarespace or Weebly someday. WP is becoming worst day by day. Even they don’t hear anything on Twitter or they never reply Emails.

    Hope, Squarespace will take some attempt to create more plugins and widely available for the users so that we can give it a try!

    Did you try with Bluehost or Hostgator or Namecheap host? Any data about them?

  133. What I don’t understand about this survey is why analyze so many sites?

    Isn’t this like trying to find the car that gets the best mileage per gallon by analyzing 5 million random cars that happen to pass through 2 points?

    Some might have been passing through during rush hour, getting really bad MPG; some might have been passing through in the middle of the night while drafting behind a truck.

    Wouldn’t a true speed test be creating 10 example sites of various types and sizes, and then recreating the exact same site, exact same functionality, colors, images, etc. everything, and then testing those 10 sites on each CMS?

    1. Hi Brad, that’s a different methodology type of methodology (experimental). This was an observational study. Both have their pros and cons. The main pro of this approach is that you analyze real sites in “the wild” as opposed to controlled conditions which may or may not represent reality. Hope that makes sense.

  134. Great article man!

    I saw a similar (but less thorough) article recently that focused on small business websites and found similar stuff (wix was really bad, along w/ most of the other large website builders).

    they included Google local sites in theirs as well which was interesting.

    Last, not to brag (haha, but kinda) we were included in that one since they said our sites (about 120 of our sites were found in their research) and found our websites performed better than all other website builders in their study except for Google’s own websites.

    Here’s a link to their research project:

    We’ve heavily focused on building an amazing tech stack and one that ranks well in Google in our niches (real estate) and was cool to see how we stack up against others!

    Lets collab on a content piece Brian!!! (taking this waaaaayyy back, but I had you on my “podcast” prob 6 or 7 years ago before Carrot was started and when you were just getting your momentum online. CRAZY proud to see what you’ve done since then!!!)

    – Trevor

    1. Hey Trevor, good to hear from you man! I totally remember going on your podcast back in the day. You’re crushing it!

      And I’m glad to hear that you enjoyed the post. I actually did read the freshchalk research. It was done in a different way, so it actually contained a lot of cool data that our study didn’t have.

  135. Hey Brian!
    Awesome blog. I want to ask one question. When I check my website speed on google page speed insights, it gives me a rank of 79, which is pretty good. But when I open my website, it loads very slow. Can you please tell me what can be the reason for this?

    1. Hi Yash, Thank you! It’s because google page speed insight focuses on your page’s code (it doesn’t actually load your page).

  136. As you said that you would choose a beautiful page over a fast page. But, what if we have a new website and we are just starting, and no one knows us. And, right now, I am using WordPress for blogs. Should I change it to Squarespace or Weebly?

  137. If it comes to WordPress it also depends on how you optimize your website. Using as less plugins as you can, updating plugins and WordPress itself. Anyway, great article. I’m impressed of the work and effort you have put into it.

  138. Hey Brian!

    Thanks for putting out a stellar report!
    Our hunch about CDNs affecting web page loading performance adversely in certain deployments is true after all! I am so thrilled about your finding on that.

    The report is filled with tons of gold nuggets that we need to keep coming back to.
    Have recommended this report to a number of people.
    Thank you once again for putting out work of such great value.


  139. Great Article! You analyzed millions of WordPress websites. I think millions of them are both old and are using premium themes, which are not good for the speed.

    When we are testing our own custom build WordPress themes with all the tools, we pass along a lot of speed tests.

    Do you think it’s fair to judge a CMS by all the old sites that are still around?

  140. Nice article Brian,
    BTW don’t you think most of the sites you’ve analyzed were old? and because of that they might have a heavy database and files and that thing is downgrading their page speed?
    What do you say?

  141. Great article Brian,

    In addition I can only say that great page speed improvement is when we decide to keep all our fonts localy (offline) instead downloading them each time from external servers during browsing the site.
    I’ve done it with my site and I’ve gained huge speed improvement.

    What do you think about this Brian?

  142. Thanks for this post, Brian. It doesn’t surprise me, especially when I see websites 3 X slower than ours, with many other technical issues beating us in the SERPs for our targeted keywords!

    As lovely as Weebly looks here on your post, compared to WP, I wouldn’t be able to invest my time into something unless I can zip it up, put it on a USB stick, & own my website in my side pocket.

  143. Thanks a lot Brian for this great content..It surprised me that Word press and Wix came in the bottom of the table but still used by so many people for SEO based websites..Most of them i never heard about..But is CDN and other webhost is easy like WordPress and Wix? I never tried CDN before ..I found its secure ..

  144. As usual…awesome content. One thing you should maybe consider with the next iteration of this post is JAMstck web dev architecture. You briefly mentioned Gatsby but as a JS framework. Not sure if you know it but it can also be used as a static site generator ie tool that produces static HTML pages as an end product.
    This ability, together with headless CMS and CDN, gives a powerful combination in terms of speed and performance (check this:
    I am talking about web dev architecture that can be used in many different ways (say WP can be your CMS while Gatsby makes the pages) and is built for speed and security, relying on frontend tools.
    The scene is evolving right now with lot of interesting solutions (instead of Gatsby you can use Hugo or Jekyll etc.) It would be nice to see it compared to the other solutions next time.

  145. “Key Takeaway: Using a CDN and minimizing HTML requests may speed up TTFB on both desktop and mobile.”

    What does it mean, Brian?

    HTML requests goings after TTFB…

  146. Your chart above shows TTFB to be within the backend. Then how is it possible that mobile and desktop is different. It is the same server serving desktop or mobile isn’t it?

    Am I missing something here?

  147. Impressive, comprehensive analysis. As others have noted, however, it’s misleading because if WordPress is set up properly, it’s actually much faster that other CMSs, even with shared hosting. I have a few WordPress sites on Hostgator (yes, Hostgator) that garner very high Pagespeed scores, due to good theme choice, caching, and image optimization, among other things.

  148. Brain, thanks for this spot-on analysis – I’ve noticed you have found some great data with regards to CMS used. Have you found any comparisons between different scripting languages? Members of our team have been keen for us to update our websites to Node as opposed to PHP, due to levels of performance and it would be handy to find something to back this up.

  149. This is really good data and an impressive analysis. I’m excited to have page speed data directly in GSC now with the most recent update from Google. With them adding in that data to search console, I think it just goes to show how critical Google thinks page speed is.

  150. I find one of the best ways to get a high score is to use a ‘bare bones’ WordPress theme (that is, if you are using WordPress!) which contains the bare minimum of code and scripts etc. Keeping your theme light is step one. Step two can often be taken care of with a plugin called Fast Velocity Minify, which, after testing practically all similar plugins, I think is the best as it never messes up any pages or the design / layout etc.

  151. Hi Brian,

    This was quite a thorough analysis of page speeds. I am definitely going to check out different web hosts (particularly GitHub Pages and Seravo) and JS frameworks (Gatsby and Right JS).

    I never knew so much went into affecting the overall page speed.
    I am from India and it is true that load times are few and far between when it comes to the same website on desktops and mobile.

    Thank you again for the awesome analysis. I’ll let you know how my experiments go. Cheers!

  152. Hi Brian,

    Great article. For hosting where would HostGator rank for speed? And would you be better off with a professionally coded website, say done in phython, than using a CMS like WordPress? Thanks!

  153. Definitely page speed plays an important role in search engine rankings specially at Google. As we know Google enables mobile-first indexing and it is very important now that we’ve to speed-up mobile version of a website. As far as I know the number of http requests on a page is responsible for web page speed and the only solution I’ve found that we’ve to combine scripts so we can reduce number of requests and most importantly images also should be optimized, that’s how we can do.

  154. Great research!
    It would be also interesting to know the key metrics (TTFB, StartRender, Speed Index, etc) for the fastest websites, not the average ones. In other words, what is the top standard for high-performance websites?
    I understand that the lower the better, but having these metrics for the real websites would be helpful.

  155. Wow, this is great content, congrats on the scale of the research! Curious to see WIX at the lower end of the scale but not that surprised to see WP xD With all this info, I would be curios to see a newer version of this article, “”, see what changed in the last 4 years. Keep up the good work!

  156. Hey Brian, if you don’t mind, can I use the images for a project? I will be giving you the credit for sure. Hope that is not an issue!

    Thanks a lot for such a great analysis

  157. This study has way too many unfounded interpretations and conclusions and compares things which shouldn’t be compared.
    Next time just present the really interesting data in a more neutral way!

    1. Tobias, my thoughts exactly. Backlinko does some of the best blog posts on the Internet – for getting views. But the actual data is meaningless in lots of situations.

      It’s all averaged out and has no relevance to anyone improving their own site.

      Lots of newbies will be blown over by this blog post, whereas people like yourself with a keener eye will see it for what it is. It’s to get lots of views rather than offer helpful insight.

      Saying that as a Backlinko fan, not a hater.

  158. I respect your work but I don’t see any value in our JavaScript section, sorry. You’re comparing apples with bananas which means e.g. JavaScript libraries with frameworks and design systems. These are totally different things. Especially the recommendations you give are highly misleading, in my opinion you should remove them. What is even Wink and RightJS? While working longer than 10 years as a JavaScript developer I have never heard of them. After searching I found out RightJS is an outdated and unmaintained framework (last commit on GitHub was 8 years ago, see, so it’s probably not a good recommendation to use it. And I couldn’t find a JavaScript library/framework called Wink!? Do you have a link?

  159. Cool post, Brian. Thanks!

    I think people shouldn’t jump to swap CMSs so quick, though. You can bog any system down or run it properly.

    WordPress is used by many people – which will ensure there are a lot of badly run sites that don’t help its average.

  160. Hi Brian,
    Great survey! Pagespeed is an interesting topic these days, as it is seen as one of the most important ranking factors.

    I recently did an on-page study between two affiliate systems, to see whether there was any page-speed difference in implementing the two different iframes on my page.

    It was a simple WordPress website. Clean theme. No large images, just size-optimized images and content.

    I tested via Google PageSpeed Insights:
    The first affiliate table gave me a score on 50 on mobile.
    Then I switched the table to the different affiliate supplier. Same partners, same table.
    At the second test, I got a score of 90. Just by changing the iframe.

    Also remember, Google’s John Mueller recently said that Googles own products (Adsense, etc) can slow your website down as well.

    Just sharing my thoughts! Thanks for a great article

  161. I think this article should be updated, I love the information but I suggest to make some tests for CDN on low end level, like BunnyCDN or any cheap CDN provider. 🙂 Thank you anyway.

Leave a Comment

Your email address will not be published. Required fields are marked *