Webinar: Core Web Vitals Tactics for Boosting Your Website’s Performance

Ever wondered why some websites zoom ahead while yours seems stuck in the slow lane?

Core Web Vitals might be your missing performance key.

I’m Peter Mead, and in this video with WP Engine, we unlock the secrets that transform sluggish sites into speed demons.

This isn’t just about metrics. It’s about making your website the “Ferrari” of your industry.

Full Transcript from the Core Web Vitals Tactics for Boosting Your Website’s Performance Video

Rick: Hello everybody, welcome to our webinar on Core Web Vital tactics for boosting your website’s performance. My name is Rick, I’m the Head of Technology Services for the APAC region, and I’m excited to have you all here today. Before we dive into the content, let’s just take a moment to make sure everyone is comfortable and ready to go. So make sure you’re sitting comfortably in your bean bags, you’ve got your water, you’re settled in.

Because first of all, we’re going to do a bit of housekeeping. This webinar will be approximately one hour long. Within that, we’re going to have a presentation and there will be a Q&A session at the end, so please feel free to submit your questions. There’s a chat box—there’s actually a dedicated Q&A chat box. If you can submit your questions into that, it makes it easier for us to track those questions. I know some people will put it into the group chat—that’s okay as well, but the Q&A chat box is the better way to do it because it makes it a lot easier for us to track.

There will be a recording of this webinar after the webinar and we will have a copy of the slide deck to be shared with you as well. So what we’re going to cover today is understanding the latest Core Web Vitals, optimizing techniques from our experts on how to improve your Core Web Vitals on platforms like WordPress, the impact of user experience and SEO, and recent trends in SEO rankings.

Now, of course, I am not the expert here, and that is why I’m honored to introduce these two experts in the field of SEO: Matt Hodgson, founder of Bring Digital Performance, and Peter Mead, Head of SEO for Bring, who will be leading this presentation and sharing his wealth of knowledge on all things to do with Core Web Vitals and how to get the most from your website. So without any further ado, I’d like to hand the mic over to Peter to get us started. Hello, hello…

Peter Mead: Yes, and welcome everybody. It’s good to see a lot of people coming from lots of different places around Australia and internationally—it’s always good to see that. Thanks so much for the introduction, Ricky, and yeah, I’ve known you for quite a while and it’s good to be finally on the webinar with you.

If everyone can see my slides okay, I’ll just start going through them. So, a little bit about me: I began making websites back in about 1997. I got involved in the internet in the early days, and it’s probably showing my age a little bit. Back then, the internet, the web, the worldwide web—making web pages—everything was kind of an experiment, like a project. Tim Berners-Lee was one of my inspirations; I was very passionate about the work he did to kick off the worldwide web. My first website back in ’97 was an HTML page with animated GIFs and very basic stuff, but I was really passionate about it.

The reason why I got into a lot of this and went down this path eventually was because of the whole sharing information thing that was going on in the early days of the worldwide web. We were just discovering things and sharing ideas, and everyone was helping each other out. That led me further on—once you build a website, people say, “How do you get found in search engines?” Of course, this was before Google, so we’re getting into AltaVista and Dogpile, web stuff that people might not know anything about. But that sort of led me further down the track—I kept doing a lot of dev work and development stuff but really pushed further into the technical side of SEO, and that’s what really got me involved in the SEO community.

The SEO community is a really terrific place. We’ve got a bunch of meetups that we have every month—we’ve been involved in these meetups for well over 10 years now. It’s called the SEO Collective, in Melbourne, Sydney, and Brisbane, if you ever want to go along to those. Either way, I’ve got a website here. Now, my major focus here is working for Bring—it’s one of my really major focuses, getting all that good juice for the clients and really getting great results. There’s a lot to cover, and even though we do all this, it’s still just a scratch on the surface, to be honest. But we’re full speed ahead.

So, why is page speed so important? Well, aside from the fact that it’s just kind of frustrating when you go to a slow website—everybody does this, right? Even if you don’t know anything about websites, the first thing you’re going to do after waiting for a while, trying to figure out why it’s slow—is my connection slow? Especially if you’re on a mobile device. What’s happening? Maybe I’ve got a slow connection, so you try someone else’s website, and that runs fast. This site’s just slow, so you go off it. You’ve lost it.

So, as far as SEO, this is huge, because the idea with SEO is we want people to have a good, positive experience and association—a bit of psychology here as well—because they have a great association with your brand, your website, and the idea is they will remember that. Now, especially if they’ve gone to Google—let’s say they’ve done a Google search for something specifically, and then your website comes up and you get the visit. In SEO, when you get a visit from Google to your website, that’s gold, right? That’s the magic—this is really why we’re doing SEO: someone did a search, especially if it’s a valuable keyword and a competitive keyword, and you’ve taken that click away from one of your competitors. They’ve landed on your page, and now your website’s running poorly. Not good.

