Core Web Vitals: What Actually Moves the Numbers

Two sites can both score 94 in a lab test & deliver completely different experiences to real users. One loads on a developer laptop over fibre. The other loads on a mid-range Android phone on a congested mobile network. Only one of those is your audience. That gap between lab scores & field reality is where most Core Web Vitals work goes wrong.

So start by throwing out the score. What matters are three measurements, each describing a distinct kind of frustration, & each with its own set of realistic causes.

Read field data before you diagnose anything

Lab tools simulate. Field data records what happened to actual visitors. Google evaluates your site on field data collected from real Chrome users, aggregated at the 75th percentile. That percentile matters: it means a quarter of your visitors can be having a worse time than your headline number suggests.

Pull field data by page group rather than for the origin as a whole. An origin-level pass can hide a product template that fails badly, simply because the homepage gets enough traffic to drag the average up. Group by template: home, category, product, article, contact. Fix templates, not URLs.

Then check the split between mobile & desktop separately. In most Nepali markets the mobile figure is the one that decides your outcome, & it is almost always the weaker of the two.

Largest Contentful Paint: it is nearly always the same four causes

LCP measures how long until the biggest visible element finishes rendering. Usually that is a hero image, a heading block, or a background image on a banner. When LCP is poor, the cause is almost always one of four things.

1. Slow server response. If time to first byte is already high, nothing downstream can save you. Look at uncached database queries, shared hosting under load, & origin servers physically far from your users. A CDN with an edge presence in South Asia is a meaningful improvement for a Nepal-based audience.
2. Render-blocking resources. Stylesheets & synchronous scripts in the head delay first paint. Inline the critical CSS needed for the top of the page, defer the rest, & load non-essential scripts asynchronously.
3. The LCP element is lazy-loaded. This is the single most common self-inflicted wound. Blanket lazy-loading applied by a plugin will happily lazy-load your hero image, guaranteeing a slow LCP. Exclude above-the-fold images explicitly & add a preload hint for the hero.
4. Oversized image files. A 2400 pixel wide JPEG served into a 390 pixel viewport wastes most of its bytes. Serve responsive sources, use modern formats, & compress properly.

If you fix only one thing this quarter, stop lazy-loading the hero image & preload it instead. It is a ten-minute change with a disproportionate effect.

Interaction to Next Paint: the metric that exposes your JavaScript

INP measures responsiveness across the whole visit, not just the first click. It captures the delay between a user tapping something & the screen visibly updating. Poor INP feels like a dead interface: you tap, nothing happens, you tap again.

The cause is long tasks occupying the main thread. When JavaScript runs for hundreds of milliseconds without yielding, the browser cannot respond to input. The usual offenders are large hydration bundles, heavy event handlers doing layout work synchronously, & third-party tags that execute on every interaction.

Practical remedies, roughly in order of payoff:

• Break long tasks into smaller chunks & yield to the main thread between them.
• Move genuinely heavy computation off the main thread with a web worker.
• Debounce handlers attached to scroll, resize & input events.
• Load third-party scripts after interaction where possible. A live chat widget rarely needs to initialise before the page is usable.
• Delete tags nobody reads. Every site we audit has at least one analytics or remarketing script installed for a campaign that ended years ago.

Cumulative Layout Shift: reserve space for everything

CLS is the easiest of the three to fix & the most irritating to users. It is what happens when you go to tap a button & the page jumps, so you tap an advert instead.

The rules are simple & rarely followed consistently:

• Set width & height attributes, or an aspect ratio, on every image & video.
• Reserve a fixed container height for anything injected later: banners, cookie notices, embedded maps, promotional strips.
• Use font-display: optional or preload your web fonts so text does not reflow when the custom font arrives.
• Never insert content above existing content once the page has rendered, unless the user asked for it.

Layout shift regressions creep back in whenever marketing adds a new banner or a new tag, so it belongs on a monitoring dashboard rather than a one-off ticket.

What Core Web Vitals will & will not do for rankings

Be realistic. These metrics are a genuine ranking input, but a modest one. They will not lift a page that does not answer the query. What they will do is protect a page that does. When two results are otherwise comparable, experience quality can be the difference. & separately from search, faster pages convert better, which is usually the stronger commercial argument anyway.

That is why we treat speed work as sitting between technical SEO & conversion rate optimisation. The same fixes serve both goals, & the conversion effect is measurable far sooner than the ranking effect.

A workable sequence

Run this over a single sprint rather than as an open-ended project.

1. Export field data by template for mobile & desktop.
2. Identify the LCP element on each failing template & confirm it is preloaded, correctly sized & not lazy-loaded.
3. Audit the third-party script inventory & remove anything without a named owner.
4. Add dimensions to every image & reserve space for injected elements.
5. Profile the longest tasks on the two templates with the worst INP & break them up.
6. Set up ongoing monitoring so regressions surface within days rather than quarters.

Re-measure after four weeks. Field data is a rolling window, so improvements take time to appear even when the code shipped immediately. Judging a fix after three days will only confuse you.

Want the diagnosis done for you? See how we approach technical SEO, browse our other guides, or send us a URL & we will tell you which of the three metrics is costing you the most.