An insight into the latest web technologies, helping you to supercharge your WordPress site performance, and other tidbits the serious site owner must know.

WARNING: Contains large numbers and may take up your entire morning. Reading this is easily a 15-minute exercise, and the donut charts may consume you.

Very exciting though!

Optimising your website performance doesn’t have to be hard. By following the points outlined in this article, you’re already doing better than most.

Increasing the speed of your website doesn’t stop at installing a performance plugin. I want to draw attention to this fact. Several things are external to WordPress that yield performance increases too. This article is for website owners who only know they have a WordPress site, although web designers and developers may find this very interesting also.

Everyone loves data, and what better way than to make suggestions and show you what others are doing. I’m going to look at what some websites in New Zealand have implemented. A large percentage of these sites are running WordPress.

The results are surprising. On the one hand, many websites were not taking full advantage of the technologies available to them. On the other hand, I’m concerned that a significant portion of sites is at serious risk of being compromised.

Web technology is ever-changing. I suspect that many site owners aren’t even aware of some of the things covered below. At the end of it all, you’ll be more informed, and hopefully, this helps you choose the right host for your website.

Let’s get stuck in.

To back these suggestions with real data, I need to analyse a rather large number of websites. Both a time-consuming and mammoth task, you’d agree. So I wrote a fancy script using NodeJS to perform much of the testing for us. The information this script collects is publicly available – just like using a standard internet browser, except the time it takes to do this is significantly sped up. The script “visited” random websites “in New Zealand” during August 2019.

That number is 33,189.

After visiting 33,189 domain names in the New Zealand namespace, I discarded invalid domain names, misdirections and redirections to arrive at a figure of 22,999.

Does your website use the Secure HyperText Transport Protocol? (HTTPS)

HTTPS is a way to encrypt information that you send between a browser and a web server. It helps prevent intruders from tampering with the communications between your website and your visitors, like credit card information or logins.

Secure connections are becoming the standard for all websites. A few years ago, it became a dead-serious ranking signal for Google. Several years ago, Google confirmed that they favour HTTPS sites. If your site isn’t secure, it could be getting outranked by similar sites that are.

Internet browsers are now beginning to warn visitors that your site is not secure.

Having HTTPS leads to increased conversions and increased customer confidence. It is also a prerequisite for some of the other technologies listed here.

Almost 30% of the websites I sampled in New Zealand have yet to implement HTTPS properly. This percentage is quite alarming, considering how easy it is to have it enabled.

Fig 1a — HTTPS Support

HTTPS Support Websites with HTTPS enabled HTTPS Segment spanning 70.73% of the whole. No HTTPS Segment spanning 22.70% of the whole. Certificate Expired Segment spanning 6.57% of the whole.

Donut chart showing - HTTPS Support

Sample Size | 22999 (100%)

Fig 1b — HTTPS Support - WordPress only

HTTPS Support - WordPress only WordPress Websites with HTTPS enabled HTTPS Segment spanning 79.26% of the whole. No HTTPS Segment spanning 15.60% of the whole. Certificate Expired Segment spanning 5.14% of the whole.

Donut chart showing - HTTPS Support - WordPress only

Sample Size | 8525 (100%)

Fig 1c — Are HTTPS Websites redirecting properly?

Are HTTPS Websites redirecting properly? We test if websites with HTTPS support are redirecting properly Yes Segment spanning 72.92% of the whole. No Segment spanning 27.08% of the whole.

Donut chart showing - Are HTTPS Websites redirecting properly?

Sample Size | 16268 (100%)

It appears that WordPress sites have a slightly better adoption rate for HTTPS.

There is no excuse for not having HTTPS implemented. We’re almost heading into 2020.

Of the ones that do have HTTPS enabled, I noted that 27% did not redirect the visitor from HTTP (non-secure) to HTTPS (secure). What is going on? If you’ve got your website domain plastered on the side of your car, remember that most people aren’t going to type in the full URL including the HTTPS protocol (or the www part for that matter). Your web server must take care of this for your visitors.

Did I mention that HTTPS is also a prerequisite to being able to adopt other technologies? like the next one…

Be sure that HTTPS is enabled on your site and that it is redirecting correctly for both www and non-www versions of your domain name.

Got Broccoli Brotli?

Brotli (pronounced Bro-li) compression is a new, open-sourced, compression algorithm developed by Google to help further reduce the size of files. It provides impressive gains of up to 25% over gzip compression. It has widespread browser support.

