A(nother) new era of WordPress

The other night at WordPress Sydney, I dropped a five minute brain-dump about some cool things going on in the web ecosystem that herald a new era of WordPress. That’s a decent enough excuse to blog for the first time in two years, right?

I became a WordPress user 9 years ago, not long after the impressive 2.0 release. I was a happy pybloxsom user, but WordPress 2.0 hit a sweet spot of convenience, ease of use, and compelling features. It was impossible to ignore: I signed up for Linode just so I could use WordPress. You’re reading the same blog on (almost) the same Linode, 9 years later!

WordPress 2.0


Fast forward to 2015 and WordPress powers 20% of the web. It’s still here because it is a great product.

It’s a great product because it’s built by a vibrant, diverse Open Source community with a fantastic core team, that cares deeply about user experience, that mentors and empowers new contributors (and grooms or cajoles them to become leaders), and isn’t afraid of the ever-changing web.

Another reason for the long term success of WordPress is that it’s built on the unkillable cockroach of the world wide web: PHP.

I won’t expound on the deficiencies of PHP in this post. Suffice to say that WordPress has thrived on PHP’s ubiquity and ease of adoption, while suffering its mediocrity and recent (albeit now firmly interrupted) stagnation.


The HipHop Virtual Machine is Facebook’s high performance PHP runtime. They started work on an alternative because PHP is… wait for it… not very efficient.

Unless you’ve goofed something up, the slowest part of your PHP-based application should be PHP itself. Other parts of your stack may exhibit scaling problems that affect response times, but in terms of raw performance, PHP is the piggy in the middle of your web server and data stores.

“But like I said, performance isn’t everything.” — Andi Gutmans

What is the practical implication of “performance isn’t everything”? Slow response times, unhappy users, more servers, increased power utilisation, climate change, and death.

Facebook’s project was released in 2010 as the HipHop compiler, which transpiled PHP code into C++ code, which was then compiled into a gigantic monolithic binary, HTTP server included.

In early 2013, HipHop was superseded by HHVM, a jitting virtual machine. It still seemed pretty weird and awkward on the surface, but by late 2013 the HHVM developers added support for FastCGI.

So today, deployment of HHVM looks and feels familiar to anyone who has used php-fpm.

Want to strap a rocket to your WordPress platform? I strongly recommend experimenting with HHVM, if not putting it into production… like, say, Wikipedia.


Not content with nuking PHP runtime stagnation, the HHVM developers decided to throw some dynamite in the pants of PHP language stagnation by announcing their new Hack language. It’s a bunch of incremental improvements to PHP, bringing modern features to the language in a familiar way.

Imagine you could get in a DeLorean, go back to 2005, and take care of PHP development properly. You’d end up with something like Hack.

Hack brings performance opportunities to the table that the current PHP language alone could not. You’ve heard all those JavaScript hipsters (hi!) extolling the virtues of asynchronous programming, right? Hack can do that, without what some describe as “callback hell”.

Asynchronous programming means you can do things while you wait. Such as… turning database rows into HTML while more database rows are coming down the wire. Which is pretty much what WordPress does. Among other things.

Based on the WordPress team’s conservative approach to PHP dependency updates, it’s unlikely we’ll see WordPress using Hack any time soon. But it has let the PHP community (and particularly Zend) taste the chill wind of irrelevance, so PHP is moving again.


Much closer to WordPress itself, the big change on the horizon is WP-API, which turns your favourite publishing platform into a complete and easy-to-use publishing API.

If you’re not familiar with APIs, think about it this way: If you cut off all the user interface bits of WordPress, but kept all the commands for managing your data, and then made them really easy to use from other applications or web sites, you’d have a WordPress API.

But what’s the point of stripping off all the user interface bits of WordPress? Aren’t they the famously good bits? Well, yes. But you could make even better ones built on top of the API!

Today, there’s a huge amount of PHP code in WordPress dedicated to making the admin user interface so damn good. There’s also a lot of JavaScript code involved, making it nice and interactive in your browser.

With WP-API, you could get rid of all that PHP code, do less work on the server, and build the entire admin user interface in the browser with JavaScript. That might sound strange, but it’s how most modern web applications are built today. WordPress can adapt… again!

One of the things I love about WordPress is that you can make it look like anything you wish. Most of the sites I’ve worked on don’t look anything like traditional blogs. WP-API kicks that up a notch.

If you’ve ever built a theme, you’ll know about “the loop”. It’s the way WordPress exposes data to themes, in the form of a PHP API, and lots of themers find it frustrating. Instead of WordPress saying, “here are the posts you wanted, do what you like”, it makes you work within the loop API, which drip-feeds posts to you one at a time.

