So hello everyone and next session will be a  very interesting one. So we have as next title the 30 minutes performance makeover and how to  do the fixes that pay off very fast. We’re very delighted to have our next speaker which is Shane  Bishop. He is the creator and developer of the e www image optimizer and for the last 14 years uh  he has been very dedicated to making websites uh faster and we’re very happy and excited that  he’s here to share his insights and tips with all of you. So Shane over to you. Thanks Miranda.  I’m excited to be here and uh share some of these things with you. Um, we we definitely see a  a lot of of different advice on the internet uh these days for how to speed up your site  and especially with page speed insights and GTMetrics. Some of the things that we see are  not necessarily fixes that payoff fast. They’re things that require an advanced developer.  And some tools are better about saying, “Oh,   yeah, you’re going to need a developer for  this.” Page speed insights, not so much. um they give the impression, oh, these are things  everyone should do. That’s not necessarily the   case. And so today, I want to focus on the things  that I think everyone should be able to do in 30 minutes to an hour. Um I’ve been doing it a  while, so I can do it quicker, but sometimes   it takes that long depending on the site. So  without further ado, um I will get right into it. All right. So we’re going to talk about  a few things. page caching um and gzip compression or broughtley compression. Uh how  we can optimize images a few things in there uh how we can optimize our JavaScript our  CSS and if we have time we will tackle a couple things that we can do with fonts as  well. And if you want to learn more about   uh all the the things I’m talking about today you  can dig a little deeper with the link I’ve got on the screen there. Um, I’ve got a whole series of  blog posts covering all these topics in depth. So, when it comes to making a site faster,  there are typically three main goals I have   in mind. One, make the initial page request  as fast as possible. Two, decreasing the size of the resources used on our site. So, that’s  the initial HTML. We’ve got all of our images, our JavaScript, our CSS, and a lot of times  fonts as well. And lastly, making sure nothing is render blocking. That is specifically  the above the fold part of the page can be displayed without waiting for anything else. You  get the HTML, poof, rendered. So that’s the goal. So, as I’m going through this, um, I’ll be talking  about the dev tools in the browser. And so,   if you’re not familiar with those, I highly  recommend checking them out. You can get to the dev tools anytime from any web page by  just right clicking on it, click inspect, and you’ll see something um, that looks like the  right side of the slide here. Um, a lot of the stuff I’ll be talking about will be on the network  tab. Um, but we’ll talk a little bit about the console tab as well. And you can also run your own  performance tests from the performance side. So all right. So the first asset if you will on your  site that loads is the HTML. The very first thing a browser does is to get that HTML. So in the  interest of making that first request faster, there are a couple things we can do. As  I mentioned before, we have page caching   and compression. So, building the HTML for  your site is not unlike building a boat, except for you don’t have a physical thing.  You have a digital thing that we’re building.   And there’s a lot of things going on behind the  scenes. Just like in building a boat, it takes a lot of time. And if someone came to the lake and  wanted a boat, we wouldn’t go build them a boat.   We would take them to the boat house and say,  “Here’s a boat we built.” Right? Well, that’s what caching does for HTML. There’s all this work that  goes on to build an HTML page. We have compiling the PHP. We have running the PHP. We have a lot of  database requests going on. And that takes time. And on an average site, that can be anywhere  from 3 to 4 seconds. It can be worse, 10 seconds, 20 seconds, and god forbid 30 seconds or more.  Um, but more often we see, you know, three to four seconds. My demo site that I uh put together while  I was working on this took three and a half. So, look at that. So, if we take that long just to  get the HTML, we’re fighting a losing battle. So, what do we do? We take that HTML that’s been  generated and we store it in a cache. restore it to disk so that it can be reused without running a  whole bunch of PHP or doing any database queries. On my demo site, um it went from that 3 and 1/2  seconds to just over a tenth of a second, and I’ll show you that here in a second. Um there’s  a couple different ways that we can cache things. Uh some web hosts offer server-based caching. So  hosts like WP Engine, Cloudways, Kinsta, Flywheel, they all have um server-based caching. There are  a bunch more. A lot of hosts don’t have that. And so then we can use a plug-in based cache. And  either way, the HTML for each page, like we said, is being stored on disk for future visitors.  And sometimes you can use a plug-in cache on top of server-based caching, which is something  I started doing recently. And it g can give you a little bit more flexibility with the cache  configuration. It’s also, as I just recently   found out, exactly how Cloudways works if  you use the Breeze plugin alongside their server-based varnish cache, which you likely  should if you’re using Cloudways, by the way. So when we implement page caching, it goes  from 3 and a half seconds to like I said   just under a tenth of a second and we’ve got  79 milliseconds for that initial page request. So the other thing we can do besides caching  is compression. And the three biggest types of compression we can apply to our pages and other  resources on our page are gzip compression, brley compression or ZT standard  or Z standard abbreviated ZTSD. So to test and see if your host is already doing  this compression, which a lot of them are, you can rightclick on the page as I mentioned before and  get to the dev tools. And then you click over on the network tab as we see top left here. And then  you’ll see a whole list of things that were loaded for your page. And you will probably have to  scroll up. Maybe not if you have a smaller site, but a lot of times you’ll have lots of resources.  And so you scroll up, click on the very top one, and then you’ll see on the right hand side uh the  headers that were sent along with that request. And so you want to look for your content encoding  header and see first off, is that present and what does it say for the encoding. So you’re looking  for either GZ for GZIP, BR for Broley, or ZTSD for Zstandard. If you see that, you’re done. Move  along. Otherwise, some cache plugins will also add GZIP rules for you, and that’s the route I would  recommend if your web host can’t do it for you, which they should, but if they can’t, um, our  own Swiss Performance can do that. WP Rocket does that, uh, WP Optimize as well. Some plugins  like Hummingbird will give you the rules and then you got to copy them into your htac file.  If you have no idea where your htac file is, I will go the right direction with the slides and  show you. Um, so in the root of your WordPress install where you have your WP content folder,  your WP admin folder, your WP config file, you will often see if you’re on Lightseed or  Apache again, you will see aht access file and you can copy those rules into there. And they will  usually look something like this. So, what it’s doing is just adding uh the deflate algorithm  to all of these file types, JavaScript, JSON, um uncompressed fonts. Most fonts are compressed  these days, but just in case, um your HTML and   your CSS, those are the big ones, the HTML,  CSS, and JavaScript that you want compressed. So in the end, uh, gzip compression not  only makes the first HTML request faster, but also helps with number two on the list,  making everything smaller since, like I said, it applies to JavaScript and CSS as well. Next up,  images. Of course, I’m going to talk about images. And in the interest of making things smaller,  thing number two, the next thing we can do is make sure our images are properly compressed. Uh, there  are plenty of plugins for this. dozens probably at this point, but the top three I recommend are our  own ewwwage optimizer, Imageify, and Short Pixel. They have the best compression to savings ratio.  Um, and those are the ones I yeah have used and think work pretty well. Uh so for a long time most  image optimization plugins focused on compressing your local images and all of these and more will  fill that role just fine. You install a plugin, you run a bulk optimization process and we move  on, right? But these days there’s a lot more we can do with our images and even some things we  can do pretty quickly. Um the next thing that I recommend is lazy loading your images. and it  should be quick because it’s built into WordPress. Now, hooray. Um, but there are some cases where  you might want a plugin, right? So, the first one is if you’re using CSS background images.  Um, those cannot be loaded by browser native lazy loading that WordPress uses. So, a plug-in  can load those. Um, and the second reason would be if you want your images to be even lazier.  So fewer images to load equals more speed. Um if we look at browser native lazy loading, they  use and lazy load plugins as well do this. They use a threshold below the viewport of how many  images they’re going to load because you don’t want your user scrolling and then seeing blank  spaces where your images should be, right? Um browsers used to be worse at this. They’ve gotten  better, but it’s still pretty aggressive. They’ll load up to 2500 pixels below the screen. So,  that’s an additional typically two and a half pages worth of images that they’re loading. Um,  plugins on the other hand, I know ours for sure loads one more screen of images, about a thousand  pixels. Um, so I think that’s a nice middle ground and so that’s why I use a plugin um among other  reasons. Um, but that’s beyond the scope of my talk for today. But background images and um  being less aggressive with the the preloading of images off the viewport are the two big ones I  would re um that come to mind. And when it comes to background images, um, U Image Optimizer  and WP Rocket are the two best options that I’m aware of since they both support background  images loading from external CSS files, which is a tricky thing to do. Uh, but both of those  will do that. And if you know of another one, feel free to drop it in the comments for everyone  else to um, be aware of that. That would be good. All right. So, either way, whether you’re using  browser native or a plug-in, just make sure your   images are properly compressed and make sure all  of them are actually lazy loaded. And on the topic of compression, there’s one last thing I think  most sites should do because it’s free, which is to convert images to a format like WEBP or AI.  This can shave an additional 25% off your images, possibly more with AIF, which is definitely  nothing to sneeze at. We can convert any ping or JPEG image to WEBP with any of the three  plugins I mentioned, uh, Imageify, Short Pixel, and our U image optimizer. And that’s done usually  with just a bulk optimization. and you turn on the web webp option, WEBP conversion, run the  bulk tool, and boom, you’ve got WEBP copies of all your images. The last step to that is turning  on a delivery method. Um, in Imageify, they have uh serverbased rewriting, which we also have,  which is the best if you can use that. Um, but then there’s a a picture-based mode that  both plugins have. And then we also have a   JavaScriptbased one which integrates with the lazy  loading. If you’re going to lazy load your images, you can also use it to uh conditionally  load WEBP. So, it’s pretty slick for that. However, now that I’ve said all that with WEBP  and image compression, there are several CDN-based image optimization options which can make this  whole process even faster and even more of a quick and fast fix. In our plug-in, we have the aptly  named, creatively named Easy Image Optimizer CDN. Short pixel has what they call adaptive images  or short pixel AI and another popular option is optimal from the folks over at theme. Generally  with these you turn them on they automatically rewrite your image URLs on the fly and you  really are done. All the image optimization is done without altering a single local image. And  this method gives you some cool superpowers too. If you don’t like the default quality level or  you decide you don’t want WEBP or you want AIF, you can change those things quickly and it applies  to every single image instantly. Super cool. Next up, we have our JavaScript. So, we have  a couple things we can do uh towards our goals here. Uh first of all we can compress it like  we said before with gzip or brley. Um we can also minify it so that it looks something like  this and is completely unreadable by humans. Um, so basically what we’re doing, we’re stripping  out all the extra white space. And depending   on the minifier, if you’re doing it kind of  pre-production, it’ll rename functions, it’ll rename variables and into a lot of times things  with onelet names like you’ll see in this example. um kind of post optimizers uh like you’ll  see in plugins that do minification will mostly just be doing whites space uh removal  because they don’t want to blow up and break your JavaScript not knowing which variables  need to stay and which ones can be modified. And then the third thing we can do with our  JavaScript um is we can defer it. Um so backing up just a hair. There’s a lot of plugins that do  minification. So just pick one. Most of them are, you know, pretty solid on that side of things.  Most plugins and themes will already have their JavaScript minified. But if you do happen to  have some unminified, like I ran into on my demo site that I was testing, um like I said,  there are plenty of options. Odd optimize our Swiss Performance and Perf Matters are just a few  examples. Um but yeah, so back to render blocking. This is a really big one and that is does the  browser have to run any JavaScript before it can render the page? We want the answer to be  no, but on most sites the answer is yes. So, we need to defer or delay that JavaScript. And let’s  talk I might have gone too far. Yes, I did. Sorry. Um, so deferring runs the JavaScript automatically  after rendering. Delay mode runs it after the user interacts with the page. So if they click on the  page, if they start scrolling, those sorts of things will trigger delayed JavaScript loading. I  don’t recommend doing all of it in delay mode. Um, I like a mix where we defer everything and then if  there’s things that are completely non-essential to the the page, um, like things that happen in  the background or can happen later on, like we have a form in the footer of our web page, that  definitely doesn’t need to load right away. So,   we delay that instead of just deferring.  And so, that gives us even more of a a speed boost. It prevents resource contention  when we’re loading all of our JavaScript. So, in theory, we just use a plug-in to  add a defer attribute to all our scripts,   but it can be a tricky thing to get right  depending on your site. The main thing to watch out for is JavaScript errors from inline scripts,  and that’s the slide I was on before. JavaScript errors are not pretty and not always fun to figure  out what’s going on. Um, so if you have if you’re deferring JavaScript, definitely look out for  this. Check it before you defer anything just to make sure you didn’t already have JavaScript  errors that weren’t a big deal. Um, you might   have something that isn’t needed for a given  page and so whatever it needs isn’t there and it throws in an an error and says, “Hey, I can’t  do this.” Um, not a big deal. Uh most JavaScript errors you should probably sort out, but every  once in a while uh there are those that are not critical. But then again, after you defer, check  for errors and uh get rid of those. Make sure everything is working correctly when you defer.  Um and the the biggest thing that we run into, as I I think alluded to a little bit, is with  inline script sections. A lot of times those will rely on external JavaScript resources.  And so if you don’t defer the inline stuff and you do defer the external, soon as the inline  script goes to run, it goes ah I don’t have my friend that I need to run and it throws an error.  Some plugins will take care of that by deferring inline scripts as well. Um we do that with Swiss  Performance. I believe WP Rocket does that and I honestly don’t know of any other plugins that do  that. Um, there might be some and again you can drop a comment in the chat section there if you  know of a plug-in that defers inline scripts as well because that’s a a great win for not causing  these sorts of errors. It can be tricky though um because there are a lot of creative developers  out there we’ll call them and we just fixed yet another quirk with deferring JavaScript in Swiss  Performance last week even. So always always learning something new and finding some new way  people are doing things and breaking JavaScript. So when it comes to CSS, uh we have a little bit  of the same but with a bit of a twist. Of course, we have our compression, which should already  be done at this point. Uh we can minify our CSS, which often is going to be done with the  same plug-in we used for JavaScript and then preventing it from render blocking. See, there’s  a problem. We can’t render a page without CSS. So there’s a bit of a dilemma. If we defer all  of our CSS to prevent it from render blocking, we’ll get a pretty ugly page. It’ll look  something like this where there’s no CSS, no styling, nothing. Now, it’s not forever. It’s  usually just for a second or half a second. Um, and we call this a flash of unstyled content  and it’s not great for user uh user experience. It causes layout shifts and all sorts of that I  believe Amber talked a bit in the accessibility section. Um, so definitely something we  want to avoid. But how do we do that? Um, so what we can do to avoid a flash of unstyled  content is either generate critical CSS, which is the the styling we need for the  above the fold section, all the part of the page that’s on the screen, or we can uh use  a method that WP Rocket has, which is to remove all unused CSS and take just the used stuff for  that page and dump it in line into the HTML. The only downside is that then none of your CSS  is cachable by the browser. So every single page needs its own CSS generated uniquely. Um it  causes the page weight to go up a little bit um not substantially usually um but a  little bit and of course that depends   on the complexity of the page. But because  of that, because of the caching issues, I prefer generating critical CSS so that  we’re just inlining a little bit of CSS and that’s what we do in Swiss Performance. But  ultimately, either one will get the job done. Um, you just do need to watch out for um any CSS  that is kind of for hidden elements like if you have a hover menu or some other stuff on the  page that is revealed through user interaction, the styling for that might get missed um  when you’re doing the remove unused CSS. So,   you might have to whitelist that or exclude  that from a feature like WP Rocket is using. And how are we doing on time? All right, I  think we got time for fonts. So, a couple quick fixes for fonts. Um, there’s usually  if you’re using the WAFT 2 format or WAFT, um, I think there’s another one. Maybe it’s just  those two. Those two are already compressed. Effectively, they’re basically using gzip for  fonts. Um, that’s there’s a little bit more to the WAF format than that, but that’s that’s  the long and short version of it. Um, but when we have fonts, we can also get another acronym,  which is a flash of unstyled text, a fo t. Um, and so to help prevent that and again improve our  user experience, not necessarily a speed issue, but a a experience issue, we can preload um one  to two of the top fonts that we’re using. Um, specifically, we want the ones that are um being  used in our above the fold stuff. And again, I would limit to no more than two. And you can do  that with uh plugins like Swiss Performance. Um, I WP Rocket might do it. I know Perf Matters  um has preloading and I’m sure lots of other performance plugins have that as well.  The other thing that we can do with fonts, especially Google fonts, is to inline the  CSS. Um, so especially with Google Fonts, they have traditionally loaded the CSS  from one domain, fonts.googleapis.com, and then they load the fonts from another domain,  fonts.gstatic.com. And that sounds innocuous enough, but it also causes extra HTTP requests  and extra DNS lookups. So in the interest of expediting the font delivery um plugins like Swiss  and um OMGF optimize my Google fonts can inline that CSS and then the only request that needs  to happen is for the external font file itself. And not surprisingly um if you’re using a  WordPress block theme that’s what they already do. um they locally host the fonts and they inline  the CSS right in the HTML. So that way there’s no external requests for the font CSS. All you got is  the font files and you’re good. Um and Swiss will also give you the option if you want to locally  host for privacy. Um I think that’s kind of a no-brainer. uh because there are no performance  benefits anymore to using this idea of oh I use Google fonts and so every site that uses it has it  cached already. Well nope they killed that because   of security reasons. So now every site has to  load its own fonts whether you’re loading them from Google or your own server. So that’s all I’ve  got and so we’ve got time for questions and I will Thank you very much and thank you for  the presentation. Very good insights,   a lot of tools to basically um  try out and explore them. So uh when we have a couple of questions to  look into. So first a question of Eric. He was seeing he was asking where do  you see the the furer and delay errors like if there’s JavaScript errors I’m assuming um  those would be right click on the page. Oh yeah I didn’t specifically say that but that’s in the  de developer tools. Right click on the page click inspect and go over to the console section.  the console is where you will see JavaScript errors. And like I said, it can be a little  bit tricky to diagnose sometimes because you   might be seeing the trickle down effect of  something else that’s being deferred. Um, so a cool thing that we have in Swiss is we  have a front-end menu that lets you see the   dependencies of different scripts. So you can  say, hey, I’ve got an error with this script. You can look it up in the Swiss control panel and  see, oh, it requires this script and this script. And so excluding one of those might be what you  need is those dependencies is what it needs for um for it to work properly. Thank you. Another  question of Fernando. Should images always be converted automatically by plugins or is manual  optimization still better? Uh manual optimization I’m guessing like pre-upload to WordPress.  Um, you can do that and I definitely not not a problem with doing that. I’ve gotten kind of lazy  because I have a plugin that does it for me. So, it’s like why go through the hassle of doing it  manually when you can just have a plugin do it. The other side of that is when WordPress generates  thumbnails, you’re more likely to be loading those on a browser um than you are to load the original  full-sized image. And those definitely need to be optimized and WordPress cannot optimize them by  default. Um it’s just a limitation to the way uh Image Magic and GD work. They optimize for  speed. They don’t use the best uh compression even losslessly. You can usually get uh savings  out of those thumbnails. So, I always recommend using a plugin uh for that reason because of  the thumbnails, not just the little thumbnail, but you know, we’ve got the medium size, the  large size, there’s a 1500 now and a 2,000. They’re all over the map. So, and um specifically  a question around your uh plugin. So can E www image optimizer API be used to automatically  convert images to modern formats like webp or a during image or during optimization. Yeah. Um with  the EU image optimizer we actually have it set up that webp can be generated for free whether that’s  locally on your server. So, if your um server has image magic or G it can work with GD, but some  servers have really old versions of GD that don’t work with WEBP very well. But especially  if you got image magic enabled on your server,   you can do it all locally. You don’t even need a  third party API. But if you’re stuck in this weird middle ground where you can’t even do that, um  we we allow free and it’s just built in. It just works. um free access to our API to generate uh  WEBP images. Um and then of course for our paid customers, we have both WEBP and AIF on the CDN  side of things. So it’s just automatic. You turn it on and poof, you’ve got WEBP images loaded  on your site. Great to hear. And um what are basically the common mistakes when uh what people  make when they are optimizing images in WordPress? I don’t know how common this is, but I think  there’s a kind of a misleading uh advice when Google tells us to not lazy load our above  the fold images or our LCP image. And so, one thing you got to watch out for is are  those images being properly scaled? So, it’s easy to overlook that you might have  an image that’s displayed at, you know,   say 300 by 400 or whatever. and you uploaded a  1200 pixel image. Well, that’s three times bigger than it needs to be. And in 2D, that’s actually  about nine times larger than it needs to be. So, that’s not good for performance. And if you  don’t lazy load that, um there’s nothing our   plug-in can do to help. And so, that’s one  of the things that I I kind of alluded to, but I said, “Well, that’s kind of outside the  scope.” But we have an automatic scaling option built into our lazy loader that will allow it  to properly scale those images for you. Um, so that’s kind of a tradeoff. If you don’t want  to lazy load those images, then make sure they’re   properly scaled. if you don’t want to waste  time with properly scaling them. And honestly, it took me probably two hours to to and I’m kind  of OCD about it, but it took about two hours just   to get one image on our homepage properly scaled  and build the responsive markup and every and make sure it was just perfect. Yeah, like I said,  little little OCD there, but it can take some time. So, if if you don’t have that time, just  let a plug-in do it and don’t worry about it. And uh maybe also related to that one, but more  related to the CSS. So uh do CMS optimization plugins actually help performance or can they  sometimes create more problems? Could they create more problems? Um I one example that I I kind of  talked about is with delaying JavaScript. I think that has the potential to create problems because  you’ve pushed all of the JavaScript to a single action. As soon as the user clicks on the page or  starts to scroll, boom, it starts doing stuff and now it’s the browser’s busy doing that stuff and  if they click on something or try to, you know, or if they hover, none of that’s happening because  it’s busy executing the JavaScript that you said to wait until user interaction. So, I think that’s  one one area that we can kind of shoot ourselves   in the foot and go, “Huh, whoops.” But we don’t  know it because the speed test will go, “Oh, yeah, you’re cool. There’s no JavaScript on the page.  Well, there is. It’s just not loading right away. Um, yeah, I forgot what it was already. There  was something with the last that I wanted to add, but oh well. Maybe it’ll come back to me. Good.  Good. I’ll do two more questions. So, uh, in your   opinion, which image format is currently providing  the best balance between quality and performance? I think still as far as like if you want  the ultimate quality, JPEG is probably still uh kind of the king there, but for balance,  I would I would go with WEBP. Um, Avis, AIF is pretty solid. Um, but not the the big  thing with AIF that drives me crazy is the performance implications of it. It is super super  slow to compress and super CPU intensive um to the tune of like 10 times more than WEBP. It’s  it’s pretty bad. So we have to put some really big guard rails on our AIF compression on the CDN  just to make sure it doesn’t overwhelm servers and stuff. So okay. And then the last question. So  um basically um in uh which quick optimization uh techniques uh are usually giving the biggest  speed uh improvements with the least effort. So basically how can we get the largest reach with  the minimum time? Um page caching is definitely I think top of the list like we saw you know  going from 3 to 4 seconds or worse to under a second is just fantastic. um compressing images  doesn’t help as much as it used to because of lazy loading. So lazy loading of course is a big win.  Um and like I said, if you’re using WordPress, that’s built in. Awesome. Fantastic. Just make  sure it’s actually getting all of your images. Um and then on the render blocking side, I would  probably lean towards the JavaScript because it’s easier to deal with. you don’t have to generate  the, you know, critical CSS takes some time to   generate and then if you muck around a whole bunch  with your homepage, you got to regenerate it, which doesn’t take forever, but it’s  just one more thing to remember. Um,   so I I would probably say those three,  page caching, um, lazy load, and deferring JavaScript. Thank you very much. Thank you very  much for your insight. You just always compress everything with gzip and minify all the things  just because it’s kind of a no-brainer. Thank you and um so thank you for the very much insights  and we go very soon to the next presentation which is why good enough performance is no longer  good enough. So stay tuned. Thanks everyone.