Heya, I'm Carl! I'm the solo founder of Ymir. Ymir is an open startup. You can view its up-to-date business metrics, and also sign up for a newsletter where you can learn how I'm building and marketing it. Check it out.
I gave a talk on serverless PHP at LonghornPHP 2022. This is the companion article I wrote for it. If you’re just looking for the slides, click here.
For PHP developers, servers occupy a weird space in our lives. We can’t work without them. But, for most of us, managing them is something that we’d rather avoid. Instead, we’re happy to pay for hosting companies to take the pain away.
But hosting companies don’t remove all your hosting headaches. If you’re managing a server yourself (or with the help of a tool like Laravel Forge or SpinupWP), you’re still on the hook if something happens and you still have to maintain them. (Ubuntu LTS still has a end of life! 😅)
And even with Platform-as-a-Service (PaaS), you’re not completely off the hook. You have to worry about scaling. This often leaves you overpaying for hosting because you have to be on a plan that can handle the worst-case scenario.
These are some problems that serverless PHP addresses. With serverless PHP, you pay for what you use. If your PHP application isn’t receiving any traffic, you’re not paying to keep a server online. But, at the same time, you get an infrastructure that can scale to handle thousands of requests within a minute.
But part of it is just not knowing what serverless is good at. Serverless is the best technology for scaling an application and doing so quickly. That’s why it’s an amazing technology for hosting e-commerce WordPress sites using WooCommerce or Easy Digital Downloads (EDD). I’ve written about WooCommerce before, but the entire article also applies to EDD as well.
That said, a lot of people know and use EDD for a specific use case: software licensing. Their software licensing extension is very popular with paid plugin authors. It saves them the time and energy to develop their own licensing system. (A complex endeavour for anyone!)
While a licensing server isn’t an e-commerce site per se, it still suffers from similar issues as an e-commerce site. That’s why serverless is also a perfect technological solution for anyone self-hosting their own EDD licensing server.
Serverless PHP is a new exciting technology that has the potential to remove a lot of the burden of hosting PHP applications. One type of application that has the most to gain from serverless PHP is WordPress. Serverless PHP eases the burden of scaling WordPress while offering the same performance benefits that you’d get with a top tier host.
To understand how serverless PHP works with WordPress, we’ll look at the current state of the modern WordPress server architecture. This architecture has evolved a lot over the last decade. (You can read more about it here.) Gone are the days of just hosting a WordPress site with an Apache server! There’s a lot more to hosting a WordPress site now.
The good news is that hosting a serverless WordPress site looks a lot like it does with a modern WordPress server stack. The big change is that you’re going to replace a lot of the architecture components with services from a cloud provider.
Now, the services that you’ll use and how they fit together will vary from one cloud provider to another. With serverless PHP, the most popular cloud provider is AWS. That’s why we’ll focus on serverless WordPress architecture on AWS.
It’s also worth noting that this is the same architecture that you’d get using Ymir. The only difference is that Ymir takes care of managing it all for you. (That’s also why it’s a DevOps platform.) But if you don’t mind putting all the pieces together yourself or with the help of another tool (such as the serverless framework), this article will help you achieve that.
That said, if you’ve ever had to deal with getting a good page speed insight score for a client, you know page caching is just one of part of the equation! There are other things necessary to optimize the performance of a WordPress site. One of them is image optimization.
Page speed insight expects you to have optimized images. As an example, this can mean converting gifs to pngs if they’re not animated. But, in most cases, it means converting images to the webp image format.
There’s currently talk of adding webp conversion to WordPress. But until that day, most of us install plugins that optimize images for us. That said, a lot of these plugins rely on (or try to upsell you) an image CDN to perform image optimization.
An image CDN is generally a better way to optimize images. They can do it seamlessly and require little to no integration with WordPress. For example, Bunny CDN has an optimizer product that’ll do image optimization on the fly for you. No plugin needed.
Now, CloudFront doesn’t have an image optimizer product like Bunny CDN does. Ymir can configure one for you. But if you’re not using Ymir, you’re not without options either. It’s actually quite simple to create a simple image optimization CDN with CloudFront using a Lambda@Edge function.
One of the most common things you’ll see as a web developer, especially in the WordPress space, is a variation of this statement:
Don’t pay $X/month on hosting when you could pay $5/month for a small server with Y and run WordPress yourself.
There’s also a serverless variation of this statement, which sounds like this:
Don’t pay a fortune for Lambda when you could get a server cheaper with Y or even EC2.
Now, sometimes you’re forced to think that way because of your clients or boss. They don’t feel that paying $30/month for hosting is worth it. Or they hear you can just pay $5/month for a server and want you to do that.
That said, this isn’t the conversation I want to have today. The one I want to have is with people who genuinely believe that it’s better you become an amateur system administrator than to pay someone else to do it. The reality is the cost calculation around that is completely flawed and out of touch with reality.
Previously, we looked at WordPress page caching using a content delivery network (CDN). This is an essential tool for speeding up a WordPress site at a global scale. That said, it’s still not commonly used by a lot of WordPress hosts.
With Ymir, you get a CloudFront (Amazon’s CDN) distribution set up to do page caching on production environments by default. This is a great feature of the product. But what if you want to configure CloudFront to do page caching yourself?
Well, this isn’t talked a lot about. In my research, the only article I found was this one on an AWS blog. This article will use that article as a baseline, but will discuss in more detail how to set up CloudFront.
We all know how important it is to have a fast WordPress site. If your site is slow, people leave or don’t make a purchase. It’s also a signal Google uses to do its ranking.
To make our WordPress site fast, we use different tools for different parts of the server stack. We have an object cache to speed up our MySQL queries. And then we have a HTTP cache to speed up how fast we return HTML back to the browser. You can see a diagram of how those different pieces work together below. (You can also read more about it here.)
You might have never heard of a HTTP cache, but you probably heard of the category of plugins that act as a HTTP cache. They’re called page caching plugins. Most WordPress sites use one or if they don’t, it’s because their host handles the HTTP caching. (Most of the time using Varnish.)
Now, you can also add a content delivery network (CDN) to the mix. If you’re not familiar with what a CDN is, it’s a service that lets you cache content in data centers across the globe. This allows you to serve cached content even faster because the CDN will serve it from the data center closest to the person making the request.
Now, a lot of page caching plugins support CDNs. But they only do so for media files such as CSS, JS, images and video. The HTML content that the page caching plugin generates still gets served from the server where your WordPress site is located. This means that, even with page caching, your site can still be slow for someone who isn’t close to where that server is.
This is, in essence, why you should use a CDN to do page caching. So why aren’t more plugins helping you do it? Let’s look at why that is and current solutions surrounding this problem.
In the last few years, two new terms have emerged in the WordPress and larger web development space. Those two terms are headless and serverless. On top of both being terms ending in “-less”, they’re two terms that aren’t very self-explanatory. (Are there still servers with serverless? Yes. Is headless some new horror movie category!? Nope!)
But to make things worse, because you often use these two new development paradigms together, people use the two terms interchangeably or think they’re the same thing. But they’re not! This increases the confusion and suspicion around both paradigms.
So with that in mind, this article will walk you through both concepts. This should hopefully clear some of the confusion. But we’ll also see how both paradigms are changing the WordPress development landscape. Let’s go!
When it comes to describing what Ymir is, WordPress serverless DevOps platform is the best way I’ve found to describe it. That said, it does feel like I’m playing buzzword bingo whenever I say it. While DevOps is a better understood term now, this isn’t the case with serverless.
The first thing someone thinks about when they hear serverless is, “Oh, there’s no more server. How does it work then?” This is a completely legitimate question! It’s also why a lot of us just think it’s a terrible marketing term. It feels like someone is trying to sell you snake oil.
But this is the term we got, and it’s not going to go away. So we might as well learn what it really means! Is it all marketing hype or are there some really exciting things about it? And most importantly, how does it change how you host a WordPress site.
Now, this article will focus on the impact of these serverless breakthroughs for running PHP on AWS Lambda. I can’t speak for other programming languages. That said, some things we’ll go over should apply to them as well.