Of course, Google knows this. So, Google brought out this thing called the Page Speed update. I’ll go into that in the next slide. There’s a lot of experts—this guy Martin Splitt, he works for Google, and there’s a lot of information he puts out there about page speed. But at the end of the day, it’s competitive, and if your competitors have got a faster website than you, then you really want your website to be faster.

So, what did happen with Google’s Page Experience update? Well, there was a range of things. Google really wanted to make web pages have a better experience for users. Now, this is because Google’s selfish—when you go to Google and you do a search, you are a Google user, right? So, when you end up on—do the search, click the button, go to your website—Google still thinks of the user as a Google user, even though they’re on your site. This is just the mindset of what’s going on when we’re thinking about it from an SEO perspective.

There’s a whole bunch of stuff: mobile friendliness—there’s still a lot of websites that just don’t hit the mark with mobile friendliness. HTTPS—sounds strange, but there’s still, hey, you know, I go to the BOM website to check the weather and it’s still running on HTTP, so still not everyone’s on HTTPS. There’s a stack of pages that aren’t changing over. Now, from a security point of view, it’s probably no big deal, you don’t need to change over to HTTPS, but just an example—even though Google wanted this, not necessarily everyone’s getting on board.

Intrusive interstitials—this was a big one, like popovers, popups, things coming up just when you enter into the site. But again, there’s a fine balance. Obviously, you’re in marketing, you want to capture some information from the user when they enter your web page, so there’s a fine line between overdoing the popup and shoving that right in their screen as they enter the page.

But really, the big one here is the Core Web Vitals. That’s the one we’ve probably—it’s really the one where everyone sunk their teeth into it. But this was a while ago—back in 2021. Things have changed a lot since then, but Core Web Vitals is Google’s measurement for speed, right? So, if you didn’t do any—if you didn’t understand Core Web Vitals or the tricks, and you just sped up your website, you might still do all right. There are some specifics, though, that Google has given us to work with.

Of course, things have changed a little bit, but there are three main areas which haven’t changed—three main areas of metrics. One is loading, interactivity, and visual stability. LCP is all about the page loading. The interactivity is FID—now they’ve changed it to INP, and I’ve got some stuff about that on the next slide. But mind you, when you go—there’s a link here to the Google documentation—when you go to this page, you’ll see that Google hasn’t updated this; it’s still showing you the FID now, even though they’re saying use INP instead. So there’s a gradual change over time—a lot of the data we’re looking at historically is still looking at FID, even though we’re working with INP.

So, basically, we’ve got LCP—that’s your page loading. Your interactivity is your INP or your FID. CLS is cumulative layout shift, so that’s your visual stability. This is probably a bit underrated as well—people don’t understand what that means, but I’ll go into that a bit more.

So, you need to measure up these three metrics. In the SEO community, there’s debate about all of these things—will they really make any difference? Some SEOs say just forget your Core Web Vitals—as long as your page is not terribly slow, get on with other SEO activities. Then there’s the other side of the spectrum, where people are like, “Well, if you want your rankings to work, Google has said this is an algorithm, it’s one of the algorithms, and so if you can optimize your Core Web Vitals, you have optimized one of the algorithms.” From an SEO rulebook point of view, you can tick off your Core Web Vitals as a job done, and it’s another step closer towards your rankings, traffic, conversions, sales—business is happy because they’re making money. These are all steps towards it, and it’s sort of the bread and butter of what SEO is all about.

So, as far as LCP—largest contentful paint, 2.5 seconds. INP—the interaction to next paint—200 milliseconds. CLS is 0.1 second. They’re pretty lean—Google’s pretty unforgiving with the speed of this stuff. If you can get your website to load in under 2.5 seconds, I’d say in a practical sense, if you can get it to load in maybe under 4 seconds, you’re doing pretty well. But if you want to get green positive markers for all of this stuff, you will need to go pretty ruthless to make it go fast.

Back when Google sent out a notification to everybody that we’re going to use INP, all the clients freaked out and started emailing and calling—what’s happening, INP is all wrong, we don’t know what INP is. Of course, Google scaring everybody again in that way. But we’re still seeing in the data, in the reports and the graphs, that it’s still showing FID. I think it will eventually possibly be replaced, but it’s a bit of a tricky one, right? Because what does Google do if it’s going to show the data and show the graph—it can’t just automatically swap everything to INP and remove FID from all the reports. So this is an interesting transition time.

