Episode 17: Applying Performance Improvements with Brian Richards

In the episode we talked about ways to improve performance. Now let’s look at how we can apply that advice. Brian Richards, an expert WordPress developer and educator over at WPSessions tells us how he has improved the performance of both his own sites, and client sites. Listen to the episode.

Show Notes


Joe Casabona: Hey, everybody. Welcome to Creator Toolkit. Last time we talked about the importance of improving website performance, and we looked at a few ways to do that in a very high-level manner. In this episode, we are going to talk about that in a very practical manner. So, welcome to Creator Toolkit. My name’s Joe Casabona, I am your host, and we have a very special guest with us today. My good friend Brian Richards of WP Sessions. Brian, how are you today?

Brian Richards: I’m doing well. Hello, internet. Always good to be in your ears.

Joe: Thanks. Absolutely. Thank you very much for joining me, Brian. Brian proofread, or at least spot checked the script for the last episode to make sure that everything was more or less factually correct. I chose Brian to do this because he, as we’ll find out in a moment, has a lot of experience with getting website load times down to the hundreds of milliseconds as opposed to seconds, which is where most people hang out. Brian, let’s start off with a little bit about who you are and what you do.

Brian: Perfect. As you said, I am Brian Richards, and I run WPSessions.com where I provide training for WordPress professionals. A lot of it is WordPress related, but a lot of it is just other industry things to make us more well-rounded developers who are working with WordPress and business owners. From that, I have expanded into virtual conferences, so I also run WordSesh which is a full day-long virtual conference that people can watch from anywhere in the world, and WooSesh. WordSesh is focused on WordPress professionals, just like WP Sessions. Then WooSesh focuses even more specifically on WooCommerce store builders. So, whether you’re a developer or someone who is just good at assembling plugins and finding all of the right tools, that’s the audience for WooSesh. A lot of the performance and fine tuning I’ve done have been for those sites, and I’m going to bring some of that as well back into WP Sessions, but much like the cobbler’s kids who have crappy shoes my own site lacks a bit of speed and luster that I’m able to provide to other people because I’m so busy doing it elsewhere.

Joe: Indeed. But you did some cool performance optimizations for, as you said, WordSesh. Which I thought was cool. We’re going to talk about two different projects here, but to set the stage, some of the things that I touched on in episode 15– I believe it is, I should probably know that and have written down– Episode 16. See that? What we talked about in episode 16 were things like good hosting, making sure your images and media are optimized. We touched on lazy loading, third-party scripts, minifying the critical CSS and then combining files as well as cache. So, why don’t you take us through? This is a pretty short form podcast but talk about some of the practical things that you did or that you can do as a non-developer, as well as some of the cool things that as a developer you did.

Brian: Yeah, I’d be happy to. I should preface this by saying all of the smart things that I’ve done and know how to do, and I lifted directly from my friend Zach Tollman who I consider to be a true performance wizard. He works for Wired and has done lots of awesome stuff, including a multi-hour course on WP Sessions on optimization and performance tuning for WordPress sites that blew my mind. If you want to learn how to do this, his stuff is the best, Zach Tollman. Like I said, you can check it out on WP Sessions, and you can check out his writings elsewhere. From that, I distilled a few actionable things that I could do on WordSesh. The things that I could do here are a lot better than what I can do for a number of different client sites because I am in full control of the entire experience. One of the concepts that Zach has that I’ve borrowed from often is this idea of setting a performance budget. “What is your ideal page load time? Your page wait? How much data do you want to deliver?” And using that to consider all of the things that you could do. “What’s going to have the best impact?” And most importantly, on all of the things that you can’t change, where do you need to find savings elsewhere in order to hit your ideal performance budget? So all of the things that you listed off there, Joe, from your previous episode are things that I employed one way or another on the WordSesh site. I got rid of scripts that were unnecessary, and I modified the ones that needed to be kept. Another important thing to consider as you work on performance and optimization, not every tactic will work the way you expect on every website. Sometimes it makes a lot of sense to combine files into a single payload because you can minify and compress those even further than having them as separate files. Other times, it’s going to work out in your favor to have lots of separate files because maybe you only need to load a few of them on one page, and a different set on another page, so your overall payload is going to be smaller because you can be more selective. Instead of bringing everything with you on every single page just in case you need it there because everything got combined. HTTP2 helps this quite a bit because you can thread and bring in things concurrently. I bet you were about to interject that.

