Core Web Vitals Assessment FAILED – Understanding Lab Data versus Field Data in Core Web Vitals

0:00Lab Data Versus Field Data in Core Web Vitals

Hello. Hey, it's Brendan from WP Speed Fix. I've been meaning to make a video about this for a long time. I want to talk about lab data versus field data in Core Web Vitals, and this Core Web Vitals assessment fail. We get a lot of questions about this. A lot of questions about PageSpeed Insights, such as why am I not ranking higher in PageSpeed Insights even with your speed work. People are using PageSpeed Insights to test it, so I want to get into that.

This is an essential concept to understand when it comes to site speed and Core Web Vitals. There is a big difference between lab data and field data. Lab data, also known as synthetic testing, is the speed data that a tool like GTmetrix or Google PageSpeed Insights spits back, or our own tool, SiteSpeedBot. These tools are basically trying to approximate reality. They're trying to act like a real user and tell you how fast the page loaded for them, so they're trying to mimic the real world. It's not the real world though.

Field data is real-world data. That is the actual speed that users are getting when they're on your site. Field data is what the Core Web Vitals data set is. It's the actual speed that users are getting when they go to your website. Google is picking this data up from Google Chrome. For any Chrome-based browser, every single page load is sending that data back to Google, and they've built this Core Web Vitals data set.

1:35Why You Can Score 100 and Still Fail Core Web Vitals

What we actually care about, and what our speed work and consulting is focused on, is the real-world or field data, the Core Web Vitals data set. It is entirely possible to have a 100 score in Google PageSpeed Insights and be completely failing Core Web Vitals, and the reverse is also true. You can be passing Core Web Vitals without a problem and have kind of an ordinary PageSpeed score. Generally, with 80 to 90 on desktop you'll pass Core Web Vitals, and anything over 60 on mobile you generally pass as well.

We get a lot of these emails saying my Core Web Vitals assessment failed but my PageSpeed score is super high, or I'm getting a 100 score, what's going on? There are a few reasons for that. One is that a lot of the time the PageSpeed score is cheated. You'll see around the web, if you've done any Googling, all these people guaranteeing that you'll get a 100 score in Google PageSpeed Insights.

2:22How Delaying JavaScript Games the PageSpeed Score

The way they do that is by not loading the entire site on the first load. The most common technique they're using is to pause or delay, or effectively not fire, the JavaScript on the page until the user interacts with it. Basically, when PageSpeed Insights does its test, it's only getting half the page. It's not loading everything on it. You'll often see, in extreme cases where a site is heavily driven by JavaScript, that in the screenshot in Google PageSpeed Insights the site is effectively completely blank.

This technique does have some merit and there are some advantages to using it, but using it aggressively like this is likely to send your speed backwards. This is where you get a 100 score in PageSpeed Insights and it looks really good, but your actual Core Web Vitals, or field data, or real-world data, doesn't move or actually goes backwards. The reason for this is that all the JavaScript is delayed or paused and doesn't run until the user starts interacting with the site. They start moving their mouse, or they start scrolling on a mobile device, and then the JavaScript fires.

So you're actually adding more time in, or there's more delay there. The user goes to do something, and then the website, or the device or browser, has to process all this stuff: analytics tools, JavaScript for running forms, sometimes menu items, all sorts of stuff. This is commonly why you'll see speed go backwards sometimes, or Core Web Vitals metrics go backwards, even though speed optimization has been done, or even where there is a very high score or a 100 score in Google PageSpeed Insights. It's essentially because the site is not loading everything on the first load. It's a trick. It's a cheat.

That's problematic for a few reasons. It often breaks the website in weird and wonderful ways. It's not good for sites like WooCommerce that are heavily JavaScript based, where you've got a lot of complex moving components: adding things to a cart, removing from cart, checkout, all this sort of stuff. This type of optimization can commonly break sites in weird ways. Things like mobile menus don't work, or if you go to the mobile site it takes three or four clicks, or three or four presses, for the mobile menu to work. What's happening is the JavaScript is processing and building that menu under the bonnet because the user started to interact with the site.

4:40How To Check for Broken JavaScript in the Console

There's a lot of risk with this technique. It's actually easy to see if you think that's been done to your site, or if you want to check your site and see if the JavaScript is broken. A really simple thing to do is right click on the page and go to Inspect. This will open the developer tools tab, and then go to the Console tab. I'm in the Brave browser, which is Google Chrome based. Most browsers have some form of this, or it might be in the developer menu up the top. In here, red is errors.

You'll see here these errors are okay, because I have this as a draft page, so these are okay to ignore, but often you'll see JavaScript erroring out. You'll see strange things in here. Yellow is warnings. These can probably be ignored. They need to be interpreted, but they can probably be ignored. In this case those are fine. That's some optimization done for fonts, but that's okay. Broadly, if you have had this type of optimization done, or you've done it yourself, where you've got a 100 score and it looks great but the site's still failing, look at the developer tools tab, the Console tab, and just see what's going on there. Any JavaScript files that are showing red or showing an error, there's likely something broken that relates to that. So keep that in mind.