WP-API completely inverts that. You ask WordPress for the data you want — say, the first ten posts in May — then what you do with it, and how, is 100% up to you.

There’s way more potential for a WordPress API, though. A fully-featured mobile client, integration with legacy publishing systems at your newspaper, custom posting interfaces for specific kinds of users, etc., etc., etc.

The best bit is that WP-API is going to be part of WordPress. It’s a matter of “when”, not “if”, and core WordPress features are being built today with the WP-API merge in mind.


According to its creators, “React is a JavaScript library for building user interfaces”, but it’s way cooler than that. If you’re building complex, interactive interfaces (like, say, the admin back-end of a publishing platform), the React way of thinking is fireworks by the megaton.

For all the hype it enjoys today, Facebook launched React in 2013 to immense wailing and gnashing of teeth. It mixed HTML (presentation) and JavaScript (logic) in a way that reminded developers of the bad old days of PHP. They couldn’t see past it. Some still can’t. But that was always a facile distraction from the key ideas that inspired React.

The guts beneath most user interfaces, on the web or desktop, look like a mad scientist’s chemistry lab. Glass everywhere, weird stuff bubbling over a Bunsen burner at one end, an indecipherable, interdependent maze of piping, and dangerous chemical reactions… you’d probably lose a hand if you moved anything.

React is a champagne pyramid compared to the mad chemistry lab of traditional events and data-binding.

It stresses a one-way flow: Data goes in one end, user interface comes out the other. Data is transformed into interface definitions by components that represent logical chunks of your application, such as a tool bar, notification, or comment form.

Want to make a change? Instead of manipulating a specific part of the user interface, just change the data. The whole user interface will be rebuilt — sounds crazy, right? — but only the changes will be rendered.

The one-way data flow through logical components makes React-based code easy to read, easy to reason about, and cranks your web interface to Ludicrous Speed.

Other libraries and frameworks are already borrowing ideas, but based on adoption to date, number of related projects, and quality of maintenance, I reckon React itself will stick around too.

Connecting the Dots

It won’t happen overnight, but WP-API will dramatically reduce the amount of active PHP code in WordPress, starting with the admin back-end. It will become a JavaScript app that talks to the WP-API sooner than anyone suspects.

Front-end (read: theme) development will change at a slower pace, because rendering HTML on the server side is still the right thing to do for performance and search. But themers will have the option to ditch the traditional loop for an internal, non-remoting version of the WP-API.

There’ll be some mostly-dead code maintained for backwards compatibility (because that’s how the dev team rolls), but on the whole, the PHP side of WordPress will be a lean, mean, API-hosting machine.

Which means there’s going to be even more JavaScript involved. Reckon that’s going to be built the same way as today? Nuh-uh. One taste of React in front of WP-API, and I reckon the jQuery and Backbone era will be finished.

In WordPress itself, most of this will affect how the admin back-end is built, but we’ll also see some great WordPress-as-application examples in the near future. Think Parse-style app development, but with WordPress as the Open Source, self-hosted, user-controlled API services layer behind the scenes.

What about HHVM? You’re going to want your lean, mean, API-hosting machine to run fast and, in some cases, scale big. Unless the PHP team surprises everyone by embracing the JVM, I reckon the future looks more like HHVM than FPM (even with touted PHP 7 performance improvements).

Once HHVM is popular enough, having side-by-side PHP and Hack implementations of  core WordPress data grinding functions will begin to look attractive. If you’ve got MySQL on one side, a JSON consumer on the other, and asynchronous I/O available in between, you may as well do it efficiently. (Maybe PHP will adopt async/await. See you in 2020?)


Look, what I’m trying to say is that it’s a pretty good time to be caught up in the world of WordPress, isn’t it? 🙂

Champagne Pyramid

This entry was posted in General and tagged , , , , , , , . Bookmark the permalink.

