 So, my talk is a little bit more on the technical side, and at USA Today, we have grown from just having one site on WordPress to having over 80 sites on WordPress over the course of the past five years, and through that process and growing our traffic to over 50 million monthly weeks, we picked up on a lot of things and so I'm going to try to pass those off to you. But before I dive into the things that you can implement today, I just want to go over general and things that I think about when talking about things like scalability and site speed. So, the first thing, obviously, speed versus scalability. A lot of people think that these are very different, and I kind of like to think of this as them being almost intertwined with each other. The reason being is if your site's faster, and you're maybe voting less resources on each page load, then you're automatically going to be scaling your site. You can run your site on a smaller server and have more traffic without having to upgrade and go to the next pricing plan. This is a tool that I always mention, at least in most of my talks, a web page test. Basically, you can put any website into this and get an overview of what is being loaded on your website and what might be causing your site to slow down. So, definitely, if you've never jumped on this, I definitely suggest running your site through it at least one time. So, jumping back to scalability, the real thing I just try to think about is traffic spikes, because that's when you're going to have issues most of the time. You know, you're testing things, hopefully, and you're running through simulations, and then you get a lot of traffic all of a sudden, and something goes wrong, and you're thinking, okay, yeah, maybe I just need to upgrade to the next plan, but the way I like to look at it is that if your site has a single point of failure, then everything's going to go down, right? So, testing everything as a whole is one way of scaling up your sites, but you also need to test each individual feature individually as well. Another thing I kind of like to think about is backend versus front-end. You know, backend, WordPress is built on PHP for the most part, so a lot of that is running on your server, right? This is going to cause, you know, if too much is running on that side, on each page load, then obviously your server could go down, or, you know, there's a whole slew of other issues, but that's why a lot of people are moving to doing a lot more things in JavaScript on the front-end. This is running on your computer locally, so that way it's not affecting your server at all. So, just, these are kind of the three categories I like to approach when talking about building up your network of sites and making sure you're ready to handle a lot of traffic. First is focusing on speed, making sure your base is good. Second is best practices. And then the third is finding the right tool set to make sure you're either testing everything properly or using the proper frameworks for making sure everything's running smoothly. So, to jump into speed optimizations, the first thing that everybody should be doing here is caching their sites. And W3C total cache plugin was the one I used to use, but I know there's a lot of great ones out there. They all essentially do the same thing, but there's several versions or several things that it will do. You can implement browser caching, so that way your site, well, if you already downloaded CSS file, you don't need to download it a second time. And you can break that with simply adding a little version number to the end of your URL, right? So that way your browser knows, hey, there's a new version. So you only download the new file when changes have been made. Page caching is another very obvious one. Instead of running, going through all your PHP code and then processing all that data on every page load, you can just save the output of the whole page. And quite often, just this all by itself will make your sites extremely scalable. And then there's this awesome thing called WPQuery. I'm sure everybody is familiar with this. Your home page is probably running this right now. You're loading the most recent articles. You can actually cache everything that's happening in WPQuery, so that way you don't have to run this on every single page load. Another smart thing to do is to minify your images. There's plugins out there for this. I know everybody talks about the Smoshit plugin, but essentially whenever you upload a photo to your website, it automatically minifies it. And then you can do it by hand with other tools like Image Optum and PNG Gauntlet. Using a CDN is another smart thing to look into. I know Jetpack has a really cool one for images. And essentially what a CDN does is it takes your things like your media files and distributes them across servers around the world. So that way if I'm in China, for instance, I'll go to the China server and download images from there. And that way it's less load on my own server. And quite often in Jetpack's case, for instance, it's free. If you have not heard about PHP 7, you should probably upgrade to PHP 7. It's much faster. Again, I mean, it's an automatic win. So I suggest doing that. Oh, and if you have a plugin that does not support PHP 7 or a theme that doesn't support it, probably not going to want to be on that theme or plugin for... They should be on that by now. Getting your site encrypted when on HTTPS and that's where you see that little green lock at the top part of your site. That allows you to activate HTTP2 which allows you to load several resources at the same time. And if you guys remember that web page test image, before you only used to be able to load maybe eight things at once, but now you can load an infinite amount of things at the same time. So automatically making your sites faster and more secure. So that's kind of setting your baseline, right? And then here's some best practices that we've implemented on our team at USA Today that have enabled us to have not only less bugs, but also put out code that is more performant. Not using heavy plugins. So again, we have 80 sites. I mean, sometimes somebody wants to just activate a plugin on a single site. So when somebody says, hey, this plugin solves all my problems, I think the best default response to that is what is the problem that you're trying to solve? And if this plugin maybe only 5% of its code base is solving the problem, maybe you could either build it yourself or only take out the pieces that you need instead. And quite often you'll find that after you bring it on, you'll be spending more time debugging and fixing issues instead of building more themes for your platform. Same thing goes for themes, right? Quite often, I've seen themes that will load 10, 15, 20 CSS files. And you can easily go to web page test, activate and deactivate your theme and see what's happening and get a good feel for what's working well, what isn't. Code review was a big upgrade for us ever since we started... No code goes out unless it's reviewed by somebody else. Really important as you grow a team. I know a lot of people when they're first starting off, they're saying, oh, everything I'm writing is fine, but the junior dev on our team's not doing so great, and they're saying, well, the first thing I'm saying is, well, do you guys review each other's code, right? It goes both ways. He should be reviewing your code so he can learn, so he can learn, and you should be reviewing his code so you can actually say, hey, everything we pushed out was together. Oh, and this is a link to the VIP standards that we use on our team. Testing, obviously very important. People forget that it's not just testing things locally or setting up Wordpress locally, but you can have a QA environment and then also staging, which is replicating a production as closely as possible. So usually, for us, we have all three of these environments. Before it even goes to production, and we test in all three. Monitoring. So that web page test tool that I showed you guys, they actually have an API so you can hit your website over and over and over again. You can easily put that on a graph and see if there's any spikes in page load for some reason. That's probably going to give you a good indication that something's wrong. Obviously, you should be monitoring your server load, and most hosting services come with that feature built in. And then another one that's been interesting for our team is options. We will actually take all of our options and put it in a single table. That way we can see the options for all 80 of our sites on one page. And this was a big deal for us because now we can see, hey, nobody's using this option anymore. So that, just getting the team in sync with that kind of mindset was what really allowed us to start making sure that we didn't have issues on production. And as we started getting better and faster to maintain that standard as well. So here's five tools that I thought that have been really interesting to me that stood out for scaling our sites. Jetpack, like I mentioned before, built by WordPress.com. A lot of amazing features, just activating that if you have nothing else is going to be a huge win for you. Elasticsearch is a very interesting side topic. It's something to think about. Most people don't need to do this, but if your site has heavy search queries, for instance, we have a site called USA Today's, a high school sports. And we have, I mean, it's like, I think it's several hundred thousands of articles to go through. So this essentially puts the search results on a separate server, and it's actually built in Java, and it returns results much quicker. Loader.io is a pretty interesting tool. You can stress test your web apps and APIs with thousands of concurrent users. So before, let's say you're expecting a big spike of traffic, this is a great way to start testing things out. And then another one that's been really interesting is Siege. Stress testing a single URL with a defined number of simulated users. So again, like I was mentioning before, with the single point of failure, sometimes you think, okay, I'll just put a bunch of traffic to this web page. But also, let's say you have a login system, right? That's built by hand. You might want to stress test that all by itself, because if that goes down, then everything else is gonna go down, right? Another thing that's a hot topic right now is serverless. This is not a WordPress thing, but maybe it could be one day. It's essentially not having to think about your server going down. Essentially, you can write your own code, put it up on... There's a lot of services that have this now, but Google and Amazon are the top competitors in the field right now, and you just put your code up there and say, hey, I'm running this on PHP, and then it'll spin up as many servers as you need or spin them down as needed and it'll only run when you call it. And then the bonus points, load balancing, and this is like... I think once you get through everything else, once you have the best practices in place, then you can start thinking about things like load balancing, and that's basically where you pass everything to a load balancer, and if you get so much traffic, you need to spin up a new server and then split the users between the two servers. Honestly, that's a great problem to have. So at that point, you can probably bring somebody in who knows what they're doing. So that is it for me, and thank you very much. Any questions in the front? The question is, how did you approach onboarding for your editor so getting these non-technical users comfortable with the new experience? It's actually been a really rewarding experience because the majority of ones that we've worked with have seen or heard of WordPress before, and they're so used to in the antiquated system like nothing works as it should, things are labeled really weird over since 1998, so it's like 1998. So it's been a really good experience just because I think WordPress is so ubiquitous that even if maybe these legacy senior editors aren't 100% familiar with it, someone in their newsroom or someone in their circle can say, oh, yeah, I've worked in WordPress before. I can show you how to log in. And then in that same token, the documentation on just using and logging into WordPress and using the editor and using the pages is so good that we didn't have to go back and reinvent the wheel to do it. We just said, hey, WordPress is becoming a global standard. It's something that people tend to just already know how to use, so it's great. Not in the back, right? Also for Tyson, so for audience, users browsing sites for the legacy system and then they transition to the new special project site, are you creating an experience that highlights the fact that they're transitioning to a new site? Are you trying to have a consistent look and feel so that they just regard the special project site as a part of that property? We're really trying to highlight the fact that they're changing. So one of the really nice features of our legacy CMS is that we can do a URL override on any story file that's in the system. So it'll appear on the traditional website like any other story, but when you click that link, you'll get a new tab, and it'll be the special projects environment. But we don't wrap it in the same header. We don't add the same footer. We want to make it look like a really special digital project. And then we really encourage sites to link to media so that people realize like, okay, this is a really big deal. And we had the same kind of question when we were launching the ads platform, right? Like most of our sponsored content has a sponsored label, but then in the end looks like a regular article. But advertisers said like, no, we want people to think like, wow, this is a really nicely designed ad. This is a really good experience. The association with what the website normally looks like, we have found that people want to sort of shed it and they like seeing something that's special and unique. You mentioned earlier, it's really important to review code for everyone. And I want to highlight and extend upon that. One of the tools we found incredibly helpful is our limping tools. So PHP CS and ES lint. It forces everyone to use a consistent style. You pick which one you want and then that happens. And then you spend time in the code of view discussing important things and concepts. And you don't have to spend the time highlighting punctuation, spacing, variable naming and so on, because your lint is already enforcing that. And these tools not only can they tell you when you've done something wrong, but they can also fix many of the common errors automatically, which is a kind of thing machines are great for and humans are lousy at. So I highly recommend if you're not using PHP CS or ES lint, that you take a look at them today or when you get back to work on Monday. Yeah, awesome. That's a great point. And also we do the same thing and we have this, we integrate it into GitHub too, which is pretty cool. And then it just like shows little X or a little green checkbox, right? So that way you don't like what you were saying. You don't have to worry about pointing out spacing issues or variable name issues, that kind of stuff. Awesome. Any other questions? Thank you, David. Thank you, Tyson. Thank you.