Demystifying Core Web Vitals for WordPress

Core Web Vitals now represents a set of mandatory metrics for optimizing your site, particularly if SEO and site performance is important to your digital strategy. Nonetheless, it can be difficult to figure out which WordPress tools and strategies are most important when trying to improve the Core Web Vitals on your site.

Watch this session for an in-depth look at the best practices and tools for understanding and improving your Core Web Vitals scores on your WordPress site.

Speakers: 

• Alex Zuniga, Product Manager at WP Engine
• Mark Davoli, Director, Web Development at Amsive Digital
• Matt Chase, Director of Development at Vital Design
• Sanjucta Ghose, Senior Web Developer at WP Engine
• Mike Crantea, Director of Frontend Engineering at XWP

Transcript: 

ALEX ZUNIGA: Hello, and welcome to Demystifying Core Web Vitals for WordPress. I’m Alex Zuniga, Product Manager here at WP Engine. And today, we’re really going to discuss the ins and outs of core web vitals for your WordPress website. Core Web Vitals is a mandatory metric to optimize if you care about optimizing your site for SEO, for site performance. But it can be difficult to know which WordPress tools and strategies are most impactful. So join this session for an in-depth look at how best practices and tools can help you improve your web vital scores for WordPress.

Now without further ado, we’re going to introduce our panelists for this session. And first off, I’ll hand it over to Mike to give a brief introduction on himself.

MIKE CRANTEA: Hello, I’m Mike Crantea. I’m located in Canary Islands Spain. I am the Director of Frontend Engineering at XWP where I have served for the past 17 years. Mostly in the frontend technology space, I love web performance. And I’m glad to be here. Hey.

ALEX ZUNIGA: Thank you, Mike. Next, we’ve got Matt Chase.

MATT CHASE: I am the Director of Development at Vital Design in Portsmouth, New Hampshire. Heavy frontend focus at my work. So we do a lot of lighthouse and Core Web Vital scores.

ALEX ZUNIGA: Awesome. Thanks, Matt. And Mark.

MARK DAVOLI: Hello, I am Mark Davoli, the Director for Web Development at Amsive Digital. Been specializing in the Core Web Vital space for our team as SEO is very important to our company. And therefore, so are Core Web Vitals. Happy to be here.

ALEX ZUNIGA: Happy to have you, man. And last but not least, Sanjucta.

SANJUCTA GHOSE: Hello. I’m also from WP Engine. I’m part of the team that’s responsible for maintaining WP Engine’s websites. And this includes the sites that came over with Delicious Brains when WP Engine acquired them. And I spent a good part of the last year optimizing the Delicious Brain sites for Core Web Vitals. So I think this should be a very interesting conversation. Happy to be here.

ALEX ZUNIGA: Thank you. Thank you. Well, welcome to all of our panelists. And we can’t wait to hear what you have to say. So we’re going to kind of break down these questions by measurement, management, tooling, and client expectations when it comes to Core Web Vitals. So our first question that we want to ask you all, why should I even care about Core Web Vitals in the first place? And to what extent should I focus on Core Web Vital optimization?

MARK DAVOLI: I can speak to that if you like. For me it’s really important to make sure you have a fast page speed. And the reason that’s important is in the end result conversions. Right? So when someone comes to a website, longer it takes a load, the more likely they are to hop off. And if you don’t have a fast page speed, then you’re going to be out of luck and lose a lot of business potentially. Especially on an eCommerce store.

SANJUCTA GHOSE: So yeah. I kind of agree with what you said because while it’s very important for SEO, but we also need to remember that Core Web Vitals are a measure of your site’s perceived performance. How the user perceives your site. And I think that’s very important to retain attention that the user perceives your site as being responsive, and interactive, and stable. Which are the things that Core Web Vitals kind of measures. So I think even more than SEO scores it’s important that user’s perception of your performance is important. And that’s why we should focus on Core Web Vitals.

ALEX ZUNIGA: Absolutely. Matt, you had–

