The Web in Numbers

What 1,800 Real World Tests Reveal About How Sites Actually Perform

This is what we found

The performance number looks encouraging until you read it alongside security. A score of 60 for security means a significant portion of the web is still running without basic hardening in place, and I do mean basic hardening, this test is not about hard ore penetration testing its about easy implement standards, for instance HSTS adoption sits at just 30%, meaning seven out of ten sites are not enforcing secure connections at the HTTP layer. That is not a new problem of course, but it remains a persistent one. I reiterate by no means are we doing a deep dive on site security here, this is just a surface test. 

The SEO average of 53 is arguably the most telling figure in the dataset, these are not low level checks either, these tests have to do with the basic structure and content, the general mechanics of the sites. Our scoring sits almost exactly at the midpoint, which suggests not widespread neglect, but widespread mediocrity. Most sites have done some of the basics and stopped there, we suspect as most sites checked are built on WordPress, the bulk of the is that WordPress does by default and then maybe an SEO plugin was installed some basic setup was put in place to tick off the SEO check box. I have to tell you that some large sites have fairly poor SEO scores too which came as a bit of a surprise but that said, if your site has a few million high ranking backlinks, and your brand is well known locally or globally, then the small things that some site owners sweat over and, web agencies loose sleep over are probably less of a concern to you. Most of us are not there. 

Cloudflare leads by domain count, but the maybe the more interesting story is that there is a risk here, not just Cloudflare, I mean Content Distribution Networks and massive global cloud service networks in general, The issue here is that it seems at least to me by relying on international, mainly North American companies we all give away or trade some of our digital sovereignly. In many, many situations it’s not an issue but something that maybe should be considered at least before deciding on where to host, how host, who protects your and what controls you have.  

The presence of Xneelo in the top ten is worth noting for anyone focused on the South African market specifically. It reflects the geographic distribution of the dataset, which skews toward ZA and US domains. Of course there are many other South African Hosting providers but because so many sites are behind services like Cloudflare it’s hard to see who they are, so things become somewhat opaque. Not discounting my comment about digital sovereignly in the paragraph above lets be honest that having that extra security and performance layer from a CDN is good for the web, better security and an improvement in performance. 

Nearly a third of domains now support dual stack, which represents real progress from where the industry was five years ago. But pure IPv6 deployments remain well essentially nonexistent in this dataset, not that it was a surprise. Honestly as things are going I am not convinced we will ever really be IPv6 Only, at least not any time soon.  The transition is happening slowly and it seems almost entirely through CDN  intermediaries rather than origin infrastructure changes. Even though the Cloud hosting giants include IPv6 its up to the webmaster, or server admin to do sorting with it. There still seems to be a level of IPv6 “Terror” amongst end customers and small businesses, not to mention a number of Managed IT providers, it’s just not standard yet and when offered to businesses and end users they often do not want IPv6, or do not use it. We assume that this will change over time possibly for no other reason than IPv4 exhaustion, but IPv6 is a slow moving train. Talking about “train”s This is something that needs to be pushed more, NICs do push training, Afrinic often has workshops to help train ISP and network entities, but it seems the bridge from ISP to Enduser needs to be built. 

Ultimately for networks and hosting providers, the dual stack figure is the one to watch. It is a reasonable proxy for how modern a site’s infrastructure actually is. Really the same goes for ISPs as a whole. I would at least question a providers motivation for not offering IPv6 on a home broadband service be it fibre to the home, or a fixed wireless service, and the same goes for your Hosting provider, Shared site, or VPS for that matter.

The weighting toward Cape Town as mentioned before reflects the geographic focus of the dataset at this stage, that and as Cape Town is the default region location it was just the fastest when testing. The split between mobile LTE and broadband is intentional, testing only on fast connections produces numbers that do not reflect how most users in emerging markets are actually loading sites. Also our LTE and 5G testing consists of Desktop and Mobile testing as there are a large number of site visitors who may be too remote for fibre or fixed wireless broadband or just in a coverage gap, again not uncommon in emerging markets. 

Tested domains resolve to 30 countries, with South Africa (600+ tests) and the United States (450+ tests) making up the majority. Of course many of these tests even in South Africa show US as the country because the sites are either on hosting services like AWS, or are behind a CDN. Of course there are also .co.za or .co.uk and other TLDs that are not hosted in their own countries, this again could be for reasons like the choice to use Shopify rather than a locally hosted WooCommerce site, in other cases its just on a server outside if its domain space country.  

The compression numbers are a little counterintuitive at first. Brotli adoption (25%) exceeding GZIP (14%) is potentially unusual, historically GZIP has been near-universal. The most likely explanation is CDN-level compression handling, where Cloudflare and similar providers are serving Brotli by default while stripping or not forwarding explicit GZIP headers in ways the test can detect. So its quite possible that GZIP is still nearly ubiquitous, but its replaced by the CDN edge. 

Around 36% of domains return Cache-Control directives that let browsers and shared intermediaries reuse the document on a repeat visit; the rest either omit the header or set it to disable caching. I need to note that  this measures, or did measure one layer initially the HTTP caching directives on the main document, not whether a site caches at all. Many sites without strong directives do sit behind a CDN edge or serve pre-rendered, origin-cached pages, and this metric is not accounting for that. This gap is real and cheap to close: setting sensible Cache-Control on cacheable responses is one of the lowest-effort wins available for repeat-visit and intermediary performance, and a majority of sites haven’t taken it. Of course the tools that helped create these datasets were and are still being improved and adapted so over time this is going to show different and changing results, as more sites are tested an we nail down the full logic and methodology. 