Joe: Indeed I was. This is a little bit hairy because it also depends on your host. Some servers support HTTP1, some support HTTP2. The analogy that I like to use there is HTTP1 is essentially one person who needs to fill the well by going to the river, so he has one bucket, and he goes, and he brings as much back as he can carry. But for every time he has to go, that takes time away from filling the well, or it takes longer to fill the well. HTTP2 is employing five or six people to go to the river to fill the well. It’s going to take seemingly less time, but again, they can only– Their time will depend on how much they can carry.

Brian: Yeah, exactly. The fiddly thing about this is you have to try optimizations a few different ways and measure them repeatedly to see if you’re getting the outcome you want, particularly when we’re talking about sub-500 millisecond page loads. Sometimes it’s just a matter of the route that your computer takes to get to the assets will have more dramatic shift than anything else you can do on your end at all. That’s certainly the case, and I’m proud to admit with WordSesh. I can routinely get it loading in at around 300 milliseconds, which is right about the pace for an instantaneous or barely perceptible load. However, at different times of day, it might take 700 or 800 milliseconds, which many of you listening might still be thinking “That’s crazy fast.” But for me, who can sometimes get the site to load in 300 milliseconds, to almost triple that is agony. “What else could I fix here?” For example, on the current page which will probably have changed by the time you hear this, there’s an email opt-in form provided by MailChimp. They provide a nice little JavaScript file for validating email, and one of the things they do is bundle all of jQuery and jQuery UI into that JavaScript file. I have taken it from their server, compressed it where I could, and served it out via my own to get more of the benefits of my own server’s speed. Not to mention a smaller overall file size. I could rip out jQuery and rewrite the thing to be vanilla JavaScript and make it even smaller, but at this point, it’s only contributing anywhere from 50 to 100 milliseconds of page load. At a certain point, you have to wonder “Am I crazy for wanting to eliminate 50 milliseconds off of this thing?” When we ‘re– If your goal is speed at all costs, then yes. Because that is sometimes the bottleneck on the page load if you look at the Chrome network tab and watch it load things in. But other times it’s not. There are a few SVGs on the page for example that have a heavier footprint than that JavaScript. It doesn’t necessarily matter that it could be a few kilobytes smaller and knock off 50 to 100 milliseconds. There are other more important things to focus on.

Joe: I’m going to interject here and say that’s a great piece of advice that you just gave there. One thing that I noticed with my own site was Convert Kit, loading native Convert Kit Forms on my WordPress site is very heavy and very taxing. I was able to instead use Ninja Forms Convert Kit integration, so I built a native form and then on the backend without loading anything extra from Convert Kit, Ninja Forms sends that information via Convert Kit’s API. I was able to save quite a bit by just not loading Convert Kit at all on the website, and taking advantage of some other tool that does it without the user having to load anything.

Brian: Yeah, exactly. It’s a series of tradeoffs and tests, is essentially how optimization works. You’ll come up with a plan of saying “OK, I need to minify these images. I need to pull out the most important CSS that is responsible for the first 800 pixels of what is loaded on the page and put that directly in line in the head, and then the rest I’ll break apart and only load the CSS that I need, etc.” To have all of these ideas of things to tackle and then you’ll need to test each one, one at a time. Sometimes turning on a CDN is going to make things so much faster, because those assets get delivered closer to each person’s home. You’ll get other benefits like CloudFlare does a lot of really slick things to make things faster, but sometimes combining that with another optimization you made makes the whole thing slower, and it’s counterintuitive. If people have one take away from what I’m saying here, performance and optimization tuning is very counterintuitive, and you’ll likely not use the same technique or same set of techniques on more than one site in a row.