MATT CHASE: Yeah that’s, basically, what I was going to say, yeah, the SEO aspect is great. But ultimately, we code these sites for people. And we want those people to have the fastest, snappiest site possible. But this affects both worlds. Right? So we get to kind of– when we tune for these Core Web Vitals, we’re doing great UX. But in a way that satisfies the SEO teams, which is sometimes not always an easy battle to win. So it works for everybody.

ALEX ZUNIGA: So with all of that said, we know it’s important. But what are the best ways to measure our score?

MARK DAVOLI: So one of the ways we measure besides using– well, there’s Google’s Page Speed Insight Tool, which is critical because that’s the tool they use to measure it. Right, so if you want to have an impact, using that tool is vital. There’s your in-browser Lighthouse as well right in the Chrome DevTools, which is super important. And Search Console has a great page user experience tool for monitoring real user metrics over the past 28 days, which is critical for long time monitoring.

SANJUCTA GHOSE: Yeah. So I’d say Page Speed Insights is a very good tool Because it gives you both real time data in the sense that the Core Web Vitals themselves are based on real user data over the past 28 days. But then you can also see your Lighthouse Report, which is based on lab data. And that’s what you can actually immediately improve upon because it takes some time before you can actually see improvements in Core Web Vitals because it’s measured over a span of time.

So if you’re trying to improve your scores, I think Lighthouse is a great tool because it provides you– it tells you what your opportunities are to improve. So you can right away try to implement those opportunities, and see how it improves your score.

ALEX ZUNIGA: Awesome. Sounds like big shout outs for Lighthouse there. Excellent. Excellent.

MIKE CRANTEA: I would like to add on this topic that tracking real user metrics performance data has been better to be able to react quicker to performance degradations that have reached production. The lab tests do help when you’re in staging. Like say there’s a degradation that we don’t want to propagate. But there’s always going to happen something in production that might come as a surprise. And instead of waiting several weeks for Search Console and the real user metrics in crux database to show up, by tracking them yourself with a Web Vitals library, you can stay ahead of the curve.

ALEX ZUNIGA: Awesome. Yeah. Always got to stay ahead of those production surprises that come up sometimes. All right. Well, thanks for answering those on measurement. Now looking into management, what are one or two things that you can do that have the most impact on Core Web Vitals?

MATT CHASE: So I guess one thing that jumps out to me is lazy load like everything you possibly can. And defer loading of everything you possibly can. That for me is kind of the one I would say kind of turnkey solution that you can just do, and see an immediate improvement. WP Rocket has a bunch of really just very easy check boxes you can turn in to enable that sort of thing.

MARK DAVOLI: Yeah. And for me, the key focus is what we call the above the fold render. So making sure that that renders as quickly as possible. And as previously mentioned, deferring and lazy loading anything else that’s off screen to make sure you get the best score possible. That being said, WP Rocket is excellent for their delay scripts feature. But we tend to– like I try to tend to limit that to the GTM, or Google ad scripts, or things like that. And really focus on improving the actual core architecture of the theme that powers the website to make sure that is optimized as possible. So you aren’t relying on a third party plugin to have that kind of performance impact.

MATT CHASE: Oh, absolutely. Yeah. Both ends.

ALEX ZUNIGA: Gotcha. Gotcha. And just to clarify, you said WP Rocket. And that’s the delay scripts feature?

MARK DAVOLI: Yes.

ALEX ZUNIGA: Awesome.

MIKE CRANTEA: One thing that doesn’t get enough spotlight is caching. But fast server response time doesn’t guarantee a fast experience. But if your server responds slowly, you’re guaranteeing a slow experience. So making use of all of the caching layers available– browser caching, object caching, page caching– and having them turned on and functional is a good first step. Do your basics. And then you can work down to– work up to the frontend optimizations. Checking what’s in your head. And so on and so forth.

ALEX ZUNIGA: Excellent

SANJUCTA GHOSE: Yeah. And I think we should also not forget to optimize our images. I think it’s very important because a lot of websites these days tend to be image heavy. So I think it’s important that you compress your images, serve them through a CDN, and then like you’ve already mentioned lazy load your images. More importantly, serve responsive images. So like you can use the source set attribute of the picture tag or the image tag to serve responsive images. I’ve seen that that really leads to a lot of improvement because Core Web Vitals are mobile first measurements. So it’s very important that you serve responsive images. It’s something that we kind of forget sometimes.