5:52SEO Risks and Tools Like NitroPack and WP Rocket

This is also an issue for SEO, particularly in extreme examples. Google's crawler comes along, and if it doesn't see the entire page, that's a problem. It doesn't always, but it has the potential to hurt your SEO and cause huge SEO issues in some cases. That's another thing to be mindful of, especially if the site is blank. If Google is seeing a blank site, that's not good at all for SEO.

Some tools like NitroPack are doing some version of this. They're deferring loads. They're kind of recomputing the page. Be mindful with tools like that. NitroPack will speed up your site, and it works really well if you have a simple site that doesn't have a lot of JavaScript or complexity. With something like NitroPack, or even just installing plain WP Rocket and using the basic settings, usually those will get basic sites into the passing zone, unless there's something weird going on. They're very good for those types of sites. They're not very good for complex sites with a lot of JavaScript, so WooCommerce sites, or things that have a lot of moving elements or forms or interactive elements. Just keep that in mind.

Some of these tools may actually increase the speed. They may improve the LCP time, but they may hurt other metrics. They may hurt the CLS, or layout shift. Layout shift is when the page is loading and you'll see the page moving around all over the place, or you're hovering your mouse over something ready to click and then the page finishes loading and now your mouse is in the wrong spot. The button's over here somewhere, or whatever, because the page has finished loading. That's layout shift. A lot of sites are overly aggressively optimized, and it'll make them faster, but it introduces layout shift and just weird stuff with the render. Just watch that and keep those metrics in mind.

7:52Reading PageSpeed Insights: Field Data, Lab Data and Mobile Versus Desktop

We talked about PageSpeed Insights. PageSpeed Insights is broken down into two. It has the top section where it has the Core Web Vitals data, which is the field data. Then it has the bottom section, which is the lab data, the individual test that's running. Also keep in mind that the mobile test is testing on a slow device. If you're getting 80 to 90 on desktop, you're probably getting somewhere between 40 and 60 on mobile. The mobile test is testing on a slow internet connection, usually a 1.6 megabit per second connection, on a CPU-limited device.

Just keep that in mind. That may not necessarily be the bulk of your users, and it may not reflect your user base at all. Some sites have a lot of mobile traffic, some have a lot of desktop traffic. There's a lot of stuff on the web that's nonsense. Everyone's like mobile first, but particularly if you're dealing with corporate or business, most of the time you'll see that the majority of users are desktop. That's the same for our website. Our WP Speed Fix website has about 80% desktop. It goes up and down a bit. It used to be 85 to 90% desktop, and it's changed a bit in recent years, but the majority is desktop, because they're business people or business buyers. They're at a desktop, sitting in an office. They're not scrollers.

It might be the complete opposite for whatever site you're looking at. There may be people sitting on the couch at 9:00 p.m. at night scrolling. Just keep that in mind, and weigh things appropriately based on data, not just guesswork.

9:01Monitoring Field Data With the CrUX Dashboard Report

Let's talk about how to monitor the field data. There are a few different tools, and a whole bunch of free ways you can do it. One of the best ways is this CrUX dashboard report. Here is a screenshot of it, and you can build one at our website. There's a link here. If you go here, just enter a URL. It takes about 60 seconds to build, and there is no opt-in required. You need to have 50 to 100 visits a day minimum for Google to have enough data to build this report.

The report looks like this. It has a date picker here at the top. This is the latest month on this report, and this report will update on the second Tuesday of each month. When you've built it, you can come back to it and get the new data. It doesn't look like there was enough data last month to generate this part of the report. If there are gaps on the report, there may not have been enough traffic to generate data. Let's just use June 2025 here. On the left you can see there are some menu tabs, and you can see the historical data there. You can see here the speed going up and down.

It has the three Core Web Vitals metrics. Also pay attention to the time to first byte. Time to first byte is not a Core Web Vital metric, but it does affect everything else. This one is actually not great. This is a membership site and it does have some problems related to that, which is why the time to first byte is not great. These guys here in the red are generally people who are signed in. It's running a really old membership plugin, and signed-in sessions are slow, so that's why there's so much red there. That's one to keep an eye on as well, because it'll affect the other metrics.

Device distribution is also interesting. This will give you the breakdown of device types. You can see here, even on this one, we're up and down a bit. Some months there's more mobile, some months there's less mobile and more desktop, so it can be a bit all over the place. This part of the report is probably a good way to weigh which metrics you should give more focus. This one's 50/50 essentially, so both are important. There's not one that's more important than the other.