It takes advantage of multiple algorithms to condense data more efficiently than gzip. In 2015, the Brotli specification was generalised for HTTP stream compression with the content-encoding type ‘br’.

Only 12% of websites have Brotli enabled – 4 years after it became available.

Fig 2a — Brotli Support (Prerequisite - HTTPS)

Brotli Support (Prerequisite - HTTPS) Websites with Brotli support GZIP Compression Segment spanning 67.61% of the whole. GZIP + Brotli Compression Segment spanning 12.49% of the whole. No Compression Segment spanning 19.87% of the whole. Only Brotli (weird!) Segment spanning 0.02% of the whole.

Donut chart showing - Brotli Support (Prerequisite - HTTPS)

Sample Size | 16268 (100%)

Some sites returned an error when attempting to validate available compression methods. Some were using the older "deflate", which is basically the same as gzip without the added reliability and checksum.

What makes Brotli better? According to a test conducted by CertSimple

  • 14% smaller than gzip for JavaScript
  • 21% smaller than gzip for HTML
  • 17% smaller than gzip for CSS

Find a hosting provider that supports Brotli. It provides for better compression than gzip and it’s now supported in all 4 major browsers.

HTTP/2 Support

HTTP/2 is a major upgrade to the HyperText Transfer Protocol, which is the underlying communication protocol of the World Wide Web.

The most common one in use today (HTTP/1.1) was officially released around January 1997. Much has changed since then. The future is here, and it is one of the greatest advancements in web technology in the past 20 years.

The most advanced feature of HTTP/2 is that it can send multiple requests for data in parallel over a single connection – allowing for your visitors to download web assets asynchronously, making your website load faster.

With effective network resource utilisation, lighter network footprint, reduced network latency and improved throughput, it makes absolute sense to adopt this new technology.

Unfortunately, it would appear that roughly half of the websites in New Zealand are locked in the past.

Fig 3a — HTTP/2 Support (Prerequisite - HTTPS)

HTTP/2 Support (Prerequisite - HTTPS) HTTPS Websites with HTTP/2 support HTTP/1.1 Segment spanning 51.52% of the whole. HTTP/2 Segment spanning 43.58% of the whole. Not detected / Invalid response to our probe Segment spanning 4.90% of the whole.

Donut chart showing - HTTP/2 Support (Prerequisite - HTTPS)

Sample Size | 16268 (100%)

Find a hosting provider that supports HTTP/2. According to Can I Use, HTTP/2 is supported by 95% of the browsers used by users globally.

HTTP/3 Support

The official HTTP/3 standard hasn’t been finalised yet – however, to determine whether a server had implemented experimental/draft support I just had to look for a header that contained this information.

It was interesting to see from our large dataset that only a small percentage of websites could adopt HTTP/3 if they wanted to. I predict an even slower rate of adoption over the next few years compared to the time it took for sites to offer support for HTTP/2.

HTTP/3 is the next iteration of the HTTP protocol family. It is very similar to HTTP/2, but it offers some significant advancements and changes to the underlying method of utilisation. Kristopher Sandoval helps explain HTTP/3 in detail here.

  • Dramatically reduced connection establishment time
  • Improved congestion control
  • Multiplexing without head of line blocking
  • Forward error correction
  • Connection migration

HTTP/3 redefines the way the internet works. The successor of HTTP/2 allows for multiple simultaneous connections between browser and server while using a UDP connection instead of TCP. Combined with new techniques to ensure high reliability of these connections, this offers unprecedented site speed. Not all browsers support HTTP/3 yet. Users of Chrome, Opera and more recent versions of Edge can use all benefits of HTTP/3.

Fig 4a — HTTP/3 Support (Prerequisite - HTTPS)

HTTP/3 Support (Prerequisite - HTTPS) Websites with HTTP/3 support Yes, supports a HTTP/3 draft Segment spanning 7.61% of the whole. No Segment spanning 92.39% of the whole.

Donut chart showing - HTTP/3 Support (Prerequisite - HTTPS)

Sample Size | 16268 (100%)

7.6% of websites tested showed some form of support for HTTP/3. It is interesting to see that most of these websites were powered by the LiteSpeed webserver.

Medieval provides experimental HTTP/3 support today. Have another jelly bean.

Transport Layer Security – faster and more secure.

Transport Layer Security (TLS) is the successor to SSL (Secure Sockets Layer). TLS provides secure communication between web browsers and servers. The connection itself is secure because symmetric cryptography is used to encrypt the data transmitted. The keys are uniquely generated for each connection and are based on a shared secret negotiated at the beginning of the session, also known as a TLS handshake.