Joe: I think that’s super important. If you think of each website as a house, you can’t just say “All right, I fix this house by doing these five things. Now I’m going to do the same exact five things to this other house.” You need to get the house inspected and then determine what needs to be fixed. This analogy brought to you by the fact that I’m in the middle of buying a house right now. I think that’s fantastic advice. The mention of a CDN, I thought was interesting, because I think that there’s some not necessarily confusion, but people lump CDNs and maybe cache in the same bucket. A CDN is essentially, let’s say you’ve got a grocery store five minutes from your house. You have a grocery store let’s say, 10 minutes from your house that you always go to. Then they decide to put one five minutes from your house. Now your travel time is cut in half. That’s almost like what a CDN is. It’s your assets are somewhere, and then you add a CDN, and the assets from your website get put other places so that the users don’t have to travel as far to get those assets.

Brian: Yeah.

Joe: Now, are you employing caching on WordSesh and on the other project that I don’t know if you’ve mentioned by name yet?

Brian: I am. The other project that I thought I’d parade out in this is a website called InsideTheMagic.com that focuses on theme park news and video games and other entertainment outlets. Yes, I am using caching. Caching is employed on both of those. I can tell you that WordSesh is currently hosted on Pantheon, and they provide some very fantastic caching built into their platform. A lot of really cool stuff which is why I went with Pantheon in the first place. Then Inside The Magic is currently LiquidWeb, who also provide a lot of really cool things out of the box. The caching layer though, I operate with it off while I’m doing all of my performance tuning. Caching is the last thing. You want to make a site that’s fast without caching, and then add caching to make it faster still. I have both object caching so that the queries to the database can happen more quickly because they only have to go to memory instead of running a fresh query. Then full page caching, so it’s essentially serving out a static HTML file after it’s been generated, which takes everything else out of the equation. Zach Tollman has another great analogy similar to the one you just made with grocery stores, which is if you think about caching like creating a meal. The very first time you make the meal if you have nothing in your pantry, you have to go to the grocery store and buy all of the ingredients that you need. Then you can prepare the meal and enjoy the meal, so it takes a very long time. But now you have leftovers that you can put right in the refrigerator, so the next time you want the meal you have to open up the refrigerator and reheat those things. It’s a lot faster. Then when the leftovers are gone, you still have the ingredients that you used to make the meal so you can make them from the ingredients. It takes a little longer, but not as long as it took to also go grocery shopping. Then when you eventually run out of those ingredients, you have to go back to the grocery store and start all over. Those are a great analogy for the different layers of caching that are available to you from object caching, which is like the ingredients, and static page caching, which is like the leftovers where you can serve them much more quickly and if they’re gone now you just go one step further and get things that are still partially cached and rebuild from there. Caching is important, but it’s the last layer because getting everything else right is more important, so that when you have a stale cache or your cache is expired those first few folks aren’t stuck and lost without it.

Joe: I think the big takeaway from that, and my analogy is that I want to go to the grocery store and get some food.

Brian: Yes.

Joe: But actually, that’s a fantastic piece of advice. Caching should be the last layer. It shouldn’t be a crutch, and it should be an enhancement on top of everything else you’ve already done. I think that’s great. So, why don’t we wrap up by talking about– You’ve worked a lot within the WordPress ecosystem, both of these websites are WordPress powered. Are there any tools that you recommend for some of the non-developers listening that could take advantage of some performance optimizations using what WordPress has to offer?

Brian: Yes, I would be glad to talk about that. One of the things that like I said I could do with WordSesh that I couldn’t do on a client site because I control the stack, I could get rid of jQuery, and the WP embed scripts. I’m using WooCommerce and was able to get rid of all of its styles and scripts on the home page and any page that wasn’t a WooCommerce page because I knew that I had isolated all of the e-commerce stuff only to the e-commerce pages. I was able to get rid of the emoji support, there’s an extra bit of JavaScript that gets loaded to handle emojis sometimes in WordPress, and I didn’t need that because I knew I wasn’t using emojis. It’s a tiny thing, it’s not something that rational human beings need to be concerned about, but it is one more asset that needed to get loaded. So, I could get rid of that as well. For all of these I was just in my themes functions file calling WP de-register script for all of the scripts, and then WP de-register style for all the styles that I didn’t need. I could get rid of a bunch of stuff. For people who are not programmers, but do have a WordPress site, there are a number of plugins that you can use to selectively get rid of scripts. If a plugin is including a script, you can say “I don’t want to include this one.” Even if that plugin itself doesn’t provide an option to get rid of the script, these other ones that are– There’s a bunch. If you search optimize in the WordPress plugin directory, you’ll probably find quite a few. Like WP Optimize, Optum, Zilla I think is one that might– That’s an image compression site. But there are a number of plugins, and you don’t have more than one, because they’ll step on each other’s toes. But they will help you get rid of scripts and styles that you don’t need to load, and they’ll help you to minify and then compress the scripts that you do need to load. Sometimes concatenate, so combine them together and then minify and Zip them. Those are very handy. Image optimization is a huge one. If your site has a lot of images, optimize those. If you, like me, have used Photoshop for a decade, Photoshop includes a ton of data. Even when you save for web that bloat the images. A website like Optum, Zilla or Kraken, Image Kraken I think is its name.

