Core Web Vitals and INP: what to fix first on your business website

Core Web Vitals measure loading, interactivity and visual stability, and each has a "good" threshold that Google publishes on web.dev. A page passes when it meets all three at the 75th percentile of its real visits, calculated separately for mobile and desktop.

That 75th percentile means three out of four visits should have a good experience. It is not enough for the site to feel quick on the office computer: what counts is what a customer sees on a mid-range phone with patchy coverage.

• [LCP](term:lcp) (Largest Contentful Paint): time until the main element, such as the hero image or headline, is shown. Good: 2.5 seconds or less.
• [INP](term:inp) (Interaction to Next Paint): latency of clicks, taps and key presses. Good: 200 milliseconds or less; 200 to 500 needs improvement; above 500 is poor.
• [CLS](term:cls) (Cumulative Layout Shift): how much content shifts unexpectedly. Good: 0.1 or less.

INP became a stable Core Web Vital in 2024 and replaced FID, a metric that only looked at the first interaction. INP observes interactions throughout the visit and, according to web.dev, its final value is the longest interaction observed, ignoring outliers.

For a business this changes the diagnosis: a site can load well and still feel sluggish when a visitor opens a menu, filters a catalogue or presses "book". Scrolling, zooming and hovering are not counted; clicks, taps and keyboard input are.

web.dev splits an interaction's latency into three parts: input delay (the page is busy with long tasks), the time the event handlers take to run and presentation delay (the browser is slow to paint the next frame). Knowing which of the three is losing the time points towards the fix.

Start with field data, which comes from real visitors, and keep lab tests for reproducing what you have already found. Field data tells you whether there is a problem; the lab helps you find the cause.

There are three free starting points: the Core Web Vitals report in Search Console, which groups your URLs by performance; PageSpeed Insights, which shows Chrome User Experience Report (CrUX) data when there are enough visits; and the web-vitals JavaScript library, which lets you record INP on your own site. According to web.dev, field data with context is the best way to find the specific slow interaction.

A warning about the lab: it depends on which interactions you try, and some tools do not report INP at all. Total Blocking Time is a rough indicator but not a substitute.

A slow LCP is almost always down to the server response or the main image. The web.dev guide splits the ideal time into four parts: roughly 40% for the server response, 40% for downloading the main resource and under 10% for each of the two remaining delays.

In practice, the fixes with the best return are these, all covered in that guide:

• Cut redirects and serve the HTML from cache or from a content delivery network (CDN).
• Make the main image discoverable in the initial HTML rather than only in CSS or JavaScript; if that is not possible, preload it.
• Give high priority (`fetchpriority="high"`) to one or two likely LCP images, and lower it for those that are not visible, such as hidden carousel slides.
• Do not lazy-load the main image: it adds waiting time for no benefit.

CLS is usually fixed by reserving space, and INP by reducing the work that blocks the main thread. Neither needs a redesign, although both need sound technical judgement.

For CLS, web.dev lists images without dimensions, ads, embeds and iframes without reserved space, and web fonts as the usual causes. The fixes: set width and height (or `aspect-ratio`) on images and video, reserve a minimum height for banners, forms and late-loading content, animate with `transform` rather than `top` or `left`, and preload critical fonts with a similar fallback font.

For INP there is no single recipe, because it depends on which interaction is slow. web.dev's hint is to break the problem into its three parts. If input delay is high, long tasks are occupying the page; third-party scripts such as chat widgets, measurement tags or pop-ups are a common culprit, but confirm that with your own data rather than assuming it. If the handler is the problem, the code behind that button or filter does too much. If it is presentation, the page does too much painting after the action.

Google recommends good Core Web Vitals, but its documentation does not give them a specific ranking weight: it describes them as part of a page experience that aligns with what its core ranking systems seek to reward. Treat them as a quality requirement for the people who visit your site, not as a magic lever for climbing positions. Useful, relevant content still matters more than a millisecond.

Our recommendation for a company website, in this order:

• Check Search Console and PageSpeed Insights and note which metric fails on mobile.
• Pick the pages that generate the most visits or enquiries (home, services, booking or contact) and start there.
• Fix what fails first: LCP if it loads slowly, CLS if content jumps, INP if it feels sluggish.
• Change one thing at a time and measure again, so you know what worked.
• Watch every time you add a plugin, a chat widget or a tag: that is when metrics tend to get worse.

If nobody on your side can read a performance report, start by asking for a diagnosis that sets priorities. Our technical SEO service reviews which metric fails and on which pages, and web development applies the fixes in code.

When the technical improvement is tied to more enquiries or bookings, look at it alongside conversion optimisation. And if your site also relies on measurement scripts, read Consent Mode v2 first, because tags and cookie banner are part of what your page loads. If you would like us to look at your case, get in touch.