So I think images. And also some very simple things like minimizing your JavaScript in your CSS during your build steps. I think that helps a lot as well. It’s quite simple to do.

MATT CHASE: Yeah. On that subject, actually, since you bring that up, WordPress distributes a kind of a packaged webpack build system. They just call it at WordPress Scripts. And our agency we struggled for a long time with trying to maintain our own webpack system. And then every eight months or so some node dependency would change, and break our entire toolchain. But WordPress kind of maintains this for us. And it’s been a huge benefit.

And the webpack in there we’ve started using dynamic imports to build our main JavaScript bundle. So we’re kind of importing our node dependencies at runtime instead of bundling it all into one main JavaScript package, which has kind of allowed us really fine tuned control over that same kind of deferred script loading. Only in specific cases. Like when our block is on the page.

MARK DAVOLI: Yeah. Also I find it very important to make sure you’re very selective around the plugins that you use on your website. You can get a lot of unexpected bloatware from installing third party plugins. So try and limit them to very well reputable, well built, plugins. And pay attention to what those plugins load. It really, really can help controlling the performance of the site. And unfortunately WordPress still relies heavily on jQuery for backend use and whatnot. But it’s not really necessary for frontend. So if possible, dropping jQuery support from the frontend of the website, and sticking to native JavaScript can really help with performance.

ALEX ZUNIGA: Awesome. I think we’re kind of already dipping into this area. And you mentioned a few. But let’s tap a little more into that with the tooling. What are some of the preferred tools that you like to use for Core Web Vital optimization? And what kind of use cases are they best for? Or is there some scenarios where they’re not a good fit?

MATT CHASE: I mean, it came up before. But really the Lighthouse in-browser tool is kind of my really go to because that’s immediate results. Right. The Core Web Vitals is great, but its power is in the fact that it’s an aggregate that’s put together over time. So you can’t really change something and see the number change. As compared to Lighthouse, in the browser, you make an update. You see your local dev environment and run a Lighthouse test. And can immediately see, oh, my performance jumped 15 points. Cool. That was the right thing to do. Push that to production.

ALEX ZUNIGA: Awesome. Any other tools that you like to use?

MIKE CRANTEA: I would like to give a huge shout out to the local overrides feature in Chrome. That, in combination with the Performance tab give you a surgical ability to play around with changing even the order of the loading of the items in your website. And how much or little that impacts. It gives you the necessary oversight of knowing whether putting the effort into making a certain change is worth it, or you just like leave it there and focus on other things that really make an impact.

MARK DAVOLI: And one thing I think is also critical is server architecture monitoring. Right. So you can have the greatest Core Web Vitals in the world, but if your server comes under an unusually heavy load and you’re not aware, you can suddenly find that your first contentful paint drops dramatically, which then affects pretty much everything else. So keeping a close eye with tools like New Relic or whatever for just monitoring performance. Keeping a close eye just to make sure that you have the proper infrastructure for rendering your website as fast as possible is critical.

MIKE CRANTEA: And that’s where having the caching turned on and ready does help.

MARK DAVOLI: And CDN.

MIKE CRANTEA: Yes. Avoid some potential disasters.

ALEX ZUNIGA: Excellent. Well, I appreciate that clarity there. So one of the questions. There are many optimization plugins to optimize Core Web Vitals. What are the limitations of WordPress plugins to help out with that? Or are they truly optimizing the site? Or are they just kind of possibly tricking Google’s measurements? And I guess maybe that’s a question of, is it better to– we kind of mentioned is it better to use plugins or doing the work instead of relying on a plugin there?

SANJUCTA GHOSE: So I think that plugins are great. Like for example, WP Rocket for example is great. We use EWWW Image Optimizer a lot. And I think that’s great too. But like I think it’s already been said. WP Rocket, you have to use it carefully because if you turn on the defer JavaScript feature, I have seen cases where it introduces strange bugs. One off bugs. So I would prefer to kind of sometimes maybe roll my own solution rather than go with a plugin. Provided that you have the development expertise.

