Core Web Vitals on the phones your buyers actually use

The office score and the buyer’s experience are not the same measurement

Somebody runs the site through a testing tool on a Monday morning. The number comes back green. The report gets pasted into a group and the performance conversation closes for another six months, which is roughly how long it takes for the same site to start losing enquiries for reasons nobody has connected back to that green number.

Here is what actually happened. A developer’s laptop has a processor several times quicker than the phone your buyer is holding, an office connection that does not degrade in a lift, and a browser cache already warmed by the fifteen times that developer loaded the page while building it. Every one of those advantages is invisible in the score. The tool measured a machine, and the machine was not representative of anybody who will ever pay you money.

Now picture the buyer. She is on a mid-range Android bought for somewhere between twelve and eighteen thousand rupees, two years old, storage nearly full, eleven apps updating in the background. She tapped your ad while standing on a Gurugram footpath with two bars of signal. Her phone has to download your page, parse it, run your JavaScript on a processor that is doing four other things, and then paint something she can read, and every one of those steps takes materially longer on her device than it did on the laptop that produced your green score.

That gap is the whole subject. Not whether your site is fast, but whether it is fast for the person you paid to bring here.

The financial shape of the problem is worth sitting with, because it is not really a technical problem at all. You spent money on the click. The ad platform charged you the moment she tapped, regardless of what happened next, and if she leaves before the page paints you have bought a visit and thrown it away without ever knowing her name. Nothing on your dashboard will label that loss. It shows up as a slightly worse cost per enquiry that everybody blames on the creative.

What LCP, INP and CLS each measure, and the published thresholds

There are three metrics. Each one covers a different part of the experience, and a site can pass two and fail the third badly.

Largest Contentful Paint answers a simple question: how long before the biggest visible thing on the screen has been drawn. Usually the hero image. Google’s published thresholds put good at 2.5 seconds or less, needs improvement between 2.5 and 4.0 seconds, and poor above 4.0 seconds. The source is web.dev/articles/lcp. LCP maps most directly to the feeling of a page being slow to arrive.

Interaction to Next Paint measures responsiveness. When somebody taps a button, opens a menu or types in a field, how long before the screen visibly changes in response. Good is 200 milliseconds or less, needs improvement is above 200 and up to 500 milliseconds, and poor is anything above 500 milliseconds, per web.dev/articles/inp. INP looks at all qualifying interactions across the visit, not just the first one, which is what makes it harder to satisfy than the metric it replaced.

Cumulative Layout Shift measures whether the page moves under the reader’s finger. It is a score, not a time. Good is 0.1 or less, needs improvement is between 0.1 and 0.25, and poor is above 0.25, per web.dev/articles/cls. The scoring uses a session window: shifts occurring less than a second apart are grouped, the window is capped at five seconds, and the reported figure is the largest single burst rather than the total across the page.

One more rule ties all three together and most teams miss it. The assessment is made at the 75th percentile of real page loads, segmented across mobile and desktop, which means Google is not asking whether your typical visitor had a good experience but whether three out of four did, and an average that looks respectable can hide a slow quarter that fails outright. Optimise for the tail. That is the actual instruction hidden inside the percentile.

Field data, lab data, and why the two disagree

Open PageSpeed Insights on any reasonably busy site and you get two reports stacked on one page. Most people read the wrong one.

The top block is field data, drawn from the Chrome User Experience Report. These are real Chrome users on real devices on real connections, aggregated over a rolling 28-day window, per the CrUX methodology documentation. That is the number Google uses. It updates slowly, it needs enough traffic to exist at all, and it is the only number that reflects your actual audience.

The lower block is lab data, produced by Lighthouse running a single simulated load in a controlled environment. It runs on demand. It is reproducible, and it gives you a specific list of things to fix. It is also a simulation of one hypothetical device on one hypothetical connection, and it knows nothing about the Android phones in tier-two cities that make up much of your real traffic. Those users are on 4G that keeps dropping to something slower.

