Comparison of WordPress from PHP 5.6 to PHP 8.0

A few days ago PHP 8.0 has come to light thus celebrating 25 years of this programming language and in a few days WordPress 5.6 will also see the light, the next version of WordPress and last of this 2020.

The initial idea in the roadmap is that WordPress 5.6 would stop supporting PHP 5.6 and support PHP 8.0, but Matt made the decision that it was still early to stop supporting that already obsolete version.

So, right now, WordPress 5.6 is going to support the following PHP versions:

PHP 5.6.20+
PHP 7.0
PHP 7.1
PHP 7.2
PHP 7.3
PHP 7.4
PHP 8.0

It is very likely that of all the CMS that are on the market right now, WordPress is the one that has the most wide use over PHP. Although we must not forget that WordPress, right now, for both WordPress 5.5 and WordPress 5.6 recommends the use of PHP 7.4.

Regarding the support of PHP 8 and WordPress 5.6 a few days ago the statement of what and how WordPress is going to support this version was released, which has basically focused on the correction of possible incompatibilities, but not the rewriting of the code to support new functionalities.

The million-dollar question is does WordPress work better with PHP 8.0?

And, in this unscientific study that I have done I have tried to do the same test with a WordPress in which I have applied the contents of the “visual test” (so that the main page had enough content) and that occupied a lot (as much as 80KB of main page). This would be a page with some content and that looks more like what a page can contain.

The machine has been assembled following the following installation tutorial with the corresponding settings for cache tests.

The experiment is done first with a VPS with Ubuntu 20, with the latest versions of each PHP version available, in 4 environments:

Config 1: 0.5 CPU, 1 GB RAM, no cache
Config 2: 2 CPU, 4 GB RAM, no cache
Config 3: 2 CPU, 4 GB RAM, with Redis + Opcaché cache
Config 4: 2 CPU, 4 GB RAM, with Redis cache + Opcaché (with plugins)
WP OPcache
Redis Object Cache
Config 5: 2 CPU, 4 GB RAM, with Redis cache + Opcaché (with plugins) + page cache
WP OPcache
Redis Object Cache
WP Super Cache

The configuration of the PHP 8.0 JIT has been done with:

opcache.jit_buffer_size = 128M
opcache.jit = tracing

All results have been obtained with the ApacheBench tool and the following command:

ab -n 1000 -c 10 https://example.com/

Time taken for tests

This figure has no value in itself, but it does give us a general idea of whether it takes more or less to do the same test in each of the configurations and versions…

The lower the value, the better.

Machine	PHP 5.6	PHP 7.0	PHP 7.1	PHP 7.2	PHP 7.3	PHP 7.4	PHP 8.0	PHP 8.0 JIT
Config 1	447.389	280.844	328.814	320.941	340.995	286.553	206.136
Config 2	168.853	109.090	133.471	131.392	122.386	112.081	77.171
Config 3	170.710	109.046	132.616	126.551	116.518	112.946	78.298	74.392
Config 4							110.727
Config 5							1.302

Data is in seconds (with 3 decimal places)

Requests per second

Theoretically this is the table with the most important data, since they are the requests per second that can be made.

The higher the value, the better.

Machine	PHP 5.6	PHP 7.0	PHP 7.1	PHP 7.2	PHP 7.3	PHP 7.4	PHP 8.0	PHP 8.0 JIT
Config 1	2.24	3.56	3.04	3.12	2.93	3.49	4.85
Config 2	5.92	9.17	7.49	7.61	8.17	8.92	12.96
Config 3	5.86	9.17	7.54	7.90	8.58	8.85	12.77	13.44
Config 4							9.03
Config 5							768.29

Data is in requests per second (to 2 decimal places)

Time per request

The times it takes to make a request, on average among all requests.

The lower the value, the better.

Machine	PHP 5.6	PHP 7.0	PHP 7.1	PHP 7.2	PHP 7.3	PHP 7.4	PHP 8.0	PHP 8.0 JIT
Config 1	447.389	280.844	328.814	320.941	340.995	286.553	206.136
Config 2	168.853	109.090	133.471	131.392	122.386	112.081	77.171
Config 3	170.710	109.046	132.616	126.551	116.518	112.946	78.298	74.392
Config 4							110.727
Config 5							13.016

Data is in milliseconds (to 3 decimal places)

Minimum Connection Times (ms)

Minimum connection time of all requests made.

The lower the value, the better.

Machine	PHP 5.6	PHP 7.0	PHP 7.1	PHP 7.2	PHP 7.3	PHP 7.4	PHP 8.0	PHP 8.0 JIT
Config 1	882	617	746	656	711	557	591
Config 2	465	239	271	284	288	238	167
Config 3	474	229	331	259	267	231	158	253
Config 4							232
Config 5							2

Data is in milliseconds

80% Percentage of the requests served within a certain time (ms)

How many requests have been served in 80% of the time.

The lower the value, the better.

Machine	PHP 5.6	PHP 7.0	PHP 7.1	PHP 7.2	PHP 7.3	PHP 7.4	PHP 8.0	PHP 8.0 JIT
Config 1	4551	2880	3352	3288	3463	2925	2113
Config 2	1734	1124	1373	1358	1267	1156	795
Config 3	1755	1127	1368	1303	1198	1164	812	767
Config 4							1156
Config 5							19

Data is in milliseconds

As I said at the beginning, it is not scientific data because I have tested it in a fairly simple environment, but it can give a small idea of the improvements that each of the versions suppose.

Conclusions

PHP 8.0 works 50% better than PHP 5.6, without a doubt
PHP 8.0 with and without JIT, on WordPress, is almost invaluable.
When WordPress gets saturated and PHP too because the machine doesn’t give more of itself (which could be considered “bad hosting”), you can lose 60% of the performance. Investing in hosting is a good idea.
Tuning database, cache, and other service configurations can increase performance enough to be performance-sensitive.
Properly configuring page cache plugins can increase speed by up to 90%.

About this document

This document is regulated by the EUPL v1.2 license, published in WP SysAdmin and created by Javier Casares. Please, if you use this content in your website, your presentation or any material you distribute, remember to mention this site or its author, and having to put the material you create under EUPL license.