Core Web Vitals are measured on real visitors, not on test runs \u2014 which is why a site can pass every laboratory check and still fail in Search Console. The gap is almost always the difference between a fast connection on good hardware and an ordinary phone on an ordinary mobile network, which is how a large share of your buyers actually arrive.<\/p>\n\n\n\n
| Metric<\/th> | What it measures<\/th> | Google’s “good” threshold<\/th> | Usual cause of failure<\/th><\/tr><\/thead> | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| LCP<\/strong> Largest Contentful Paint<\/td> How long until the main content of the page has rendered<\/td> | 2.5 seconds or less<\/td> | Oversized images, slow server response, render-blocking resources<\/td><\/tr> | INP<\/strong> | Interaction to Next Paint<\/td> How quickly the page responds visually after a tap or click<\/td> | 200 milliseconds or less<\/td> | Heavy JavaScript occupying the main thread<\/td><\/tr> | CLS<\/strong> | Cumulative Layout Shift<\/td> How much the layout moves around while loading<\/td> | 0.1 or less<\/td> | Images without declared dimensions, late-injected banners<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n | Those thresholds are measured at the 75th percentile of real visits<\/strong> \u2014 meaning three-quarters of your actual visitors need to experience that level or better. A site can have a fast median and still fail, because the slowest quarter of visits is what decides it.<\/p>\n\n\n\n INP replaced the older First Input Delay metric in March 2024, so any audit or plugin still reporting FID is measuring something Google no longer uses.<\/p>\n\n\n\n The third is the one users notice most viscerally, even though it is discussed least. A page where the button moves as you reach for it produces a specific kind of irritation, and it is usually caused by something trivial \u2014 an image with no declared dimensions, or a notification bar inserted after the layout has settled.<\/p>\n\n\n\n Testing tools run in a controlled environment: consistent connection, consistent device, no browser extensions, nothing else competing for resources. Real visitors have none of that.<\/p>\n\n\n\n Field data \u2014 collected from real Chrome users and reported through the Chrome User Experience Report, which is what Search Console shows \u2014 describes what your visitors actually experienced, on a rolling 28-day window. When lab and field disagree, field is the one that matters, both because it is what Google uses and because it is what your customers went through. A change you ship today will not show fully in that report for about four weeks.<\/p>\n\n\n\n A practical check, useful mainly because it is uncomfortable: load your own site on a mid-range phone on mobile data during a busy period. That is closer to the median experience than anything you will see on an office connection.<\/p>\n\n\n\n None of this requires a rebuild. The instinct when performance is poor is to rebuild the site, and it is usually the most expensive route to a result that image optimisation and a script audit would have produced.<\/p>\n\n\n\n The direct ranking weight of Core Web Vitals is modest, and it is easy to conclude they are therefore not worth much attention. That reasoning misses where the cost actually falls.<\/p>\n\n\n\n A visitor who leaves before the page renders never reads the content, never sees the offer, and never enquires. That loss has nothing to do with rankings \u2014 you already won the click and lost the visit. On mobile connections during peak hours, the difference between a well-optimised page and a heavy one is the difference between arriving and giving up.<\/p>\n\n\n\n It also increasingly affects whether you can be found at all. Content that requires heavy JavaScript to appear may never be seen by the crawlers behind AI answers, which are less tolerant of rendering delays than Googlebot has become<\/a>. Google states that its AI features impose no technical requirements beyond ordinary Search eligibility, so this is not a separate bar to clear \u2014 but it is the same bar, and a page that renders slowly or only through script is at risk of clearing it poorly.<\/p>\n\n\n\n You already paid to win the click. Losing the visit to a three-second render is the most expensive kind of loss there is.<\/p><\/blockquote><\/figure>\n\n\n\n Google’s measures of loading performance, interaction responsiveness and visual stability. They are assessed on real user data rather than laboratory tests, which is why a site can score well in a testing tool and still fail.<\/p>\n\n\n\n They are a ranking factor with modest direct weight. Their larger effect is on behaviour – slow pages lose visitors before the content is read, and that costs more than the ranking impact.<\/p>\n\n\n\n Testing tools simulate a controlled environment. Search Console reports real visitors on real devices and connections. The gap between the two is usually the difference between a fast desktop connection and an ordinary mobile one.<\/p>\n\n\n\n Images that are larger than they need to be, followed by scripts that block rendering. Both are fixable without rebuilding anything, and both are extremely common.<\/p>\n\n\n\n It is simply how indexing works now. Google indexes the mobile version of your site, so anything absent from the mobile version is effectively absent from the index.<\/p>\n\n\n\n If your site passes testing tools and fails on real users, the fix is usually smaller than a rebuild. Send us the domain and we will tell you what is actually slowing it down. See how we approach site performance<\/a><\/strong>, message us on WhatsApp<\/a>, or send an enquiry<\/a>.<\/p>\n\n\n\n |