Core Web Vitals 2026: LCP, INP and CLS in Practice – A Performance Guide for Websites and Online Shops

When we at HELITS take over an existing website or online shop, the first measurement almost always lands in the same category: solidly built, but slow over time. Over the years a plugin gets added, then a second tracking tool, a chat widget, larger product images, a new font family. Each addition is harmless on its own. Together they produce a site that feels noticeably sluggish on a customer's phone – and Google has been measuring exactly that for years in the form of the Core Web Vitals.

For 2026, little has changed about the target values, but a great deal has changed about the most important lever. Since March 2024, INP (Interaction to Next Paint) has replaced the old FID metric. Anyone still building their performance strategy around FID is optimising the wrong thing. This article sums up what matters now and offers an order of work that lets even an SME without a dedicated performance team get measurably faster.

The three target values in plain language

Google gives clear orientation values for the Core Web Vitals. A page counts as good when 75 per cent of page loads meet these thresholds – measured against real users in the field, not in the lab:

• LCP (Largest Contentful Paint): under 2.5 seconds. When is the largest visible element – usually the hero image or product shot – finished loading? That is the perceived moment when the page is "there".
• INP (Interaction to Next Paint): under 200 milliseconds. How quickly does the page respond visibly to an input – click, tap, keystroke? INP looks at all interactions in a session, not just the first.
• CLS (Cumulative Layout Shift): under 0.1. How much does the layout jump while the page loads? Anyone who has accidentally tapped an ad because a button slipped down at the wrong moment knows a poor CLS score from the user's side.

The key distinction is between field data (real users, visible in Google Search Console and the Chrome User Experience Report) and lab data (Lighthouse, PageSpeed Insights). We regularly see pages that glow green in the lab and fail in the field – because the test device is faster than the average customer's phone and because the lab measures no real interactions. Optimising for Lighthouse alone means optimising an ideal that has little to do with reality.

INP: why this metric is the most work

FID only measured the delay of the first interaction – and only up to the point where processing began. In practice it was a flattering number. INP goes further: it considers responsiveness across the whole session and measures up to the next rendered frame, that is, until the user actually sees the result of their action.

This brings INP very close to what people perceive as "laggy". And that is precisely why most sites struggle with it today. The cause almost always lies with the main thread – the single strand in which the browser runs JavaScript. If it is blocked by heavy scripts, third-party code or expensive rendering, it simply cannot react to the user's click.

In our experience the most effective levers for INP are:

• Break up long JavaScript tasks. Tasks over 50 milliseconds block interaction. Split them, defer them, lighten the load.
• Tame third-party scripts. Tracking, consent tool, chat, A/B testing tool: each runs on the same main thread. Anything not strictly needed early is loaded later.
• Avoid unnecessary rendering. Large, non-virtualised product lists with thousands of DOM elements are a classic INP killer in e-commerce.

The most common performance killers

Across many audits the same causes recur. Checking these six points already covers most problems:

• Oversized images without modern formats (WebP, AVIF) and without sizes suited to mobile devices. The most common LCP culprit.
• Uncontrolled third-party scripts – tracking, widgets and chat tools that nobody ever cleans up.
• Render-blocking CSS and JavaScript that slows the page build before anything becomes visible at all.
• Too many fonts and font weights that load late and shift the layout when they appear.
• Unoptimised product lists with too many DOM nodes, slowing rendering and interaction.
• Layout shifts from late-loading elements – banners, images without reserved space, cookie notices that pop in. The classic CLS trigger.

Checklist for online shops in 2026

For shops, performance is not a matter of taste but directly tied to revenue: every extra second of load time and every layout shift in the checkout costs conversions. We work through optimisations in this order – on the principle of greatest effect for least risk:

1. Images first. Hero and product images in modern formats, correctly sized, with lazy loading for everything below the fold. Usually the fastest jump in LCP.
2. Clean up tracking. Inventory every script, remove anything no one evaluates any more, defer the rest.
3. Sort critical CSS and script loading. What is needed for the first visible impression comes first; the rest follows non-blocking.
4. Paginate or virtualise product lists so that hundreds of items are not all sitting in the DOM at once.
5. Keep the checkout stable. Reserved space for all elements, no banners jumping in late – CLS in the checkout is especially costly.
6. Establish monitoring. Search Console for field data plus real-user monitoring that raises the alarm after every release.

In practice, the combination of image optimisation and third-party cleanup alone delivers most of the improvement for many shops – with manageable effort and without touching the business logic.

Performance is not a project, it is a state

The most common mistake is to optimise performance once and then tick it off. But every new release, every additional marketing tool, every campaign with a large promotional banner can tip the values again. A page that is green today can be red after the next plugin update without anyone noticing – until rankings or the conversion rate slip.

That is why every optimisation needs a discipline: check Web Vitals after every release, approve tracking changes deliberately, question new tools before installing them. In our web development projects we therefore rely on a clean technical foundation – lean assets, controlled script loading and monitoring that surfaces regressions early. Where performance touches larger structural questions, such as overgrown tool landscapes or outdated hosting setups, this flows seamlessly into our IT consulting and, for server-side matters, into our network and infrastructure support.

For SMEs and retailers in the Berchtesgaden and Traunstein region who want to know where their site currently stands, the entry point is simple: a measurement of real field data, a list of the biggest bottlenecks and a prioritised action plan including quick wins. That is exactly the point where an abstract metric turns into a concrete competitive advantage.

In short

• 2026 target values: LCP under 2.5 s, INP under 200 ms, CLS under 0.1 – measured against real users, not in the lab.
• INP is the new benchmark and has replaced FID since March 2024. The biggest lever: relieve the main thread.
• Images and third-party scripts are the most rewarding first steps in most cases.
• Monitoring and release discipline decide whether good scores stay good.

---