So most of the optimizations that we did for Delicious Brain sites we rolled our own rather than used a plugin. But that said, I think plugins are a great starting point. So when you’re just starting out, you might want to, for example, implement deploy WP Rocket on your staging site, and play around and see if it breaks things or not. Or if it brings in real improvements. So I think plugins should be used carefully. And you have to know what’s going on in the background what the plugins are doing. And how it might affect your site.

MATT CHASE: Yeah. Thankfully, WP Rocket I think in more recent versions has at least been good about very clearly labeling the dangerous switches that they have. Because I’ve been burned by that plenty of times too where the delayed scripts– and even ones you wouldn’t expect like the CSS optimization somehow has broken models where it didn’t get the thing that said a class name would make them visible. So that was an exciting day.

But yeah. WP Rocket is definitely my go to other than obviously good code in, good code out. Right. Doing the work is always the best way to approach it. Plugins can automate stuff. But there is no substitute for actually having your code be lean and mean.

MIKE CRANTEA: There is one more plugin that is marked as a lab type of plugin. That’s Performance Lab. It’s done by the WordPress Performance Core Team. And even though it sounds like it’s something scary, it provided in all of my tests so far full stability. And that was very impressive for what it was supposed to be, and the quality of the work that ended up in that Performance Lab plugin. So it’s worth trying it out. A couple of checkboxes. And everything that’s in there is safe. Well, I’m not so sure about the database switch. That’s something more controversial when I read about it. Yeah. Just don’t touch that button. Like they added SQLite support or something like that inside the plugin, which is definitely working for some smaller websites.

ALEX ZUNIGA: Interesting.

MARK DAVOLI: Yeah. And for me, WP Rocket’s fantastic. We do limit its use on most of our sites because most of what we do is built natively. But there’s a lot of other features in Core WordPress that if used properly can really get you a well optimized site. Like using the Block Editor instead of third party like Elementor or et cetera, can add a lot of bloat to a site. So if you build around like the new native Gutenberg type block system, and really load files as needed instead of loading everything all at once on every single page for example. There’s built in lazy loading features into WordPress now. So monitoring how it’s used and using it appropriately, et cetera. And then adding a tool like WP Rocket to enhance what’s already there. But not solely relying on it.

It can be beneficial for getting you there, especially if you have a site that doesn’t work well. But as mentioned, like the critical CSS generation, those things can have a lot of issues because they make a lot of assumptions based on what their bot sees on your page. But it can’t predict things that aren’t going to render initial views. So if you have models, as mentioned, those pop up, it’s not going to know that that’s a possibility. It won’t generate the CSS for it, and in-line it properly. So like doing things like preloading your key fonts or rendering that above the fold. Again, that’s the key. Really the most important thing.

SANJUCTA GHOSE: On the topic of critical CSS, I just wanted to jump in and mention that Addy Osmani has this awesome tool called Critical. You can add that to your build process to generate your critical CSS. It’s awesome. And it’s very reliable. So since you mentioned critical CSS, I thought I’d add that. Sorry for cutting you off.

MIKE CRANTEA: That’s fine. On the same topic of the critical CSS, there’s been some effort from the Jetpack team to do something with the Jetpack Boost plugin. That does a very, very interesting way of generating the critical CSS by rendering the pages in iframes or something like this. That provide when it works, it’s a great solution. When it doesn’t, it tells you, hey, it doesn’t work here. Just move along. You need something else. It’s not always easy to get to the critical CSS. On the other hand, 4 or 5 years ago, critical CSS were super big. It helped a lot.

In the last two or three years with the advancements of HTTP/3, having one critical CSS that’s rendered blocking has very small impact to have 100 kilobytes or something of inline CSS. Is making a website work as fast as a website that used to have critical CSS four or five years ago. So don’t be afraid to have a decent sized CSS inside of your site. You don’t have to get rid of it. And I’ve seen websites that were like super optimized.

We have in critical CSS like 100 kilobytes of inline CSS. And render blocking, jQuery, and two other scripts that were not used. It’s like, yay. You’re defeating the purpose with that. It can help us last 5% type of approach. But if you start with that, look at the first.

