 In my case, in the L-Words case, it was very complicated and it made the site far slower than it needed. My name is Mika Epstein. Most people know me as Ibsgenu. I work for Dreampost as a WordPress and DreamPress developer, playing with a full stack. I'm glad I used for this experience those dream objects that we have on Amazon history too. And yes, all over the place. The site that runs the code was built on DreamPress and Dreamhost is kind enough to support me, not just coming to events like this, but to run that site on DreamPress as a bit of our canary and use it to test and explore and figure out how can we make hosting better for everyone, but also how to make WordPress better for everyone, no matter where it goes. Is it possible to take the SVGs and turn them into a font set? Yes, it is, but when you take the SVG set and turn it into a font set, you have to load the entire font set or portions of it on every single page, whether or not you use the image. And our thought was that, well, let's just load the images as we need them instead of the whole font size. For example, we used font awesome at first and we had it locally installed, not at the run-up for some reason. And the size of the page is a little bit larger, and you were trying to keep the size down to keep the page up. We did experiment with it in the very early stages before, which are a little bit better. Plus, it's a lot easier to just add a new image than it is to go in and read the font set. Why is the SVG the slow on the circle, which must be lighter than air? They are actually women's local. They're incredibly faster than anything else, but it was just those multiple calls every time I went to the circle. So it's just to continue with that line. The problem was that they weren't local, or that it had something to do with the CDN, but the problem was the remote yet. For example, if you just keep them local, but invoke a CDN that just sort of chooses its own files, like a template like Cloudflare or something, you probably wouldn't experience the same slowness as what you described. Is that true to say? What do I experience the same kind of slowness with a Cloudflare type CDN? Cloudflare is more of a proxy CDN than a true CDN. So when I talk about a CDN, what I really mean is like using a Kami CDN or something, but you actually have the files loaded on another server, and you call them locally. Photon does a very good job at this, where you think that the images are on your server, but they're really duplicated to a Photon server that used Jetpack as a Photon that calls something else now. It actually copies the images out to their servers, and dynamic replaces the content on your site, so that it's calling them remotely instead of locally. That's the kind of CDN that I'm talking about. There is another kind of CDN like Cloudflare. Security has one, and Capsula has one, and those are CDNs that act as a proxy for their own role between you and your visitor. And with those, they copy your whole site, so they wouldn't, in fact, copy the SPDs to their local. So the first kind of CDN that you mentioned, which is the one I mean, if you looked at your source, you would see different URLs for those images pointing to the CDN server, instead of your server, right? That's what you're talking about, where every place is a code, and that would have been slow for you as well. Yes, even having it done that way, having it be where the URLs were placed and it was calling it remotely, those were still slow to call, because the only way to get those, I say that, and I hesitate because there's actually some that I'm working on myself to try to resolve this in other ways, which is what might dynamically change them, and that was the whole job-strip journey. The only way to tell WordPress and PHP where the images are is to literally tell it, here are where your images are and you need to get them, or the cloud can get them so that you could generate things in the PHP at some point, because otherwise it's just not going to know. That's where it went slow, and theoretically with the CDN and some sort of dynamic check on the images to replace the like, like Photon does, yes, I could get around this problem. That said, there's a reason that Photon is so darn good. They have a lot of servers and a lot of logic behind it that is not quite open source, so I haven't quite been able to break through the wall and reinvent their wheel. I'm trying to bribe them. But obviously, they charge for some of those things, and they have a proprietary software, and I totally understand that they don't want some open source co-jockey to go through and take their stuff and make it public so that anybody can make their own version of Photon, which is what would be involved in making it faster. But also, again, those are true images, and remote loading true images is always easier because you're just going to swap out the image source location. And if that's all I was doing, CDN's no problem. It doesn't matter if they're SPGs. The problem is that SPGs don't act like images, and if you use image tags, you restrict what you can do with them. So that was an option, but it would make my cycle. If anybody else does, I have one other question. As you were talking through the tools that you were using to figure out what might be slowing down your site, and I mentioned the database tools, but one thing that a lot of times I've experienced slow sites, and I don't really understand how to use query monitor that well, but I used it and I see that there really aren't too many slow queries. So my next thought is that it could be the server itself, maybe something with PHP writing slowly, maybe not enough memory, things like that. And if you're using a server that you don't have full control of, you can't find out those things easily. And I'm wondering, for example, I helped one of my clients load a site onto a specific host, whose name I won't mention, and we found that the site took, it was a WooCommerce site, and it was taking 20 to 30 seconds to load the page sometimes, and it was a brand new VPS, so we couldn't believe that it would have been that server's fault, but then we tried another hosting company, and then the site loaded it in three seconds, so we clearly determined that it was a factor of that particular first host that we chose. But I don't know how I could have, what tools could I have maybe used to figure out on that side other than just, you know, slow bandwidth or slow database? So the question for those watching the video is, for your monitor, you're trying to find an HTTP calls and database calls and things like that, but how do you debug things that might be caused by the PHP implementation on the server? Especially if you don't have access to the server with command line, that's really hard. When you said WooCommerce though, well, probably the issue is going to be in the fact that the way that WooCommerce interacts with PHP is different than any other plugin, most of the plugins. And that's because it's a big beast of a plugin, it does a lot of amazing, wonderful things. Debugging it is an idea, because it doesn't like all versions of PHP. The thing that I will start with when I'm trying to debug the PHP is figure out what version I'm on. I'm fairly certain that WooCommerce itself has like a, you can check out PHP info page within the WooCommerce dashboard to just get an idea of what sort of PHP options have been selected and installed. There isn't the great plugin that lets you go in and say, aha, these PHP queries are slow. That said, query monitor actually is going to tell you some of those things, but reading it can be very difficult, less difficult today than it was a week ago, but understanding what each line means and what each call means, you say, well, here are my database queries, here are these queries. It'll tell you things like this PHP function took a long time to run. But that is really helping you understand why is that specific PHP function slow. It just tells you what that is. And with WooCommerce being so big, it is really hard to say, well, okay, that's a function. Great, cool, what do I do now? Which is what I spent a lot of time doing for people who post on DreamPress. Sometimes they have those long lead over when you try to help them figure it out. In the case of WooCommerce, it is very barely WooCommerce itself that isn't playing well with your version of PHP, but it's going to be one of your plugins or add-ons for WooCommerce. They are not all rated people, not even the one-to-five WooCommerce store. The reason for that is, unless they're written by, they have to go through quite as rigorous tests in multiple environments, which is why you see such a big difference between post-A and post-B. And a lot of that comes down to post-having different beliefs than what PHP security means. Some people believe that the best PHP security is to allow people out of everything. And some people believe that the best PHP security is to make PHP itself relatively secure. Good luck on Wednesday. Both of these are valid concepts. If you've made PHP itself secure, yeah, you technically don't have to worry about what your customers and clients are doing. On the other hand, if you prevent them from doing certain things that could possibly hurt them, you've made them safer, but you just made debugging a real nightmare. The best thing that I like to do when I see problems like that is I spend on a local box, not even on a separate host. I just try to figure out how can I reproduce the problem. And so what I'll do is I'll go to that PHP info page in WooCommerce, have that build a local box that has the exact same settings or the closest I can get and see if I can make it slow again. That is not easy. That is hard stuff. And debugging PHP problems is just going to remain hard stuff. I would strongly advise you to keep debug bar on. There are a few debug bar add-ons that do perform to help with finding those PHP problems. A friend of mine, Jenny, wrote a few of them, and I'm blanking on your names, but if you just look up debug bar add-ons, there are some that are good for helping you with your permalink problems, or if you're trying to do redirects and make custom endpoints and stuff, and things that will help you with the JSON API, which I'm just so much in love with our state-of-the-art emails. Crazy. But those things can help you. And the biggest problem you're going to have with debugging WooCommerce is that the trick to being able to debug all that successfully is that I knew what my site was doing. Knowing what WooCommerce is doing requires being almost a WooCommerce expert at this point, for the code, not just for the product. And that is not something I'm going to do. So it was an option to use HTTP1, or HTTP2, excuse me, instead of HTTP1 for the request. It was not because the cloud services, well, it was on Amazon and it didn't seem to make too much of a difference. It just, it set up that it could do multiple calls at once, but because the PHP is a top-down sort of thing and I was sending, you know, loop through all of my tags and for each tag, if it has an icon, show the icon. It was difficult to speed that up because HTTP doesn't really understand how to take this calls quite the same way that we would like it to. So sadly, HTTP2 didn't really speed it up and it was only available on one of the servers I tested on when I was trying to reduce the problem. Which sucked. You thought it would have helped. There was something there that I said, oh, this is going to solve it, but it really didn't. It was very disheartening to me. I hope you enjoyed the rest of your day.