You can also run this report for competitor websites. It's free, so long as they have enough traffic, you'll be able to run this report. That's the CrUX dashboard report. This one can also be set up to email. It's a great management-level report. It's high level and gives you a good overview of the site. You can set it up to email monthly. It's got pretty colours, and it's really easy at a glance to see what's happening. For a passing score, these metrics generally have to be 75% or more green to be in the passing zone. You can see here this one has some work to do, with 74% on desktop and 69% on mobile. This is because of the membership site aspect, because people are logging into the site and the sessions are slow.

12:05Digging Deeper With CrUX Vis and Google Search Console

Some of the weaknesses of that report are that it's a sitewide report. It's great for management-level discussions, but it's not amazing for technical stuff, digging into it in detail. It's good for determining which metrics need improvement. This one here, CrUX Vis, is a bit more technical. Actually, it's much more technical. It's using essentially the same data set. This is another Google tool, but it allows you to dig into these metrics in more detail. If we go here to All Metrics, and we want to dig into LCP time, we can see the different parts of what LCP is comprised of. Is it time to first byte that's causing the problem? You can see here, yes, it is. In this case you'll see time to first byte was an average of 1.7 seconds, so we have a time to first byte issue.

This is related to the membership elements of this site. This is really why the site is slow, because of the members logging into it. This is a good technical report. It also has history in here, but it's good for digging into things in more detail. It's not so great as a management report. It's very technical and not so easy to look at at a glance, but very powerful, very useful.

Google Search Console. You should know what this is if you're looking at this video. This is Google's SEO console for showing you all sorts of stuff about site speed, SEO, crawling and indexing. Let me just load one up here. Here we go. It's under Core Web Vitals here on the left, and if you click here, Open Report, let's open this one, mobile. It'll give you a breakdown of what's happening. This is a bit better. It's a bit more pointy. It gives you groups of pages, so it's still not great down to a page level, but we have kind of groups. You'll see URL groups and types of pages here, and what the group speed is. You see there were 70 pages of this type and 19 pages of this type that have a problem.

This is a bit better for digging into stuff. Once you've fixed your speed, if you click Validate Fix in here, it'll come back and tell you if things are good. You can see here the speed was good on desktop and then it's dropped off a little bit, but you generally want to see this good. Also remember there'll be no data in here if there's not enough traffic, so keep that in mind.

14:23Real User Monitoring With Vital Signs Tracker

Last one: RUM tools, real user metrics tools, like Vital Signs Tracker. We built Vital Signs Tracker because we have this problem where Core Web Vitals is based on a 28-day average. We can't sit on our hands and wait 28 days to see if the changes we've done for customers have actually fixed the problem. Google also doesn't give us very pointy information. So we built this tool to basically track the same data Google is tracking. It uses JavaScript and picks up the speed from every user session and puts it into our database, so we can run reports on it.

Here's what a report looks like for this website. Let me just click over and I'll show you live. I've just run the same website, last 7 days, versus mobile. Also note here, that's looking weird, ah, because we opened the dev tools. Also note here we can actually break it out by segments. We can see logged-in versus logged-out users, people who are failing, all sorts of different stuff here. This is actually really useful, because membership sites and WooCommerce sites have logged-in users, so we can see the speed separately. You can see in this case we have the high-level speed again.

If we scroll down here we have country by country, and then page-level stuff. We can actually click into these metrics and see why this My Account page is slow. Well, time to first byte is bad on this page. It's an account page, so that's why that's slow. We can actually dig in and see, you know, US mobile traffic is great, so let's have a look at that. Here are all the individual sessions and what's happening here. This one had a delay. It doesn't always track the attribution, but you see here this is the image that was attributed to be the LCP image. We can dig into that data and see what's going on there. I think it's the same with FCP. You see the attribution and all the individual sessions that made that up.

16:20Key Takeaways and Getting Help

That's it for this video. I'll try and keep that kind of tight. Some key takeaways: probably a good place to start is to set up that CrUX dashboard report, sorry. Set this up to be emailed to you monthly. Do it once and then you have that report in your inbox at a glance. It takes 60 seconds to look at this and see what's going on with the speed. That's a good place to start.

If you want to get more into it, Vital Signs Tracker is available as a standalone tool on our website. I think if you click that link there, it'll load up, and you can track this data here and see what's going on. There's also some other SEO stuff built into this. We also track whether pages are indexable or not, because generally if they're not indexed, they don't count towards the speed. You can then also track it by indexable or non-indexable pages. There's more information and a walkthrough there on Vital Signs Tracker on our website. The signup link starts from 29 bucks a month.

If you want help, go to our homepage. On our homepage there is a free audit tool where you can submit a request, and then one of our team will come back to you generally within one business day or so. That's it for this video. If you have any questions, post in the comments below or head to our website and send us a request there. Cheers.