Moeez: And we are back, folks. My name is Mo, as you may all remember me from yesterday, I am one of the co-hosts for the performance boot camp this year along with Danish, and what a fantastic day we had yesterday. Day one performance boot camp, sessions from Sabrina, sessions from Amber, a lot of different guest speakers, and I want to thank them all for being here yesterday and enlightening us with their performance knowledge and expertise. Today we want to continue that momentum, and we have so far had two amazing sessions previously, and now we want to turn our attention to a panel discussion, and it’s a live performance teardown. So if you are someone who works in the performance space, who has different clients facing performance issues, this panel discussion is for you.

So before we begin, I have a few announcements to make. Just a reminder that we have a leaderboard which is active, and you can climb that leaderboard by asking questions in the chat and interacting with the guest speakers during the session, so that you can climb the leaderboard and, you know, get a chance to win some amazing prizes. And apart from that, we have amazing partners that have partnered with us in this performance boot camp, who I also want to thank and appreciate.

The topic of this panel discussion is live teardown, and it’s from Nat Miletic and Matt Zeunert, and I want to call both of them on stage now and would like them to sort of give their introductions to our audience. So Nat and Matt, if you can just, one by one, give your short intro to our audience, let us know what you’re up to nowadays, and then we can quickly start off with the panel discussion. Thank you.

Nat Miletic: Yeah, my name is Nat Miletic. I own a company called Clio Websites. I’ve been in the WordPress and agency space since probably 2007, and excited to be here today and talk about performance.

Matt Zeunert: Cool. Yeah, thanks. So, yeah, I’m Matt. I own a company called DebugBear, so we do web performance monitoring, and yeah, I’ve been spending the last like eight years or so kind of working with, you know, consulting clients, kind of users, trying to help them improve their performance.

Moeez: Awesome. I want to thank you both for being here on this stage and enlightening us with your performance expertise and knowledge. I want to quickly jump on to the first question of this panel discussion, and my question is from you, Nat. And the question is, when a client says my site is slow, what’s the first thing that you check? Like when a client is sort of complaining that my site is not performing up to the mark and the load time is not there and the performance benchmarks are not getting met, what is the first thing that you want to check on the client’s website?

Nat Miletic: Is it just me, or, I’m sorry, I was muted. Can you hear me okay now? Okay, thank you for that, thanks for the nudge. So yeah, when a client says my site is slow, the first thing we do is we run a quick audit. It could be slow sort of from a front-end perspective, it could be slow in the back end, you know, when they’re trying to make changes, or they could be referring to something like, more from an SEO perspective, they’re seeing maybe PageSpeed Insights showing them that it’s not meeting Core Web Vitals, for example. So it could mean a lot of things, you kind of have to peel the onion a little bit. It also depends on how, I guess, technical and knowledgeable your client is, right? Some people might say my site is slow and mean that it’s like, you know, slow to open up on their device or whatever, and others might mean something very specific. So what we do usually is we check visually what’s going on with the website, we check on a few devices, we log into the back end, do a quick sort of audit, and then we also use primarily PageSpeed Insights, which is a Google performance testing tool, to see, you know, what kind of metrics we’re seeing, more from the lab data and the actual real-time data, and just kind of compare and see what’s happening. So usually that’ll give us some clues as to, you know, what to tackle next.

Moeez: Awesome. Matt, I want to turn our attention to you now for a second, and, you know, I know that you analyze a lot of slow sites. Based on what you do, how do you prioritize what to fix first? You come across a slow site, there are multiple issues on it, but how do you prioritize that this is the issue that I want to fix first, and then this comes second, and this comes third? So what does the prioritization list look like for you?

Matt Zeunert: Yeah. So I think it’s basically two bits. Like, one is kind of finding what pages should we optimize first, and then it’s like looking at those pages and seeing, okay, what are the most impactful changes that we can make. And yeah, in terms of identifying pages, probably just looking at some of your most popular pages is useful, and then seeing how well are those performing. And then if you look at various like real user data sources, like if you look at Search Console for example, you can often see specific URLs where, you know, that people are having problems. And then once you kind of know what the pages are, you can kind of start optimizing those.