It has been over eight years since the last protocol update. Just about every website I sampled that had HTTPS enabled utilised TLS version 1.2.

TLS 1.3 was published in August 2018 (IETF standard in RFC 8446) and it includes a lot of security and performance improvements.

With TLS 1.2, two round-trips have been needed to complete the TLS handshake. With 1.3, it only requires one round-trip, which in turn cuts the encryption latency in half.

Support for TLS 1.3 is limited. Most web servers don’t have the most up to date Linux distributions and therefore don’t contain the required dependencies, such as the NGINX web server (>1.13) and OpenSSL. You’d have to compile these yourself if you’re administering the server yourself. If you’re using a popular control panel such as cPanel or Plesk, it could be a long while before this feature is provided.

Find a web host that supports TLS 1.3

Web Server Location

The location of the server that your website resides on is very important to the speed and general satisfaction of your visitors. Here is a break down of the location of 8525 WordPress sites.

Fig 5a — Website server location (based on IP address) - WordPress sites only

Website server location (based on IP address) - WordPress sites only Website server location New Zealand Segment spanning 68.47% of the whole. Australia Segment spanning 6.71% of the whole. United States Segment spanning 16.34% of the whole. Singapore Segment spanning 0.25% of the whole. United Kingdom Segment spanning 0.33% of the whole. Elsewhere (Japan, Netherlands, Canada, Greece, India, Germany, France, Bulgaria) Segment spanning 7.91% of the whole.

Donut chart showing - Website server location (based on IP address) - WordPress sites only

Sample Size | 8525 (100%)

As you can see here, around 25% of sites will see a significant boost in speed if they had picked a closer server. There are so many variables to take into account when measuring the performance of a website, but generally speaking — If you host your website on the other side of the world, it will be slower to your kiwi visitors. The extra hops and latency add up.

This test is conducted by looking up the country location for the IP address of the website. Some websites are using CloudFlare. It is difficult to determine where the backend web server is located for these sites. CloudFlare is a global content delivery network and the service masks the origin of the actual web server.

Websites that use the CloudFlare service aren’t necessarily faster for us kiwis in New Zealand. In most cases, all the requests have to go through the United States. Sometimes I could see the traffic was being routed through Singapore. This additional latency hurts your website performance.

Of all the WordPress sites located in New Zealand (5837) – None of these were utilising the CloudFlare service. This suggests to us that CloudFlare does not yet have a POP (point of presence) in New Zealand.

What about a Content Delivery Network (CDN)?

And where are they located? That’s right – usually overseas. To everyone reading this exciting piece, you’ve got to remember that all this data relates to websites in New Zealand. We’re so far away from everyone else. A CDN service is not likely going to offer any additional performance benefit unless it is also hosted in New Zealand. It only appeals if you have a global audience.

Host your website on a server that is geographically closer to your target audience. For us kiwis, hosting in Australia is attractive too. Higher performance server hardware can be obtained more cheaply due to a larger economy there.


I’m in the business of providing superior hosting and support services for WordPress, so it made absolute sense to get a rough idea of how WordPress sites are being supported in New Zealand.

When I first conducted these tests, this article was mainly focused on WordPress and my sample size for WordPress powered sites was just 1781. After research and analysis, I realised how bad things were. I needed more data and so I expanded my dataset to include a further 6734 WordPress sites.

By default, from version 3.7 and above, your WordPress site will update itself when a new minor or security update is released. What surprised me is that a significant portion of WordPress sites was still stuck on an older “major release”, or had something preventing the site from updating itself.

I can draw an interesting conclusion that some of these sites perhaps didn’t have anybody actively looking after them.

Let’s see… yes! Where have we seen this before? You’ve spent thousands of dollars on a new website, settled on a place to host it and then your developer offered you a monthly support package “but wait there’s more”, and you said no thanks, I’ve already spent too much money on this!

It’s easy to neglect your site. Several years later you still haven’t logged into it.

It is very crucial to keep your plugins updated and this is equally or more important than WordPress itself. Outdated or exploited plugins are the number one reason why WordPress sites are compromised in the first place. If the WordPress site is running an older version, I can probably assume that the plugins aren’t being updated either. Something I’ll touch on again shortly.

Of the 8525 WordPress sites, 7125 kindly gave us the WordPress version, which is exposed by default. 1400 managed to conceal this information by using a security plugin, so I wasn’t able to include these in our assessment.

Fig 6a — Distribution of Major WordPress releases

