Core Web Vitals 2026: Every Google Change This Year and What You Need to Do About It
Core Web Vitals 2026: Every Google Change This Year and What You Need to Do About It
If you run a website — whether it’s a personal blog, a SaaS product, or a client’s e-commerce store — you’ve probably noticed that Core Web Vitals conversations have gotten more complicated. What started in 2021 as three metrics (LCP, FID, CLS) is now a more nuanced framework, and the changes Google rolled out in 2025 and early 2026 have shifted which sites are winning and which are losing ground in search.
This post covers what actually changed, why it matters, and what you should be doing about it if you haven’t already.
A quick orientation for anyone who needs it
Core Web Vitals are Google’s set of user experience metrics that factor into search rankings. The concept is simple: pages that load fast, respond quickly, and don’t move content around unexpectedly rank better than pages that don’t. The specific metrics have evolved since launch.
The current active set as of 2026 includes:
Largest Contentful Paint (LCP): how long it takes for the largest visible element on the page to load. For most pages this is a hero image or a large text block. Google’s threshold for a “good” score is under 2.5 seconds.
Interaction to Next Paint (INP): this replaced First Input Delay (FID) in March 2024 and is now fully incorporated into ranking signals. INP measures the delay between a user interaction (click, tap, keyboard input) and the next visual change on the page. Good is under 200ms; needs improvement is 200-500ms; poor is above 500ms.
Cumulative Layout Shift (CLS): how much the page’s layout shifts unexpectedly during loading. A button that moves just as someone’s about to click it, an image that pushes text down, an ad that loads late and shoves content — these all generate CLS. Good is under 0.1.
Now here’s what changed.
INP: the metric that surprised everyone
Interaction to Next Paint replaced First Input Delay in March 2024, but the full weight of that change in search rankings wasn’t felt until late 2025. A lot of sites that thought they were fine discovered they weren’t when their search positions started sliding.
The difference between FID and INP is significant. FID measured the delay on the very first interaction a user had with the page. INP measures every interaction throughout the entire page session and reports the worst one (with some percentile smoothing to ignore genuine outliers). This is a much stricter standard.
The practical implication: a page that loads fast and responds quickly to the first click can still fail INP if there’s a heavy interaction later in the session — a search filter that takes 800ms to respond, a cart update that freezes the UI for half a second, a modal that’s slow to open. FID would never have caught these. INP does.
The sites that got hit hardest by INP had three things in common: heavy JavaScript frameworks with unoptimized event handlers, third-party scripts running on the main thread, and interaction patterns that worked fine on desktop but performed poorly on mid-range mobile devices.
If you haven’t audited your INP scores on mobile specifically, do that before anything else. Google’s CrUX (Chrome User Experience Report) data shows mobile INP scores are significantly worse than desktop for the majority of sites, and mobile is how most of your users are arriving.
What changed in 2025 and early 2026
Google’s Core Web Vitals updates in this period focused on four areas.
INP weighting increased. Google confirmed in late 2025 that INP’s contribution to the Page Experience signal increased relative to LCP and CLS. For sites that had invested heavily in LCP optimization but neglected interaction performance, this rebalancing was painful.
LCP expanded to cover text rendering. In 2026, Google updated how LCP is measured for text-heavy pages. Previously, LCP often captured a hero image as the largest element even when the primary content was textual. The update better handles cases where the largest text block is the meaningful content element, meaning blogs and editorial sites now have LCP scores that more accurately reflect their actual user experience.
CLS measurement extended to the full session. CLS previously measured layout shift only during the page load period. The extended measurement window, which became a ranking signal in Q1 2026, captures layout shifts that occur later in the session — infinite scroll implementations that push existing content, dynamic widgets that load after initial render, and cookie banners that appear after a delay. If you’ve invested in CLS optimization for load time but have late-loading dynamic content, check your scores in Search Console under the new session-window data.
INP granularity in Search Console improved. Google added breakdown data in Search Console showing which specific interactions are driving high INP scores. This is genuinely useful — rather than knowing that a page has a poor INP score and having to audit every interaction manually, you can see that it’s specifically the “add to cart” button or the filter dropdown that’s causing the problem. If you’re not using this, open Search Console, go to Core Web Vitals, and look at the URL groups with poor scores.
What’s actually causing most failures
Having reviewed scores and audited fixes across dozens of sites, the issues cluster predictably.
Main thread blocking JavaScript
This is the most common cause of poor INP scores. When JavaScript runs on the browser’s main thread and takes a long time to execute, any user interaction that happens during that execution has to wait. The user clicks, nothing happens for 600ms, then the page responds. That’s an INP failure.
The fix is typically a combination of code splitting (so JavaScript for features below the fold doesn’t block initial interaction), deferring non-critical scripts, and moving heavy computations off the main thread using Web Workers where possible.
Third-party scripts are a major contributor here. Analytics platforms, chat widgets, ad scripts, social media embeds — these run on your page and use the main thread. A single poorly optimized third-party script can single-handedly push your INP into the “needs improvement” range. Audit your third-party scripts with a brutal eye and remove anything that can’t justify its performance cost.
Large, unoptimized images causing LCP failures
LCP failures on image-heavy pages in 2026 still mostly trace back to the same issues: images that aren’t in next-gen formats (WebP, AVIF), images without explicit width and height attributes (causing layout reflow), hero images that aren’t prioritized with fetchpriority="high", and images that are served at a larger size than they’re displayed at.
The fetchpriority attribute is underused and meaningfully impactful. Adding fetchpriority="high" to your LCP image — the hero image that you know is going to be the largest paint — tells the browser to prioritize that resource. Google’s own studies have shown this single change reduces LCP by 5-10% on pages where it’s correctly applied.
Fonts causing both LCP and CLS issues
Web fonts are a reliability hazard for Core Web Vitals. They contribute to LCP by delaying text render, and they cause CLS when they load after the page has already painted with fallback fonts (font swap causing layout shift).
The best practice combination: use font-display: optional for non-critical fonts (prevents layout shift by not swapping), preload your primary font file with <link rel="preload">, and self-host fonts rather than loading from Google Fonts or Adobe Fonts (removing a network round-trip). If you’re using a web font for your primary body text, consider whether the brand benefit outweighs the performance cost — system font stacks have improved considerably and the visual difference is often smaller than designers expect.
Slow server response times inflating all metrics
All Core Web Vitals are affected by Time to First Byte (TTFB) — the time it takes for the server to respond with the first byte of HTML. A slow server makes everything downstream slower: the browser can’t start parsing, fetching resources, or rendering anything until that first byte arrives.
TTFB issues come from slow hosting, uncached dynamic content, database queries running on every request, and geographic distance between server and user. For a site serving Pakistani or South Asian audiences from a US-based server, the round-trip latency alone can add 150-300ms to TTFB.
The solutions are straightforward but sometimes involve tradeoffs: use a CDN (Cloudflare is the standard choice, and the free tier covers most use cases), implement server-side caching for dynamic pages, and consider whether your server region is appropriate for your primary audience.
The Shopify and WordPress situations specifically
Two platforms generate more Core Web Vitals questions than any others.
WordPress: WordPress sites have a wide performance range depending on theme and plugin choices. The single most impactful change for most WordPress sites is switching to a lightweight theme (GeneratePress, Kadence, or a custom theme) and auditing the plugin stack ruthlessly. Plugins that add scripts to every page regardless of whether they’re needed on that page (contact form plugins, slider plugins, social sharing plugins) are common culprits. WP Rocket or similar caching plugins, combined with a CDN, get most WordPress sites into the “needs improvement” range. Getting to “good” across all three metrics typically requires more targeted optimization.
Shopify: Shopify’s platform handles some performance basics well but has real constraints around script loading. Shopify stores with more than three or four active apps often have INP problems because each app loads its own scripts. The App Blocks architecture introduced in 2023 helped, but a significant portion of older apps haven’t migrated. Auditing which apps are loading scripts on which pages and removing or replacing apps that have poor script performance is often the most impactful intervention available to Shopify store owners.
How to audit your site right now
If you want to know where you stand before doing anything else, here’s the fastest path to useful data.
Google Search Console is your primary data source. Go to Experience > Core Web Vitals and look at the URL groupings with “Poor” status. This is real user data from Chrome users, not lab data — it reflects actual performance on actual devices and connections.
PageSpeed Insights (pagespeed.web.dev) gives you both lab data and field data for individual URLs. Use it to diagnose specific pages rather than the site as a whole.
Chrome DevTools’ Performance panel is for diagnosing the root causes once you’ve identified which metrics are failing. Look for long tasks (marked in red) on the main thread — those are your primary INP candidates.
WebPageTest.org gives you more detailed network-level analysis and lets you test from different geographic locations and device types. If you’re serving a South Asian audience, test from a Mumbai or Singapore node on a simulated mid-range mobile device.
Prioritizing your fixes
Not everything has the same impact. In most audits we run, the highest-return fixes are:
Removing or deferring third-party scripts that aren’t essential — typically generates the biggest INP improvement for the least development work.
Adding fetchpriority="high" to the LCP image — quick win, meaningful LCP improvement.
Implementing CDN and server-side caching — improves TTFB, which improves everything.
Auditing the JavaScript bundle for code that can be split or deferred — more development work but often necessary for sites built on heavy frameworks.
Converting images to WebP/AVIF and adding explicit dimensions — routine work that most developers can handle quickly.
At KodersKube, speed optimization is one of the services where we see the clearest before-and-after data. A client’s e-commerce site we worked on last year had an LCP of 6.2 seconds and an INP in the poor range. After targeted interventions — primarily image optimization, third-party script audit, and server-side caching — LCP came down to 1.9 seconds and INP moved into the good range. Organic traffic from that site increased by 23% over the following two months.
Performance work has a direct revenue impact. The data on this is consistent across studies: faster pages convert better, rank better, and retain users more effectively. Core Web Vitals are Google’s formalization of something that was already true.