And then, yeah, beyond that, generally I would kind of start, run a bunch of automated tools, like PageSpeed Insights, DebugBear, WebPageTest, and they typically give you specific recommendations that are already kind of prioritized. And hopefully, you know, they are kind of specific enough and they make sense for your website that you can actually apply them. If you actually have a developer involved and you kind of need to, like, you know, go the extra step, then you just really need to understand, like, why is my website rendering the way it is? So you need to kind of look at, like, what is the specific set of resources that are loading on the page, how are they related to each other, what’s triggering one request and then another. And then once you know the exact sequence of events, then you can look at how do you compress that sequence and avoid, you know, how can you prioritize the really key critical part of the page load process and maybe load some other content that’s not as important later on to not kind of cause performance problems.

Moeez: Awesome. Nat, a few things obviously that you do on a daily basis, but at what point do you stop optimizing and recommend rebuilding? So at what point do you think that a website becomes so sluggish and so problematic that optimization doesn’t work anymore, so you recommend that you start from scratch again? What does that point look like for you?

Nat Miletic: Yeah, it’s usually fairly evident, you know, when you get a new client and you’re troubleshooting performance issues, you know, whether or not a rebuild is the next course of action, that’s typically, by, you know, looking at sort of, in the WordPress space specifically, you know, how many plugins they’re running, how old the website is in terms of like how much technical debt there is. So there’s usually a number of factors. One is, you know, a number of plugins that they’re using. Sometimes it’s the tool set, for example, that they’re using, if they’re using an old version of like a page builder that’s no longer supported, or something that we know doesn’t necessarily help with performance and necessitates a rebuild, where it’s a little bit more cost-effective and resource effective to do it that way. Those are kind of the things that we would look for.

A lot, usually it’s centered around like tech debt. So what happens typically is, people, you know, if they’re using an older tool set to build their website, and that tool set is kind of ingrained in the website, so for example it could be like a builder or like a theme that they’re using that, you know, creates a lot of bloat or requires a lot of different plugins in order to run, those are the types of things that we would look for and then advise the client to recommend rebuilding the website to alleviate those issues. Because you get to a point where sometimes it’s faster, you know, especially for like a smaller site that may not be super complicated, it’s probably faster to rebuild a website from scratch properly than it is to spend, you know, a lot of time trying to fix those issues. And in some cases it’s not even fixable, depending on the framework or the technical debt.

Moeez: Yeah. I want to turn our attention to waterfalls now. And Matt, obviously you spend a lot of time optimizing sites for your clients or for people that you work for, and what patterns in waterfall charts immediately signal, you know, structural problems? Like when you look at a waterfall, what are those signals that when you look at them, you say that, okay, so these are the problems that cannot be fixed from a surface level, but you want to sort of go deep into the website and fix them? So what are those signals in the waterfall charts?

Matt Zeunert: Yeah, I think there’s like a couple of things, depending on how the website is built. So, especially kind of with like, you know, a WordPress site for example, you often see like a higher Time to First Byte because people have a lot of content, a lot of plugins, all that kind of stuff. And if you see that the first request is really slow, but then maybe after that everything loads within like half a second, then you kind of need to look at what is happening in the back end and kind of optimize that.

Another factor that you often see is like sequential request chains. So you might have, you know, you need to load the document, then you load a CSS file, then you load another CSS file, and then once you’ve done that, you’re like, oh, we need to load this font. So there’s this kind of really long chain of requests that can often cause problems. Like background images are another example of that, because if you have an image type in the HTML, the browser can kind of just start loading that right away, if you have a background image that’s referenced in a CSS file, you end up having a chain with the HTML, then the CSS, and then the image.

