Core Web Vitals: Real Ranking Gains from LCP, CLS and INP

Core Web Vitals are not the whole story of ranking, but they are one of the few signals you fully control, and the field is wide open because most sites still fail at least one of them on mobile. The wins are concrete and rarely require a rebuild. What follows is what actually moves each metric, in the order we work through them on a real site.

Measure the field, not the lab

Field data from real users is the number Google uses. A lab score from your laptop on office fibre is a debugging tool, nothing more. On a mid-range Android phone on Nepali mobile data the two numbers are frequently a factor of three apart, and the field number is the honest one.

• Use the Core Web Vitals report in Search Console for the trend and the URL groups that are failing.
• Use PageSpeed Insights for a single URL, and read the field section at the top before the lab section below it.
• Chrome DevTools with CPU throttled 4x and network set to Fast 3G is the closest desk approximation to a real Nepali visit.
• Judge at the 75th percentile, which is what Google uses. Your median user being fine is not the standard.

LCP: make the biggest element appear fast

Largest Contentful Paint measures when the main content shows up, and the target is 2.5 seconds. It decomposes into four parts, and almost every failure is in the first two: how long the server takes to send the first byte, how long resources take to load, and only then rendering.

• Fix the server first. Server-side rendering with a cached response beats any front-end trick. If time to first byte is over 800ms, nothing you do to the image will save you.
• Serve the hero image in AVIF or WebP, sized to the viewport rather than to the designer's monitor. A 2400px-wide hero on a 390px phone is the single most common cause of a failing LCP.
• Preload the LCP image and the font it sits next to, and never lazy-load the hero.
• Move render-blocking third-party scripts below the fold or defer them. Analytics, chat widgets and tag managers are the usual offenders.
• Self-host fonts, subset them, and use font-display: swap so text paints before the font arrives.

CLS: stop the layout from jumping

Cumulative Layout Shift punishes content that moves while loading, and the target is 0.1. Every cause is a reservation you failed to make. Set explicit width and height on every image and video so the browser reserves the box before the file arrives. Reserve space for ads, embeds and cookie banners rather than inserting them above existing content. Load fonts so the fallback and the real face have similar metrics, or the text reflows on swap. Never insert a promotional bar at the top of a page that has already painted.

INP: keep the page responsive to touch

Interaction to Next Paint replaced First Input Delay and measures responsiveness across the whole session, with a target of 200ms. Long JavaScript tasks are the enemy, and the fix is nearly always less JavaScript rather than cleverer JavaScript.

• Break work longer than 50ms into chunks and yield to the main thread between them.
• Debounce anything running on keystroke, scroll or resize.
• Do not hydrate components that are never interactive. A static block of text does not need to ship a component.
• Audit third-party scripts by cost, not by importance to whoever asked for them. A chat widget that adds 300KB and blocks the main thread is a business decision, not a technical one.

Set a performance budget before the site grows

A budget is a number the team agrees to before anyone wants to break it, which is the only time it can be agreed honestly. Without one, every individual request is reasonable and the site gets slower anyway: one font, one tracking pixel, one carousel, one video embed, and a year later the page takes six seconds on a phone.

• Around 150KB of compressed JavaScript for the initial route. Beyond that, INP suffers on mid-range Android regardless of how well written the code is.
• Under 1MB total transfer for a first view, images included.
• LCP under 2.5s and INP under 200ms at the 75th percentile on mobile field data.
• A hard cap on third-party scripts, with a named owner for each and a review date. Anything unowned gets removed.
• Enforce it in CI so a regression fails a pull request instead of being discovered by a customer six weeks later.

The budget only works if it can say no. If a new tag pushes the bundle over the line, something has to come out, or the budget is raised deliberately with everyone aware of the cost. That is a conversation worth having once rather than a rule quietly ignored forever.

When a progressive web app is worth it

A progressive web app is a normal site plus a service worker, a manifest and an install prompt. It is worth building when your users come back often, when their connection is unreliable, and when an app store presence is not required. A restaurant menu does not need one. A delivery driver's job list, a field survey tool or a booking system used daily on patchy rural data absolutely does.

• A service worker that caches the shell and the last-viewed data makes a repeat visit feel instant, which is a Core Web Vitals win as well as a usability one.
• Background sync lets a form submitted with no signal complete when the connection returns, which matters on a Nepali highway more than in a case study written in San Francisco.
• Installability puts an icon on the home screen without an app store review, which for internal tools is often the entire argument.
• What you give up: the store listing itself, some platform integrations, and on iOS a set of capabilities that still lag Android.

If the answer is that you need real native capability, the comparison to make is in React Native vs Flutter rather than here.

The order to fix things in

Server response, then the hero image, then image dimensions everywhere, then third-party scripts, then the JavaScript bundle. That order is not arbitrary: it is cheapest-first and it front-loads the changes that move the field number. Most sites we audit gain more from the first two than from everything after them combined.

Chasing a perfect lab score is a trap. Field data from real users is the number Google actually uses.

Speed sits underneath everything else in search, but it does not substitute for the rest. The crawling, indexing and on-page work is in the technical SEO audit checklist, and building this in from the start is part of how we do web development.