But here’s anybody who’s used the PageSpeed test tool will see now we’ve got LCP, which I’ve talked about, CLS, we’ve got INP, FID, time to first byte (TTFB), and first contentful paint. This is an old metric—first contentful paint. We used to use first contentful paint years and years ago; that was the important metric to get right. This little screenshot is a live screenshot from one of our clients. We’re getting pretty good performance here—when it comes to speed, 98%. It’s very difficult to get 100% on everything, but if you can get over 70%, I’d say you’re doing pretty well.

So, how will the report—there’s a few different reports, and we’ll get into some of these. Chrome DevTools—Google’s saying use TBT instead, so total blocking time. Use TBT instead of INP for that, and also Lighthouse uses that metric. That’s because you’ve got lab data and then field data, which I’ll get into as well in some of these slides.

So, how do we measure this stuff? There are many, many, many tools to measure your Core Web Vitals, and many ways of going about it. There are all kinds of third-party tools, all kinds of things—Google gives us a few tools. It’s probably good to use Google’s tools as a bit of a benchmark, but a lot of other tools can give you much more x-ray vision into the underlying things—what’s happening in the DOM, which JavaScript files, which CSS files, which DOM elements are causing issues, is the DOM oversized or bloated. There’s a lot of things we can get into with some of the third-party tools that perhaps some of the Google tools don’t allow us to. But as far as benchmarking, we do want to use the Google tools because Core Web Vitals is their metrics—it’s their system.

Let’s get into some of this stuff about lab data versus field data. Lab data describes a hypothetical user may experience your website—lab data is not real. When you go to PageSpeed, type it in, do a PageSpeed test, it’s not actually really testing the speed of your site—it’s just going through a bunch of checkpoints and giving a hypothetical example of the speed. But field data is actually data that’s been collected and stored by Google and shows actual real users visiting the site. That comes from the CrUX data.

There’s also RUM—you can use real user monitoring, which is another level again. If you’re getting advanced, you can go into Cloudflare, set up RUM, set up a RUM collection, and it will collect that data. If you really want to go to the next level, get into RUM—it’s great. CrUX is a Chrome User Experience Report—this stuff gets stored. CrUX is a BigQuery dataset, all sitting in Google’s cloud, but it’s gathered from real Chrome users in the field—people who visit your site. But your web page needs to have a sufficient amount of traffic going to it on a regular basis before it triggers Google to start storing this stuff. You might have a couple hundred visits a month, but that might not be enough to trigger Chrome to start storing the field data. We don’t know exactly where the limit is, but I think the limit’s probably—it’s one of those elastic limits that seems to kick in with Google, which is a lot of things. I like this in SEO—you just don’t know really, and Google won’t tell you exactly the number of visits, probably because they’re using some kind of algorithmic, maybe AI-based limit.

But anyway, suffice it to say that if you’ve got a reasonably commercial website with a fair amount of traffic, you will have a CrUX dashboard—you can go in there and create your dashboard. There’s a link here—you’ll get these slides afterwards, we’ll share the URL.

So, the first thing you do is go to this dashboard—it takes you to the Community Connector. This is using—it’s not Data Studio, it’s Looker Studio—I still call it Data Studio because I’m a little bit rebellious in that way. Looker Studio—I just don’t understand why it’s called Looker. Data Studio makes more sense and I like saying that. Go to this page, it will take you to the data connector—here you connect it up. Here, I’ve just got—we did some consulting for this client at one point, and then connect, you just connect.

When you connect, it brings in all this data sitting there so you can start creating your report. You just click “Create the report.” I haven’t altered any of this, but you can alter all this if you want. Now, here you go—you’re getting a rich data report with all of the fields—all of the Core Web Vitals metrics and the history. Now you’re getting months of data, and you can go back and look at trends. You can see the actual real-time visits to your site. This shows 10 months of historical trend by metric type. For instance, this one is your CLS—cumulative layout shift—and here we can see the trend going on. They’ve got a fair bit of CLS happening, sort of red things—this is all going back in time now, but at the time this snapshot was taken, you can see there’s work to be done—there’s lots of red, which is good, it means we have work to do, we need to get in there and fix the CLS.

What we’re looking at here is CrUX is averaged over a period of 28 days. Since CrUX provides a rolling average over 28 days, it’s a rolling average. It’s not an ideal tool to use during development—it’s not real-time. When you’re actually working on the site and you want to have a look—say you’ve fixed up some of these DOM elements, removed some div tags or put some H1 tags in there, something like that—you’ll want a different tool to see real-time. But CrUX is a great tool for your Chrome, for seeing field data. It’s handy if you don’t gather your own field data, you haven’t got RUM. If you did have RUM, you could use your own field data instead of the CrUX dataset.