Joe: Yeah.

Brian: There are quite a few, and there are some that even offer plugins. Every time you upload an image into WordPress, it will automatically run it through the compressor. Get rid of that extra metadata, the additional layer information that isn’t– Not layer information but pixel data that is not needed for showing that thing. They make a huge difference if your site is image heavy. In my case, on WordSesh, I didn’t have any images. I could convert everything to SVGs, and those are super lightweight. Some of them weigh in at less than a kilobyte. The others are just a few K for what ends up being a nice layered nature illustration. So, that was pretty cool. A lot of people can’t get away from images and go SVG only though, so optimizing images is big.

Joe: Right. I do want to point out there that WordSesh is beautiful. I’ll like everything in the show notes, which you can find over at CreatorToolkit.com/017. But it’s beautiful, and it’s nicely optimized for those reasons that you’re using SVG, which describes the way an image should look as opposed to embedding hard pixel data.

Brian: Bingo.

Joe: I think that there’s a lot of really good advice there. I will be sure to link everything that Brian has mentioned in the show notes, again over at CreatorToolkit.com/017. So, Brian, I’m going to put you on the spot here as we close and I’m going to say– I’m going to ask you if there is– I have a website, I haven’t optimized it at all, what is the first step that I can take in my optimization journey?

Brian: To figure out how much less stuff you can put in your website. That is probably the least obvious, but also most important thing. There are a lot of things that you might realize you’re loading in your site that isn’t enhancing the visitor experience at all, isn’t something that you’re using. Including perhaps an analytics or multiple analytics services. Each of those bring it– I mean they’re tiny, but it adds up. If you’re not actively monitoring that data, why are you collecting it? So figure out how much less you can load, and then if you have a bunch of things that are critical that you can’t get rid of, the next thing to figure out is “How much of that needs to load on every page?” The easiest wins, as I just mentioned at the end, optimizing images and optimizing your scripts and style sheets so that they are compressed. Rather, minified, compressed, and only loaded on the pages that they are needed will probably make the biggest difference. Then turning on a CDN, if that makes sense, a lot of hosts include that automatically these days. Most have a relationship with CloudFlare, and then finally turning on caching. Both object caching to make the raw database queries faster, and then whole page caching. Some hosts will call this by what it is, and varnish caching is the tech behind the scenes that’s doing that. That whole thing will make– That for sure makes it fast, but that doesn’t solve the problem of why it was slow in the first place. So, solve those problems and turn on caching, and then everything is awesome.

Joe: Awesome. Brian, thank you so much for joining me today. I appreciate it. Where can people find you?

Brian: It’s my pleasure. I am often hanging around on Twitter as @rzen, or the best place to find me is on WPSessions.com where we host new training sessions every month.

Joe: Awesome. Again, I will link all of those in the show notes. Thanks so much for listening to this episode of Creator Toolkit. Hopefully, you got some great actionable advice from my good friend Brian Richards. For all of the show notes, head over to CreatorToolkit.com/017. If you liked this episode, please share it. Let somebody know how they can optimize their website. My question of the week for you is “What’s the number one thing that you learned in this episode?” I want to hear about that, so let me know Joe@Casabona.org or on Twitter @jcasabona. Thanks so much for listening, and until next time get out there and build something.

Originally published on Creator Toolkit

Leave a Comment