Distribution of Major WordPress releases Distribution of Major WordPress releases Version 2.x Segment spanning 0.03% of the whole. Version 3.x Segment spanning 1.77% of the whole. Version 4.x Segment spanning 35.99% of the whole. Version 5.x Segment spanning 62.22% of the whole.

Donut chart showing - Distribution of Major WordPress releases

Sample Size | 7125 (100%)

See here, a significant portion (36%) are still on the 4.x version of WordPress. There could be a good reason for this. Perhaps the website theme is not ready for the new Gutenberg WordPress editor. Gutenberg became available with the release of WordPress 5. Or perhaps they are too scared to update in case some things may break the site.

But, the much-awaited and anticipated release of WordPress 5.0 happened on December 6, 2018. At the time of testing for this article, that was 8 months ago.

WordPress routinely provides sub-point releases that contain bug fixes and security updates to address vulnerabilities such as cross-site scripting (XSS) and SQL injections etc. I can see that around 23% are outdated – They haven’t updated to latest “sub-point” release for the version of WordPress they are using.

Fig 6b — Websites running an outdated version of WordPress

Websites running an outdated version of WordPress Comparison of WordPress sites outdated versus updated Outdated, could be prone to security vulnerabilities Segment spanning 22.85% of the whole. At the end of a point release, but not necessarily the latest version of WordPress Segment spanning 77.15% of the whole.

Donut chart showing - Websites running an outdated version of WordPress

Sample Size | 7125 (100%)

What would you consider a proactive WordPress site? I would imagine that would be one receiving constant love and support versus one that isn't. Let's say that anything older than version 5.2 is not proactive.

Fig 6c — Indication of what percentage of WordPress sites are "proactive"

Indication of what percentage of WordPress sites are "proactive" Comparison of WordPress sites newer and older than version 5.2 WordPress version 5.2 or newer Segment spanning 54.02% of the whole. Older than 5.2 Segment spanning 45.98% of the whole.

Donut chart showing - Indication of what percentage of WordPress sites are "proactive"

Sample Size | 7125 (100%)

If you’re not able to keep your WordPress installation and plugins up to date regularly, perhaps it is time to start using a service that provides this peace of mind for you.

What concerned is that according to our data, it seems like there are a lot of WordPress sites running on older versions. There are also a significant number of sites sitting on a point release that has already been superseded by a more recent security release.

So who exactly is looking after these sites?

I acknowledge that WordPress Core itself is reasonably secure. What is worrying is the high probability that if the WordPress version is not a recent one, how many outdated and vulnerable plugins exist too?

Sites that remain in this state are more prone to being exploited, turning them into a potential host for scam landing pages, or as a sending source of spam. Next time you’ve clicked on fake Netflix account page asking for you to enter your credit card – Let’s have a moment’s silence for that website owner.

Here is our data that some may find interesting. Also, just for fun, 15% of these WordPress sites are actively using WooCommerce.