PageSpeed Insights is probably the most common, most accessible, easy-to-use tool. PageSpeed Insights report shows field data, but it also has a lab data section. You just Google for that, type it in—they’ve changed the URL a few times over the years, but just go to this, load it up, and you just put any URL in here—it’s a URL per URL. So if you put your homepage in, it’s not going to check the speed of your whole website. You have to go in there URL by URL, type it all in.

PageSpeed Insights data covers the last 28 days, but the lab data is represented by the Lighthouse scores—Lighthouse gives specific opportunities for improvement. This is key at the 75th percentile. So, if you’re into statistics, PageSpeed is good if at least 75% of page views meet the good threshold. This is really understanding Core Web Vitals, diving deep into it. Look at this table—if you’re into stats and you really want to know how this works to squeeze the most juice out of Core Web Vitals.

Should I be using PageSpeed Insights? It’s good for page-level performance checks. It’s helpful for people who aren’t necessarily fully developer-focused. You can just load it up and drop it in, and it gives you a bunch of reds and greens and ambers—people like those traffic lights.

The other way of looking at this stuff is you can look at your Core Web Vitals inside of your Google Search Console. This is another indication of why and how this is important. Google spent probably multi-million dollars providing the Search Console and also the Core Vital metrics inside of the Search Console. The fact that they’re spending money on this, making it available to us, probably means it’s an important thing for us to get under control.

The idea here is that here we can identify groups of URLs. It’s important also to see that this data is coming from CrUX, so it’s still got that 28 days of data—this is not live data. If you make an improvement to this tomorrow, you’re not going to necessarily see tomorrow in your Core Web Vitals inside of Search Console that it has improved straight away. But what you will see is groups of—so, categories, right? If you’ve got a category like kittens or puppies, and if there’s a recognizable pattern of pages within that category, it groups it, and that’s how it’s doing it—it’s looking at groups of data, groups of information.

This might not be good if your pages aren’t in the CrUX set—so if you’ve got a low-traffic website, you might see that your web pages are not appearing inside Google Search Console.

Now, I just had a thought that maybe there are people on the call that don’t know what Google Search Console is. If that’s the case, that’s probably a good one to follow up on another separate call, but just to say that if you go to Google, type in Google Search Console, if you don’t know anything about it, you can add your site to Google Search Console quite easily by just adding a little piece of code to your website. There’s also other times—if you’ve got Google Analytics already, you can hit the button and verify it that way as well, without having to add any code. So there’s a few ways you can do it. But Google Search Console is the powerhouse SEO tool for us that Google gives us for free to dive into all the technical elements of a website—just thought I’d explain all that stuff.

So, Lighthouse. Lighthouse is—if you’re on Chrome, you go to the Chrome web tools, scroll up to the tab at the top, and you can go to Lighthouse. Lighthouse, as this GIF is showing here, you click on Lighthouse and it will give you—it’s the same sort of thing as PageSpeed Insights or whatever. But Lighthouse is the underlying data, and you can pull this directly from your page. This is kind of a balance—same kind of thing here, but here we can see it’s quite slow at the moment—this is many years ago, it’s been improved since. But it’s not as convenient for page analysis.

So, how does Lighthouse test Core Web Vitals? Lighthouse simulates a mid-tier mobile device on a slow 4G connection. That’s a mid-tier mobile device on a slow 4G connection, so it’s trying to do a test that suits somewhere on an average. That’s why sometimes you can browse the same page and think, “What’s wrong? My site is running fast, how come Google’s telling me it’s slow?” Well, you probably don’t have a mid-tier mobile device on a slow 4G connection, right? Based on the 75th percentile logic for a variety of devices and connections.

That’s why people get surprised, especially clients—they’re saying, “Oh, the site’s fast,” or they’re sitting in downtown Sydney on a fiber connection.

We can also use another tool—a Chrome extension. This one measures Core Web Vitals in real time, and it gives you a bit of a—you know, if the CrUX dataset is available during startup and while browsing the page, layer shifts, and after. You can add this in and, as you’re browsing pages, pop open this Chrome extension and get a look at what’s happening. Largest contentful paint looks okay there, and as you can see, you’re browsing, you can just see the metrics as you’re going—spot checking with the Web Vitals extension.

As I said, it’s not going to give you all the details you need—it’s just a high-level, “Oh, is this page a bit slow?” But obviously, you’re going to need to use Chrome DevTools or something like that to really get into the debugging.

So, let’s have a look at some of the common optimizations. Now that we’ve talked a bit about what Core Web Vitals is and how you can get a feel for them using various tools, now the hard work begins, because now we actually have to get in and do some of the work. But we can get a few head starts here.