Let’s Encrypt and Google Trust Services together account for 60% of certificates. Paid certificate authorities now represent a minority of deployments. For smaller sites and development teams, the cost barrier to HTTPS has effectively been removed. This is not surprising either as many of the sites are behind Cloudflare or other CDNs and most if not all hosting providers have been SSL Default On with Let’s Encrypt.

This also clearly tells us that the market for paid SSL certificates is smaller than what was expected to be when SSL started becoming the expected standard. Let’s face it, for the vast majority of sites being visited Let’s Encrypt is sufficient, maybe more than sufficient. For online stores, banks and other possibly high value content I think most people would still prefer a paid ‘professional’ certificate. It would be interesting to hear more about this from the security community. 

TLS version adoption is similarly mature: 89% of sites are running TLSv1.3, with 8% still on TLSv1.2. TLSv1.0 and TLSv1.1 do not appear in meaningful numbers. Again much of this helped but the CDN edge and its security settings. 

The gap is HSTS. Despite near-universal SSL, only 30% of domains send an HSTS header. Adding it is trivial,  a single line in the server config, or a checkbox in the CDN panel. However it takes a deliberate decision and action, because HSTS doesn’t arrive with the certificate. It’s an enforcement layer on top of TLS, not part of it, essentially you’re telling browsers to refuse any plain-HTTP connection to the domain, which only makes sense once HTTPS is already working. For most sites without it, a valid certificate isn’t enough on its own, nothing instructs the browser to insist on HTTPS, so a network attacker can still strip the connection back to plain HTTP on that first request. The encryption is available; its use just isn’t guaranteed. This probably isn’t critical on a personal blog, but your business site may well be more of a deliberate target. Beyond HSTS, the other security headers we check are Content-Security-Policy (CSP), X-Frame-Options (clickjacking protection), and X-XSS-Protection.

Cloudflare appearing as a server type reflects how many sites now sit behind its proxy, there is o doubt that Cloudflare  has become practically omnipresent on the internet. But this can and does mask the underlying origin server, and not just for Cloudflare customers. The 15% unknown figure is consistent with this fingerprinting server technology has become harder as CDN adoption increases.

Apache’s decline to 4% is notable for anyone who has been in the industry for more than a decade. It was the dominant server for most of the web’s commercial history. There really was a time were Apache was the king of the hill, now is it over the hill? 

WordPress continues to run a third of the detectable CMS installations in the dataset. Magento at 9% is higher than most industry-wide surveys suggest, which likely reflects the ecommerce skew in the domains being tested. Of course there are millions of WooCommerce site out there so don’t read too much into the 0%, this is really more about what was tested not what is out there.

HTTP/3 adoption at 42% is the number that stands out here. Industry-wide estimates for HTTP/3 tend to sit in the 20-30% range. The higher figure in this dataset is almost certainly a Cloudflare and CDN effect, Cloudflare and others enable HTTP/3 by default for domains on their network, and Cloudflare accounts for a significant share of the datasets as you already know by getting this far.

HTTP/1.1 at 6% represents sites that have not yet migrated even to HTTP/2, which has been available and widely supported since 2015.

The static HTML figure of 70% is high and guaranteed to be skewed if not misleading, but not surprising given the rise of static site generators, edge-deployed frontends, and CDN-cached responses that present as static to the testing infrastructure. The Ruby figure at 9% likely reflects a concentration of Shopify hosted domains, since Shopify’s infrastructure is Ruby based.

All performance metrics below are from real test runs across the throttling profiles described above. Desktop and mobile figures are reported separately.

TFB averages are high. Google’s own guidance suggests TTFB should be under 800ms for a “needs improvement” classification, and under 200ms for “good.” The dataset average of 523ms on desktop sits in the middle band. Nearly a third of sites in the slowest percentile are exceeding 1 second before the browser has received the first byte of HTML. 

Mobile performance is better than desktop in this dataset. This is a little skewed at fist glance but explainable. The mobile tests include LTE throttling which penalises raw transfer time, but the sites being tested tend to have better mobile optimisation than desktop, responsive images, lighter CSS, deferred scripts and the much of the other best practice expectation. The desktop numbers reflect what happens when those optimisations are absent. Once again this probably isn’t a surprise there has been a big push over the years for Mobile First, and even with the enhancements of high speed mobile internet and incredibly powerful mobile devices, often the desktop is neglected simply because desktop raw power and bandwidth makes it less of a factor. 

CLS is largely not a problem, at least not in these test results. The average CLS score of 0.059 on desktop and 0.030 on mobile is within Google’s “good” threshold of 0.1. Layout shift has clearly become a known issue that development teams are actively managing.

LCP is where most sites fail. The average LCP of 1.95s on desktop and 1.62s on mobile sits below Google’s 2.5s “good” threshold, but the slowest 10% at 3.77s is well into “poor” territory. LCP is the metric most directly tied to what users perceive as page speed, and the spread between best and slowest is the widest of any metric in the dataset.

This dataset is a snapshot, not a census. The domains tested reflect the composition of Enterramon’s testing base at this point in time, which skews toward certain geographies and industries, not to mention code updated and changes on the test tools. The figures should be read as indicative of patterns rather than precise industry wide statistics.

What the data does offer is a comparison point. If your site’s TTFB is consistently over 800ms, you are in the bottom third of the dataset. If your HSTS header is not set, you are in the majority,  but a majority that has a simple, low-effort fix available.

The full dataset, updated with each cron run, is available at enterramon.com/global-analytics-page. The figures in this article reflect the snapshot taken on 1st of June 2026.

Data collected and published by Enterramon. Testing conducted across six geographic locations using real browser automation. All domain data anonymised prior to aggregation.

Thank you for taking the time read this, please share it if you found it interesting.