And we are back folks. Uh my name is Mo as you may all remember me from yesterday. I am one of the co-hosts for the performance boot camp uh this year along with Danish and uh what a fantastic day we had yesterday. uh day one performance boot camp uh sessions from Sabrina, sessions from Amber, a lot of different guest 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 uh previously and now we want to turn our attention to a panel discussion and it’s a live performance tear down. So if you are someone who works in the performance space who has different clients facing performance issues this panel discussion is uh is for you. So before we begin I have a few announcements to make. Uh just a reminder that we have a leaderboard uh which is active and you can climb that leaderboard by asking questions in the chat and interacting with the guest speakers and during the session so that you can climb the the the leaderboard and uh you know get get a chance to win some amazing uh prizes and apart from that we have amazing partners uh that have partnered with us uh in in in this in this performance boot camp who I also want to thank and and appreciate. Uh the topic of this panel discussion is uh live tear down and it’s from uh Nat Millitech and Z Matt Zun 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. Yeah my name is Natt Militic. Um, I own a company called Cleo Websites. I’ve been in in the WordPress and agency space since probably 2007 and uh excited to be here today and uh talk about performance. Cool. Yeah, thanks. So, yeah, I’m I’m Matt. I own a company called Debug Bear. So, we do web performance monitoring and yeah, I’ve been spending the last like eight years or so kind of working kind of with, you know, consulting client kind of users like trying to help them kind of improve their performance. Awesome. I want to thank you both for for being here on this stage and uh uh 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. Uh and the question is when a client says my site is slow, what’s the first thing it is that you check? Like when when a client is sort of complaining that Masar 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? Um uh is it just me or is 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 when a client says my site is slow, the first thing we do is we run a quick audit. Uh 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 um more from an SEO perspective. They’re seeing maybe uh um page speed 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. Uh also depends on how you know uh I guess technical and and knowledgeable your client is right. Some people might say my my site is slow and mean uh 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 uh we check visually what’s going on with the website. Uh we check in a few devices. as we log into the back end, do a quick sort of audit and then we also um we also use primarily page speed insights which is a Google uh performance testing tool to see um you know what kind of metrics we’re seeing more from uh sort of like you know the the the lab data and the actual um uh real-time data and and just kind of compare and see see what’s happening. So, usually that’ll give us some clues as to, you know, what to tackle next. Awesome. Uh, Matt, I want to turn our attention to you now for a second. And, you know, I know that you analyze a lot of new a lot of slow sites. Uh, based on what you do and how do you pri prioritize what to fix first? You come across a slow site. Uh, 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 looks like for you? Yeah. So I think it’s basically a two bit like one is kind of finding like what pages should we like optimize first. Um and then it’s like looking at those pages and seeing okay what are the most impactful changes that we can make. Um and yeah in terms of like identifying pages probably just looking at some of your most popular pages is useful. Um 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. Um and then once you kind of know what the pages are you can kind of start optimizing those. Um and then yeah beyond that generally I would kind of start but run a bunch of automated tools uh like page speed insights debug bear web page test and they typically give you specific recommendations that are already kind of prioritized. Um 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? like what’s triggering one request and then another. And then once you know like the exact sequence of events, then you can look at like how do you compress that sequence and avoid, you know, um how can you prioritize like 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. Awesome. Uh, Nat, a few things obviously that you uh that you do on your 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. So, what is that point looks like for you? Yeah, it’s uh usually fairly evident, you know, when you uh when the client when you get a new client and you’re u you know troubleshooting performance issues um you know whether or not re a rebuild is the next course of action that’s typically um by you know looking at sort of in the WordPress space specifically you know how many plugins they’re running uh how old the website is in terms of like how much technical debt there is Um, so there’s usually a number of factors. Um, one is, you know, a number of plugins that they’re using. Um, the sometimes it’s it’s uh the the tool set for example that they’re using if they’re using a old version of like a page builder that’s no longer supported or something that we know uh doesn’t necessarily help with performance and and necessitates a a rebuild. uh where it’s a little bit more cost-effective and and uh 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 um 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 or requires a lot of different plugins in order to run. Um those are the types of things that um we would look for and then advise the client to recommend uh bu rebuilding the website to 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. 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 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 is what are those signals that you when you look at them, you say that okay, so these are the problems that cannot be fixed from 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? Yeah, I think there’s like a couple of things depending on like how the website is built. So, especially kind of with like you know kind of WordPress site for example, you often see like a higher time to first bite because people have a lot of content, a lot of plugins, all that kind of stuff. Um, 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. Um, 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. Um, 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. Um, and the third one that I would kind of look at is kind of JavaScript um, kind of applications on 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. Um, so yeah, that’s like the third one I would look at. Awesome. uh 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 so how do you explain performance trade-offs to non-technical clients yeah that’s a great question um I think for the most part clients understand that you know you sometimes do need to make certain tradeoffs in order to uh reach performance targets. A great example of this is uh like various trackers and an 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. Uh a lot of those things will add to the performance. you know, it’ll they’ll have performance tradeoffs where they’re they they will slow down a website um uh 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 things that like a discussion we would have with the client to say um for example, you know, this particular tracker is causing, you know, a performance problem. we we can show them using page speed 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 and they forget to turn them off or remove them after they don’t they they stop using them. 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? Yeah, I think most of the time it’s going to be the other way around. The people are like, well, we have a bad score, therefore we must have issues. But if you look at the view user data, you know, probably things aren’t as bad as the lighter score suggesting just because, you know, the the setting the page for inside users, they look at maybe the slowest 5% of visit experiences. Um but like the typical visitor probably is having a good experience anyway. Um but there also there there are some cases where Lighthouse might say that your website is fine but actually when you look at views later data um there are problems. So one I would say is that um Lighthouse always looks at like a fresh page load. So if a logged in user gets a very different experience uh from you know a new user who doesn’t have anything cached or who isn’t logged in um 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 kind of see all that kind of customized dashboard content or whatever. Um but you’re not being able to detect that if you just run the lighthouse test. Um and one challenge you also kind of run into is um 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 just going to send an empty script file so we get a better lighthouse score. Um, and I think there’s issues with like, you know, WordPress kind of plugins or Shopify um, plugins where they kind of just kind of create they fix the l score, but they just don’t do it in a way that actually fixes the underlying performance issue. Awesome. Uh, 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 uh, this question on their minds as well. In WordPress specifically, what’s usually the root cause of a of a slow website? Is it themes? Is it plug-in? Is it hosting? Or is it the design? Um, it’s hard to pick just one. Usually it’s a combination or it it’s very dependent on the project. Um, obviously, uh, hosting plays a huge role. Um, you know, that’s one of the sort of foundational things that you need in order to have good performance. Um, it’s kind of u interesting, you know, and sort of related to what Matt was just talking about as well. Um, you know, you can mask a lot of like performance issues and and treat them as fixes. Uh, but if you’re on bad hosting, uh, it doesn’t really matter. Your your user experience is still going to be uh, you know, negative. So, uh, it’s hard to say like, you know, to pick one specific thing. we usually see um a combination uh or we usually see a root cause being one of those depending on the situation. Uh hosting is like definitely a foundational thing that you need. Um I am of the mind that I don’t like to blame plugins usually um because you know you can have you 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 uh 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. Um the most common issues we see are you know bad hosting and then uh from a design perspective the you know having a lot of images having a lot of scripts those are those are usually the biggest culprits. Um and then themes can also cause a lot of issues. Not not that the themes are to blame but sometimes uh 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, uh 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. Uh so is the design obviously plugins a little bit less uh of a concern in my experience if you’re using the right ones. Awesome. So, hosting, design elements and themes, and then maybe somewhere down the line, plugins as well. Uh, Nat, I’m going to throw a direct question at you as well now. Uh, since you work a lot with agencies, uh, what’s the most common false fix agencies attempt nowadays? Is that for me as well or for Matt? Uh, that’s for that’s for Nat. That’s for you. Oh, okay. Thank you. Yeah, our names are very similar sounding, so it’s hard to say. Um yeah, so the the the common the most common false fix would be that we see is uh just applying something like you know uh WP Rocket or one of those performance plugins that kind of mask the issues, right? So, um, we usually actually when we’re troubleshooting and working on performance type, uh, engagements is we 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 what’s being loaded because what happens sometimes is um, like these perform 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 um minify um you know 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 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 page speed 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 uh from a performance perspective but from you know like an audit perspective it looks it looks fine. Awesome. Uh Matt, uh 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. Yeah, I think it’s mostly kind of starting with kind of 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 cover 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, that’s really it 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 like spent on the connection, how much time was spent like downloading different data chunks. like you just have like much more in-depth data and because of that 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. Um so that is one big advantage. The other thing with synthetic testing is once you have the end of data you can do comparisons and you can very easily see not just well what is what metric changed but like okay maybe we added maybe the marketing team added like a new third party script or maybe you know like some we a new version and like you know the new image is a lot bigger so you can see at a much more nuanced and detailed level what actually changed. Awesome, Matt. My next question is from you as well. Uh, how do you ensure performance improvements stick longer term? Yeah. So, I think basically you kind of need monitoring. Um, so then you can like see like how are you trending over time? How are you trending within your industry? Um, 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 performance budget and say well we want LCP to be you know below like 3 seconds on this type of device. Um so then you’re going to find out you can see like how we doing and um you know are we kind of introducing new regressions and when you when you introduce a regression you can fix it quickly. Um 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 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. Um, but you can’t really like have everybody kind of in charge. So I think the thing I would say is like decide like identify like you know a person who’s like in charge of performance in charge of like checking that you 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. Awesome. Uh Matt and Natt 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 of your own choice. Uh we have the last 7 to 8 minutes left. So if you can both just one by one. Nad if you can go first with a quick fix on your screen and our audience would definitely want to see that uh on their screens as well. Sure. I will share my screen. Hope everybody can see that. Okay. Oh, it’s uh my screen is kind of mirrored though. Let me try that again. me share your screen again. Okay, perfect. Um, so here’s a website that we’re currently working on. Uh, this is still in development. Um, we typically use uh Elementor Pro for building websites. We try to keep things lean and, you know, not use a lot of plugins. Uh we use the hello team by elementor. So it keeps things relatively easy and um and clean. Um however, you know, there’s always things to clean up. So this is without uh a lot of like any performance tuning at this point. Um this would kind of be like a starting point for us uh for for a new website build. And typically the way we do things, we try to keep things fairly lean um anyways. So we will get out of the box fairly good um you know performance and um you know on desktop obviously it’s table stake stuff it’s very easy to get good performance on on desktop but we mostly look at mobile because mobile is what uh Google will also look at more from like a SEO perspective and um the SEO score is low obviously as well this is a no index it’s still in production or it’s still in development. Um, but basically what we would do for every uh 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 those in that checklist is to do a page speed audit and uh resolve any issues that come up. Um 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 um most of the time it’s you know not necessarily achievable and unless you have like a totally static website but for the most part we try to be sort of in the 80s or 90s uh on mobile as well. Um so one of the things that’s pretty common is for example uh uh 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 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 wanted to, you know, if you get a warning like this where it says reduce unused JavaScript, uh, that means that for some reason, you know, the website thinks that you’re not using this particular component. Um, and so you’re still loading it in your in your uh in your in your on your website and it might not be necessary. So, one of the there’s a few ways to to fix that or to resolve that. Um, 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. Um, or the more proper way to do it is to like 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 uh Elementor settings and then under editor, there’s a element manager. And so, uh, 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, uh, complaining about is the, um, it was the, uh, that swiper file basically, which is, uh, being called by this carousel. And so, you know, you can turn off a lot of these uh things that you’re not 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 uh probably is to like go through things that you don’t need and you’re not not not using and then, you know, just turn them off in order to eliminate those issues. So it might not be this might take a few minutes uh to kind of rerun but um essentially what you would do is you would go you know line by line uh take a look at all of the issues that come up and um and resolve them by you know doing something on your website. Now the the the approach of like resolving these is the these issues is going to be different obviously um based on you know what the problem is but you can see that that uh unused uh JavaScript thing disappeared now because I turned off the one of the scripts that it it said we’re we’re not using for this particular website. So that’s a quick fix um that you can implement. So just like you know the the takeaway is eliminate as many things that you don’t need. Uh some tools are easier to to do that with and and other tools are a little bit harder. There’s a few different ways to achieve this, but just uh you know if you’re looking to to improve performance, make sure that you’re uh only using things that that that you need to use. That was awesome, Nad. Thank you so much. Yeah, that was awesome, Nad. Thank you so much for that quick fix on performance. Matt, if you want you want to go next and show us your quick fix on the screen. 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 SCP to kind of load the important images early on. Um, and when you look at Chrome Dev Tools, um, 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. Um, and what 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 B is low priority. And lower priority is just the default because the browser doesn’t want to load loads and loads of images. Um, but also before the page is rendered, the browser doesn’t know what images are in the viewport. Um, so there’s kind of like a delay normally before the browser finds out whether an image is important. Um but there is a feature called the fetch priority attribute which um they actually added to this website. You can kind of see it here. Um 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 um that it’s important before it actually starts rendering the page and knows where on the screen it shows up. Um so I think this is actually something that they fixed like relatively recently on this website. Yeah, I think I ran like a test um in our tool um like in December and you kind of see the 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 that’s does not start making the request yet. Um, and as a result, you get kind of a lot of delays from that. Um, I think we ran like a test here. You can kind of see if you add fetch priority high, um, like basically the image starts showing up right away. Whereas, if the browser doesn’t know about the request priority without fetch priority, um, it just takes a really long time for the image to load. Um, and I think this kind of was added, you know, like a couple of years ago. It came 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 um optimize um kind of image loading on their website. That was awesome, Matt. Thank you so much uh both for for being here. This is it for 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, 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 uh gift cards at the end of day two as well. So stick around. We will be right back.