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.
Show Notes
Brian Richards
WPSessions
Episode 16: Improving Performance on Your Website
WordSesh
Inside the Magic
Zack Tollman
Using Chrome’s Networking Tab
Josh Koenig and Pantheon
Transcript
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
