 that are really, really helpful, right? There's that first one that I can't ever pronounce. I know it's cute to mix auto and optimize, but try and say that out loud. And don't say auto-optimize, because that would require two O's. Yeah, that thing. I can't say it, okay? I can rub my belly and my head at the same time, but I can't say that word. So, you should be able to spell it, look it up, try it. It has a whole bunch of features. And as we started playing with it and tuning it, we discovered this really does change performance on most of the stores that we have. Right? So, you go, okay, that could be very, very helpful. Async JavaScript. I told you earlier about JavaScript and the fact that you're pulling files down and then you're purchasing them, you're processing them. It takes a while to do all that, and you're like, well, do I want to do that? It's all asynchronous, but do I want to do it up front? Do I want to do it at the end? How do I want to play this out? I can't test it out, but that plugin is also really helpful. And then, one of my favorites and go-tos is a plugin called WP Disabled, which does a lot of work to making performance better by simply going in and saying, yes, please, take off all the appended strings to the URLs for the resources I'm pulling down. Or, yes, let's turn off some of the dashboard widgets or, yes, let's change the way we call Google Fonts. There's a whole litany of things that they do that help your store perform better. And you go, okay, just these three can end up... I've seen, personally, going from one store in one dynamic to another store, just these three plugins tweaking it can drop two to 10 seconds of performance depending on how bad the site started with. And you go, wow, okay, that's serious. So these are three that I say, just put on your list. It's in the part that's good because it's worth doing, but it's also not in the cheaper fast because for you to evaluate it means take a copy of your store, put it somewhere else, and then start testing out some of the different settings and run through performance tests. So it's going to take you a little bit of work. But once you get it locked in right, this can be very powerful for you in terms of performance. RAM is one of those confusing things when you start thinking about a store and performance because you're like, oh, I just need to give it a lot of RAM. The truth is, RAM is the first thing that will help your store get faster. Because remember we talked about all those calls to the database? The queries are back to a database, and those queries, if you're putting it all in RAM, it's like you're putting it all in localized, quick access location where I can get to the data faster. And so you're like, ooh, RAM is good. If I can have more RAM on my store than the size of my database, it means I can put that whole database in RAM and I can take everything faster. And that will help speed up your store. But I won't do all the work because at some point, that's going to have diminishing returns and now it's your CPUs. It's going to be how many CPUs are you able to process when you're talking about concurrent orders, concurrent traffic. A lot of people coming at the same time. So when you're talking about a high concurrency, high performance site, you're going to shift away from RAM eventually. You're going to move from RAM to CPUs and say, I really need to be thinking about CPUs. But initially, you're going to want to start with RAM. And so the quick rule of thumb is more RAM, rather than less, and more RAM than the size of your database. Are you good there? Make sense? Okay. Learn to leverage cache and bypass rules. If you can cache your whole site, your whole store, cache everything, and then once someone takes an item and puts it in the cart, which is the expressed intent that they plan to spend money with you, and then you say, ooh, now I'm going to drop cookie. I'm going to use that cookie to bypass the cache and I'm going to make it so that the customer now is experiencing a slightly slower version of the store. But it's so that it's dynamic, that their cart shows the right amount in it and they can check out and all that. The bypass rules, the cookie drop, and the non-cache site for them is worth it because all the rest of the people are still running on cache. They're just what one developer calls window shopping. They're just browsing around, so just make it super fast for them. So there is a lot of different cache, right? You talk about Redis, you talk about memcache, you talk about object cache. There's a lot of different ways to talk about cache. Varnish, if I didn't mention that. Some of those things actually make your store slower, not faster. Sometimes because the people configuring it don't know what they're doing. So my general tip is learn where cache is and learn how it works. And there are two resources here, both from hosting companies and either from ours. One is easyengine.io, the other is servebolt.com. And again, if you go look at the slides, you can see those URLs, but both will walk you through exact details of how to think about some of this stuff. It'll take some work, but it can make your store much, much faster. Does that make sense? I know there are a lot of plugins that do the abandoned cart emails. I know there are plugins that do the follow-up emails. I know there are plugins that do the bring inactive customers back to your store emails. I know there's a whole bunch of plugins that try to interact with your customers from your database in different ways. And there are plugins that you install that will on your server start doing scans of your database to find these segments, and then they'll generate emails on your server, and then they will formulate it and put it into calls that will send out those emails. Your store is no longer functioning as a store. Your store is now an email server. That's not a good thing. And it's definitely not a high-performing thing because the people who wrote that plugin that will go find which customers of yours haven't been active in the last three months and put them on a specialist so you can send them a promotion, those people were trying to solve the problem. How do I find these people and mail them? They were not trying to solve the performance problem. And they may not know enough to figure out the performance problem. And when they tested it on their local computers, they tested it with 100 orders, no concurrent traffic to their store locally, and they just went through and did it and said it works. What they were evaluating was does the query work, does the function work, does the email get sent? What they were not evaluating was is this going to perform well in your store environment? Just don't do it. There are alternative ways to go after all these things, but don't do it from your store. Which also gets me into reporting. If you care about speed, you going into the report section of your store, going into reports and then hitting, ooh, let me look at the most popular reports and then you get fancy, you're like, let me look at it for the last week, let me look at it for the last two weeks, let me look at it for the last quarter, let me look at it for the last six months, this is amazing, I'm getting so much awesome data, and someone else goes, hey, I don't know what's going on on our server, but customers can't even check out, they're all leaving. All those queries that you're running against the database, all of them are having a performance impact on your store for your customers. Don't do this. Maybe the biggest tip I can give you in terms of performance is keep your store focused. Your store should be doing cartwork, transaction work for customers. That's what it should be. And like when we build our products, we use Glue.io. Glue.io is a very fancy, happy you don't need this, and that's okay, right? But for your real stores, they tap in through the API new commerce, and every hour they pull data out, and it goes into a data center, and we have our own cluster in the data center, and all it does is segment all the data, all the time. It's constantly processing, but all that processing is happening in another data center with other servers that are not related to your store. So your store works just fine, we use Jilt for abandoned cart, same thing, right? Comes into the API, pulls data out, and then the Jilt servers are processing abandoned cart and sending emails and all that, but your store's not doing it. And then Algolia, right? For search, every time you want to pre-index all the data, people are doing a search on your site, they do a search, it's sub-second, it's 400 milliseconds, and they get back presented the stuff they want, but you're not using your store to do it, you're not using your store to index it, you're not going to respond to it. The queries aren't happening there, they're happening on Algolia's servers, right? The more you get off your server, the faster your store performs. Does that make sense? My name is Chris Thoma, I do work at the web, I'm a VP of products. And on Twitter at atchristhoma, you can find me at christhoma.com, you can find me at leaders.blog. Thank you very much. So we have a couple minutes for questions. The question was where are the slides? Slideshare.net slash C-F-L-E-M-A C is in Chris, F is in Frank, L-E-M is in Mary, A. Slideshare.net I'm operating the VP7, not like, depending on the level of updates you've done on your plugins, VP7 to like, plugins now. Yes, that's a great word. Anytime you update anything on your website, even in a staging environment where you can test it, because whether it's PHP7, or an ODB, or another plugin that's getting an update, it could break. Plug-in developers, theme developers, they're not perfect, so do everything in staging. Yeah? Yeah. They seem to be extremely slow no matter what we try to do in the service. Yeah. Do you have any ideas on that? I do, I run a clarity service that... No, I'm just kidding. Yeah. So one of the first things I'd say is get someone who is a database expert to start looking at stuff, because variations... There's a couple of dynamics. One is how they get imported in, right? So did you manually have them in or did you import them in? And then the variation data, and where it's being stored, and how it's being indexed, could all have a performance problem, right? So you want to get someone looking into that. Is the matter of me putting these decks on? I'm not going to tell you to go in and put decks on your story, that's not good. So that's what I'm saying, get someone to look at it deeply. Inline JavaScript, so you avoid some of those external calls and how do you feel about putting it together if you have five policy, five different CSS scripts or JavaScript files putting them in one and minifying? So I mentioned the auto-optimized plugin in his name I can't pronounce. And they do that. So they will do that for you and they'll both minify both JavaScript and CSS. And again, you can turn it on and off each one. You can go into the advanced parts to control it and you can test it to make sure that it's actually not writing anything. Because one of the things that happens is you do something and you go, oh, this should work, but there is a chance, right, that you need a call to JavaScript in a certain order to be able to do some of the other stuff on your page. So you need to pay attention to some of that. Yeah, minify JavaScript for a long time. Were those tests for Will-Conference did it help somewhere? You said there was like 20-something tests, do you guys run? You want it all for free? I don't know, maybe. Yeah, we're making it available to everybody. Okay, cool. And then Astro is A-S-T-R-A. Yeah.