Count Version Major Release Date Minor/Security Release Date Outdated?
1 2.5 March 29, 2008 Yes
1 2.9.2 December 18, 2009 (2.9) February 15, 2010 No
3 3.0.1 June 17, 2010 (3.0) July 29, 2010 Yes
1 3.1 February 23, 2011 Yes
1 3.1.1 April 5, 2011 Yes
1 3.1.3 May 25, 2011 Yes
2 3.2.1 July 4, 2011 July 12, 2011 No
5 3.3.1 December 12, 2011 January 3, 2012 Yes
2 3.3.2 April 20, 2012 Yes
1 3.4 June 13, 2012 No
8 3.4.1 June 27, 2012 Yes
9 3.4.2 September 6, 2012 No
2 3.5 December 11, 2012 Yes
10 3.5.1 June 21, 2013 Yes
6 3.5.2 June 21, 2013 No
8 3.6 August 1, 2013 Yes
11 3.6.1 September 11, 2013 No
1 3.7.1 October 24, 2013 October 29, 2013 Yes
6 3.7.29 March 13, 2019 Yes
1 3.8 December 12, 2013 Yes
1 3.8.11 September 15, 2015 Yes
20 3.8.29 March 13, 2019 No
4 3.9.1 April 16, 2014 (3.9) May 8, 2014 Yes
3 3.9.2 August 6, 2014 Yes
1 3.9.3 November 20, 2014 Yes
1 3.9.6 May 7, 2015 Yes
1 3.9.25 July 5, 2018 Yes
1 3.9.26 December 12, 2018 Yes
16 3.9.27 March 13, 2019 No
6 4.0 September 4, 2014 Yes
1 4.0.1 November 20, 2014 Yes
2 4.0.8 September 15, 2015 Yes
1 4.0.15 January 26, 2017 Yes
22 4.0.26 March 13, 2019 No
1 4.1 December 17, 2014 Yes
1 4.1.1 February 18, 2015 Yes
1 4.1.7 August 4, 2015 Yes
1 4.1.13 September 7, 2016 Yes
27 4.1.26 March 13, 2019 No
2 4.2 April 23, 2015 Yes
2 4.2.1 April 27, 2015 Yes
6 4.2.2 May 7, 2015 Yes
2 4.2.3 July 23, 2015 Yes
5 4.2.4 August 4, 2015 Yes
1 4.2.8 May 6, 2016 Yes
1 4.2.10 September 7, 2016 Yes
1 4.2.12 January 26, 2017 Yes
45 4.2.23 March 13, 2019 No
5 4.3 August 18, 2015 Yes
10 4.3.1 September 15, 2015 Yes
1 4.3.3 February 2, 2016 Yes
1 4.3.6 September 7, 2016 Yes
1 4.3.11 May 16, 2017 Yes
1 4.3.12 September 19, 2017 Yes
1 4.3.17 July 5, 2018 Yes
49 4.3.19 March 13, 2019 No
2 4.4 December 8, 2015 Yes
1 4.4.1 January 6, 2016 Yes
8 4.4.2 February 2, 2016 Yes
5 4.4.3 May 6, 2016 Yes
1 4.4.5 September 7, 2016 Yes
48 4.4.18 March 13, 2019 No
1 4.5 April 12, 2016 Yes
2 4.5.1 April 26, 2016 Yes
8 4.5.2 May 6, 2016 Yes
12 4.5.3 June 21, 2016 Yes
4 4.5.4 September 7, 2016 Yes
1 4.5.9 May 16, 2017 Yes
1 4.5.15 July 5, 2018 Yes
1 4.5.16 December 12, 2018 Yes
69 4.5.17 March 13, 2019 No
2 4.6 August 16, 2016 Yes
16 4.6.1 September 7, 2016 Yes
1 4.6.4 March 6, 2017 Yes
1 4.6.5 April 20, 2017 Yes
4 4.6.6 May 16, 2017 Yes
1 4.6.10 January 16, 2018 Yes
1 4.6.12 July 5, 2018 Yes
80 4.6.14 March 13, 2019 No
1 4.7 December 6, 2016 Yes
1 4.7.1 January 11, 2017 Yes
7 4.7.2 January 26, 2017 Yes
10 4.7.3 March 6, 2017 Yes
4 4.7.4 April 20, 2017 Yes
5 4.7.5 May 16, 2017 Yes
3 4.7.6 September 19, 2017 Yes
8 4.7.7 October 31, 2017 Yes
3 4.7.9 January 16, 2018 Yes
2 4.7.10 April 3, 2018 Yes
5 4.7.11 July 5, 2018 Yes
205 4.7.13 March 13, 2019 No
13 4.8 June 8, 2017 Yes
22 4.8.1 August 2, 2017 Yes
12 4.8.2 September 19, 2017 Yes
12 4.8.3 October 31, 2017 Yes
4 4.8.4 November 29, 2017 Yes
12 4.8.5 January 16, 2018 Yes
6 4.8.6 April 3, 2018 Yes
4 4.8.7 July 5, 2018 Yes
2 4.8.8 December 12, 2018 Yes
238 4.8.9 March 13, 2019 No
6 4.9 November 15, 2017 Yes
13 4.9.1 November 29, 2017 Yes
11 4.9.2 January 16, 2018 Yes
62 4.9.3 February 5, 2018 Yes
25 4.9.4 February 6, 2018 Yes
24 4.9.5 April 3, 2018 Yes
38 4.9.6 May 17, 2018 Yes
18 4.9.7 July 5, 2018 Yes
142 4.9.8 August 2, 2018 Yes
28 4.9.9 December 12, 2018 Yes
1151 4.9.10 March 13, 2019 No
3 5.0 December 6, 2018 Yes
9 5.0.1 December 12, 2018 Yes
11 5.0.2 December 19, 2018 Yes
49 5.0.3 January 9, 2019 Yes
338 5.0.4 May 21, 2019 No
43 5.1 February 21, 2019 Yes
704 5.1.1 March 13, 2019 No
28 5.2 May 7, 2019 Yes
89 5.2.1 May 21, 2019 Yes
3159 5.2.2 June 18, 2019 No