And the third one that I would kind of look at is kind of JavaScript applications, client side rendering. So what you see there often is like a pattern that, it looks like, well, you load the HTML, you load like two or three render blocking scripts, but when you look at what the user can see at that point, it’s still like a completely blank page. And then if you kind of look a bit further, you end up seeing, okay, well, there’s like two megabytes of JavaScript being loaded, but still nothing on the screen. And you look a bit further and you’re like, oh, well, there’s another 200 kilobytes of, you know, JSON data that needs to be downloaded before the page can actually start rendering. So in that case, you often see just a lot of different files, a lot of JavaScript, but no content early on. So yeah, that’s like the third one I would look at.

Moeez: Awesome. Nat, I know, or I do understand, that you know, you might get a lot of clients with different technical abilities and different technical acumen. You know, some clients may understand the technical terminologies and jargon that you may use, but some of them might not. So how do you explain performance trade-offs to non-technical clients?

Nat Miletic: Yeah, that’s a great question. I think for the most part clients understand that, you know, you sometimes do need to make certain trade-offs in order to reach performance targets. A great example of this is, like, various trackers and analytics tools that people love to add to their website in order to, you know, track certain actions on the website, or conversions, or heat maps, or whatever. A lot of those things will add to the performance, you know, they’ll have performance trade-offs where they will slow down a website, because, you know, all of these external scripts are basically loaded and are tracking sort of actions and conversions on the website. So that’s a great example of, like, a discussion we would have with the client, to say, for example, you know, this particular tracker is causing, you know, a performance problem. We can show them using PageSpeed Insights or another tool that it’s, like, you know, creating a bottleneck, and we’ll usually, you know, chat with them about either using, you know, like less of those, do you really need all of these trackers, do you need all this analytics, or can you like settle on one, or can you use it temporarily? So we’ll have that discussion. That’s a very common sort of thing we run into, where we build a site, you know, it’s very fast from the get-go and stuff, and then they start adding things, and they forget to turn them off or remove them after they stop using them.

Moeez: Awesome. I want to touch on the Lighthouse scores now. And Matt, my question is from you. Many teams chase Lighthouse scores, and from your experience, when does a high score hide real world performance problems? Because I do understand that it’s an obsession for some teams to get the perfect scores for the website, but at what point do you think that those scores may be hiding some real issues that are lying underneath?

Matt Zeunert: Yeah, I think most of the time it’s going to be the other way around, where people are like, well, we have a bad score, therefore we must have issues, but if you look at the real user data, you know, probably things aren’t as bad as the Lighthouse score is suggesting, just because, you know, the PageSpeed Insights field data, they look at maybe the slowest 5% of visit experiences, but the typical visitor probably is having a good experience anyway. But there also, there are some cases where Lighthouse might say that your website is fine, but actually when you look at real user data, there are problems. So one, I would say, is that Lighthouse always looks at like a fresh page load, so if a logged in user gets a very different experience from, you know, a new user who doesn’t have anything cached or who isn’t logged in, then you might see in the Lighthouse score that everything is loading really fast, maybe you’re just hitting the kind of public cache, but the user, they might see all that kind of customized dashboard content or whatever, but you’re not being able to detect that if you just run the Lighthouse test.

And one challenge you also kind of run into is kind of people trying to cheat with Lighthouse. So I know for example, like a while ago, we were testing like chat widgets, and they were picking up, okay, is this a Lighthouse test, and therefore we’re just going to send an empty script file so we get a better Lighthouse score. And I think there’s issues with like, you know, WordPress kind of plugins or Shopify plugins, where they kind of just create, they fix the Lighthouse score, but they just don’t do it in a way that actually fixes the underlying performance issue.

Moeez: Awesome. Nat, I’m going to throw a very direct question towards you, and I’m sure a lot of people who are watching us have this question on their minds as well. In WordPress specifically, what’s usually the root cause of a slow website? Is it themes, is it plugins, is it hosting, or is it the design?