ALEX ZUNIGA: Awesome. Awesome. I think all of those tools. It’s great to hear those shout outs. And great to hear those suggestions and recommendations. And a lot of that kind of swirls around our next question. What are the unique aspects of working on WordPress specifically with Core Web Vitals? Is it that you’re having to do this via plugins versus doing it with any other tech stack? Is it easier with WordPress? Are there more tools available? As we just kind of mentioned you all just shot off a lot of tools. Is it easier with WordPress? Is it more difficult with WordPress? What’s y’all take?

MATT CHASE: I think it’s very easy with WordPress. So we talked a little bit about– or I mentioned the WordPress scripts node package that they distribute, which is just a great kind of webpack build system in a box. They also have WordPress Create block, which is just a really quick and easy way to bootstrap a custom block for your WordPress based site. But it’s built in such a way that a lot of the glue code, so to speak, is kind of written for you. So it’s already smart about– Mark, you mentioned only in cue those scripts when you’re supposed to. So you know if your block is doing that right out of the gate. You don’t even have to think about it. So WordPress makes that kind of stuff really easy.

MARK DAVOLI: Yeah, absolutely. And it’s open source. Right? So you can change pretty much anything. It’s much harder when you are working with a closed system to optimize for Core Web Vitals versus WordPress because of that. And when Core Web Vitals were first announced it wasn’t quite there yet. It was a lot more challenging. They’ve really come a long way with adding a lot of these features, especially with the block editor and the block based building, et cetera, to really optimize that ability to selectively load assets, CSS files, font files, et cetera. So yeah. It’s been great.

ALEX ZUNIGA: That’s probably the call of closed system versus open source. Go ahead, Sanjucta.

SANJUCTA GHOSE: Yeah. Yeah. And I think because there’s a lot of hosting providers dedicated to WordPress. And like you said. WordPress is open source. So there’s a lot of optimizations around hosting WordPress sites. And so I think there’s already a lot of support available there if you’re building on top of WordPress, which means that you don’t have to kind of reinvent the wheel. So I think it’s definitely easier if you’re building on top of WordPress to optimize your Core Web Vitals.

ALEX ZUNIGA: Beautiful. So we’ve talked about how do we measure those tools, what do we use to actually enhance our Core Web Vitals, some of the tooling. Now when we’re talking about client expectations, at what stage of a new project do you start to consider Core Web Vitals as part of your build or your strategy? Is that right when you start like your base boilerplate template? Or is it something that you optimize a little further along in the story? What do you all do?

MATT CHASE: Yeah. I think for me it’s more of just a way of building things to begin with more than a thing you do to an unoptimized website. It’s from the very beginning. And it is there in every line of code you write ideally. I try not to– I don’t want to build up a big optimized site, and then go back later and fix it. I want to try to write as cleanly as I can from the get go. And then usually, I find that doing it that way, squeezing out that last little bit of optimization juice at the end is kind of a little bit easier.

MARK DAVOLI: Yeah. He’s absolutely correct. We start building it right from the get go. I mean, there are components that don’t happen like closer to the end. We’re not going to run images through an image optimization until closer to launch. But you have to really not even in the build itself, but even in the design process sometimes, it’s important to think about how the site’s being designed if you’re taking Core Web Vitals into account. Because architecturally, it’s more challenging to implement certain designs to be fast versus others. So understanding that and educating designers around what could potentially make a more difficult implementation versus not is very helpful.

MIKE CRANTEA: And dictating the limits. Hey, you can only have up to x phones. You shouldn’t bring 25 to the table with all of their variations. That helps from the design phase. Also it’s without having some touchpoints that happen for the duration of the project, it’s sometimes easy to get some things through. Like a sprint seven requests for adding a quiz plugin to the mix. If that goes unchecked, you find it a bit at the end. So my recommendations are process this every couple of sprints. We do check our automated measurements of the staging of how things evolve. What happened with the last things that got pushed to go Did things slow down? Do we need to make any corrective measure ahead of the time rather than being reactive at the end of a project.