WordPress Plugins

Plugins are the number one source of malicious code and the reason why so many WordPress sites fall to its knees.

From a security perspective, you’d want to review your plugins quite frequently. I’ve seen sites get exploited due to plugins not being updated quick enough – not the fault of the site owner. Getting exploited due to a vulnerable plugin isn’t a lucky dip – once the attackers are aware of relatively young security exploits, they’ll search around to find websites running that plugin.

If you’re not able to monitor your plugins for updates regularly, PLEASE consider enlisting a service that can manage that for you.


PHP (Hypertext Preprocessor) is a server-side scripting language. PHP scripts are interpreted and run on a server that has PHP installed. WordPress is written using PHP as the scripting language.

A lot of sites (44%) are running an unsupported version of PHP. In other words – end of life.

I saved the best for last. If you thought the WordPress numbers were impressive. PHP is going to be a shock to the system.

To obtain the PHP version, I look at the header data that is received by the browser. Not all web servers dish out this information, so out of a sample size of 8525 WordPress sites – 3577 kindly exposed their PHP version.

The sample size of this data is not a significant number, and it won’t accurately reflect the real-world.

It is also important to note that the web servers that expose their PHP versions are most likely to be operated by shared hosting providers using cPanel or Plesk control panels. It is a fairly common practice for some specialised providers such as ourselves to prevent the PHP version from being made public.

Fig 7a — PHP - Active support vs End of life/security fixes only

PHP - Active support vs End of life/security fixes only PHP - Active support vs End of life/security fixes only Active Support (≥ 7.2) Segment spanning 32.99% of the whole. End of Life (≤ 7.0) Segment spanning 44.12% of the whole. Security fixes only (Ver 7.1) Segment spanning 22.90% of the whole.

Donut chart showing - PHP - Active support vs End of life/security fixes only

Sample Size | 3577 (100%)

A lot of sites (44%) are running an unsupported version of PHP. In other words – end of life.

End of life (EOL) – A release that is no longer supported. Users of this release should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities. Source –

Your PHP version is not something to be too alarmed about, but running a more recent version gives you a boost in performance, both on the front-end and the back-end.

You wouldn’t want to eat end of life food, so why would you run your website on end of life software? It would be only a matter of time before things on your website begin to break, stop working. Not a good thing for websites that make you money!

Developers who write software in PHP (i.e., plugins for WordPress) are only interested in supporting the majority. Newer versions of PHP often introduce new functions and methods. Sure, there may be backward compatibility, but the line draws somewhere. Try running that plugin on your old web server, and it may spit the dummy.

The WordPress Requirements page recommends PHP version 7.3 or greater.

When WordPress 5.2 was released in May this year, there was an update to the minimum required version of PHP. The minimum required version is now PHP 5.6.20, despite it already being EOL.

From — If your site is running on an unsupported version of PHP, the WordPress updater will not offer WordPress 5.2 to your site. If you attempt to update WordPress manually, that update will fail. To continue using the latest features of WordPress you must update to a newer version of PHP.

Code execution in PHP is single-threaded – This means loading a single page on your website will only ever utilise one CPU core. PHP 7 is twice as fast as PHP 5.6 out of the box. Each new release of PHP is faster than its predecessor. If you want to increase the performance of your website, upgrade PHP.

PHP 7.4 comes out November this year.

Here is a break down of the sites using an unsupported version of PHP. It not is surprising that some servers are still operating on 5.2, 5.3, 5.4 and 5.5. Many sites are still using 5.6. And I think I know why! Keep reading.

Fig 7b — Distribution of Unsupported PHP versions

Distribution of Unsupported PHP versions Distribution of Unsupported PHP versions Version 5.2 Segment spanning 1.33% of the whole. Version 5.3 Segment spanning 6.15% of the whole. Version 5.4 Segment spanning 10.52% of the whole. Version 5.5 Segment spanning 5.32% of the whole. Version 5.6 Segment spanning 47.85% of the whole. Version 7.0 Segment spanning 28.83% of the whole.

Donut chart showing - Distribution of Unsupported PHP versions

Sample Size | 1578 (100%)

Yes, that’s right. Version 7.0 is already in the ground. Version 7.1 is already heading towards the end of its useful life with security fixes only until 1st Dec 2019.

Below shows the distribution of supported versions. Remember, only 33% of the sites I tested that exposed their PHP version are using a supported version. By December 2019, I believe that that may drop further to around 25%.

