A Malaysian business owner runs their homepage through PageSpeed Insights, sees a score of 94 out of 100, and assumes the website is in good shape. A week later, Google Search Console’s Core Web Vitals report flags that same page as “Needs Improvement.” Neither number is wrong. They are measuring different things, for different reasons, and only one of them is the one Google actually uses to judge page experience in search.

What Google is actually measuring

Core Web Vitals is three metrics, not one. Largest Contentful Paint (LCP) measures how long the main content takes to appear, with a “good” result at 2.5 seconds or less. Interaction to Next Paint (INP) measures how quickly the page responds when someone actually taps or clicks something, with a good result at 200 milliseconds or less; it replaced an older metric called First Input Delay in 2024 because it captures the full response, not just the first fraction of it. Cumulative Layout Shift (CLS) measures how much content jumps around as the page loads, with a good result at 0.1 or less.

Google assesses these at the 75th percentile of visits, separately for mobile and desktop. That detail matters more than it looks: a page doesn’t need every single visit to pass, but it does need three in four of them to, and mobile and desktop are judged apart because the conditions behind them are so different, particularly in a market where phones carry most of the traffic.

Why the same website gets three different verdicts

Lab data tells you what’s possible, not what’s happening

PageSpeed Insights runs a single Lighthouse test from a fixed location and connection profile. It’s genuinely useful for diagnosing a specific problem on a specific page, but it can’t measure INP at all, since interactivity requires an actual person interacting with the page; Lighthouse substitutes a proxy metric instead. A 90-plus lab score tells you the page is capable of loading quickly under controlled conditions. It doesn’t tell you how it behaves for someone browsing on a mid-range phone with several tabs open and a patchy connection.

Search Console only reports on real visitors, and only once enough of them show up

The Core Web Vitals report in Search Console draws exclusively on the Chrome User Experience Report (CrUX): anonymised data from real Chrome users who visited the page, aggregated over a rolling 28-day window. It groups similar URLs together rather than testing one page in isolation, and it includes URL parameters that PageSpeed Insights strips out by default. That’s one reason the same page can look fine in one tool and flagged in the other: the two aren’t always looking at the same set of URLs in the first place. A new page, or one with low traffic, often won’t have enough CrUX data to appear individually and gets reported at the whole-site level instead.

Third-party checkers are testing from somewhere else entirely

Tools such as GTmetrix or Pingdom run their own synthetic tests, often from servers outside Malaysia, under network conditions the tool has chosen rather than conditions an actual visitor experiences. They’re useful for catching an oversized image or a slow server response. A good score there says nothing about what Google records for someone on a congested mobile connection, which is where a meaningful share of real traffic happens.

Why the gap matters more here than the global advice suggests

Most Core Web Vitals commentary is written against a fairly uniform device and network mix. Malaysia’s field data covers a much wider spread of Android devices and connection quality than a typical in-house team tests against, and a growing share of traffic now arrives through in-app browsers on Facebook, Instagram and TikTok, which can render a page differently again. A site that feels instant on an office laptop over fibre can still fail INP for the median real visitor, because that visitor’s phone is doing noticeably more work to render the same page.

What this does, and doesn’t, do to rankings

Google has been consistent that Core Web Vitals act as a modest, tie-breaking signal between pages that are otherwise similarly relevant, not a primary ranking factor on their own. Failing them won’t usually knock a genuinely useful page out of the results. But treating that as a reason to ignore the report misses the real cost: a page failing INP is a page where a visitor is tapping a call button, a WhatsApp link or a form field and waiting for it to respond. That’s a conversion problem whether or not Google ever weighs it directly in rankings, and it’s often the more expensive of the two.

Where the real problem usually hides

On the sites MRVS reviews, a failing INP score is rarely caused by the page’s own code. It’s caused by what has been added to it over time: a chat widget here, a retargeting pixel there, a WhatsApp click-to-chat button, a separate tracking snippet for a campaign that ended months ago, each loaded independently rather than through a single tag management setup, and each competing for the same thread the moment a visitor actually taps something. This is also where the gap between managing a website and managing a paid media account tends to show up. A campaign team adds a new conversion pixel to hit a reporting deadline, and nobody connects that back to the page getting slower to respond. Looking at the website, the tracking stack and the advertising account as one connected system, rather than three separate scopes of work, is usually the quickest way to find out which script is actually responsible, rather than guessing from a lab score.

How to check it properly

  • Check Search Console’s Core Web Vitals report on a schedule, not only after a redesign, and note whether you’re looking at page-level or whole-site data.
  • In PageSpeed Insights, read the field data section when it’s available, rather than the lab score alone; the lab score is a diagnostic tool, not a verdict.
  • Test on a throttled mid-range mobile profile occasionally, not only on office wifi and a current-generation phone.
  • Audit third-party scripts after every campaign launch, not just once a year, since pixels tend to accumulate and rarely get removed on their own.

Two questions worth settling first

Does failing Core Web Vitals directly hurt rankings?

Not usually on its own. Treat a fail as a flag to investigate the underlying experience, not as an emergency ranking fix.

How current is the Search Console report?

It refreshes every few days but reflects a rolling 28-day window, so a fix made this week won’t clear the report immediately. Expect it to take several weeks to fully show a genuine improvement.

None of this requires chasing a perfect lab score. It requires knowing which number actually describes your visitors, and checking that one regularly. If your SEO, your ad account and your website are each being looked after separately, that’s usually where a script like this gets added and never revisited. MRVS’s Website Design & Development team can audit what’s actually slowing a page down for real visitors, and our SEO team can place that fix in the context of the other signals affecting your rankings. We’ve written before about a related failure mode in why website conversion tracking often breaks — the same script sprawl is usually behind both problems.