Improve Your PHP Performance By Upgrading To PHP 7

When your phone starts to feel slow or you find your tablet or laptop taking a long time to perform some task, you start to think about upgrading. Odds are a newer device will come with better specs and a generally more performant device.

Upgrading to the latest version of your server side language is similar. It may vary with specific versions of specific languages, but with PHP, right now is a good time to upgrade.

The last couple of weeks I’ve been talking about PHP and performance as part of a larger series about website performance. I talked about dynamic sites in general and then last week offered some tips for writing PHP that will run faster.

Today I want to talk about PHP 7 and about how and why it’s faster than the versions that came before it. I’m hoping to convince you to upgrade if you haven’t already done so.

PHP Version Benchmarks

A few months ago I told you how I moved this site to a new host and I presented some before and after performance results. With the move I upgraded the site to run on PHP 7.2.3 where it had previously been on 5.6.31. A shout out to Siteground for making this so easy. Unfortunately I didn’t get to run tests comparing the two versions of PHP on the same host so I’ll have to trust others that suggest PHP 7 runs about twice as fast as PHP 5.6.

Kinsta published an article with test results from different content management systems and plugins across different versions of PHP. Here are the benchmarks for WordPress to give you an idea what they found.

  • WordPress 4.9.4 PHP 5.6 benchmark results: 49.18 req/sec
  • WordPress 4.9.4 PHP 7.0 benchmark results: 133.55 req/sec
  • WordPress 4.9.4 PHP 7.1 benchmark results: 134.24 req/sec
  • WordPress 4.9.4 PHP 7.2 benchmark results: 148.80 req/sec
  • WordPress 4.9.4 HHVM benchmark results: 144.76 req/sec

You can see PHP 7.2 was able to handle the most requests per second and that all variations of PHP 7 far exceeded the results of PHP 5.6. Here are a few more comparisons if you want more data.

So why is it faster?


There was no PHP 6 outside of an experimental version a few years ago that never made it into production. The current version skipped the number 6 to avoid confusion with the experimental version.

PHP 7 was released in 2015. It’s based on the phpng branch. The ng is a Star Trek reference to Next Generation by the way. This branch of PHP was written specifically to increase performance and decrease memory usage. Also included were improvements to the underlying Zend engine, which has been powering PHP since 1999 and version 4 of the language.

I don’t want to get deep in the weeds about what’s different in PHP 7, but let me mention a couple of things, asynchronous programming and a just-in-time compiler. The former is part of PHP 7 and the latter is planned for PHP 8.

Asynchronous Programming

In synchronous programming, code is executed one statement at a time. The next statement can’t run until the current statement has finished executing. Not a big deal when everything runs very fast, but when something might take a little time to complete, everything else has to wait.

In asynchronous programming, code statements can start to run before other statements have completed. While one piece of code is waiting on database results, another piece of code can make a calculation. Since statements don’t have to wait as long to start execution, the overall time to run the code is reduced.

Just in Time (JIT) Compiler

The just-in-time (JIT) compiler or just-in-time engine is in an experimental branch of PHP, but it’s expected to arrive for good in PHP 8. To understand why it’s a big deal you have to first know how the Zend Engine currently works.

The engine parses PHP code and converts in into an abstract syntax tree (AST). This is translated into something called opcodes, which are execution units for the Zend Virtual Machine. The opcodes are low level in that they’re closer to the machine code the hardware understands as opposed to the higher level abstraction of PHP that’s easier for us to read and work with.

When the same code is needed again, instead of converting from high level to low level, a cached version of the opcodes can be used instead. The process was optimized in PHP 7.1, which increased the overall performance. When I talked about OPcache a couple of weeks ago, it’s the opcodes that are cached.

A just-in-time compiler compiles the opcodes instead of interpreting them. They’re compiled directly into machine code so there’s no need to go through all the interpretation and conversion when an application runs. When the code is needed the Zend Engine will grab the compiled object instead of the interpreted opcode, which is a much quicker and more efficient process.

Again, the JIT compiler is expected in version 8 of PHP. I mention it because many of the changes in PHP 7 involve changes like optimizing data structures such as zvals (Zend’s representation of a PHP variable) in preparation for migrating to the just-in-time compiler in the next major version.

Not Backwards Compatible

PHP 7 is not backwards compatible so you do need to check and make sure your code will continue to work, though in all likelihood it should. If you run WordPress or another content management system, you shouldn’t have issues with the core of the system.

Older plugins and modules that haven’t been updated in awhile are where you’ll probably encounter issues if you have any. I didn’t when I upgraded, but that doesn’t mean that will hold true for all sites. It’s a good idea to test first or at least have an easy way to revert back if something goes wrong.

If you do run WordPress you can give the PHP Compatibility Checker plugin from WP Engine a try to see if your site is compatible with PHP 7 or what issues you’ll need to correct before it is.

There are certainly other improvements to PHP 7.x, but I won’t list them all here since others are better able to tell you about them and explain what they mean. Instead I’ll provide a few resources if you want to know more details.


In the Kinsta results I listed earlier, you might have noticed that the benchmark for HHVM was pretty much the same as the benchmark for PHP 7.2. So which one should you use?

HHVM is developed by Facebook and it’s main advantage has been its just-in-time compiler. Prior to PHP 7, HHVM was a better option and it still is a good option, but the benefits aren’t so great over PHP 7 as they were over PHP 5 and I’m not sure what value it will have once PHP 8 has its own just-in-time compiler.

Some testing suggests HHVM is still faster than PHP 7, but I think you’re better option at this point is to stick with the latest version of PHP, especially as it may already be faster than HHVM.

Closing Thoughts

Whatever server side language you use on your site, it’s generally a good idea to keep it updated and that’s especially true right now with PHP. If you aren’t yet running PHP 7.x, you probably should. It’s much faster than PHP 5.2 or 5.6, which is what many hosting companies still provide as defaults.

PHP 7 runs up to twice as fast and can see significant improvements in memory consumption. Do make sure your code will run after an upgrade as PHP 7 isn’t backward compatible in all things, but assuming you won’t have issues, you’ll be happy you upgraded.

A few times in all this talk about PHP I mentioned your database as the likely bottleneck and that’s where I want to turn next in this series, to SQL and more specifically MySQL databases. First though, I want to spend a couple of weeks talking about creativity and productivity. I’ll be back with the MySQL database part of this performance series later in the summer.

« »

Download a free sample from my book, Design Fundamentals.

Leave a Reply

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