View All
seo

Core Web Vitals in 2026: Fixing INP, LCP and CLS

Suliman Hakimi5 min read

Core Web Vitals are Google's three user-experience metrics, and in 2026 INP (Interaction to Next Paint) is the one most sites struggle with: it measures how quickly a page responds when someone taps or clicks. To pass, a page needs an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less, measured at the 75th percentile of real visits.

Key Takeaways

  • INP replaced First Input Delay as a Core Web Vital in March 2024 and is stricter, because it looks at interactions throughout the visit, not only the first.
  • Most INP problems come from too much JavaScript running on the main thread: heavy frameworks, third-party scripts and large event handlers.
  • LCP is usually fixed by serving a smaller, prioritised hero image and a faster server response.
  • CLS is fixed by reserving space for images, ads, embeds and web fonts.
  • Judge your site by field data from real users, not only by a lab score.

What Are the Core Web Vitals Thresholds in 2026?

The three metrics and their "good" thresholds are:

  • LCP (Largest Contentful Paint): the main content appears within 2.5 seconds.
  • INP (Interaction to Next Paint): the page visibly responds to taps, clicks and key presses within 200 milliseconds.
  • CLS (Cumulative Layout Shift): the layout shift score stays at 0.1 or below, so buttons do not jump under people's fingers.

A URL passes when at least 75 percent of real page loads meet each threshold. Google collects this data through the Chrome User Experience Report (CrUX), and you see it in Search Console's Core Web Vitals report and in PageSpeed Insights. Core Web Vitals are part of Google's page experience signals; they rarely outweigh relevance, but between two similar pages the faster one has an edge, and the conversion benefits of a fast site are real regardless of rankings.

Why Is INP Harder to Pass Than FID Was?

INP measures the full delay of interactions throughout the visit, while FID only measured the input delay of the first one. A page could pass FID simply because nothing was busy when the user first tapped, then freeze for half a second when they opened a menu or added an item to the cart. INP catches that.

An interaction has three parts: input delay (waiting for the main thread to be free), processing time (your event handlers running), and presentation delay (the browser calculating layout and painting the new frame). INP reports roughly the slowest interaction on the page, so a single sluggish filter or accordion can fail the whole URL.

How Do You Fix a Poor INP Score?

Reduce the work the main thread must do around each interaction, and give it chances to breathe. In rough order of impact for most business sites:

  1. Audit third-party scripts. Chat widgets, tag managers, heatmaps and social embeds often add the most main-thread work. Remove what you do not use and load the rest after interaction or when the browser is idle.
  2. Ship less JavaScript. Frameworks like Next.js with React Server Components let you render most of a page on the server and send JavaScript only for the parts that are truly interactive.
  3. Break up long tasks. Split heavy event handlers so the browser can paint between chunks; yielding to the main thread (for example with scheduler.yield where supported, or a setTimeout fallback) lets the visual response appear first.
  4. Update the UI before doing the expensive work. Show the menu opening or the button state change immediately, then run analytics calls and data processing afterwards.
  5. Avoid large DOM updates. Re-rendering a 2,000-row table on every keystroke will fail INP; virtualise long lists and debounce search inputs.
  6. Watch CSS and layout cost. Very large pages with complex selectors make the presentation phase slow.

Use the Performance panel in Chrome DevTools with CPU throttling enabled to reproduce the problem. Many visitors in Afghanistan use mid-range Android phones, which are much slower than a developer's laptop.

How Do You Improve LCP on Slow Connections?

Make the largest element, usually a hero image or headline, arrive and render as early as possible. Serve images in AVIF or WebP at the size actually displayed, mark the hero image with fetchpriority="high", and never lazy-load it. Use a CDN so files come from a location near the visitor; a server in Europe or the Gulf is typically closer to users in Kabul than one in the United States. Cache HTML where you can, and preload the one web font your headline uses.

On expensive mobile data, page weight matters as much as speed. We cover this in detail in our article on website speed for slow internet in Afghanistan.

How Do You Stop Layout Shifts (CLS)?

Reserve space for everything that loads late. Set width and height (or aspect-ratio) on images and video, give ad slots and embeds a fixed minimum height, and avoid inserting banners above existing content after the page has rendered. Web fonts cause shifts when the fallback font has different metrics; use font-display: swap together with size-adjusted fallbacks, or preload the font. Persian and Pashto fonts are a frequent source of CLS on Afghan sites because they are large and their metrics differ a lot from system fonts.

How Should You Measure and Monitor Core Web Vitals?

Start with field data, then use lab tools to debug. Check Search Console's Core Web Vitals report, which groups similar URLs, and PageSpeed Insights for individual pages. If your site has too little traffic to appear in CrUX, add real-user monitoring with the open-source web-vitals library and send the results to GA4 or your own analytics.

Treat performance as a budget: set limits on JavaScript size and third-party tags, and re-check after every release. Core Web Vitals are one section of our technical SEO audit checklist, and if you are choosing a stack, our guide to Next.js 16 for business websites explains why server rendering helps INP.

Work With Sheen

Sheen builds fast Next.js websites and fixes Core Web Vitals on existing sites as part of our SEO services and web design work. Book a call, or email info@sheen.af or phone +93 784 966 018.


Frequently Asked Questions

What is a good INP score?

An INP of 200 milliseconds or less is rated good. Between 200 and 500 milliseconds needs improvement, and anything above 500 milliseconds is poor. Google evaluates the 75th percentile of real visits, so a page passes only when at least three out of four page loads respond within 200 milliseconds, measured separately for mobile and desktop users.

Do Core Web Vitals directly affect Google rankings?

They are a confirmed but modest ranking signal within Google's page experience systems. Relevant, helpful content still matters far more, so a fast page with weak content will not outrank a slower page that answers the query better. Their bigger impact is on users: faster, more responsive pages tend to keep visitors longer and turn more of them into enquiries and sales.

Why does PageSpeed Insights show a different score from Search Console?

PageSpeed Insights shows two things: field data from real Chrome users over the previous 28 days, and a lab test (Lighthouse) run once on a simulated device. Search Console only uses field data, grouped across similar URLs. The lab score is useful for debugging, but the field data is what counts for Core Web Vitals, and it changes slowly as new visits replace old ones.

Does hosting location affect Core Web Vitals for visitors in Afghanistan?

Yes, mainly through LCP. Every request has to travel to the server and back, so a distant server adds delay before anything appears. Using a CDN with locations in Europe, the Gulf or South Asia, caching pages at the edge, and keeping pages light usually helps visitors in Kabul, Herat and other cities far more than upgrading to a bigger server.


Keep reading

Read More