One of the very first things we can do is fix up our DNS and our CDN. Unfortunately, some of the web hosting providers are a little bit slow—not as fast as we want, they’re not necessarily Ferraris, let me say that. Cloudflare—oh man, that’s the infrastructure, the technology they’ve put together here. Just get on it. If you’re not using Cloudflare, I highly recommend it—we’ve just never had any complaints. Stick it in there, it’ll fix up your DNS. Don’t be a cheapskate—pay the $25 a month, whatever it happens to be, because you get the extra features and you do get some more performance. It’s definitely—you know, every single time we’ve done this, we’ve been pleasantly surprised, never seem to be disappointed. Cloudflare—content delivery network, images, all kinds of things that Cloudflare can do for you. This is a head start without having to go into any of the WordPress code or anything. They have an automatic WordPress optimization tool, so if you’re short on time or can’t get access to change any code on the site, you can plug this in and it does make a difference. It really does—we’ve seen this really speed things up. There are some wild claims here—300% faster—I have seen some things go pretty fast, but you can never really say, “Oh yeah, you do this and you’re going to get this percentage of speed improvement.” It’s really just more the case of, you want to go faster, do these things and you can get faster.

WP Engine—of course, we’re on the WP Engine webinar here, but I’ve been a fan of WP Engine for many years. Every single time we bring a client across onto WP Engine, we just see the benefits, and those benefits have really been improving over the years. PHP 7.4, HTTP/2—especially if you’ve got HTTP configured on Cloudflare and you’ve got that connecting up with your WP Engine, so you’re getting a seamless HTTP/2 connection—that’s your protocols optimized. The caching here—this caching stuff works awesome, and the CDN works beautifully with Cloudflare. Depending on what sort of configurations you get to—I can’t claim these numbers, I can’t say that they are specifically what I’ve experienced, but I have seen that it does handle spikes and does quite well.

Now, you can go and get your premium hosting, but the key is—get that premium hosting. Don’t be a cheapskate, don’t pay $5 per month for some cheap hosting and expect to make it go fast. It’s just not going to happen. The server architecture—the computer that your website is running on—is not going to be fast enough. All of that infrastructure just won’t be there. Go pay some money, get some premium hosting like this stuff, WP Engine, and you will see the speed improvement.

So, then we dive into WordPress. There’s a stack of stuff we can do—log in to WordPress, let’s get working, let’s install WP Rocket. Some things we can do straight away just by ticking boxes—we can load defer JavaScript. There’s a bunch of settings—once you get this plugin running, you’ll be playing around with lots of buttons and tick boxes and options. Deferring JavaScript—that’s one of the big problems when it comes to Core Web Vitals, because all the page builders, they all put the JavaScripts at the top of the DOM, right? DOM is the document object model, and so as the page loads, it’s not loading asynchronously, it’s not deferring the JavaScript, it’s just loading the page down the DOM, pulling in JavaScripts, pulling in CSS, and it’s blocking it up. If you’ve got dozens of JavaScript files—which page builders can do—you end up with stacks of time that’s gone by before your page is loading. Same with the render blocking—it won’t render the page because it’s got render blocking scripts.

There’s another tool you can install, which is Autoptimize, and there’s a bunch of configurations here—automagic stuff. I call it automagic because you tick the box and it optimizes for you. Asset Cleanup Pro is one of my favorites, but it really is a bit more advanced. It’s a bit more—it’s a bit of a weapon without a safety catch, this one. There’s lots and lots of configuration, so if you’re quite technical and like getting into that level of optimization, get into Asset Cleanup. There’s lots of stuff you can do there.

Code bloat—what we’re looking at here: the page builders, the theme files, the plugins—all this stuff bloats up the code on the page and it has to get transferred across your HTTP protocols and delivered to the client, and then all this complicated network DNS stuff—not to mention what kind of speed the client is browsing on. They could be on a train somewhere on their mobile device, in between mobile phone towers, and you’re trying to get your page to run fast enough so they can have a good experience and make the purchase on your e-commerce store. This is what we’re talking about when we’re talking about speeding things up. We’ve got to be a bit ruthless, and you might need to ditch Elementor, you know? Like, you like it, it’s fun, you can use it, you can make layouts, you can do all kinds of stuff. What are some of the other ones you can use instead? Well, just use Gutenberg, right? You can use the Gutenberg editor which comes with WordPress—it’s very powerful, very functional. If that’s too pure and raw for you, you can use some other things like GeneratePress, Oxygen Builder. Genesis Framework—one of the best you can possibly use. It’s very lean, very functional, but it does require a little bit of developer experience. But if you’re still hooked on Elementor, the Elementor Hello theme—that’s a heck of a thing. But you’ve got to think about what is the cost of a page builder—it’s adding another whole layer of elements, HTML elements, styling, CSS, JavaScript, all this stuff, adding it into the document object model. We definitely need to consider the cost and what that cost is worth to us if we’re losing sales or if the site is running slow.