SANJUCTA GHOSE: Yeah. I agree. It’s very important that you start from the design phase because like simple things like whether there should be a pop up, an ad banner, or something like that. Sometimes it makes a huge difference to maybe your cumulative layout score. So it’s good to know upfront what’s going to happen. Whether you’ll have a pop up or a banner coming in. And you don’t want surprises towards the end of your project. So I think it’s very important to involve the client or the stakeholders right from the design phase, and tell them that this could have an impact on your Core Web Vitals so they can take an informed decision.

MARK DAVOLI: That’s super helpful post-launch too because as soon as your site’s out the door sometimes it may be like, let’s throw a chat widget on or whatever like later on. Then all of a sudden, there’s a kink. And then you have to think about how do we get this integrated and optimized. So the delay scripts feature can push most advertising pixels, which are notoriously bad for killing your Core Web Vitals score. But sometimes you can’t delay something because it’s kind of important to what the client really wants. So balancing it as best you can, and making sure communicating the potential impacts. And just the end result is to get it as fast as you can. Sometimes you have to make sacrifices for functionality. Sometimes you don’t. But get it as fast as you can to increase those conversions.

ALEX ZUNIGA: Excellent. Excellent. So I’m hearing kind of this like better ingredients makes better websites from the get go. Not that we’re just going to slap some Core Web Vitals on at the very end. It’s something that really is a way of life if you want to think about it that way first. Well, awesome. So just our last question. Do you ever have any problems conveying the value of the time that you spend working on Core Web Vitals to your clients? Is that anything they ever push back on? Do they ever not understand why you’re doing that work?

MATT CHASE: I don’t think I’ve ever gotten any kind of pushback actually. If anything, it’s kind of the opposite. Usually, it’s we want the performance. We want the Core Web Vitals. Let’s make it happen. I will say that we don’t always reflect on– we talked about tracking pixels and how they are like notorious for bringing that score down. But nobody cares. We’re just like pixels, pixels, pixels, pixels. So people need to think about actually weighing that cost benefit when they’re adding tracking because it’s not as simple as just throw it on and get results. Because there is a cost.

ALEX ZUNIGA: Awesome.

MIKE CRANTEA: I think with performance there’s a lack of patience. So if you’re thinking, oh, let’s do some performance work that will last a couple of sprints, after the first one. When do I see it? When do I see it? Planning to release it iteratively, like increasing one feature, one feature, one feature grows the confidence of the impact this work does. And the more you see this translate into conversions and change, the more quickly the value is perceived without having to spend a lot of time doing the education work.

MARK DAVOLI: Yeah. And I think one thing that could be tricky for clients to understand is the difference between real user metrics versus lab data. Because a lot of them may run their own tests and whatnot. And don’t fully understand. So helping them understand that the origin summary part of the page be the insights is really the one that Google uses to effect like for SEO ranking and things like that. Because a lot of them come looking for that score and optimizing that. And helping them understand it takes 28 days to measure any change made in production before you’ve got the full gamut of how your change affected things.

ALEX ZUNIGA: That’s a great call out. Great call out.

MIKE CRANTEA: And I should call out one of the metrics that is the most confusing out of all. The interactivity metrics. Those have been notoriously volatile. And for some type of people that are more scared of like any variations in the score, it’s like did that new feature that we built slowed down the website significantly? And then like hit the test again and is like going up by 10 points, and then going down by 10 points. Explaining this variation is so time consuming. Why isn’t it that just one number that’s consistent? Well, that’s something as hard as naming things and caching.

ALEX ZUNIGA: Well, awesome. It sounds like we really appreciate all of y’all’s input, all of your feedback on Core Web Vitals. How to use them, what to use to measure them, how to set the customer expectations for all of that. It’s really been a learning lesson. We hope our panelists have enjoyed your time here. We definitely enjoy hearing all of your feedback. And we hope the attendees here as well have gotten some great feedback.

So all of you, thank you so much for your time. Well, that was our panel. We really want to say thank you so much to all of our panelists. We want to thank you for attending this panel. And we hope you have a great time watching the rest of our sessions a DE{CODE}.