 Thank you. Hope everybody's had a great time here at WordCamp. I certainly have. Today, we're going to talk a little bit about speed optimization. It's interesting. I had a talk yesterday about security, but most people don't really care if their website gets hacked. What they really care about is this. Is it going fast? So, without further ado, okay, without further ado, let's get your website going faster. With the words of the famous or infamous philosopher Ricky Bobby, I want to go fast. So, what is PageSpeed? PageSpeed is how quickly your website loads for the visitor and your visitor may not be on a fast high-speed internet. And high-speed internet is kind of relative these days. They may be on 3G, which may be considered slow. That used to be fast, because we did have dial-up way back in the day. But there are people in the world that still have dial-up speeds, unfortunately. So, and it's not something you think about that often, but Google does. And if you are at all interested in ranking in Google, then PageSpeed is probably pretty important. So, why does it matter? Brass tax, bottom line, it affects your revenue. If your website brings in revenue, it does affect you either positively or negatively, because it affects your conversion rates. And that's when someone's actually contacting you for future business, purchasing something, or some people interaction may be your conversion for a particular type of site, such as Facebook, or so forth, if you have advertising. But your conversion rates are how is what drives your revenue? And if your site speed affects your conversion rates, it's an important thing. It also creates a better user experience. If someone goes to the website and they're able to find what they need, find it faster, and they're more than likely going to have a better experience, and so likely they're going to have, they're going to be more inclined to convert as a customer, statistically. And as I mentioned before SEO, someone contacted me just recently said, hey, my website, I mean, very popular website gets about 75,000 visitors a month. I went, wow, that's fantastic. She said, no, it's awful. She said it used to get a lot more, like 250,000, but because it doesn't, she has, the site just doesn't load fast enough because of advertising and her revenue is driven by advertising, it affected her ability to rank, which affected her traffic, which also affects her user experience, and ultimately her conversions on clicking on ads. And if she's selling anything, also buying anything, so it's all connected. People don't think about this that often, but if you do have a website that is pretty heavy on the load, then you're probably going to need a lot more expensive hosting, but if your website's much leaner and more, it's faster, it's smaller, it's able to handle a lot more traffic, you're probably not going to need as much bandwidth, and bandwidth can get expensive, or resources such as RAM or CPU usage on your server. So these, there's not typically things that the average, you know, website developer thinks about, they're just worried about the building the website and making sure it works, but as a business owner, whether you're a developer or not, these are things that affect your bottom line. And so faster is cheaper in the long run, and it's a double gain. It'll save you money, and if your website does make you money, it'll make you money. I like to look at stats. Does anybody here like to geek out on some stats? I don't like to make decisions without it being really an informed decision. And so I found a case study that was made it clear to me that speed was the way to go. And so 30 days of mobile traffic for an online retailer, and this study showed the study that I found, and I'll have a link to it so you can look at it at a later time. It shows 30 days worth of the site's mobile performance data comprising almost 4.5 million mobile user sessions. That's a lot, which means this is a reliable study. These sessions are plotted on a graph that shows a distribution according to load time. Check this out. That, the horizontal axis is your load time in seconds, goes up to 10 seconds. The vertical axis is the amount of sessions, if you can see that clearly. You'll notice that about 2.4 seconds is where that 1.9% conversion rate is. Now, I kind of consider a 2% conversion rate is a healthy conversion rate for a website. I've seen websites that convert better than that. I've seen websites that convert lower than that. But that's about a healthy conversion rate. In this scenario, as the load time increased, you'll notice that the conversion rate started to drop. And then there's that dotted line that's considered the performance poverty line. And what is that about? It started hitting at about 5.7 seconds is when it hit the poverty line on the conversion rate for this e-commerce site. That's pretty bad. And as a retailer, that's a big deal. So, clearly, the longer your website takes to load, it affects your bottom line. Now, ideally, I like to think of a healthy website, regardless of the size, needs to load under 3 seconds. And that seems pretty ambitious, but look at the stats. If you're under 3 seconds, you're right there near that 1.9% conversion rate. And if you're real good at positioning your content and your advertising or your products, you can get that conversion rate up even higher. But it's not just the conversion rate's important, but it's also the bounce rate that is involved. Now, a bounce is kind of like someone just came in this room and they're like, where am I? Oh, this is not the place I want to go and they leave. Well, as a retailer or even a website of any sort of business, you don't want them to just show up, look around and leave or not even look around. What's the point? So that's a bounce. They just came in the door, looked around, if that, and then bounced. Well, we want to lower that bounce rate as much as possible. And there's no such thing as a 0% bounce rate because of technology, crawlers, search engine bots, et cetera. But I've never got a bounce rate below 20%. That'd be awesome. But as you can see here again, that load time is that horizontal axis is up to 10 seconds on that horizontal axis. And the vertical axis is the amount of sessions. And as you can see, at a load time of about 2.4 seconds was the lowest bounce rate. They got a 12.8% bounce rate. They've got some awesome developers. That's impressive. That is very impressive. I've looked at a lot of stats and I've never seen a bounce rate that low. So I would like to see this website. But regardless, if you can get your bounce rate below 30%, you're rocking it. And part of doing that is making sure, one, your traffic source of traffic is good because if you're targeting their own people, then what's the point? They're just going to bounce anyway. But if you are really targeting the right audience and your website is fast and they can find what they need to find, you can get better results from it. So I like to look at stats, but I like to look at stats that are realistic for me. And this is actually a website that I built a while back. It's not my website, but I built it a couple of years ago. And right here on this green line, you'll see that this is a point where I did in this timeline I did just a few updates to an existing site. Part of that was some speed work and a friendlier mobile menu. So the menu buttons were the size of a finger, not tiny. So it was a little bit more intuitive, easier to read and concise. That changed the site from a 2.1% conversion rate to a 2.44% conversion rate. It doesn't sound like a big deal, but hey, we're talking about a conversion rate over 2%. That retailer had a 1.2% and this is a site that I actively work on today. Now that seemed a little high to me, but because that particular time span is not over a really long period, that could be affected by the particular time of the year. So 2.44% is pretty high. As you'll notice, we did a full-blown redesign on the site a little bit several months later. And you can see that the overall long-term conversion rate was still higher than that 2.11%. That's huge. That is huge, especially when you're talking about a lot of traffic. So that converts in the dollars. And overall the big point in going to this new design is it was more friendlier, and overall it was faster, and that was the real big deal. They were really trying to ramp up its search engine optimization, which is a slower game, but the speed affects you now. And so if you can get your conversion rates up higher more immediately, then the SEO benefits that you'll benefit later is just icing on the cake. So at least you can make more money from your current traffic, regardless if you rank better or not. And I think that's a big benefit there. I like to think of the internet as a water hose. I was talking to someone about this, I think yesterday, and I said, your server, where your website is, is the beginning of the water hose. It's the faucet you turn it on, and my browser is where the water is coming out. And sometimes the water comes out real fast, and sometimes it does not. Someone stepped on it, and there's a kink in it, there's multiple kinks in it, and it's just not coming out like it should. Well, those kinks can be a lot of things. They can be the size of your website. If I have to put, let's say, a gallon of water is equal to one megabyte website, well, I can push a gallon of water through that water hose at a certain rate, but what if the website's five gallons, five megabytes? It's going to take longer to get that amount of water to the end. And the same thing goes for your website. The smaller it is, the faster it goes there. It's easier on your resources for your servers. It's going to be cheaper on your hosting. It's overall going to affect your speed, but it's not the only thing. Your server's resources is going to affect your speed. Your site size, it's a tremendous amount of things, but if you think about the internet flowing into your browser, into your phone, or your laptop, there's multiple things that can kink up that flow of information. And one of the things is having too many plug-ins. I'm sure that no one's guilty of that. I sure am. I like to have ideally less than 20 plug-ins, but sometimes that's pretty ambitious depending on the complexity of the site. But I actually saw something like this in India back in November. It was crazy. People actually do this, but, you know, you use what you got, and sometimes if you don't have a developer and you need the functionality now, you've got a plug-in. You've got a bunch of plug-ins. But if you can simply reduce the amount of plug-ins that you have, or maybe reduce, let's say one of those bricks is a plug-in, but it's a heavier brick, what if you could get a lighter replacement alternative version of that plug-in that has less impact? That is going to affect your speed. So let's just make it faster, you know? By default, use less plug-ins. That's an easy change to make. You don't have to have a whole lot of access as far as like to code to do that as long as you know you don't need that plug-in. And here's another thing. Hello, Dolly. If anybody's ever seen Hello, Dolly, it's not a heavy plug-in, but you don't need it. I've never seen a site that actually needed it, but maybe someone needs it. But disable that, delete it. It's just one other thing that's loading that doesn't need to load. Make your site smaller, like I said before. Your logo. Your logo is an image. If you can, make it a vector image. Heck, you want to go a step further, make it a vector image, such as an SVG, and then open that up in a code editor. And you'll notice that that image is all of a sudden a bunch of code. Well, that's kind of cool. Well, let's copy that code, and if you have access to your theme, or access to the code, you can literally paste it in line to your website, so you don't have to load a file. That saves you one request to the server. It's a little bit faster, just for that. So that's a tactic you can use. It will make your overall site bigger, because if you have that SVG in multiple places, you would be having duplicate code in multiple places. However, I think my logo is like two kilobytes. It's pretty small. So an SVG is really lean, so even if it is extra code, it's really small. It's worth it. Another thing to do is any PNGs or JPEGs that you have, ideally, I like using PNG. It's sharp. Unfortunately, it's bigger. A JPEG is going to be a little leaner on your size. But you can use this great tool called tinypng.com. Go to this website. You can drag and drop a whole bunch of them on there. It'll resize them, and you can download them, and it'll show you how much space you've saved. Well, usually, it's about 75%. So think about that. If your website is five megabytes in size, I would about bet you 95% of that is images. And if you could cut that down to 25% of that, that's a big deal. I mean, making your website smaller is one of the first and most impactful ways to make your website faster, and tinypng is a way to do it. Now, if you're like, well, gosh, I've got thousands of photos on my website looking for you, tinypng actually has a WordPress plugin. I think they might have a pro version, too. I've never used the pro version, but tinypng is great for that. You can install their plugin, and then the next time that you upload a file, it will automatically compress those files for you. And it's supposed to be lossless, meaning you can't tell the difference between the high-resolution version and the low-resolution compressed version. Most of the time. Sometimes I can see some grain, but it just really depends on how picky you want to be. So depending on what it is, if you're showing a multimillion-dollar house for sale, maybe you want a higher-resolution version. If it's just a slideshow of just some background on your home page and there's five slides, compress it. Your situation is going to be different per website. So figure out what works for you. There's a lot of trial and error when you're doing speed optimization, so you'll be refreshing that page a lot. Be sure to turn off your caching while you're doing all this work, otherwise you won't realize the impact you're actually having on your website. One cool thing that I like to do is use something like Font Awesome. Has anybody ever heard of Font Awesome? It's awesome. It really is. I'll tell you what's even more awesome. Go to Fontello.com, and instead of loading an entire library of Font Awesome, find the icons that you want to use and build your own font. That's the way to do it, because it's much more lean, and you're not loading a tremendous amount of icons that you're never going to use. Now, if you're not sure if you're going to use things or not, then maybe you want to use an entire library. But if you know that Font Awesome has a couple icons that you want and you just want to use those, and maybe there's some icons that they don't have, go to Fontello. It searches a lot of other different libraries of fonts, and you can build your own font. Even better, if you are a designer and you're comfortable making SVGs in Adobe Illustrator, you can actually import an SVG into Fontello and then export that into a font. And now, guess what? If your logo is only one color, make it a font. It'll load faster. So, if you've ever been to Twitter before, they have no images. It's only a font. Their entire website's a font. That's why they're so fast. Makes a difference. Used to, you would make sprites. You would make a bunch of icons and put them in a little sprite and then tell it the coordinates of the image and use a background image. That's an old-school CSS style. If you're comfortable dealing with Adobe Illustrator and SVGs in Photoshop or you know someone who's a designer who does do that, this is the route to go. Create you a font, and then you can embed that font. And then, hey, your speed will tremendously be improved. If you're using little icons as PNG images or JPEGs, you'll see a tremendous update in your speed. Consolidate and compress your code. CSS, JavaScript, and HTML are kind of like the building blocks of your front-end of your website. That's front-end development right there. Your HTML is the walls and the ceiling of this building. The CSS is the paint and the carpet on the floors. And the JavaScript is the things that make those doors open. So, if you can compress that, there's plugins that do that. And I'm going to mention a few of those here in just a moment. But if you can automatically compress that and then cache it, that's less things that you actually have to load and hit the server for. Also, defer your JavaScript files. When JavaScript loads, it kind of blocks the rendering of the page. If you can defer that to the end, that will make a tremendous difference on the usability of the site. So the user, even if it does take a longer time to load the site, the user doesn't notice. So, if some sites are just big, this is how it is. Maybe you can't get it to load in under three seconds. But maybe you can get it to look like it loaded in under three seconds. That's better than nothing. So, and if you can increase your conversion rate just because the user gets it faster, maybe the bottom half is still loading. But that's okay, the user doesn't see it yet. Not a big deal. The bottom line is it affects your conversion rates and affects your revenue. So defer JavaScript files is a way to do that. You can use a CDN. Now, there's a lot of different services out there that do CDNs. SiteLock, actually I was having a talk with the guy from SiteLock just earlier. I didn't realize they did a CDN. Cloudflare has their own CDN. You know, there's all these different services that provide a CDN. I'm not a big fan of having a CDN personally. And that's because that's my scenario. My server has Nginx and Apache running together. So it's actually slower for me to use a CDN because I've tuned my server to run faster. If that wasn't the case, I would be using a CDN. Whatever your situation is, make sure you implement the tools that fit your needs first. The more graphics you have, you're probably going to start going into a CDN world anyway. And I mentioned Nginx, and that's why I don't pay for a CDN because it just doesn't benefit me. Load your third-party scripts such as ads, advertising, or your heat maps. Some people start getting into heat map, AB testing, that type of stuff. Load that on a delay. Please. Those are the things that really kill your site speed. Put it on a two-second delay or a three-second delay. It's not going to kill you. And it'll still work. If it doesn't work, lower the delay. But still, usually, at least with GT metrics, for example, they measure it, and then they wait two seconds to see if anything else is going to load. And then that's when they cut off the speed test. So if Google's testing your site for speed, and you just have it on a delay, all the heavy stuff, and if you've got big graphics and it's in the footer, put it on a delay. And you can write a little bit of a JavaScript that wraps around that script that just writes it to the screen, to the code, when that delay is up. So that's another way to kind of trick the system. And that's actually better for the user as well because they can't see that content yet. Doing a lazy load as well. Don't load all your... If you've got some fancy skills or you've got a developer who's got some fancy skills, don't load the entire homepage yet. That's an option. Wait till they scroll down far enough, especially the more complicated the site is, and then load it in, on using Ajax, or React or View, or whatever they want to use. So that's another tactic. Now, unfortunately, you know, HTTP1 protocol is slower, which is an unsecured... I'm sorry, is slower than HTTP2. But that's deceiving. An SSL that runs HTTP1 is slower than HTTP2. Unfortunately, HTTP unsecured site is faster than a secured site. That's unfortunate. Because you're having to load encryption. But you need it. Especially if you're... Just period. I think it's a big ranking factor these days. So if you do have an SSL installed, which the chances are, if you do, you want to make sure that you're actually running protocol HTTP2, and because it will asynchronously load things in a much faster way. You can check that out to see if you're compliant by using this little link right here. And run your website on it. And if you're not, contact your hosting and say, hey, my website's not running HTTP2. Can you fix it? Let them fix it. That's their responsibility. It should be. Especially if they've installed your SSL for you. Upgrade to the newest PHP7. Supposedly, it's faster. Now, I say supposedly because I can't tell. And the reason why I can't tell is for a good reason. I cache. I don't run PHP on every request. That's crazy. Especially when there's faster ways to do it. And so if your website's doing any caching whatsoever, your PHP gets actually compiled and then cached using opcache on the server. So it's cached there. Then your website itself is getting cached at multiple layers. There's so many layers of caching. It's a nightmare if you're chasing your tail and you're looking in an old version that's been cached and you're not seeing your updates. However, I can't see a big improvement, me personally, noticeably, on the PHP upgrade. So my recommendation there is supposedly it's faster. However, I imagine that if you have a really gigantic PHP-driven site and WordPress is PHP-driven, then maybe you would be able to tell the difference. Maybe. Have better security. Unfortunately, security is at multiple layers. Security is an onion. It happens at multiple layers in the technology stack. It happens at the server. It happens at the software level. It happens at your level, the person. But the reality is the more security you try to compensate using your website for the security that your hosting doesn't have, the slower your website's going to be. Because what's your website about? Security or selling clothing or selling products or information or whatever your topic of your website is about. So you need security. However, you can go overboard with it and it can negatively affect your speed. So you need to keep that in mind when implementing these types of things because they all affect each other whether we like it or not. And upgrade your hosting package. If you're, you know, let's say you saw the Ferrari on the first slide, you want to go fast. Well, guess what? That Ferrari is about $250,000. And if you say, well, you know, I want to go fast, I'm going to go buy me a Ford Fastiva over here. This thing is awesome. It's not going to go 185 miles an hour. It's just over 220. It's not going to do it. You can put wings on it. The premium gas in it, it's not going to do it. So the reality is you've got to upgrade. And I get the question all the time, well, what hosting company do I need to go with? Like, there's a secret guy. There's a secret. There's a secret hosting company out there that no one knows about that. I'm not, I'm holding out. I don't want to tell anybody to give out my secret hosting company that I use because the hosting company I use doesn't matter. What matters is the technology you're using and the hosting company, what really matters with a hosting company, if they've got, if all things are equal in the fact that their technology is good and most hosting companies are, what the difference is the support. I need less support than someone else. Or maybe I just don't want to do it. Which is, which, you know, I got other things I need to do. So maybe I want more support. Someone just to take care of it. That is what goes into the decision on who I use for hosting. Don't make decisions on hosting because Jim over there is using, using this company. Or because I'm using it. That may not be the solution for you. The first question I ask is, what kind of website are you trying to host? What are you trying to accomplish? It matters. And I'm not going to tell you what hosting company you should use. I'm going to tell you what you're going to need on your server or you may need load balancing or you need shared hosting. I mean, it depends on your website. But that can affect your speed and especially if you're getting a lot of traffic you'll notice all of a sudden you've done all these fancy performance upgrades and your website's loading slow. Well, that's what happens when you get popular. You need more hosting. More capacity. You need a faster car. And hosting is where sometimes just upgrading your hosting will take care of those problems. Talk to your hosting company and they'll help guide you on those things. So, I mentioned performance plugins. One of my favorite plugins is the first one here. It's called Auto Optimize and it's free. It doesn't cost anything. And if there was a pro version I would buy it because I like it that much. But there's none. So, I use Auto Optimize personally. I use W3 Total Cache. W3 Total Cache, you can have a premium version of it. You can have a free version of it. W3 Total Cache is a lot more complicated than Auto Optimize. But it does a lot of the same things. It depends. I use them both depending on the website and depending on the server that goes with that website. There's one server I was working on the other day and I'm like, wow, which plugins should I use? Come to find out. They were using Redis to cache the database and really rocket and fire on any searches that were happening. It was giving it back to you really fast. Well, that would be a W3 Total Cache moment. Auto Optimize is not going to be able to handle it because I would get more performance out of using that plugin in that scenario and so on and so forth. Everything's different. So research, it's good to know what is the technology behind your website? You're hosting. How heavy is your website on functionality? If it's a simple website, put Auto Optimize on it. I'm going to demo this in just a moment on Auto Optimize. W3 Total Cache is very complicated. There's a lot of settings. That's a session in itself. We don't have enough time for that. I'm going to demo Auto Optimize and some testing tools. There is also WP Super Cache. It will cache some files for you. And I think it also does page caching. There's a lot of sites I work on that use this. I'm not as familiar with it as I am the other two. And WP Rocket is a premium caching plugin. I've heard a lot of great things about it, but I have never used it personally. But if that may be worth looking into as well if you're serious about speed. So how do you know how fast you're going? Let's actually measure it. Well, there's three tests that I like to do on a site. I don't use just one because one may say, you're good to go. You got an A. Congratulations, Gold Star. Well, Google may see it differently. And Google is the one that really matters in my opinion because they're the one with the search engine. I've never heard of a search engine called Pingdom or GTmetrics. So until they are competing in the realm of search engines, I will always use Google PageSpeed as part of my testing array. So the first thing I'll do is I'll actually use GTmetrics first. I like GTmetrics for one key thing. It has a waterfall where you can see each item that's loading a bottle necking you. And you can clearly see, oh, wow, we got some really big images, or our servers responding slow, or you can identify problems that you wouldn't otherwise be able to see by someone saying, yep, website loaded in three seconds. That was fantastic. Well, why? Why did it load in three seconds? There's a reason. So GTmetrics helps you with that. Pingdom does a really good job as well. Unfortunately, Google PageSpeed, I mean, it gives you some advice, but it's not that helpful. So I prefer to get GTmetrics scoring really well, and then once it's scoring the way I want it to score, then I start testing against Pingdom and seeing is there something else that I need to address. And then I look at Google PageSpeed and say, okay, now what do I need to address? And then by the time I've gone through all three, the site's pretty fast. So here's an example of a GTmetrics score. This was an actual site for a client that I did. This was their website before I ever touched it. We actually ended up not doing any speed work for them, which is fine. When we switched hosting and I don't even have the screen for it, I wish I did, but when we switched hosting, their speed went to three and a half seconds. Just using switch. That's it. And the reason why is because we switched to my particular server who was using Nginx and Apache. Apache runs PHP faster than Nginx, and Nginx search static files faster than Apache. So because of that we leveraged the server without ever touching one piece of code on this website, and we cut off about three seconds. We're about two and a half seconds. That's awesome, and that was a cheap change. And that's why they decided not to do any speed performance. Okay. That's fine. Of course, obviously they could do some improvements. Their total page size is higher than I would like it to be. I prefer it to be about two meg, or less. But it's 3.23 megabytes. Request, I prefer that to be under 50. They've got 96 requests. And page speed score is awful. I like for that to be above 90. And why slow score? I like for that to be above at least 85, if not 90 above. Here's what it should look like. And this is my example. This is a separate site that I did do some speed on. They were using a lot of third-party scripts. So it was hard for me to get that why slow score any higher. And that's just, sometimes that's just how it goes. But in this case, we got them up to a 97% that why slow score is 85%. Their on-low time was 2.6 seconds. That's under that 3 second mark. That's awesome. And in that example earlier when we was looking at those charts, that's pretty close to the stats that we were looking at. The total page size, under 2 meg. Perfect. And you notice it's marking everything green. And the total request, 24. Now when I started with this one, it had over 100 requests. And I got it down to 24. And what that request is is it's literally requesting a file. It hits the server. That's my request. And so that means there's 24 files things going on. It had to hit the server, get the request back from the, get the response back from the server to say, oh yes, the domain's good. Okay, that's our first request. We're going to do another one. And it starts and all those things start stacking up. That takes time. In milliseconds, but it takes time. And so by consolidating CSS files and consolidating JavaScript files or inlining some of those things and removing the file altogether that reduces the amount of requests that we perform thus cutting down the time frame it takes to load that actual website. So let's do some demos. Does anybody have any questions on anything I've said thus far? Before I show an example of how to use some of these test tools and also an example of auto-optimize. Yes, absolutely. So the question that she just asked was when you're deferring JavaScript to the footer how do you know which one's to defer? And when you do defer it how do you know which one's going to break? Well, the answer to that is I don't. It is a trial and error process unfortunately. It's not a fun one either. What I like to do is I like to defer JQuery first if you're using JQuery, usually that's on by default in WordPress and I make sure it's first and then as long as everything else comes in behind it I'm pretty safe unless you've got multiple JavaScript files relying on each other and I think that as a developer that's not very smart. If you can consolidate your code dependency code so that one JavaScript file is not relying on another JavaScript file it's a safer deployment. So if you have control over that I would highly recommend consolidating files that are dependent on each other and then at that point as long as JQuery comes in first it doesn't matter which one's load next. So that's really the safest route to go. Not a bullet proof route. It's a trial and error process. Yes. I'm sorry, say that again? Tremendously. Well, like I said earlier, so the question was what is the difference in speed when it comes to engine X and Apache? Now, mentioned earlier I'm running both. I'm running a reverse proxy engine X in front of Apache so basically every request that comes into the server engine X handles first and it says what kind of file is this? What kind of request is this? Oh, it's a static file. Engine X is going to handle it. If it's a PHP request it passes through to Apache so Apache can handle it. There are actually performance tests out there. I would highly recommend googling it because I don't know any stats off the top of my head but the reason why there is a difference is two things. Engine X can handle more request at a higher rate so if you've got a, if you're a high website it can handle the request better than Apache, period. It's not as fast as Apache in processing PHP though. That is the downside. It's not crazy slow at it but it's not as fast so that's why I use both. However engine X is, if you use a CDN, guess what? That CDN is using engine X and that's why I don't use a CDN because I'm already using engine X so it depends on the website and your web's configuration. So if you're running a LAMP stack and Linux, Apache, MySQL and PHP and you're on Apache, you may want to implement a CDN because at that point if you don't want to change host or change your stack you could implement that CDN and leverage engine X for your static files and supplement that. Does that answer your question? Okay, perfect. Anyone else?