At this point, it should not be necessary to explain what PHP is. The Hypertext Preprocessor is the most widely used server-side interpretable web language, with an overwhelming market share, according to public statistics shown on W3Techs :
You can see the previous table updated at this URL: https://w3techs.com/technologies/overview/programming_language
But from these percentages, we must not only interpret the numbers we see but also the graphs of growth or loss of market share.
While PHP stays the same and even goes up a bit: https://w3techs.com/diagram/history_technology/pl-php
The second competitor, ASP.NET goes down very fast: https://w3techs.com/diagram/history_technology/pl-aspnet
It is true that there are some SSI ( Server Side Rendering ) technologies that are gaining market share quite quickly, such as Javascript or Ruby. However, they are still far from PHP.
In recent years PHP has improved a lot in effectiveness, achieving better performance and lower resource consumption.
We can say that PHP 8 has improved efficiency by almost 400% compared to PHP 5.6.
Let’s remember that PHP 7.0 was released in 2015, but it didn’t get a strong implementation until 2016-2017. That is to say, little by little, PHP 5.6 was stopped being used.
By this, I mean that, in just 5 years of updates, PHP has managed to double and even triple performance and lower resource consumption.
Although the performance and efficiency have not been the only improvement of PHP 7 and PHP 8 compared to PHP 5.6, in certain “non-technical” environments it has been the one that has attracted the most attention.
Benchmark de PHP
As we have mentioned before, one of the things that have stood out the most in PHP over the years has been the performance improvements.
So you can see what I mean, the following graph represents some performance benchmarks (tests) carried out on a Raiola Networks SSD Home Plan with the different versions of PHP from 7.0 to 8.0.
As can be seen, from version 7.0 to version 8.0 the speed of executing operations with the PHP interpreter practically doubles.
But there is more because if you pay attention to this other graph, you will notice that since version 5.1 of PHP the performance has quadrupled :
This does not mean that we have to update to a new version of PHP whenever it is available, it simply reminds us that – at least for WPO – it is essential not to be left behind.
When a new version of PHP comes out, normally neither the CMS nor the plugins are compatible, since they change code in the PHP interpreter and we need developers to change them in the code of their applications to avoid problems.
For example, WordPress supports PHP 8 since version 5.6. That is, it has taken 9 months since the release of PHP 8 to be compatible.
However, as of August 30, 2021, only 60% of the plugins in the repository are compatible with PHP8, so there are still many plugins that do not support this version of PHP and, if we used them, we would not be able to pass . from PHP 7.4 to PHP 8.
PHP 8 y WordPress
Delving deeper into the subject of the main CMS on the market working with the new versions of PHP, we find that the core of WordPress quickly adapts to the new versions of PHP.
I remember quite well when WordPress started working with PHP 7.0 a few years ago. The speed achieved by making this change was brutal, and a WPO consultant like me remembers these things.
Although with version 8.0 of PHP the same leap has not been achieved in terms of loading speed, we can say that it has improved a lot. This stands out more if we compare PHP 7.0 with PHP 8, going through all the PHP 7. X branches.
As we mentioned earlier, WP core adapts quickly to new versions of PHP, but it should be noted that plugin developers often take a little longer to adapt their code to be fully compatible with new versions.
It is also common for many plugins to run out of updates along the way and we are forced to resort to other alternatives to replace them when we want to jump to the PHP version.
It is important to note that, in a WordPress blog or static web installation, where visitors load everything cached, the PHP version is a bit more indifferent, since it will only be noticed in the dashboard.
However, in complex installations where page caching cannot be applied, having one of the latest versions of PHP is a considerable improvement in load speed and resource consumption.
For example, a WooCommerce online store or an LMS platform created with LearnDash will take advantage of the efficiency of PHP8 very well.
PHP 8, PHP 7, and the OPCache
Until PHP 5.6 it was very common to talk about different OPCode Cache for PHP, or what is the same, OPCache.
They were also called “PHP accelerators” or “PHP Accelerators” and were used as a cache of pre-processed PHP files in RAM memory.
This does not mean that they are not still used now, but… really only one has remained.
These are some of those who shared market share in the version and their performance:
Some OPCaches like APC are still used for other tasks, such as non-distributed object caching.
In the end, the winner of the battle was Zend OPCache (the one who played at home).
Zend OPCache was the best, and in the end, it is the one that got integrated into the PHP interpreter natively, so as of PHP version 7.0, Zend OPcache is built into the core.
I show another test where only the OPCache is activated and deactivated between both benchmarks.
This comparative benchmark shows the difference between OPCache enabled and disabled on an SSD Home Plan of ours using PHP 7.4 :
As can be seen in the screenshots above, with an OPCache we almost managed to double the performance when performing operations with the PHP interpreter. This means that we also manage to optimize the loading of scripts and CMS such as WordPress.
For the CMS, the OPCache works transparently. That is, it simply stores more or less processed PHP files in RAM (so to speak) and loads them directly from the OPCache when they are needed.
This consumes a little more RAM on the server but makes up for it with improved efficiency and performance.
As a final point, add that as of PHP 7 the OPCache (Zend OPCache) is integrated into the PHP interpreter, although in many cases we must activate it to be able to use it:
Once activated, it will start to work completely transparently and without us having to do anything.
It is very rare to find problems with OPCache since currently any CMS or script is ready to work with it.
Personally, I currently consider its activation essential, both from the point of view of resources and performance itself.
OPCache y WordPress
As I said in the previous section, today it is very rare to run into problems between PHP’s OPCache and a CMS (at least an updated CMS).
In WordPress with the OPCache activated we do not have to do anything to make it work, although if we want to empty the OPCache cache or see what the OPCache contains we must use a plugin or an external script.
In WordPress, my recommendation is to use the WP OPCache plugin:
It is a free plugin that allows us to empty the cache and see the PHP files that are inside the OPCache and some data about them.
As you can see in the two previous screenshots, in the WordPress administration bar we have a button called “Flush PHP OPcache” that helps us to empty the OPCache.
This is quite useful when updating plugins, deactivating, or uninstalling plugins, although it is also applicable when modifying a PHP file in any circumstance.
Other caching plugins like WP Rocket have integration with the OPCache currently and allow us to empty it, although they don’t allow us to see what’s inside like the WP OPCache plugin.
Using OPCache as Object Cache in WordPress
For a few months, there has been a plugin called Docket Cache that allows us to use the OPCache as an object cache.
The OPCache and the object cache are two different types of cache, although they are similar in many ways.
While the OPCache only allows saving PHP files, the Object Cache literally stores “data”.
So… How do we use the OPCache as an object cache if it only allows us to save to PHP files? Well… converting that data that was going to be stored in the object cache into PHP files.
The data is “serialized” in PHP files and when needed, the process is reversed, making the plugin an interpreter.
In many cases, this can be counterproductive, but as always in WordPress, when we work with complex installations, everything is circumstantial.
If you want to know more about Docket Cache for WordPress, I recommend you watch the video that I share below, recorded by me some time ago:
This plugin was released in November 2020 and has improved a lot since then. In fact, it has added WooCommerce – specific tweaks that are exclusive to Docket Cache in some cases.
I/O consumption has been improving and its efficiency has been improving, although we must be aware that, when using solutions like these, the RAM consumption of the hosting or server plan will go up, although the CPU consumption will go down.
On the other hand, it should be clarified that this solution is not always ideal. It is only “valid” when we have our website hosted on a shared hosting server where neither Memcached nor Redis is installed and we need the Object Cache to speed up our complex website.
OPCache and Prestashop
Prestashop is still one of the most used CMS for eCommerce despite the “beating” that WooCommerce and Shopify are taking in market share.
Prestashop is a complex CMS and at the PHP level, it overloads the CPU and RAM a lot. Also, the “Smarty” template system doesn’t help much either.
In Prestashop, having the OPCache active is always important, since we will almost always achieve greater speed.
This is because 99% of the Prestashop stores use the native object cache, but do not use a specific page cache, which is very common in other CMS like WordPress.
By activating the OPCache we will achieve a very important improvement in the execution of PHP and, therefore, we will improve the loading of the cart and the checkout of any eCommerce, including Prestashop.
I share again the comparison between running the same benchmark with OPCache enabled and disabled :
Change the version of PHP in a hosting or server
In recent years, many things have changed around the action of changing the PHP version on a hosting or server.
For a long time hosting servers – and even VPS and dedicated servers – had one server-wide version of PHP, and if you wanted to change it, it changed server-wide.
Later it was allowed to customize the PHP version for each account, but in the vast majority of cases, you had to contact the server administrator to do so.
Since approximately 2019, it is very rare that the user himself cannot change the PHP version at the account level or even at the web level, directly from his control panel without having to contact an administrator.
I give you two examples.
On the one hand, on a cPanel server with CloudLinux like the ones we have for shared hosting (and its variants), advanced hosting, and reseller hosting at Raiola Networks, you can change it directly from cPanel :
But not only that, but in other control panels like VestaCP, the one we use for our optimized VPS servers, we also allow changing the PHP version :
Although in this case, the change is not at the entire account level, but at the domain or host level.
Even in LEMP stacks without a panel, such as CentMinMod, it is very easy to change the PHP version with the scripts included in the stack without having to do the whole process manually.
As you can see, currently changing the version of PHP on your hosting or server to adapt it to your website is very easy and it is really worth approaching the most recent and most optimized versions of PHP.