• How Gutenberg Blocks are Fundamental to Your WordPress SEO webinar

There’s a whole bunch of stuff—Asset Cleanup, you can unload, you can remove unused CSS. Page builders, you’re attaching dozens of CSS files and they just don’t get loaded—they just sit there. They’re loaded, but they don’t get used in the page for the render, but they’re still loaded, so you’ve got to get rid of that.

CLS—cumulative layout shift. What we’re looking at here is when the page loads, your cumulative layout shift is that little shift as it’s loading, it sort of boop, and it pops a bit more, and a little ad comes in, or one of your elements is resizing—especially an image file, like it’s loading, then it needs to resize to render. CLS—Google does—the reason why it’s bad for SEO is because you go to click on a button, and next thing you know, it moves and you missed the click. You can imagine from an SEO black hat point of view what kind of tricks you could do with that. CLS has got a few reasons why it’s important. We can debug it—there are tools to debug this stuff and have a look. Here’s an example where this little black section appeared, so that’s now got a cumulative layout shift, and Google hates that stuff.

There are CLS debuggers, tools you can use. Some of the things we can do—fonts. Fonts is one that really causes this problem. You can avoid the shift while the fonts are loading. There are many plugins—here’s one which is Google Fonts to swap that font, so that’s definitely something worth doing. If, as your page is loading, it’s trying to show a font and then it swaps it out with Google, you don’t want that to happen.

Images—especially images that don’t have dimensions on them, so your width and height. This little screenshot here I’ve taken is directly from the PageSpeed diagnosis—the analysis that it gives you. It’s saying you need to specify width and a height on your images. Sounds like a no-brainer, but if it doesn’t have a width and a height, and if the width and the height doesn’t match the size of the image file, or if you’re talking about resizing images, media queries, that kind of thing, then that needs to be all done properly. But there is another little hack you can do—go into your WP Rocket, tick the box, and it will add missing image dimensions.

LCP—largest contentful paint. It’s theoretically the largest file, usually something like a hero image. We’re talking about 2.5 seconds for this to be good. It’s something like a hero image, a banner image, or sometimes a banner video—whichever the largest element is on that page, which is taking the longest. The PageSpeed Insights tool will show you what that is—it points out what your largest contentful paint element is. Go in there, compress that up, squish it down, and Autoptimize can do this stuff. Now you’ve improved your LCP.

INP—here we are, now we’re talking about INP. Your INP is under 200 milliseconds—again, it’s pretty ruthless, right? That’s very ruthless. Interaction to next paint—what that means is, it’s moving from one element to the other as it’s rendering. You’re not going to get that—as I said, this is ruthless stuff. If you’ve got stacks of JavaScript files, stacks of CSS files, all kinds of stuff, you want to reduce that. Tick the boxes, minify—just minify those down. If you haven’t consolidated your JavaScript files, just minify them, same with your CSS.

Third-party code is a big one. What’s the cost of third-party code? You’ve got Klaviyo, you’ve got Hotjar, you’ve got all kinds of third-party codes—Bing Ads, everything, all jammed in there. This is slowing the site down. You need to find a way of reducing the third-party code. This plugin here will do it—plug this plugin in and reduce that third-party code.

YouTube—what you can do is replace the YouTube iframe. YouTube’s embedding in an iframe—the iframe needs to load, so it needs to ping the third-party website, needs to ping YouTube, and be able to load that and verify and begin the video in your page as your page is loading. So you replace the iframe with a preview image—it gives you a preview of the video, then when you click the preview image, it goes and loads the video. That’s a big speed improvement right there.

Properly sizing images—resize them to the correct size needed for the page. This again is coming from PageSpeed Insights, the tool that Google gives you. So you can look at that—it’s pointing out which things are wrong, what needs to be fixed. Compress your images—ShortPixel is sort of an old thing, but it’s really good. Use explicit width and height on an image, and as I said, add missing image dimensions.

Serve images in modern formats—WebP. WebP has been around for quite a while now, but lots of websites still aren’t using WebP. It’s definitely worth getting on board with that one—it’s a next-gen format. There’s tons of tools that’ll do this—here’s one called WebP Converter for Media. I just recommend getting on board with that.

Defer offscreen images—this is essentially lazy loading. If you’re not a developer, what does lazy loading mean? It means you’ve got a great big long web page, and down below the fold are all these images that are still actually loading as your page loads, and it’s going to slow the whole page down. The idea is, you don’t want any of those images to load below the fold until you scroll down, then it loads them below the fold. WordPress introduced this feature, so lazy loading is built into WordPress core. One of the things we’ve got to be careful of is that we don’t want lazy loading images to appear above the fold, because then it means that when Google renders that page, the image is lazy loaded—it won’t, even though it might appear in our browser to us, but to Google, Google’s rendered the page and it just can’t see that image. So we don’t want to lazy load images above the fold.