Nat Miletic: It’s hard to pick just one. Usually it’s a combination, or it’s very dependent on the project. Obviously hosting plays a huge role, you know, that’s one of the sort of foundational things that you need in order to have good performance. It’s kind of interesting, you know, and sort of related to what Matt was just talking about as well, you know, you can mask a lot of like performance issues and treat them as fixes, but if you’re on bad hosting, it doesn’t really matter, your user experience is still going to be, you know, negative. So it’s hard to say, like, you know, to pick one specific thing, we usually see a combination, or we usually see a root cause being one of those depending on the situation. Hosting is like definitely a foundational thing that you need.

I am of the mind that I don’t like to blame plugins usually, because, you know, you see that sort of advice a lot, like use less plugins, but there’s certain types of plugins that, you know, work just fine, and you can have 50 plugins and you can still have a fast site, or you can have 10 plugins but still have a slow site, so it doesn’t really correlate usually. The most common issues we see are, you know, bad hosting, and then from a design perspective, you know, having a lot of images, having a lot of scripts, those are usually the biggest culprits. And then themes can also cause a lot of issues, not that the themes are to blame, but sometimes inefficient themes will use a lot of inefficient plugins. When you install a theme, it’ll like install a bunch of plugins that users usually don’t know if they need them or not. So having a good quality theme that’s tuned for performance is also a foundational thing. So, you know, hosting and theme I would say are foundational things, so is the design, obviously, plugins a little bit less of a concern in my experience if you’re using the right ones.

Moeez: Awesome. So hosting, design elements and themes, and then maybe somewhere down the line, plugins as well. Nat, I’m going to throw a direct question at you as well now. Since you work a lot with agencies, what’s the most common false fix agencies attempt nowadays?

Nat Miletic: Is that for me as well, or for Matt?

Moeez: That’s for Nat, that’s for you.

Nat Miletic: Oh, okay, thank you. Yeah, our names are very similar sounding, so it’s hard to say. Yeah, so the most common false fix that we see is just applying something like, you know, WP Rocket or one of those performance plugins that kind of mask the issues, right? So we usually actually, when we’re troubleshooting and working on performance type engagements, we’ll typically, if they have them, we’ll turn those off temporarily in the staging environment just to see actually what’s going on and what’s being loaded. Because what happens sometimes is, like, these plugins are great, by the way, I’m not knocking on the plugins, but sometimes they’ll mask problems. So I’ll give you an example. You’ll use something like WP Rocket, and you’ll do like, you know, minify JavaScript, or combine, or lazy load them or whatever. So when you run a speed test, they may not show up as culprits, because maybe they’re combined, or maybe you’re not getting the full picture. But actually what you should be doing is like removing scripts and things that you don’t need, right? So it’s a false fix in a way that, you know, it might trick, kind of like what Matt was talking about earlier, it might trick PageSpeed Insights where it might look like the issue is not really evident, or that the issue is not there, but actually in the background you’re just like combining things, delaying them from actually executing. So you’re still causing issues from a performance perspective, but from, you know, like an audit perspective, it looks fine.

Moeez: Awesome. Matt, we’re sort of moving into the final few questions, and I wanted to ask you, how should teams balance synthetic testing versus real user monitoring?

Matt Zeunert: Yeah, I think it’s mostly kind of starting with kind of real user monitoring, because, yeah, ultimately that is what tells you, like, are people really having a good experience, where are people having problems, you know, that’s kind of what impacts your Google Core Web Vitals and SEO, that’s going to impact your conversion rates. So, you know, kind of all else being equal, if you’re kind of looking at one thing, it’s probably more important to know, do we have issues and what are those issues, than synthetic testing. And synthetic testing, I would say, well, it really tells you like what is wrong a lot of the time, you know, because you have much more in-depth kind of reporting. You can have like screenshots of every single paint, you can see every single request and like how much time was spent on the connection, how much time was spent like downloading different data chunks, like you just have much more in-depth data. And because you have the in-depth data, that is also, the automatic tooling can do much more in-depth analysis of what is causing performance problems, so that is one big advantage. The other thing with synthetic testing is, once you have the in-depth data, you can do comparisons, and you can very easily see, not just, well, what metric changed, but, like, okay, maybe the marketing team added like a new third party script, or maybe, you know, we shipped a new version and the new image is a lot bigger, so you can see at a much more nuanced and detailed level what actually changed.

