# Core Web Vitals in 2026: What to Fix First | Nadya > Core Web Vitals in 2026: the LCP, INP and CLS thresholds, why LCP fails most often on mobile, and the fixes to make first, based on web.dev and Google guidance. Canonical: https://nadiaconstructionstudio.com/blog/core-web-vitals-2026 [Home](https://nadiaconstructionstudio.com/) / [Blog](https://nadiaconstructionstudio.com/blog) # Core Web Vitals in 2026: What to Fix First By Nam Bok Rodriguez · October 16, 2026 · 5 min read Fix whichever Core Web Vital fails for real users on mobile, and on most sites that is Largest Contentful Paint. The targets are LCP within 2.5 seconds, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile of real visits. Start from field data, find the failing metric and page type, and fix the cause rather than chasing a lab score. ## What are the Core Web Vitals in 2026? According to [web.dev](https://web.dev/articles/vitals), there are three metrics, each with a "good" threshold: - **Largest Contentful Paint (LCP)** measures loading. Good is within 2.5 seconds of the page starting to load. - **Interaction to Next Paint (INP)** measures responsiveness. Good is 200 milliseconds or less. - **Cumulative Layout Shift (CLS)** measures visual stability. Good is 0.1 or less. A page passes when it meets all three at the 75th percentile of page loads, split by mobile and desktop. INP replaced First Input Delay and became a stable Core Web Vital in 2024, so any advice still centered on FID is out of date. ## Do Core Web Vitals affect Google rankings? Google's [Search Central documentation](https://developers.google.com/search/docs/appearance/core-web-vitals) says it highly recommends that site owners achieve good Core Web Vitals for success with Search, and that page experience aligns with what its core ranking systems seek to reward. It does not say good scores guarantee rankings. We treat Core Web Vitals as a requirement for a good experience and a supporting signal for search, not a shortcut past relevant content. ## Which metric fails most often? The [2025 Web Almanac](https://almanac.httparchive.org/en/2025/performance) from HTTP Archive reports that 48% of mobile origins and 56% of desktop origins had good Core Web Vitals. On mobile, 62% had good LCP, 77% had good INP and 81% had good CLS. LCP is the metric holding most sites back, which is why it usually comes first. Your site may differ, so check your own numbers before deciding. ## Where should you get your numbers? Use field data first. web.dev notes that the Chrome User Experience Report feeds PageSpeed Insights and the Core Web Vitals report in Search Console. Those show what real visitors experience. Lab tools such as Lighthouse and Chrome DevTools are for diagnosing why. One catch: Lighthouse cannot measure INP, because there is no real user interacting, so it uses Total Blocking Time as a proxy. A perfect Lighthouse score can sit next to a failing INP in the field. For your own monitoring, the web-vitals JavaScript library reports the metrics from real sessions. ## How do you fix a slow LCP? web.dev's [LCP guide](https://web.dev/articles/optimize-lcp) breaks the metric into four parts and suggests rough shares of the total time: - **Time to first byte:** about 40%. - **Resource load delay:** under 10%. - **Resource load duration:** about 40%. - **Element render delay:** under 10%. Measure which part is oversized, then fix that one. The most common fixes, from web.dev's [top recommendations](https://web.dev/articles/top-cwv): - **Make the LCP image discoverable.** Its URL should be in the initial HTML, not injected by JavaScript or hidden in a CSS background. - **Prioritize it.** Add fetchpriority="high" to the likely LCP image. The guide warns that marking more than one or two images as high priority makes the hint useless. - **Never lazy load the LCP image.** web.dev says it will always cause unnecessary load delay. - **Cut server time.** A CDN is the guide's main recommendation for reducing time to first byte. Caching HTML at the edge helps further. - **Aim for instant navigations.** The back and forward cache and speculative prerendering can make repeat navigations feel immediate. - **Right size images.** Serve modern formats at the dimensions actually displayed. ## How do you fix a slow INP? INP is about what happens after a tap or click. web.dev's [INP guide](https://web.dev/articles/optimize-inp) splits each interaction into input delay, processing duration and presentation delay. Fixes target each: - **Break up long tasks.** Yield to the main thread often so the browser can respond to input. The guide notes that yielding indiscriminately is better than not yielding at all. - **Ship less JavaScript.** Split code that is not needed for the first render into separate bundles, and audit third party scripts, which often run on every interaction. - **Avoid layout thrashing.** Do not write styles and then read layout values in the same task. - **Keep the DOM small.** web.dev notes that DOM size and the intensity of layout work are correlated. - **Show feedback first.** Update the screen to acknowledge the interaction, then do the heavy work. ## How do you fix layout shift? CLS is usually the easiest of the three: - **Set width and height on images and video** so the browser reserves space. - **Reserve space for late content** such as ads, embeds and banners, with a sensible minimum height. - **Keep pages eligible for the back and forward cache** unless they show sensitive data. - **Animate with transform, not layout properties.** web.dev advises never animating properties like top, left or margin that force layout. - **Load web fonts carefully** so text does not jump when the font arrives. ## What order should you work in? Our usual order: fix the failing metric on the templates with the most traffic, starting with mobile. Templates matter more than single pages, because one fix to a product or article template repairs thousands of URLs. Then confirm the change in field data, which takes time, since CrUX reports a rolling window of real visits. ## A Core Web Vitals checklist - Check Search Console and PageSpeed Insights field data for mobile and desktop. - Identify the failing metric and the page templates affected. - For LCP, measure the four subparts and fix the largest. - Put the LCP image URL in the HTML, add fetchpriority="high", and remove lazy loading from it. - Serve HTML and assets from a CDN. - For INP, find long tasks in DevTools, yield more often and remove unneeded JavaScript. - Audit third party scripts and drop the ones you do not need. - For CLS, set image dimensions and reserve space for dynamic content. - Make pages eligible for the back and forward cache. - Add real user monitoring with the web-vitals library. - Recheck field data after the rolling window updates. If your site is failing Core Web Vitals and you want it fixed properly, at the template level, we can help. [Start a project](https://nadiaconstructionstudio.com/#start) and send us the URL. ## Sources - [web.dev: Web Vitals](https://web.dev/articles/vitals) - [Google Search Central: Understanding Core Web Vitals and Google search results](https://developers.google.com/search/docs/appearance/core-web-vitals) - [HTTP Archive: Web Almanac 2025, Performance](https://almanac.httparchive.org/en/2025/performance) - [web.dev: Optimize Largest Contentful Paint](https://web.dev/articles/optimize-lcp) - [web.dev: Top Core Web Vitals recommendations](https://web.dev/articles/top-cwv) - [web.dev: Optimize Interaction to Next Paint](https://web.dev/articles/optimize-inp) Start a project ## Tell us what you want *built.* A few lines is enough. The person who reads it is the person who builds it. - A reply within one business day - A written scope with price and date before any work - Code, infrastructure and accounts in your name Prefer email? [nam@nadiaconstructionstudio.com](mailto:nam@nadiaconstructionstudio.com)