23 Responses to A(nother) new era of WordPress

  1. Lamosty says:

    Nice writeup. You summarized almost everything I have been thinking about lately. I’m looking forward to the times when themes and plugins will be using Reactjs for front-end rendering and WP-API on the backend.

    On the other hand, there creators might be reluctant to use React for HTML components because users will probably not be able to modify the themes afterward, especially when using JSX to write React components. One solution is to have React support built in WordPress, but that is unlikely.

    As far as HHVM goes, it really pushes the loading times further down. However, you need to take the increased RAM usage into consideration as HHVM likes to use relatively lot of it (v. 3.5). Also restarting HHVM FastCGI service once in 24 hours is good as it tends to crash or behave strangely sometimes (just my observations, I might be doing something wrong).

    All in all, I think WordPress has a bright future ahead, hopefully gaining 50% of market share. For that to happen, we (developers) need to work hard and use the best technologies and standards for the job.

  2. While I can appreciate your enthusiasm,

    Other parts of your stack may exhibit scaling problems that affect response times, but in terms of raw performance, PHP is the piggy in the middle of your web server and data stores.

    is not true, and you didn’t provide any sources for it. Unless you’re running at the scale of Facebook, Wikipedia, or WordPress.com, you’ll be seeing performance issues at the database access level much sooner than the PHP level. Throw in things like the now-integrated OPcache and recent optimizations in new versions, and your PHP-based application can scale both vertically and horizontally.

    For the *vast* majority of users, vanilla PHP is more than enough.

    while suffering its mediocrity and recent (albeit now firmly interrupted) stagnation.

    PHP 5.3 was released in 2009 [0], almost 6 years ago. Ever since then I feel that PHP has made leaps and bounds at a fairly quick pace. The introduction of HipHop (now HHVM and Hack) have sped up this process considerably, but I do not think it is accurate to describe the last 6 years as stagnation.

    Developers should use HHVM/Hack because they’re great tools, or they want to see what all the fuss is about. Simply suggesting that jumping to HHVM will introduce noticeably speed gains is FUD, when, again, most speed gains will be introduced by SQL query optimization and introduction of a true cache system.

    While I think WordPress serves its purpose, have you considered that many of the speed problems you might be seeing are brought on by its core developers’ refusal to drop support for PHP 5.2, thereby severely limiting themselves to what they can actually do to optimize WordPress?

    [0] http://php.net/ChangeLog-5.php#5.3.0

    • Jeff Waugh says:

      My comment on relative performance is unsourced because it’s experiential and, frankly, obvious: If you’re spending more time during each request doing database work rather than PHP work, then you’ve got a problem that needs to be fixed. You’ve probably hit a database scalability limit, or tried to get the database to do something silly. (And hey, that’s easy to do with MySQL, which is fast primarily because it’s dumb.)

      Most of the large, healthy PHP-based sites I’ve worked on spend 5-20% of their average request time in the database. Which means PHP is chewing 80-95%. Which makes PHP the slow bit. Not because PHP is bad: That’s a pretty reasonable figure for platforms based on Ruby, Python, PHP, etc. (Less so for Java and .NET.)

      The conservative choice of PHP 5.2 as the minimum requirement for WordPress doesn’t stop performance sensitive sites using later versions of PHP, or HHVM, or Phalanger, or whatever floats their boat. Indeed, only 30% of WordPress installs use PHP 5.2. So, runtime features are not a problem for WordPress users.

      If you think the minimum requirement is “severely limiting” potential for optimisation, what are some relevant language and library features in subsequent versions that the WordPress team can’t use?

  3. Josiah Goff says:

    YES. I’ve been saying a lot of this stuff recently as well. I work at Jetty where we’re building an enterprise application on top of WP. When we discovered WP-API last summer, it completely changed our whole approach. Now most of the app is a hacked, hybrid wp-admin with WP-API/Backbone bits all over the place, but we have plans to move over to a completely custom JS dashboard once the API is solidified and rolled into core. These are indeed exciting times to be a WordPress developer.

    Anyway, great post. Thanks for sharing!

  4. Very nice perspective and I agree with you. It’s time for big improvements, we’ve seen online platforms get better and better this last few years in an exponential way.

    I really liked the WP-API which is something that will not only benefit common users, but also will be good for developers for WordPress integration with their apps and others if the API is open.

  5. Jeff Waugh says:

    And then, as if by magic, Zend publishes an experimental JIT for PHP

  6. Joshua Sandlin says:

    Ohhhh that is a sexy bit of thought. I hadn’t really considered the porting of something as established as WordPress over to one of the newer/alternate “PHP” implementations. My playing around with minimizing frontward facing PHP was somewhat nice; though this sounds even better.

    Can’t wait!

  7. PJ Brunet says:

    “Unless you’ve goofed something up, the slowest part of your PHP-based application should be PHP itself. Other parts of your stack may exhibit scaling problems that affect response times, but in terms of raw performance, PHP is the piggy in the middle of your web server and data stores.”

    I completely disagree. PHP is rarely the issue and I don’t know where people get this idea that PHP is slow. Unless you’re calculating the flight trajectory to Mars, the main bottleneck of WordPress is MySQL. I guarantee if you fill up you PHP application with microtimers, you’ll see PHP only needs milliseconds to do its job even without caching. If there’s anything slowing you down, you’re probably waiting for MySQL or Curl or some external application.

    • Jeff Waugh says:

      Please refer to this comment. Healthy sites do not spend the majority of their average request time doing database work.

      • PJ Brunet says:

        IMO that’s a huge generalization, but I do appreciate hearing about HHVM and Hack, which hasn’t been on my radar for a while. I’m tempted to try it. I’m looking forward to see some unbiased, real-world benchmarks. Possibly this is a game-changer for some people and I’ll be following the developments. Is saving a few milliseconds worth switching hosts? For some markets/applications that might make sense. I think adoption of this might be about the same as adoption of NginX, if the technology works as advertised. Also I think it’s good PR for Facebook if there’s no tricky backdoors hidden in the code 😉

  8. Hi there,

    Seems a good way to go.

    But… is there any plans to support PostgreSQL? Being WP ‘MySQL-only’ seems like a foolish dependency to have in such a big project.


    • Jeff Waugh says:

      I’m a big PostgreSQL fan myself, but I can’t see it being an option for production sites any time soon. The database abstraction layer in WordPress is very old, and very thin (which is not to say that it’s bad), and countless themes and plugins do raw MySQL queries. It’d be a spectacular uphill battle. 🙂

      • dimeo says:

        Based on your comment one would come to the conclusion that the performance matter you are talking in your article is actually not PHP related after-all but due to “The database abstraction layer in WordPress is very old … and countless themes and plugins do raw MySQL queries.”, as you have indeed pointed out.

        • Jeff Waugh says:

          That might be the case if much time were being spent in the database or wp-db.php, but no. The abstraction may be old, but it’s also very thin.

          It really surprises me how many people desperately want to refute the idea that PHP is inefficient. This is not new information! 🙂

  9. If you’re spending more time during each request doing database work rather than PHP work, then you’ve got a problem that needs to be fixed.

    How about running benchmarks before running your mouth? Kthx

    • Jeff Waugh says:

      My comments are based on extensive operational experience with WordPress (and other PHP platform) site performance, including benchmarking. Thanks.

      • PJ Brunet says:

        It depends on the app. I think you’re assuming the whole database is in memory and all the queries are cached in memory. For many blogs, that’s realistic. Other blogs and apps, that’s either unrealistic or cost-prohibitive. If by “healthy” you mean a funded startup throwing money at the database, I’m sure that’s real fast. Many of our web apps out here in the trenches, we’re not pouring the champagne yet 😉 We’re on Linodes sharing servers to save money. But back to WP–it should just be reading a few cached files off the disk most of the time, which should only take a few milliseconds. Sadly, that’s generally not the case. WordPress is a pile of spaghetti, relatively speaking, to my 2400 baud sensibilities. Some of my own PHP blog software runs in a few ms (just reading cache files off the disk) but I don’t have 1000s of contributors clogging up my code with bright ideas either. Anyway, we all have different perspectives. Obviously C is faster than PHP, we have always known that, and more complex applications will need more CPU time.

  10. If you think the minimum requirement is “severely limiting” potential for optimisation, what are some relevant language and library features in subsequent versions that the WordPress team can’t use?

    You mean besides OpCache, openssl_random_pseudo_bytes, and a lot of small optimizations in the PHP binary? A whole bunch.


    PHP 7 is also going to be a massively improved release by the end of this year.

    • Jeff Waugh says:

      Everything you’ve named [1] is a runtime improvement, not a language/library feature. I run WordPress on PHP 5.3 (Ubuntu 12.04) and 5.5 (Ubuntu 14.04), so I get to use most of those improvements while WordPress happily remains compatible with PHP 5.2.

      [1] except openssl_random_pseudo_bytes, the relevance of which is practically zero in this context

  11. Jeff Waugh says:

    For historical reference: A pretty good Hacker News discussion about this post.

  12. Jeff Waugh says:

    For anyone still trying to convince themselves that PHP is efficient and their database (or communications with it) is not, please read Asynchronous Python and Databases. It goes through all the important things you need to understand, while not offending you by talking about PHP. 😉

  13. mike says:

    I got a good crack up on all of the PHP isn’t efficient comments.

    I would like clarity on one subject, I keep hearing React and WordPress being thrown around together, but I haven’t yet seen anything official documenting that.

    Preparing to build a new team at my new job I’ve changed up a lot about the stack I’m introducing and the little workd I’ve done with react I enjoyed. Even though there isn’t any tangible need to emulate what the core team is doing. I find things are usually easier done the WordPress way, if not just for the amount of documentation and examples will be online. But Im also guilty of being a Backbone or at the very least Ampersandjs fan.

    I know wp.com went react, is wordpress itself going react in a known way?
    Also, out of curiosity, what do you got against Backbone other than data binding?

    • Jeff Waugh says:

      wp-calypso is the open source React-based admin interface built for WordPress.com and the new WordPress.com client applications. Integration with the broader WordPress project is under consideration.

      I don’t have anything against Backbone, but it doesn’t compare to React in terms of scope, potential, or developer usability.

Leave a Reply

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

Comments will be sent to the moderation queue.