laptop computer on glass-top table showing web vitals

Core Web Vitals: The 2026 Threshold Change Nobody Noticed

Core Web Vitals got noticeably stricter in March 2026 — Google lowered the “good” LCP threshold from 2.5 seconds to 2.0 — and sites that didn’t notice the change saw average ranking drops of 2 to 4 positions, even though nothing about their own site had changed.

Most Sites Are Quietly Failing

Sites passing all three Core Web Vitals

Only 42% of mobile sites and 63% of desktop sites pass all three Core Web Vitals thresholds as of 2026.

Mobile is where most sites lose the fight, and mobile is also where the ranking penalty bites hardest — sites with good scores across the board saw average improvements of 5.2 positions for competitive keywords, with the mobile gains outpacing desktop. If your mobile LCP has never been checked against the new 2.0-second bar specifically, it’s worth five minutes to look.

Diagnose It: Which Vital Is Probably Your Problem?

Likely LCP (Largest Contentful Paint). Usually a large hero image, unoptimized font loading, or a slow server response. Check whether your main image is compressed and served in a modern format like WebP.

Likely CLS (Cumulative Layout Shift). Usually images or ads without reserved dimensions, or web fonts swapping in after layout. Set explicit width/height on all images and embeds — this is one of several ways design decisions quietly affect SEO.

Likely INP (Interaction to Next Paint). Usually heavy JavaScript blocking the main thread. Third-party scripts — chat widgets, ad tags, analytics — are the most common culprit.

Interactive diagnostic: a slow-feeling page points to LCP problems, content jumping around points to CLS problems, and delayed taps or clicks point to INP problems.

The Three Metrics and Their Thresholds

MetricGoodNeeds improvementPoor
LCP (Largest Contentful Paint)≤ 2.0s (as of March 2026)2.0s – 4.0s> 4.0s
INP (Interaction to Next Paint)≤ 200ms200ms – 500ms> 500ms
CLS (Cumulative Layout Shift)≤ 0.10.1 – 0.25> 0.25

Google scores a page based on the 75th percentile of real-user visits over a rolling 28-day window, not a single lab test — which means the number you see in PageSpeed Insights for one visit and the number in Search Console’s field data for the same page can genuinely differ, and it’s the field data that reflects what actually affects your ranking.

This Isn’t Just an SEO Metric

Every 100 milliseconds of load time costs roughly 1% in conversions. That sounds abstract until you put a number on it: for a site doing 10 million francs a year in revenue, a 500-millisecond improvement can recover around 500,000 francs annually. Rakuten 24 saw a 53% increase in revenue per visitor after fixing LCP. Ray-Ban’s mobile product page conversions more than doubled. These aren’t SEO vanity metrics — they’re revenue numbers, and Core Web Vitals happens to be the thing that moves both at once.

The Most Common Fixes, by Platform

The specific fix depends heavily on what the site is built on, and generic advice (“optimize your images”) often skips the platform-specific detail that actually matters. On WordPress, the single biggest lever we see is plugin bloat — every additional plugin that injects its own CSS or JavaScript on every page load adds render-blocking weight, and a site running 25+ plugins almost always has room to consolidate. A caching plugin plus a modern image format plugin (serving WebP or AVIF automatically) typically recovers more LCP time than any other single change. On Shopify, third-party apps play the same role plugins do on WordPress — review the app list and remove anything not actively used, since abandoned apps still load their scripts. On custom-built or headless sites, the usual culprit is unoptimized font loading: web fonts that block text rendering until fully downloaded should be swapped for a font-display: swap strategy or self-hosted with preload hints.

Mobile-First Isn’t Optional Anymore

Google has used mobile-first indexing exclusively for years now, which means the mobile version of a page — not the desktop version — is what actually gets crawled, evaluated, and scored for Core Web Vitals in the vast majority of cases. A site that looks fast on a developer’s desktop monitor over office wifi can still fail badly on a mid-range Android phone over a 4G connection in a train tunnel between Zürich and Bern, and that second scenario is closer to how most real visitors actually experience the page. Testing exclusively on desktop, or on a fast wifi connection, systematically hides the problems that are actually costing rankings. Throttled testing — simulating a slower connection and a mid-tier device — surfaces issues that a fast development environment never will.

A Realistic Remediation Timeline

Fixing Core Web Vitals issues isn’t usually a single afternoon of work, and it isn’t a multi-month project either — for most small-to-midsize sites it falls somewhere in between. Image optimization and lazy-loading configuration is typically the fastest win, often achievable within a day and producing a measurable LCP improvement within the next crawl cycle. Third-party script auditing (removing or deferring chat widgets, unused analytics tags, and old marketing pixels) usually takes a few days of testing to make sure nothing breaks, but produces the biggest INP gains of any single fix. Layout shift fixes — reserving space for images, ads, and dynamically injected banners — require touching template code directly and are the slowest to roll out safely, but they’re also usually the smallest of the three metrics to move since CLS issues tend to be concentrated in a handful of repeat-offender components rather than spread across the whole site. Google’s field data updates on a rolling 28-day basis, so the ranking impact of a fix doesn’t show up immediately — expect a one-month lag between shipping a fix and seeing it reflected in Search Console.

Where This Fits Into a Broader Audit

Core Web Vitals is one piece of a wider technical health check — crawlability, indexation, and structured data all matter alongside speed. Our technical SEO service audits all of it together, since fixing speed in isolation while ignoring crawl errors leaves real ranking gains on the table.

Why Some Teams Fix It and See No Ranking Change