So the two disagree. That disagreement is informative rather than a bug. Lab better than field is the common case, and it usually means your real audience is on weaker devices or worse connections than the simulation assumed, or that a third-party script behaves badly under real network conditions in a way a clean lab run never triggers. Field better than lab happens too, generally on sites with heavy repeat traffic where returning visitors load from cache while the lab run always starts cold.

Use both, for different jobs. Field data tells you whether there is a problem and how big it is. Lab data tells you what to change. Fixing something on the strength of a lab report and then declaring victory without waiting for the field data to move is the most common self-deception in this work, because the 28-day window means you will not see the truth for a month.

If your site is small enough that CrUX has no data for it, you are not stuck. Real User Monitoring scripts collect the same three metrics from your own visitors and report them immediately, and a lightweight one costs almost nothing to add. Do that before you start optimising blind.

How to test properly, in the order that gives you honest numbers

Testing badly is worse than not testing, because it produces a number you trust. Here is the sequence. It produces numbers worth acting on.

Start with your own analytics, not with a speed tool. Pull the device and network breakdown for the last quarter and find the tenth or fifteenth most common handset in your traffic, not the first. That model is your test target. For most Indian sites selling to consumers it will be a mid-range Android from Xiaomi, Realme, Vivo or Samsung, two or three years old, and it will be nothing like the phone anybody on the project team carries.

Then use Chrome DevTools. Turn both throttles on. CPU throttling at 4x slowdown is the setting that matters most and the one people skip, because processor speed, not bandwidth, is what makes JavaScript-heavy pages feel broken on cheap hardware. Set network throttling to Slow 4G rather than Fast 3G, which is closer to what most Indian users experience most of the time. Always test in an incognito window with a cold cache, since a warm cache turns a five-second load into a one-second load and flatters you enormously.

Now buy the actual phone. This is the step teams resist and it is the one that changes behaviour, because a throttled desktop browser is still a simulation and a real handset is not. Get a mid-range Android, put it on a normal consumer mobile plan rather than office wifi, and make the whole team load the site on it once a month. Keep it on the desk. Nothing improves a performance culture faster than a product manager watching a hero image crawl in over four seconds on a device that cost less than her monthly commute.

Test the money pages. Not the homepage. Your landing pages, your product detail pages, your enquiry form. Test them under the exact conditions a paid visitor arrives in, which means loading the full ad URL with its query string and tracking parameters attached, because those parameters frequently trigger extra scripts that never run when you type the bare domain into a browser bar.

Finally, test twice on different days. Third-party scripts change without telling you.

The usual culprits on Indian sites, in the order they normally bite

The same six problems account for most of what goes wrong, and they tend to appear in a predictable order of severity. Treat this as a checklist. It is not a ranking somebody measured, so work through it in order and test what changes on your own site.

Oversized hero images come first, almost always. A designer exports a 3000-pixel-wide JPEG at maximum quality, it lands in the CMS untouched, and every phone downloads two megabytes to display something 400 pixels across. This is the single biggest LCP problem on Indian sites and also the easiest to fix. Serve WebP or AVIF, generate responsive sizes with a srcset, and let the phone choose. The image should be measured in tens of kilobytes.

Third-party tags and pixels come second and are the hardest politically. A typical site accumulates Google Analytics, Google Ads conversion tracking, the Meta pixel, a heatmap tool somebody installed for a two-week test in 2023, a CRM chat script, a review widget and two remarketing tags nobody can identify. Each one costs download, parse and execution time on the main thread, and the phone runs all of them before it can respond to a tap. Audit the tag manager. Delete anything nobody has opened a report from in ninety days.

Font loading is third. Custom fonts loaded from an external host block text rendering while they download, so the reader stares at empty space or watches everything reflow when the font finally arrives. Self-host the files, subset them to the characters you need, use font-display: swap, and preload only the one or two weights the page above the fold actually uses. Most sites load six weights and use two.

Sliders and carousels are fourth and deserve less sympathy than they get. A hero carousel loads every slide, which means five large images downloaded so the visitor can see one, and the JavaScript library that drives it adds weight and main-thread work on top. Almost nobody swipes past the first slide. Use a single static hero, and if the stakeholder insists on rotation, at least lazy-load slides two onward.

