 I'm going to talk about website performance, which is a difficult thing to talk about. Just a quick show of hands. How many people in the room would say I am a developer? All right, cool. And how many people in the room have at least dabbled in systems administration, like logging onto servers and configuring things? Okay, so we've got the right crowd. I'm glad to hear. Website performance is a difficult thing to talk about, because often, I don't know if you get this feeling, but I do. Sometimes you see a talk or you read a blog post, and it has the vibe of one of those kind of sketchy internet ads, the one weird trick to get great website performance, or, like, this guy's website got totally jacked, with the bulging veins. And I've all victimized this as much as anybody else, because I've entitled this also five must haves. But I prefaced it with real talk, because I think I'm going to talk mostly about performance from the server side, from the back end, that's my jam, that's what I've been doing professionally for more than a decade. And the great thing about it is that there's a lot of stuff that I can talk to you about and advise you strongly to do, because it's no longer really up for debate. This isn't going to be a talk about crazy experimental stuff, or things that are, like, way out on the cutting edge. This is going to be a talk that covers things that you really, really should be doing, and you might not get if you don't ask for them, but they're kind of no brainers, and everybody should be doing this stuff, because it can help every website. So I'm Josh, I'm Atlantis Josh, on the internet, on Twitter, on my blog, and I'm Josh at pantheon.io. Pantheon, of course, isn't a host, but it is a website management platform. Website management platform provides several metric tons of hosting, along with great cloud-based development tools. So we do, like, billions of pages a month. We run some really large websites. Thousands of developers use it daily. And the talk that I'm giving is based on my professional experience kind of seeing across this broad spectrum, and working with particular clients of ours solving their problems. It's something that I care about deeply, not just because site performance is super crucial to the user experience, and not just because site performance is super crucial to SEO, but also because site performance is crucial to me and my industry. As infrastructure providers, we have a responsibility to make things go fast and work efficiently. Data centers now consume 2% of all the power in the country. And the last studies indicated that the largest public clouds, which are supposed to be the most efficient, like Amazon EC2, are running at something like 7% to 10% efficiency. They use all the electricity either way, but only 7% to 10% of it is actually churning through CPU cycles. And if you think about a power-in-benefit-out ratio, that's like incandescent lighting levels of efficiency. It's just not going to scale. We have to do better than this. So it's in my interest for your sites to be performant, because when your sites are performant, you're using my infrastructure effectively and efficiently, and everybody wins. I also say really quickly that I've seen things you wouldn't believe, projects that were like so amazingly awesome, projects that were so amazingly, I don't know how they're working, but they are. And there's no shame in this game. I'm not, if any of this stuff is challenging for you, or you can't get to it, or you feel like there should be no shame, right? Because we're all learning this stuff together. And so this is not a talk in any way to disparage anyone, their current choices that they're making. It's just to present some options that I think are really right down the main line of what I think the whole internet is doing and what WordPress developers and site owners should be doing as well. So let us begin. A lot of times we think about our WordPress as a kind of a motor, right? It's the motor that makes your website go. And we're all familiar with the motor. You've got your theme belt there, and of course the login gasket. And then you've got your plug-in rotors so that you can rotor your plug-ins. And then if you're smart, you've also installed the emergency overdrive valve. That's a pretty key component. And this is one mental model for things. And if you really tune the motor, if you get it as good as it can possibly go, you can go pretty fast, right? A finely tuned car can go 125 miles per hour without shaking itself apart, which is pretty impressive. But sometimes that's not enough. Sometimes if you want to get much faster than that, you need to think about a completely different form of propulsion. Like if you want to escape the Earth's gravitational pull, you need to go 200 times faster than that. And it doesn't matter how much you tune your motor, it's never going to happen. You need to rock it, right? The only way you're going to get to 25,000 miles per hour is with solid booster fuel that's shooting you straight up in the air. And so the first piece of real talk I have to deliver is that the keys to breakthrough performance aren't inside of WordPress. There's no plug-in you can install. There's no weird line of code you can do. There's lots of stuff you can do to optimize, and there's lots of plugins that are smart and some that maybe aren't from a performance standpoint. But if you really want to get to internet-scale performance and really delight your users and really handle good amounts of traffic, you have to think outside the bubble of WordPress. And particularly, you have to examine the technologies that WordPress, the environment WordPress runs in, and the technologies above and below it in the stack. So you may have heard people talk about PHP 7 and how exciting that is. This is how exciting that is. And we're talking about a significant speed-up in terms of the CPU execution time. This is important, right? Everybody should be using the most modern version of PHP they can. Like, forget about the super-i-popping PHP 7 HHVM numbers from this, and this is from earlier this year, so it's probably gotten better since then. Just the difference between PHP 5.3 and 5.6 is a 25% speed-up. That's legitimate. That is a real performance benefit. And in the game of performance optimization engineering, if you can find one thing to change is it gives you a 20% bump, that's like high five. Let's go get a beer. That's a really good thing to be able to do. So you should be running, this is a must-have. You should run on the most recent version of PHP that is possible. And that means you need to think about maybe ditching some of that legacy code that doesn't want to run on the most recent version of PHP or thinking about getting into an environment that'll let you run on the most recent version of PHP. PHP 7 just came out last week, so not a lot of people support it yet, but it should be available, should be widely available early in the new year, and you should all be thinking about moving to it if you care about performance, which I hope all of you do since you're here. Real talk. It's caches all the way down, man. Every computing system of any complexity is riddled with caches because it's one of the only ways to make things performant. You've got to prevent repetitive, unnecessary busywork from being recomputed so you cache the results of your computations. And if you care about performance, you must care about caching. And there are many, many layers of caching to consider when you're talking about website performance, from the browser cache all the way back to caches that are in the database. And so I'm gonna talk about what I think are the three most important caches to be aware of. They're not the only ones to care about, but just caching in general gets savvy to it, and here are three that you really should be smart about. Number one is the opcode cache. The opcode cache is something inside of PHP. So PHP is a dynamically compiled language, and that's beautiful because it means you can change a line of code, hit reload, and boom, you see your change immediately. There's no compile step. You don't have to go through some other process to see the results of your development work. It's wonderful as a developer to have that. But what it means is you're actually under the hood asking PHP to go read every PHP file that is involved in bootstrapping the application, which in the case of WordPress is hundreds, sometimes thousands of files, parse through all of them, compile the result, bring it down to machine code, and then execute it. That's a lot of work. The opcode cache, and then that work gets thrown away at the end of the page cycle because PHP share nothing. It like forgets everything when the page cycle is done. The opcode cache holds the compiled result of all the PHP code in memory between page requests. And real talk, a vanilla WordPress homepage with one post actually compiles down to billions of CPU cycles to execute because we're working with pretty complex software. And so if you're not using opcache, you're wasting your life because you're making the CPU do that work over and over and over again whether anything has changed or not. And the opcache is becoming more and more, it's like enabled by default in PHP 7 now, but you still need to know about it because depending on whether it's tuned right, it might or might not be helping you. So the opcode cache is something to be aware of as a developer, make sure you're using it, make sure it's working properly, otherwise you're just wasting your life. A second cache that's very important is the object cache. As we all know WordPress stores its state, all of its persistent information in the database, which is awesome. And in the course of rendering a page request, it will query things from the database and build all these various objects so that it can fulfill the task of rendering the page. And it will actually hold onto those objects, much like PHP holds onto the compiled code for the duration of that page request. And at the end of that page request, it forgets everything. And on the next page request, it has to re-queer the database and reassemble all those objects. And you know what that is? It's busy work. WordPress is like it's the smartest thing in your stack because it's like dynamic and configurable plugins, themes, admin interfaces, all this stuff. But it's also the slowest. Because it has so many different things that it can do, it just can't do any one thing very quickly. And so the key to performance, thinking outside the WordPress bubble, is very often about finding dumber but faster systems that you can outsource some of the labor to. And a persistent object cache is an example of that. So if you can keep those objects between requests, you're gonna lessen the load on your database, you're gonna lessen the time that PHP has to execute to interpret those objects because they're already pre-compiled and you'll see much faster performance for logged in users or like generating lots of dynamic page requests. Cream number three, the page cache. And of course everyone knows that you need to have a page cache, right? And there's plugins that do this for you and they're pretty decent if that's your only option. You really don't wanna be regenerating every page from soup to nuts if you've just gotten onto Reddit or something and you've got 10,000 people clicking to see the same URL. You wanna find a way to say, they all wanna see the same HTML, I don't need to have WordPress go to a billion CPU cycles to figure out what the contents of that page is, I just need to be able to serve the same output over and over again really fast. And a page caching plugin can do this but it's doing that still within WordPress which while that's better than generating it from start to finish every time, you're still using the smartest and slowest piece of infrastructure in your stack to do this pretty menial job of just repetitively serving the same pages. And the good news for all of us is that this isn't a problem for WordPress, this is a problem that the internet has been dealing with for since the internet was around and there's a strong suite of technologies that use a really, really well understood and widely adopted method of communication called reverse proxy caching that can give you significantly better performance on page caching. So if you wanna look at varnish, you wanna look at NGINX, you wanna look at even Apache that can be set up as a reverse proxy cache. Modern CDNs like Cloudflare and Fastly can function in a reverse proxy fashion. And what this basically is, is using HTTP headers to outsource the repetitive, brain dead function of just spitting out the copies of the pages that people wanna see to another dumber but much faster, like 200 times faster subsystem. Your reverse proxy cache will literally saturate a network interface before it will break a sweat on the CPU side. So if you're not using reverse proxy cache, I would also say you are wasting your life. Finally, real talk. The database is the ultimate bottleneck. You can scale WordPress horizontally if you have a lot of traffic. You can set up multiple instances across different servers to keep lots of CPUs busy and load balance across that. But all of the one website's all gonna come back to talking to one database. And so database performance regressions when they occur can also be debilitating. If you deploy some code that's not super well optimized, like it maybe runs through an array a few too many times, you're probably talking about 20 milliseconds, half a tenth of a second performance hit at worst. But if you deploy something that makes a really hairy database query that's not optimized, you could see multi-second lag per page request. That's the type of stuff that will crash your website. It falls off a cliff. And so you have to be cautious about how you use your database, especially when you have a lot of content. But no matter what, you should be using the InnoDB storage engine and SSD-based disks. So that's like a modern version of MySQL and modern infrastructure for your database. Otherwise, you're just wasting your life. Like, you don't need to wait five minutes for a computer to boot up anymore because it has an SSD. The same speed-up benefits can apply to your database and they should. Because it's just like, it's a no-brainer. Like, there's just no reason not to do this stuff. And it's commonly available if you know to ask for it. So final real talk is contrary to all I've said about you don't do these things you're wasting your life, if you have hairy performance problems, throwing hardware at them will likely not provide a permanent solution. If your only problem is you need to serve like lots of cached pages, a reverse proxy will be probably a permanent solution. But if you know that you've got a site that's just not optimized and like you get a lot of traffic or you've got a lot of users or you have a lot of content and there's like these weird things that happen that bring the site down, you can throw hardware at it and sometimes that's your only option in the short term. But it's unlikely to solve the solution in the long run because throwing hardware at something is just sort of like kicking the can down the road to some extent. In order to scale, you have to have lots of hardware but if you're just concerned with performance, the hardware is a short-term solution and you need someone, this is must-have number five, you don't need to have an Einstein, you don't need to hire a core developer, although it's cool if you can, but you do need someone on your team who knows this stuff, who knows it from a code level and knows how the code interacts with the underlying systems to deliver the page results. Otherwise you're gonna kind of be wandering in the dark and if you're a developer, investing and learning about this stuff is a great investment in your future career. This never goes out of style. I guarantee you there will be people who will be asking for performance enhancements, performance audits, performance optimizations for decades to come because everyone cares about this and once you get into like interesting use cases like multiple logged in users or again, larger bases of content, the answer that the must-have still makes sense but the real answers are in understanding the use case and figuring out how these systems interact. So if you don't have a developer on your team who's into performance, find one or start to grow one by learning, if you are a developer interested in performance, it's a great time to learn. There's wonderful resources and tools out there on the internet. This is science, right? It's not magic. If you like take the time to understand how the computers are talking to each other, it does all make sense and it's kind of awesome when it does. Provides you with lots of dopamine bursts in your brain when you figure things out. And I mean, I think we all need it for the WordPress to continue to thrive and grow, especially as WordPress tackles more complex sites, bigger, high profile sites. This is gonna become more and more of a thing that's gonna be in demand. So they're finally real talk. This performance is not easy. It's actually hard. So the five must-haves are must-haves but they aren't necessarily gonna solve all your problems. They're kind of like best practices that everyone should follow but that's the beginning of your journey, probably not the end, if you have an ambitious or interesting use case. It takes constant improvement to be great. I didn't talk at all about front-end performance like rendering in the browser. That's the other half of the equation and it's like actually a much faster moving frontier with a lot of really cool things happening. But it's a lot of fun to work on and it's very important for you, for your clients, for your customers, for the internet at large and I thank you for listening to me and good luck to all of you.