Moeez: Awesome, Matt. My next question is from you as well. How do you ensure performance improvements stick longer term?

Matt Zeunert: Yeah. So I think basically you kind of need monitoring, so then you can see how are you trending over time, how are you trending within your industry. And also you want to make sure, like, what are you actually trying to achieve, like what is your goal? So you can set up kind of a performance budget and say, well, we want LCP to be, you know, below like 3 seconds on this type of device. So then you’re going to find out, you can see how are we doing, and, you know, are we kind of introducing new regressions, and when you introduce a regression you can fix it quickly. The other part is, I guess, more at an organization level, you just kind of want to make sure that somebody is in charge of performance. So often, you know, you might have people work on the marketing website who sort of do some performance stuff, you’ve got people on the development side kind of doing some performance stuff, you know, but then you also might have like a freelance writer who’s just kind of adding like a new big image. But you can’t really have everybody kind of in charge, so I think the thing I would say is, like, identify, you know, a person who’s in charge of performance, in charge of like checking that you’re staying on top of performance, you know, and maybe have like a monthly report or something, just to kind of see that, you know, somebody knows how you’re doing and whether you need to improve.

Moeez: Awesome. Matt and Nat, my last question is from you both, and I’m sure our audience would love it if you can display a quick fix on the screen, on a website of your own choice. We have the last 7 to 8 minutes left, so if you can both just, one by one, Nat, if you can go first with a quick fix on your screen, and our audience would definitely want to see that on their screens as well.

Nat Miletic: Sure, I will share my screen. Hope everybody can see that. Okay, oh, it’s, my screen is kind of mirrored though, let me try that again.

Moeez: Let me share your screen again.

Nat Miletic: Okay, perfect. Um, so here’s a website that we’re currently working on, this is still in development. We typically use Elementor Pro for building websites, we try to keep things lean and, you know, not use a lot of plugins. We use the Hello theme by Elementor, so it keeps things relatively easy and clean. However, you know, there’s always things to clean up. So this is without a lot of, any performance tuning at this point, this would kind of be like a starting point for us for a new website build. And typically the way we do things, we try to keep things fairly lean anyways, so we will get out of the box fairly good, you know, performance. And, you know, on desktop obviously it’s table stakes stuff, it’s very easy to get good performance on desktop, but we mostly look at mobile, because mobile is what, you know, Google will also look at more from like an SEO perspective. And the SEO score is low obviously as well, this is a noindex, it’s still in development. But basically what we would do for every performance sort of like engagement, and even for new sites that we build, we have a checklist that we go through. One of the items in that checklist is to do a page speed audit and resolve any issues that come up.

There are some problems that you might not need to fix obviously, like, you know, are we aiming for 100% on mobile? Usually not, just because it’s, most of the time it’s, you know, not necessarily achievable, unless you have like a totally static website, but for the most part we try to be sort of in the 80s or 90s on mobile as well. So one of the things that’s pretty common is, for example, reduce unused JavaScript. So one of the things that you do typically when you’re using like these builders, like, you know, Elementor or any of the other ones, is they’ll add a lot of like JavaScript files and components that you may or may not be using. And so this is what I was talking about earlier. For example, if you get a warning like this where it says reduce unused JavaScript, that means that for some reason, you know, the website thinks that you’re not using this particular component, and so you’re still loading it on your website and it might not be necessary. So there’s a few ways to fix that or to resolve that. The best way, again, you can install like WP Rocket and just kind of like delay all the stuff and combine it and call it a day. Or the more proper way to do it is to actually disable and turn off things that you’re not using.