Unoptimised video is fifth. An autoplaying background video in the hero section is a common request from clients who saw one on a competitor site, and it is frequently a twenty megabyte MP4 with no poster frame, competing for bandwidth with the content the visitor came for. Compress hard, cap the resolution, add a poster image, and consider whether the video needs to load on mobile at all.

Chat widgets come last in severity. They are the most reliably badly behaved, because they load a large bundle, inject a floating element after the page has settled, and often ship their own analytics along for the ride. Delay loading until the user scrolls or after a few seconds of idle time. The widget does not need to be present in the first second of a visit.

INP is the one most teams have not adapted to

INP replaced First Input Delay as a Core Web Vital in March 2024, and a large number of sites have not adjusted their thinking since. The change matters. It is bigger than a metric swap usually is.

FID measured only the delay before the browser could begin processing the first interaction. It was a generous metric and most sites passed it comfortably, which made it a poor signal. INP measures every qualifying interaction across the entire visit, and it measures the full path: the delay before processing starts, the time the event handler takes to run, and the time until the browser actually paints the result on screen. All three phases count. A site that passed FID easily can fail INP badly, and many do.

INP catches what FID ignored. A menu that takes 600 milliseconds to open on the fourth tap. A filter on a product listing that locks up for most of a second while JavaScript re-sorts an array of four hundred items. A form field that lags behind typing because a validation function runs on every keystroke and re-renders the surrounding component each time.

Long tasks are the usual root cause. JavaScript runs on a single main thread, and while a task holds that thread nothing else can happen, including responding to the user, so any function that runs for more than fifty milliseconds is blocking the browser from painting anything at all. On a mid-range Android that fifty-millisecond desktop task might take two hundred. The threshold is 200 milliseconds and you are already over.

Fix INP by doing less. Break the work into smaller pieces. Yield to the main thread between chunks of work, defer anything not needed for the current interaction, debounce input handlers so validation runs on pause rather than on every keystroke, and virtualise long lists so you are rendering twenty rows rather than four hundred. Heavy frameworks make this harder, since hydration on a large React or Vue page is one long task by construction and it lands precisely when the user is most likely to tap something.

Measure it in the field. INP is hard to catch in a lab run because a simulated load does not tap anything, which means a Lighthouse report can look clean while real users sit through half-second delays on your filter controls every single day.

CLS and the late-loading banner problem

Everyone recognises this one. Even readers who have never seen the metric. You start reading, the page jumps, and your thumb lands on something you did not intend to touch.

The mechanism is straightforward. Something arrives after the initial paint, takes up space it had not reserved, and pushes existing content down. Images without explicit width and height attributes are the classic case, because the browser has no idea how much room to leave until the file arrives. Ad slots do the same thing. So do cookie consent bars, festival offer strips, app-install prompts, sticky headers that materialise on scroll, and the sales chat bubble that appears three seconds in.

There is a seasonal version. Indian sites get the Diwali or end-of-season sale banner injected by a marketing tag, sitting above the header, loading last because it comes from a third party. It shifts the entire page down at exactly the moment somebody is reaching for a product link. The marketing team never sees it, because their browser has the banner cached from the twenty times they previewed it.

The fixes are unglamorous and they work. Set width and height attributes on every image and video so the browser reserves the box before the file lands. Reserve fixed space for ad slots and promotional strips with CSS, even when the slot is sometimes empty, since a reserved empty box costs you nothing and an unreserved full one costs you the metric. Load banners and consent bars as overlays that sit on top of content rather than as elements that push it down. Use transform-based animation rather than animating properties that trigger layout.

Remember the session-window rule when you read your score. CLS reports the largest burst of shifts within a five-second window rather than a total for the whole page, so one badly timed banner can define your entire score while a dozen tiny shifts spread across a long scroll may barely register. Find the burst. Fix that.

A diagnosis order, so the work is not guesswork

Most performance work fails because somebody starts fixing before they finish measuring. Work in this order. You will not waste a sprint.

First, establish the field baseline. Pull the CrUX data for your top revenue-carrying URLs and write down the current 75th-percentile figures for all three metrics. If the site is too small for CrUX, install a Real User Monitoring script and wait two weeks. Do not skip this. Without a baseline you cannot tell whether anything you do afterwards helped, and you will end up arguing about it in a meeting with no evidence on either side.