Fig 7c — Distribution of supported PHP versions

Distribution of supported PHP versions Distribution of supported PHP versions Version 7.1 Segment spanning 40.97% of the whole. Version 7.2 Segment spanning 46.92% of the whole. Version 7.3 Segment spanning 12.11% of the whole.

Donut chart showing - Distribution of supported PHP versions

Sample Size | 1999 (100%)

Upgrade your PHP to the latest version to get significant speed improvements.

Is your web server quick and nimble?

Most aren’t. During my testing, I ignored any website that was going to take longer than 7 seconds to give me my first byte.

The time to first byte (TTFB) is the amount of time it takes from when a visitor makes an HTTP request in their browser, to it receiving its first byte of data from the webserver. Measuring the TTFB is an essential aspect of website optimisation since the faster the TTFB, the faster the requested resource can begin its journey from the server to being delivered to the browser.

It consists of 3 components, the time needed to send the request, the time needed for the server to process the request, and the time needed for the server to send back the first byte of the response.

A slow TTFB can be caused by many things.

  • Delivery of dynamic content (not already cached)
  • Networking issues
  • Poorly configured web server
  • Server capacity issues — such as low memory, slow disk performance, bottlenecks, and CPU contention issues
  • Database server and query latency

Our test results show us that your TTFB suffers if you host on the other side of the world, but having said that, if you get everything else right, your site could still easily outperform sites hosted here in New Zealand.

Ideal TTFB ranges are;

  • Under 100ms — Fantastic
  • 200 – 500ms is a fairly standard expectation
  • 500ms – 1 second is less than ideal but workable
  • Anything greater than 1 second should likely be investigated further

Fig 8a — Time to First Byte (TTFB)

Time to First Byte (TTFB) PHP - Active support vs End of life/security fixes only ≤ 100ms Segment spanning 10.23% of the whole. 101-200ms Segment spanning 6.23% of the whole. 201ms - 500ms Segment spanning 14.02% of the whole. 501ms - 1000ms Segment spanning 22.50% of the whole. Between 1001ms and 4000ms Segment spanning 42.98% of the whole. Between 4001 and 7000ms Segment spanning 4.05% of the whole.

Donut chart showing - Time to First Byte (TTFB)

Sample Size | 8525 (100%)

A typical by-product of using oversold shared hosting is a higher TTFB. Around 47% of sites took between 1 and 7 seconds to respond with one byte. Most of these sites identified themselves as being hosted with well-recognised cheap web hosting providers. This determination, however, is not conclusive as many other factors will affect TTFB.

Our TTFB tests were conducted on the first-ever visit to the website using an internet connection typical of what most New Zealanders would be using today (VDSL in Auckland).

Speed up your TTFB by using an excellent caching plugin to create static versions of your pages, and use a hosting provider that specialises in WordPress performance.

A thing or two about server density

It isn’t a secret that most shared hosting providers have over 600 or so websites per server. After all, their target market is CHEAP web hosting. So it shouldn’t come as a surprise to you that if you commit to ~$9 (NZD) per month to have your website up and running, there is no way you can expect top-tier performance.

That’s because the quantity of processors or cores in the server is a finite number. Shared hosting has always been like this; you’re sharing resources.

But it’s when you might decide that shared hosting is not for you, understandably so because you’ve read all the horrible things associated with shared hosting, and then you upgrade to a VPS (virtual private server). Bee’s knees right? Wrong!

There is a common misconception in the market that a VPS outperforms and outshines shared hosting. A dedicated bare-metal server outperforms shared hosting because you’re the only one on it. But in a way, VPS is still loosely classified as shared hosting.

VPS’s do have their strengths – you can spin up your choice of Linux distribution, maintain whatever you want to run on it but you’re still limited to its processing capability which comes in the form of a vCPU, or virtual Core.

Just like having a timeshare holiday home, you are sharing your precious core with several other VPS’s housed on the same server. Noisy neighbours are still prevalent. One vCPU does not equal 1 physical core. The number of virtual machine vCPUs allocated compared to the number of physical CPU cores available is the vCPU-to-core ratio.

Some hosts overcommit their ratio to 8:1, or even higher. It is something to be mindful about when you’re considering a low-priced VPS. You’re not necessarily going to achieve more exceptional performance.

It is what separates a host that focuses on cheap from a host that is performance orientated. How much more you’re prepared to pay for that additional performance affects how successful your website becomes.

