Core Web Vitals in 2026: What They Are and How to Actually Fix Them

Largest Contentful Paint measures how long until the largest visible element — usually a hero image, a heading or a block of text — has rendered. In plain terms: how long the visitor stares at a blank or partial screen. The target is under 2.5 seconds for three-quarters of visits.

Interaction to Next Paint measures responsiveness: when someone taps or clicks, how long before the page visibly responds. It replaced First Input Delay because that metric only measured the first interaction and only measured the delay before processing began, which flattered pages that responded slowly thereafter. INP looks at interactions across the whole visit and reports near the worst of them. The target is under 200 milliseconds.

Cumulative Layout Shift measures visual stability — how much content jumps around while loading. Everyone has experienced this: you go to tap a link, an image finishes loading above it, the page shifts, and you tap an advertisement instead. The target is under 0.1.

Each corresponds to a real complaint. Slow to appear, slow to respond, and jumping about. That is why they are worth fixing regardless of any ranking consideration.

This distinction causes more confusion than anything else in this subject, and getting it wrong means optimising for a number nobody experiences.

Lab data comes from running a test — Lighthouse in your browser, or PageSpeed Insights simulating a device. It is reproducible, useful for debugging, and does not reflect reality. It runs on one simulated device on one simulated connection.

Field data comes from real visits by real people on their own devices and networks, collected by Chrome and reported in the Chrome User Experience Report. This is what Google actually uses for ranking, and it is what appears in the Core Web Vitals section of Search Console.

The gap between them is often large and almost always in the same direction: field data is worse. Your visitors are on older phones and worse connections than any test assumes. So debug with lab tools, but judge with field data, and never report a Lighthouse score to anyone as evidence that a site is fast.

LCP is usually the easiest of the three to improve and the one where generic advice most often misses. The fix depends entirely on which of four phases is consuming the time, and you have to find out rather than guess.

If the server is slow to respond at all, nothing else matters — everything waits. Cheap shared hosting, an uncached database-heavy page, or a server geographically distant from your visitors all show up here. For an Indian audience, hosting in or near India rather than in the United States is frequently the single largest available win and is routinely overlooked.

If the resource is discovered late, the browser did not know it needed the hero image until it had parsed and executed something else. Preloading the LCP image fixes this, as does avoiding lazy-loading anything above the fold — a surprisingly common self-inflicted wound, because lazy-loading is generally good advice applied indiscriminately.

If the resource is slow to load, the image is too large. Serve modern formats, size images to what is actually displayed rather than shipping a 3000-pixel-wide original into a 600-pixel slot, and compress properly. This alone frequently halves LCP on image-led pages.

And if render is blocked, stylesheets and synchronous scripts in the head are preventing paint. Inline the critical styles, defer the rest, and move scripts out of the blocking path.

INP is the hardest of the three because it is caused by JavaScript doing too much on the main thread, and the main thread is shared by everything. A page can be visually fast and still fail INP badly.

The dominant cause on typical business sites is third-party scripts. Chat widgets, analytics, advertising tags, heat-mapping tools and social embeds each compete for the same thread that must respond to taps. A page with six third-party scripts frequently has no capacity left to respond promptly, and no amount of optimising your own code will fix that. Audit them ruthlessly: every tag should have an owner and a reason, and most sites carry two or three nobody can justify.

The second cause is doing heavy work in response to an interaction — filtering a long list, recalculating a layout, re-rendering a large component tree. Break long tasks into pieces and yield to the browser between them so it can paint. Show an immediate visual acknowledgement of the tap, then do the work, rather than doing the work and then updating.

The third, on WordPress specifically, is a page builder plus an accumulation of plugins, each attaching its own event handlers. This is genuinely difficult to fix without reducing the plugin surface, which is the real answer and the one clients least want to hear.

CLS is the most fixable of the three, and a poor score is almost always the result of a small number of well-understood mistakes.

Images and videos without dimensions are the most common. If the browser does not know how much space to reserve, it reserves none, then reflows everything when the image arrives. Setting width and height attributes, or a CSS aspect ratio, resolves this completely and costs nothing.

Web fonts cause shifts when the fallback font has different metrics from the web font, so text reflows when the real font loads. Preload the font, use font-display: swap or optional, and choose a fallback with similar metrics.

Content injected above existing content is the third: cookie banners, announcement bars, advertisements and lazily-loaded embeds that push everything down. Reserve the space in advance, or position the element so it overlays rather than displaces.

And anything animated using properties that trigger layout — top, left, width, height — will contribute. Animate transform and opacity instead, which the browser can handle without reflowing the page.

Most performance guidance is written against assumptions that do not hold here, and this is why sites that score well in testing still feel slow to actual customers.

The typical visitor to a Kolkata business site is on an Android phone costing between nine and eighteen thousand rupees, two to four years old, on a congested 4G cell shared with a great many other people, with several apps resident in memory and possibly a battery saver throttling the processor. That device has a fraction of the JavaScript execution capacity of the machine your site was built on.

The practical consequence is that JavaScript is far more expensive here than payload size suggests. A 500 KB bundle is not just a download cost; it must be parsed, compiled and executed on a slow processor, and that execution time is where INP goes wrong. Reducing JavaScript is disproportionately valuable in this market compared with what international guidance implies.

It also means testing honestly. Test on a real mid-range Android on mobile data, not on a flagship phone over office wifi. The difference is routinely three to four times, and every performance decision looks different once you have seen it.

A perfect Lighthouse score is not the objective and chasing the last few points usually costs more than it returns. The objective is passing the field thresholds for real visitors; a site at 85 with good field data is in better shape than one at 100 with poor field data.

Ignore advice to install several optimisation plugins simultaneously. They frequently conflict, each minifying and combining the same assets, and the result is often slower and considerably harder to debug. One well-configured caching layer beats four overlapping ones.

Ignore anyone who diagnoses a performance problem without looking at your field data or a trace. Performance is specific; the same symptom has half a dozen causes and generic checklists address the wrong one as often as not.

And ignore the temptation to optimise a page nobody visits. Start with your highest-traffic entry pages — usually the homepage and two or three service or product pages — because that is where the aggregate benefit is.

Begin by measuring the field data in Search Console and identifying which metric fails and on which page types. Do not start work until you know this; guessing wastes the majority of the effort.

Then fix CLS first. It is usually the cheapest to resolve, the fixes are unambiguous, and it disproportionately affects how competent a site feels to use.

Then LCP, working through the four phases in order — server response, resource discovery, resource size, render blocking. For most Indian sites the biggest wins are hosting location and image handling, both of which are one-off changes rather than ongoing effort.

Then INP, starting with a third-party script audit, because that is usually where most of the main-thread time is going and because removing a tag is faster than optimising code.

Finally, protect it. Performance regresses quietly — a new plugin, a marketing tag, an unoptimised image in a blog post. Check the field data monthly and treat a regression as a bug rather than as something to look at eventually.