 old WordPress query, and it's showing you 20 at a time, and if WordPress was slow, showing you an archive page, everybody would be up in arms, and they'd all be using Drupal. It's important to recognize when you're wrong, when you follow the path down the wrong way. Now, don't regret that. It taught me a lot, a lot, about debugging, about understanding what my site was doing and why I was doing specific. I have the three that are really slow. Statistics are slow because it's running a lot of math, and by which I mean, it's going through calculating percentages, calculating averages, and that's only a little bit slow. I could speed that up with a little bit more caching, with the limits of how many things it runs, and I didn't actually get, everything except two of the statistic pages are now pretty fast. Three, if I count one that does a very complicated multiple level query, and it's just crazy, and about the page that lists all my shows. And I looked at it and I said, boy, the book that a lot of those cute little SVGs have on them, you turn off SVGs. I went through it, just knocked out all the entries, commented them all out, reloaded the page, he's gonna be still fast, okay? Obviously what's in common here is the SVGs, but if it's not one SVG and if it's not two SVGs, what's the breakpoint of how many SVGs I can have on a page before it turns to be 13 seconds slow and the answer's somewhere around 70. See, for all the regular characters that we have, and remember we've got like 25 on the other here, they had at least two SVG icons that indicate character cliches we like to call them, like someone who happens to be in law enforcement, because lesbians in law enforcement is a massive cliche for characters. We also have those who have intimacy issues, which if you've seen the other one, basically we're talking about shame. There were 15 tags additionally on each show page, but those listed out the show tropes. All of those had individual SVG icon, and the L-word had more tropes. Then we have an additional three icons to show rankings and ratings, and the subjective value or how good we thought the show was. And I started counting all of them, and then I divided them by 13.5 seconds to figure out exactly what was going on. Those SVG images was taking around up to four seconds to the total. 2.6 to four seconds, depending on the time of day. Went for another bike ride to go to work the next morning, checked a few other pages with a lot of SVGs, and I found exactly the same thing. Few of the SVGs, the Bachelor page, or SVGs slower the page. So what's different about SVGs that could be causing the problem? We remember way back in the beginning, how I was talking about how to use special command instead of an image tag to get SVG images. It was WP remote yet. The whole jQuery monitor, and I said, okay, you know this is slow. You're throwing me nice and layers. Thank you, that's great. What is slow? And it said, oh, the HP requests are slow, man. The page was waiting for my CV end to finish loading everything. And I found that it was between 0.1 and 0.4 seconds per image. I was reading ahead, 0.65 is about 35 seconds. So that kind of explains why I was getting 13 if it's 0.1 to 0.4. The math does actually work out when you start thinking how many images I was removing and adding and removing and adding. It wasn't just WP remote yet, but slow because it ended up itself 0.1 for each image. That's really not actually about that. The problem was my sanity check. I was checking, get the image, make sure the image has a proper response, and then load the image. And basically it double checked. It checked, it would do a query twice out to the remote image. So I was doubling things completely unnecessarily was, is it there? Okay, is it still there? Okay, now you can include it. So all right, let's optimize that and make sure that I'm actually using WP remote yet properly. Get it, check the body request, slide the body request. Great, I've knocked the time down. It's still slow. In order to drop the page down to about one second load time, I was wanting to have to make the images local. Because as soon as you make them local, you don't have to use WP remote for SVG images. You can't do that with remote images on most servers. You can't do remote images on most posts. And that's okay. Those are things that you don't want to do. Because again, we're talking about the weird document object model and how your PHP page has to have access to edit parameters, not really parameters, but it's already explained in another way. Basically, in order to make my page talk to the SVG, they had to be in the same level of document. We can go up a level, we can go down a level, and the way to do that with a remote image is remotely getting the image. With a local image on the same server, it's a lot easier. All right, let's see what happens when I fill them all locally. I was smart. I had the location of the images defined with a define as opposed to, because I thought, oh, maybe one day I want to move it to another server. I just searched the defined name of the local instead of the remote server. Copy all the images locally, ran it again, and boy, that's not fast. It's still fast. The images, yes, are still local. No matter what I did, if I loaded them remotely, I couldn't get anything better than a 10-second load on those image tags instead of SVGs. If I'm not doing a remote yet, I can just use an image tag. But that meant I can't use CSS to color them, resize them properly, and then I'm gonna be loaded with a document object model. All right, I don't know images. To which point I have come full circle and all work was worthless. Okay, there is option four, don't use SVG as a solution. SVG icons had to be local for the site to be fast. To meet my needs of being able to change the colors, change the size, change the effects that I was overlaying on them. I'm tracing from flying out from Billy and Strangler to be from making our brand new site really really slow. My new site, you definitely don't want to do it. You're working on a site with one of your best friends. I've been chatting with a bunch of people about this problem and I've finished this talk. In original, we're talking to Gregory and me saying, you gotta be local, because SVG images do not like being remote like that. And somebody said, you know, I bet you can find a JavaScript that will go through your, so me and a couple of spent nights at a printing sitting in my hotel room going through the various options that we had banging on this. This is what nerds do when you get us all in a room. You decide we're gonna have fun and play with them. We are actually able to be moderately successful with this. We've got a few JavaScript libraries, SVGJS is one of them, there are a few others that are similar names. Work is that they apply the CSS and your changes via JavaScript to the image. Instead of just having the image tag or whatever, they say, oh, this is an image tag. I'm gonna convert it to an embedded in the document object model and then your CSS will have to be applied. And it mostly worked. And there were a few quirks to it. Sometimes the culprits didn't work, right? Under a second, load in about 3.4 seconds. My site is slow just to make it an acceptable thing. If it's not fast, I suspect the server was up before running the JavaScript. I could, through WordPress. I actually could write in a little check that said, hey, ping the server, if you get a response back, right, keep loading the JavaScript. But remember how is that the double check made my site really slow? It doesn't JavaScript it. I did change it so that it just didn't make you the JavaScript if that was the case. But then what happens to my images? Well, they're not resized. They're not taller. They no longer match my site. That's a terrible experience for my visitors. They need to just look back. There was no way to do this without adding about 3.5 to 5 second page time on a page load. No possible way. It just was. Actually, so are the various page view ways that I tried, by the way. And yes, I went through. Part of the journey was because everybody and their mother told me, you want to use CDNs for your images, CDN is magic. Okay, it's just somebody else's server out in the cloud somewhere. The cloud is just another fancy name for a server farm that you build your own with. That's okay. The cloud is a great idea. A CDN is a wonderful idea because if you have a lot of images, having them distributed around the world means that people who visit your site in different countries and this specific site can take a lot from other countries, it'll be faster than them. Not everybody will be hitting your server for the images. That's faster. That's great, especially if you've got people in low band with area, making sites run faster for people who don't have high speed Google internet is really key. And when you start to understand the metrics of who visits your site, how many are on mobile? How many are on terrible mobile but have lousy browsers? The number can be quite surprising. Understanding your audience is hugely important here. Until it's not. The CDN is magic when you're loading images. It's not magic when you're using remote. Because I was using the cloud model but because I was making the wrong assumption about how remote calling the files worked. Again, SVGs are not actually images, they're files. They can be anything. And because of that, they can't be treated like an image. And because of that, they're going to be slower than it would be if you used an SVG or a CDN for your JPEGs for your PNGs. It's just going to be slower. Various versions of PHP, various versions of server software are making this better and smarter and safer. PHP 7.2, remarkably fast when you compare it to 5.6. Which we should all be getting on but if you haven't gotten off of PHP 5.6 please make that next week's work. You'll want to do that. PHP 7.2 faster than 7.1 is faster than 7, right? It does make these calls better and smarter but there's an amount at which you can no longer speed things up with the setup that you have today and it's not a fault of WordPress making WP remote slow because again, it was slow but I was using curl. It's simply a fault of how PHP has to process the document when it doesn't know what the document is. When we tell HTML show an image, HTML knows what to try to do with the image. When we tell HTML, when we tell PHP, get a document and embed it so that HTML knows what to do. We've added an extra layer onto that. When we tell PHP, make sure this image actually, this file actually exists before you embed it. We've added another layer onto that and all of those layers combined made my site slow. There are more marvelous ways to make your site faster with the cloud, with CDNs. It's just not good remotely getting them like that today. But I'll test before you roll out anything without doing it now to the start because you will save yourself, people telling you your new site looks great but it's really slow. And that would suck. That could kill your business model in a day. We certainly did test, obviously. But if we hadn't understood how our site worked and all the parts that went into it, we would not have been able to debug this at all. I bounced a lot of these ideas off of Tracy. To be honest, neither of us actually understood the whole picture of what we were doing as we started to walk through it. We do now, but at the time we're like, okay, well we tried this and it doesn't work. How do these things work? Let me talk from the left. Find somebody co-workers, great, a friend, great, a dog, or a cat. They don't really get great advice about it. They certainly listen to help. And just talk out the problem that you're thinking through. Understand yourself how all these pieces come together. How does the PHP make this call? What is it doing to the HTML? How am I getting this data? How am I passing it back? Understanding the pieces help you figure out where you need to start debugging it. Don't be afraid that you start debugging on the wrong road, spending all that time on your own database. The use of debugging tools, query monitor, and debug bar are like heroes. If I didn't have those two plugins on my website and I happened to visit A on the site, I would not have been able to solve this in four days. I would have just rolled it back and not understood why. At least now, I made the educated decision. Why do I need to roll that? Query monitor is not just going to tell you that your database sucks. It's going to tell you that your HTTP calls suck. It's going to tell you that your JavaScript sucks. And that's good. Remember, all of our code sucks at some point in time. Usually, right in the beginning, when sometimes, oh, I don't know how to fix this, I'll do it in two seconds, click, click, oh, I just took the end of that site. That was two days ago. Excellent. My JavaScript, I'm getting that. I don't even do the whole embrace JavaScript deeply. What's really happening is that I've embraced JavaScript about the depth of the key tool. I'm trying. It's hard because you have a rapid competitor and a new thing goes back to understanding your site. Understanding why things were slow, healthy understanding where a CDN was good and where a CDN was bad. Still today, working on figuring out ways to speed up the relationship between remote again and CDN. I may have built all this out of a green press, so we have a cloud dream object. Built it all out on that, and I thought, oh God, if you really do something wrong, then we're on the wrong with dream objects. Are we ruining things for our customer? I ran over to my test site on Amazon S3, I had the exact same problem. Hey, it's not just us. That makes me feel better on one end because I don't have to turn to the folks who work on that team and say, we have a problem. And he said to real life, this is actually endemic of all cloud based apps like this. And then I thought, well, maybe it's not just a cloud. I put images on another server and did the whole remote get that isn't a cloud server. Same exact problem. Congratulations, maybe you have a problem in how PHP renders things in, and it's not a problem. That's the darn thing of a wholeness. It wasn't a problem at all. It was me not understanding what was involved in what I was doing, and now I do. And now I understand that when you say remote get, it's more process-intensive than just an image. And because I wanted to put in that safety check to make sure I didn't show someone a broken image on a site, I had made things a worse experience. It's a little script that runs that I upload the images to the cloud. And every time I update our library code, it does a poll and it says, hey, do we have any new images for it? Let's send them down and throw them on all servers. The slowest page we have now is the page on the back end that I made that lets you listen to images. You want to know what you're having, right? You want to know what they look like. What image represents sub-tech? Definitely that the kind of image that relates to a taxonomy is something that is going to be unique and individual to each and every cell.