And in the newer versions of Elementor, you can do that. So if you go to the Elementor settings, and then under editor, there’s an element manager. And so there are going to be things here that, you know, you’re not going to be using and things that you may not need, right? So one of the things that it’s complaining about is the, it was the, that Swiper file basically, which is being called by this carousel. And so, you know, you can turn off a lot of these things that you don’t need on the website, which will keep it, you know, running quicker and leaner. So, you know, this is an easy fix probably, is to like go through things that you don’t need and you’re not using, and then, you know, just turn them off in order to eliminate those issues. So it might take a few minutes to kind of rerun, but essentially what you would do is you would go, you know, line by line, take a look at all of the issues that come up, and resolve them by, you know, doing something on your website. Now the approach of resolving these issues is going to be different obviously based on, you know, what the problem is, but you can see that that unused JavaScript thing disappeared now, because I turned off one of the scripts that it said we’re not using for this particular website. So that’s a quick fix that you can implement. So just, like, you know, the takeaway is eliminate as many things that you don’t need. Some tools are easier to do that with, and other tools are a little bit harder. There’s a few different ways to achieve this, but just, you know, if you’re looking to improve performance, make sure that you’re only using things that you need to use.

Moeez: That was awesome, Nat, thank you so much. Yeah, that was awesome, Nat, thank you so much for that quick fix on performance. Matt, if you want to go next and show us your quick fix on the screen.

Matt Zeunert: Cool. Yeah. So I think the main thing that I will kind of look at is kind of images, just because, you know, it’s so important for LCP to kind of load the important images early on. And when you look at Chrome DevTools, you’ve got this priority column, I’m not sure if it’s enabled by default, but you kind of right click and select it. And when you look at that, you can see that like the first five or six images, they’re going to be medium priority, but everything else after that is kind of low priority. And lower priority is just the default, because the browser doesn’t want to load loads and loads of images. But also, before the page is rendered, the browser doesn’t know what images are in the viewport, so there’s kind of like a delay normally before the browser finds out whether an image is important.

But there is a feature called the fetchpriority attribute which they actually added to this website, you can kind of see it here. And that basically tells the browser from the start, okay, this is an important image and you need to prioritize it, because, you know, it’s going to take up a lot of space on the screen, and the browser then knows that it’s important before it actually starts rendering the page and knows where on the screen it shows up. So I think this is actually something that they fixed like relatively recently on this website. Yeah, I think I ran like a test in our tool like in December, and you kind of see, at the time, like the request priority was kind of low, and when you look at what that means in the waterfall, it basically means this kind of whole gray area for like two seconds, the browser knows that this image is on the page, but it kind of decides it’s not quite ready to download it yet, because it’s kind of worried, well, maybe there’s render blocking CSS code or other more important resources, so maybe it does not start making the request yet. And as a result, you get kind of a lot of delays from that.

I think we ran like a test here, you can kind of see, if you add fetchpriority high, like basically the image starts showing up right away. Whereas if the browser doesn’t know about the request priority, without fetchpriority, it just takes a really long time for the image to load. And I think this kind of was added, you know, like a couple of years ago, it was added as like a browser API, and that’s probably one of the biggest changes in terms of what people can do to optimize kind of image loading on their website.

Moeez: That was awesome, Matt, thank you so much, both, for being here. This is it for this session, folks. And I want to thank Nat and Matt for being here and sharing their performance knowledge and also showing us the quick performance fix on our screens as well. As for you folks, I would want you all to stick around, because we have another activity coming up after this. I know that we had a couple of activities yesterday as well, and if you missed out on those, don’t worry, we have another activity coming up right after this session, which is called decode the emojis. So it’s an interesting one, and this will obviously give you an opportunity to win some great gift cards at the end of day two as well. So stick around, we will be right back.