Core Web Vitals is a legitimate ranking factor, but it’s a comparatively small one relative to content relevance and topical authority — Google has said as much directly. A page with thin, generic content and a perfect Core Web Vitals score will not outrank a page with genuinely better, more thorough content and a mediocre score. Where speed matters most is as a tiebreaker between pages of otherwise similar content quality, and as a floor below which a page gets actively penalized rather than merely neutral. Teams that fix their Core Web Vitals numbers and see no ranking movement are usually in one of two situations: either their content was never the limiting factor to begin with, meaning speed wasn’t holding them back at all, or their content still isn’t competitive against what’s actually ranking, meaning speed fixes removed a penalty without adding a genuine advantage. Treating Core Web Vitals as a magic lever independent of content quality is the single most common reason technical fixes disappoint teams expecting a dramatic ranking jump.

A Worked Example: What 500 Milliseconds Actually Bought One Client

A Swiss e-commerce client came to us with an LCP hovering around 3.4 seconds on mobile — solidly in “needs improvement” territory under the new threshold. The diagnosis took under an hour: a 2.8MB unoptimized hero banner image loading before any of the page’s actual content, plus three marketing pixels loaded synchronously in the document head, each blocking render while it fetched. We compressed and converted the hero image to WebP (bringing it under 200KB with no visible quality loss), deferred the marketing pixels to load after the main content painted, and added explicit dimensions to every image on the template to eliminate the layout shift that was happening as images popped in at different sizes. Mobile LCP dropped from 3.4 seconds to 1.9 seconds within the next crawl cycle — comfortably inside the “good” threshold. Over the following two months, organic mobile sessions to product pages rose 18%, and mobile conversion rate on those same pages rose separately by 6%, consistent with the pattern in the Rakuten and Ray-Ban cases above: the ranking gain and the conversion gain arrived as two separate, additive effects from the same underlying fix, not one masquerading as the other.

Tools for Checking Your Own Numbers

Google Search Console’s Core Web Vitals report is the most important one to check first, because it reflects real-user field data aggregated across your actual visitor base rather than a single simulated test — this is the data source Google actually uses for ranking purposes. PageSpeed Insights layers a lab test on top of that field data and, critically, breaks down exactly which resources are contributing to slow LCP, high INP, or layout shift, making it the right tool once you already know something’s wrong and need to find the specific cause. Chrome’s own DevTools Performance panel goes a level deeper still, useful once a developer is actively debugging a specific interaction lag rather than doing an initial diagnosis. For ongoing monitoring rather than one-off checks, a synthetic monitoring tool that tests from a fixed location on a fixed schedule catches regressions introduced by a new plugin, a marketing team’s new tracking pixel, or a redesign — before those regressions show up as a ranking drop weeks later.

Why This Keeps Getting Stricter

The March 2026 LCP threshold tightening from 2.5 to 2.0 seconds wasn’t an isolated event — it’s part of a multi-year pattern of Google raising the performance bar as average device and connection speeds improve globally. INP itself only replaced the older First Input Delay metric in 2024 specifically because FID was judged too lenient, measuring only the delay before a browser began processing an interaction rather than the full time until the next visual update. Each tightening catches a wave of sites that were comfortably passing under the old threshold and pushes them into “needs improvement” without any change on their end — which is exactly the mechanism that produced the ranking drops many businesses noticed in early 2026 without understanding why. The practical implication is that passing the current thresholds isn’t a one-time project to check off; a site sitting right at the edge of “good” today is a strong candidate to fail the next tightening, whenever it lands. Building in a genuine margin — targeting an LCP closer to 1.5 seconds rather than exactly 2.0 — is cheap insurance against a threshold change nobody can predict the exact timing of.

Testing on a Realistic Swiss Mobile Network

Switzerland’s mobile network infrastructure is genuinely strong by international standards, which creates a specific testing blind spot worth naming directly: a developer testing on a good Swisscom or Sunrise connection in Zürich or Geneva may see numbers that look comfortably passing, while a meaningful share of that same site’s actual visitors are on slower connections, older devices, or roaming internationally with degraded coverage. Throttled testing that simulates a genuinely constrained connection — not just a slightly-slower-than-ideal one — surfaces the real-world experience of that slower-connection segment of visitors, which is precisely the segment most likely to bounce from a slow-loading page before it finishes rendering at all. A business assuming Switzerland’s strong infrastructure means Core Web Vitals concerns are somewhat less urgent locally than elsewhere is making an assumption worth actually testing rather than accepting at face value.

Related Guides

Frequently Asked Questions

What changed with Core Web Vitals in 2026?

Google lowered the “good” LCP threshold from 2.5 seconds to 2.0 seconds in the March 2026 core update — a stricter bar that caught many previously-passing sites off guard.

Does page speed actually affect conversions, or just rankings?

Both. Every 100ms of load time costs roughly 1% in conversions on top of any ranking impact — the two effects compound rather than being separate concerns.

Which Core Web Vital should I fix first if I can only fix one?

LCP, in most cases — it’s the metric most sites fail, it’s the one that just got a stricter threshold, and image and font optimization fixes tend to be faster to ship safely than the JavaScript refactoring INP fixes usually require.

How often should I re-check Core Web Vitals after making fixes?

Field data in Search Console updates on a rolling 28-day window, so give a fix about a month before judging whether it worked. Lab tools like PageSpeed Insights give an immediate read but won’t match field data exactly.

Should I build in a margin above the current “good” threshold?

Yes — thresholds have tightened repeatedly as device and connection speeds improve globally. A site sitting exactly at the current bar is a strong candidate to fail the next tightening, whenever it comes.

Want your Core Web Vitals checked against the current thresholds, and folded into a broader technical audit rather than fixed in isolation? See our pricing or read more about how we approach technical SEO for Swiss businesses.

References

Scroll to Top