Second, segment by device and connection. Split the field data by device class before you look at anything else, because a site that passes overall and fails on Android is extremely common and the aggregate number hides it completely. If your paid traffic skews toward cheaper handsets while your organic traffic skews toward desktop, those are two different performance problems wearing the same average.

Third, find which metric is failing. Note by how much. They have entirely different causes and entirely different fixes, and doing image work when your problem is INP is a month spent improving a number that was already passing.

Fourth, run a throttled lab test on the worst page and read the waterfall rather than the score. You are looking for the specific resource that delays the largest paint, the specific script that occupies the main thread longest, and the specific element that shifts. Names, not categories. The report will tell you exactly which file is responsible if you scroll past the headline number.

Fifth, fix one thing. Ship it alone. Bundling six changes into one release means you learn nothing about which of them mattered, and when the field data moves in four weeks you will have no idea what to do more of. One change per release, then wait for the window.

Sixth, re-measure in the field and only in the field. The lab number will improve immediately and it is not the number Google uses. Give it the full 28 days.

What to fix first when the budget covers exactly one thing

A small business. One developer, a fortnight of budget. This happens constantly and the honest answer is not to do everything badly.

Fix the hero image. Take your highest-traffic landing page. That is the recommendation nine times out of ten, because LCP is the metric most Indian sites fail hardest, hero images are the most common cause, the fix requires no architectural change, and it is the one piece of work a single developer can complete properly in two days including testing on a real handset. Export to WebP, generate three responsive sizes, add width and height attributes, preload the image, and remove any carousel wrapped around it.

Second choice, if the image is already clean, is the third-party tag audit. Open the tag manager, list every tag, and ask who reads the report it feeds. Delete anything with no answer. This costs developer hours near zero and it frequently removes more main-thread work than a week of code optimisation would.

Here is the reasoning for prioritising this way, worked as an illustration with invented figures you should replace with your own. Say you spend two lakh a month on search ads and it brings four thousand visits to one landing page, and that page currently loses some share of arrivals before the hero paints. You cannot know that share without measuring, and anybody quoting you a percentage for it is selling something. What you can know is the direction. Every visitor who leaves before the page renders was paid for at full price and produced nothing, which makes page speed a media-efficiency problem sitting in an engineering ticket queue, and that is why it keeps getting deprioritised against features nobody asked for.

Do not start with a framework migration. Do not rebuild on a new stack because a vendor said their platform is faster. Those are twelve-week projects with real risk attached, and the site that needs them is rare. Compress the image first. Measure. Then decide whether anything else is actually required.

What good enough looks like, and when to stop

Optimisation has a stopping point and most teams either quit far too early or never quit at all. Both are expensive.

Good enough is passing all three thresholds at the 75th percentile on mobile field data, sustained across a full 28-day window. LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1. Once you are there you have satisfied Google’s published bar and, more usefully, you have a site that feels acceptable to somebody on a two-year-old Android. That is the target. Not a hundred on a lab score.

Chasing a perfect lab number past that point is where budgets go to die. The last few hundred milliseconds cost far more engineering effort than the first two seconds did, the returns fall away sharply, and a green field assessment is binary from Google’s side, which means an LCP of 1.2 seconds is not treated as better than 2.3 seconds for ranking purposes. Both pass. Spend the difference elsewhere.

Note what these metrics miss. A page can pass all three and still be a bad experience: confusing navigation, a form asking for eleven fields, a phone number nobody answers, pricing that is impossible to find. Core Web Vitals measure the delivery of the page, not whether the page is any good. Once you are passing, the next rupee is better spent on the form and the follow-up than on another hundred milliseconds.

Then hold the line, because performance decays. Somebody adds a tag, a marketing banner ships without reserved space, a plugin update pulls in a heavier library, and six months later you are failing again without a single deliberate decision having caused it. Put a monthly field-data check into somebody’s calendar and set a performance budget your build pipeline enforces, so a regression is caught before release rather than a quarter later. Maintenance is cheaper than repair. It always was.