So basically, I’ve run through a bunch of tips—I’m trying to keep things into perspective of what is the SEO philosophy behind all these kinds of things. I wish I knew—I wish I kind of believed, I want to believe in FID versus INP. I don’t know, it’s too much the same stuff for me to really say that one is better than the other, that it’s going to help or be anything. But I mean, I guess there will be people that will—and I want to hear this, I’d love to hear it—if you have any ideas or thoughts about why Google swapped out with the INP and the FID. But other than that, fast page speeds—it is an SEO win, we’ve seen it time and time again.

Just to put it in perspective, instead of me reading out these bullet points, what I’ll say is we had a client—we were trying to get them some really big wins in Google Discover and also in the Google News Top Stories. This languished for quite a long time, they weren’t getting anywhere until we fixed the Core Web Vitals. We fixed the Core Web Vitals and almost instantly, almost the next day, bang—they were getting Google Discover traffic and Google News traffic, like a lot of it, a lot of traffic. So I would say this is definitely not a futile exercise. As I said, a lot of SEO people sometimes put Core Web Vitals on the back burner, but my take on it is it’s definitely worth the effort.

There’s a bunch of resources here to look at, read more, learn more. Other than that, thank you very, very much. If we can go on to some questions, I’ll just stop my screen sharing here.

Rick: Thanks for that presentation, Peter. I’ve got a couple of questions here. We did get quite a lot of questions during the presentation and we tried to answer as many as we could as we went along. We’re running out of time, but we’ll try and answer as many as we can right now. Probably the first one I think—I’m going to ask is: Are there any caching plugins considered as black hat SEO, and are any caching plugins still advisable to be used?

Peter Mead: I know where this is going because—so, black hat, right? Caching—so the idea is, you could possibly, if you had a caching tool that could do this—I mean, there’s other ways of doing this—but you could end up doing something like what we call cloaking, which is essentially showing one URL, like showing one rendered page to Google and a different rendered page to the user. Now, you could use some sophisticated plugin that does this, and then you could show one rendered version to Google and another rendered version to the user. I just think it’s not worth the effort—there’s so much more marketing to do, so many more ways to get traffic than to try and trick Google into giving you traffic, so I’d say don’t even bother thinking about it. But most—no, I mean, in general, caching, if you’ve got a good caching plugin, it’ll work fine. It’s not a problem, unless you’re using it for some reason to try to trick the end result.

Rick: Awesome. Another quick question: Is having a slider in the website—does that impact page speed? Someone said, “I have a hard time optimizing the sites having sliders in the first fold of the page.”

Peter Mead: Yeah, it can, yes, because you think—I mean, again, it depends how they’re optimized, and not all sliders are created equal. If you’re using some code like Gutenberg, there’s some slider elements that you can use. Genesis, there’s some stuff—it’s really well coded, predefined framework code you can use to put sliders in there, which can be much more optimized. But it also depends on the content within the slider—if you’ve got massive images, oversized, and they’re not, as I said, if the dimensions aren’t specified or if they’re not compressed. Also, all those images—say you’ve got 10 things in a slider—all those images have to load and they’re all above the fold. So yeah, it can—you’ve got to think of the cost, and it can take quite a bit of work to get to the bottom of how to optimize that.

Rick: Awesome. Another question we got was about delaying JavaScript. Sometimes people are saying that can ruin the look of the website. Is there any rule to it, and is it really beneficial to delay the JavaScript?

Peter Mead: Yeah, it is beneficial, yes. Depending on how the theme files have been coded, yes, it can sometimes mess up your layout. What I would say is definitely consider the cost—how much, you know, how many milliseconds or seconds. I mean, if you’re looking at something like three or four seconds of JavaScript that needs to load, then yeah, you want to really think about that. So it might take a bit of recoding to do that. But again, page builders are going to be the worst culprit—if you’ve got page builders that are just dumping dozens of JavaScript files onto your homepage, that’s not going to be good. In my experience, I find page builders are kind of like a Swiss knife—they’re great because they’ve got so many tools and things you can do with them, but at the end of the day, you’re carrying around a big bulky thing and you might not use all those, but you’ve got to bear the bulk of it. So there’s a time and a place for them. Again, if you’re on a budget and you want to smash out a fast website, then you might want to use the page builder.

Rick: Exactly. Another quick question—SEMrush: do you use a tool like SEMrush to analyze your SEO instead of manual analyzing?