Look for a host that is happy to answer your questions concerning server density. The best ones are those who go to great lengths to help you understand how their infrastructure guarantees you ample server resources. Shared hosting isn’t necessarily a bad thing; this is about knowing how many websites are on the same server and keeping that figure low to ensure your website can perform better. You pay for that privilege.

But don’t be discouraged by shared hosting / VPS

There is nothing wrong with shared hosting. The infrastructure behind services that are purported to be shared hosting, whether it be a cPanel service or your own VPS, is the same. What it boils down to is the server density and the level of support you receive. If you pay peanuts, you’ll get peanuts. Pay a bit more, and you’ll start getting the performance and support level you desire.

Have you heard of this magic dust for networking performance?

The web we have today is vastly different from the one we surfed with our dial-up modems 30 years ago.

BBR (“Bottleneck Bandwidth and Round-trip propagation time”) is a new congestion control algorithm developed at Google. Congestion control algorithms — running inside every computer, phone or tablet connected to a network — that decide how fast to send data to the receiver. With BBR from Google, it’s possible to get increased throughput and also reduced latency for connections.

Today’s web, distributed across 7 billion people on devices and network connectivity, ranging from very fast to very slow – most are communicating using older algorithms. The new BBR congestion control algorithm is for the congestion of the modern internet.

This great article written by Colt McAnlis explains in awesome detail what BBR is all about.

  • Higher throughput — BBR enables big throughput improvements on high-speed, long haul links. Significantly increased bandwidth and reduced download times for webpages, videos or other data.
  • Lower latency — BBR enables significant reductions in latency in last-mile networks that connect users to the internet. This greatly benefits visitors who are using their mobile phones.

Switch to a server that utilises BBR congestion control for significant networking speed gains.

To www or not to www?

Some websites have the “www” subdomain preceding their domain name, and others don’t. There isn’t anything wrong with one way or the other. But whatever you decide to choose — make sure both of them work!

In case you were wondering…

Fig 9a — WWW vs NON-WWW

WWW vs NON-WWW WWW vs NON-WWW With WWW Segment spanning 37.93% of the whole. Without WWW Segment spanning 62.07% of the whole.

Donut chart showing - WWW vs NON-WWW

Sample Size | 22999 (100%)

You may find this funny. Some sites had only a domain record for one or the other. For any prospect visiting your website on the wrong one, that is 0% performance. I came across 84 sites that were explicitly www only.

Although not a big deal, another thing I noted is that there are sites that mix and match between having www prefixed to their sites internal links.

Ensure you have domain name records for both variants so that you are capturing all sources of traffic. For your site and its internal links, it is a good idea to settle on one variant or the other.

Fix unnecessary redirections

Having your web server redirect from HTTP to HTTPS is a no-brainer. Likewise, automatically redirecting from non-www to www or vice-versa is also a no-brainer. Ensure you have domain name address records for both variants.

But, I also encountered many websites that would take us on a little journey. > > >

Ensure that your web server and website is redirecting correctly. Unnecessary redirections add delays and potentially double the number of TLS handshakes.


It’s not easy to adopt all of the things contained in this article. The reason for that may be because there are limitations to the software used by your web hosting provider. Some implementations, such as TLS 1.3 or Brotli, involves re-compiling software. Introducing BBR congestion control requires an operating system kernel upgrade.

But having said that, now that you are aware that these technologies exist – you can make a better-informed decision on what to do with your current host, or how you tackle your next host.

My best bet is that many “oversold and budget” shared hosting web providers are finding themselves stuck on ancient software and older operating systems, unable to extend and adopt newer tech. It is because it would mean having to undertake a mammoth task having to relocate anywhere between 600-1000 websites on the one server before they can upgrade the underlying system.

It could also be the reason why so many websites are still running on outdated PHP versions. As typical shared hosting is similar to a no-frills budget car – you’re not interested in what is under the hood, and for the super-low monthly price you’re paying them – they’re not likely to inform you. It is once you’ve experienced better robust support that cares about your website performance where you may realise what your options are. And believe me, proactive support is worth it.

The best thing you can do is look for a provider that promotes these implementations as part of their service offering. That ones that highlight these technologies on their respective websites are those who care more about performance and security.

About Steven Munro
Steven Munro
Hailing from New Zealand, Steven has worked with WordPress for over a decade and provides the best possible support to his close-knit and loyal customers. WordPress developer, Linux Systems Administrator (28+ years), NodeJS, and React enthusiast. Lives with three cats and a teenage son who is addicted to Fortnite. Steven also bakes very good cakes and muffins. Email Steven.