Peter Mead: Yeah, so, I mean, we need lots of tools when we get to this level—when we’re dealing with large clients with lots of data. We’re using the free tools, and you can get by with lots of the free tools. Things like Screaming Frog is free, there’s all kinds of things. Google gives you free tools. But professional tools like SEMrush—we use SEMrush. I’ve been using SEMrush since about 2013. Big fan—have always loved SEMrush and the tools. They’re making big advancements in those tools. Of course, each tool has its strengths and each gives you a different perspective. But definitely worth it—if you’re going to get serious, it’s definitely worth forking out for one of these tools. Pay the money and do it, yeah, absolutely.

Rick: As we go through this journey, there’s always tools—you’ve got to find the right tools for the job that suit you and work for you. Another question—and I guess as you went through this presentation you talked about a lot of plugins and things to help on this journey of making the sites SEO friendly. One of the questions was: Installing this many plugins can create complexity on the site. Is there any resolution or thoughts on this?

Peter Mead: Yes, there is. Topic I know, oh yeah, and especially because of what I talked about. Pick and choose, right? When you make your meal, you’ve got options of different kinds of meat and veggies for your dinner, right? You’re not going to put all the meat on the same plate, and you’re not going to put all the veggies on the same plate. So choose one of the meats and a few of the veggies. You’re not going to have Asset Cleanup Pro and WP Rocket and Cloudflare APO, Automatic WordPress Optimizer—you’re not going to have all the tools all turned on and enabled so all the plugins are loading up. There’s kind of this theoretical limit we used to talk about, which was maybe about 20 plugins is a good amount, but it’s probably more a case of which of those plugins is changing the DOM, which of the plugins is changing the way the page renders or puts load on the front end of your DOM, your code. If you’ve got plugins on the back end that are only affecting things in the underlying code, in the PHP, then it’s not making any difference to the speed of the site. But then again, you still don’t want to put plugins in—you don’t want three different caching plugins and all of a sudden they don’t know which cache is working and which one’s not. So probably, pick and choose—choose your poison. But it’s just playing around with what works—if you like WP Rocket, go for that, and then maybe don’t use Asset Cleanup Pro.

Rick: Thoughts? Now, I know we’re a little bit over time and thank you everybody who’s been with us a little bit over time here, but I’ve got one last question that’s a bit of a doozy: Where do you think the future of AI and SEO will go?

Peter Mead: We’re waiting for this one. This is obviously the flavor of discussion. Since—really, it’s been like this for the last 12 months or so, this discussion. Where will it go? Things will change, definitely. Search engines will change, user behavior changes. Almost everybody on the face of the planet’s heard of ChatGPT. They are bringing out a search engine—they will bring out a search engine solution. Google’s building AI directly into the search interface. AI is just everywhere—it’s on your computer, you load it up, every time you go to a website, it’s got some AI function. It’s here to stay—there’s no going back now. The genie is out of the bottle. Exactly where it all goes now, I think the pace will be dictated by user adoption, because not everybody just sort of says—everyone’s heard of ChatGPT, but not everyone jumps on and starts using it. So they’re going to slowly, maybe pick it up, and a lot of people just don’t actually care—they just go to Google and do a Google search. But as Google starts changing, and when Google turns around and says, “Well, actually, Google says, ‘No, AI for everyone, we’re going to give everybody AI,'” that’s where things change. That’s an opportunity right there for other players, because if Google gives you AI and says, “Yes, everyone has to have AI for search,” well, then they need to be able to do it the best. So if someone else comes along—Perplexity AI or Bing—who possibly has a better AI functionality, it’s possible. The days of the old website, you go to Google, you type in and you get 10 blue links, they’re just all back in history. Who knows, we might all be sitting around with some kind of optical implant and bio-connectors, reading our mind, and we just sit there flicking through web pages or reading results or just streaming up applications and they build in front of our eyes as we’re sitting there. This will happen eventually. How long that takes, I don’t know.

Rick: Good answer, love it. I think with AI, there’s no right or wrong answer at the moment. We’re just waiting to see what happens. But look, I want to thank you, Peter and Matt, for bringing this webinar to us. They approached me a couple of months ago to make this happen, and I appreciate them doing this because it is a hot topic and it’s one that we all have to know about in this day and age.

Thank you everybody who joined us today. Remember, we will be sharing the recording and the slide deck after the webinar. Not sure how long it’ll take us to get it out there, but we will get it out to everybody. Apologies that I didn’t get to all the questions—we had a lot of questions come through during the presentation. We will try and find a way to answer those questions, somehow, but if not, please bear with us. They’re very hard to answer all the questions during this short time. But thank you all for joining, this was a great presentation. I learned a lot, I’m sure everybody else has learned a lot, and I look forward to seeing the next webinar in a couple of months’ time and seeing what we bring up to help people understand the web and all things WordPress. So thank you very much, Peter and Matt, and we’ll see everybody later on. Thanks, everyone.