Core Web Vitals in 2026: What They Are and Why Your Score Is Hurting Your Rankings

You built a website. It looks professional, the content is strong, and you have done everything your developer told you to do. Yet your pages are sitting on page two of Google — behind competitors whose websites look noticeably worse than yours. If you have ruled out content quality and backlinks as the problem, there is a strong chance your Core Web Vitals scores are the hidden variable suppressing your rankings.

Core Web Vitals are Google's official set of page experience metrics — and since Google's Page Experience update made them a direct ranking signal, a poor score is no longer just a user experience inconvenience. It is a measurable competitive disadvantage. In this article, we explain exactly what each metric measures, what good and bad scores look like, what causes them to fail, and how every website we build at Peak Web Craft is engineered to pass them from day one.

Why Core Web Vitals Exist — And Why Google Made Them a Ranking Factor

Google's core business is search — and search only remains valuable if the results it surfaces are genuinely useful to the people clicking them. A page that ranks well on keyword relevance but delivers a slow, unstable, or unresponsive experience is a bad result. Google has always cared about this in principle. With Core Web Vitals, they created a standardised, measurable framework for evaluating it systematically across billions of pages.

The logic is straightforward: pages that load fast, stay visually stable as they load, and respond immediately to user input create better experiences — and Google wants to surface better experiences. Pages that fail these tests create friction, frustration, and abandonment. Google does not want to surface those. By making Core Web Vitals a ranking factor, Google aligned the incentives of web developers with the experience of their users. Businesses that invest in performance get rewarded with visibility. Businesses that do not get penalised with obscurity.

A slow website is not a technical problem. It is a business problem. Every second of load delay is a percentage of visitors who have already made a decision about your brand — before they have seen a single word of your content.

Peak Web Craft — Web Performance Strategy, 2026

The Three Core Web Vitals Explained

There are three metrics that make up Core Web Vitals. Each one measures a different dimension of page experience, and each one has a clear threshold that separates a passing score from a failing one.

LCP — Largest Contentful Paint

LCP measures how long it takes for the largest visible element on the page — typically a hero image, a large heading, or a video thumbnail — to fully render. It is the closest proxy Google has for "when does this page feel loaded to a real user." A good LCP score is 2.5 seconds or under. Between 2.5 and 4.0 seconds needs improvement. Above 4.0 seconds is a poor score that directly suppresses rankings.

LCP failures are most commonly caused by unoptimised images — particularly large PNG or JPEG files that have not been converted to WebP or AVIF format, not compressed, and not sized appropriately for the viewport they are displayed in. Slow server response times, render-blocking JavaScript, and unpreloaded hero images are the other primary causes. Every website we build uses next-generation image formats, preloaded hero assets, and a fast hosting configuration to ensure LCP scores comfortably below the 2.5-second threshold.

CLS — Cumulative Layout Shift

CLS measures visual stability — specifically, how much the page layout shifts unexpectedly as it loads. If you have ever gone to tap a button on a website and had it jump down the screen just as your finger reached it, you have experienced a high CLS page. A good CLS score is 0.1 or below. Between 0.1 and 0.25 needs improvement. Above 0.25 is poor.

CLS failures are almost always caused by images without explicit width and height dimensions defined in the HTML — so the browser cannot reserve the correct space before the image loads and the layout jumps when it arrives. Web fonts that cause a flash of unstyled or invisible text, dynamically injected content above existing content, and advertisements that load after the page are the other most common culprits. Fixing CLS is primarily a code discipline issue rather than a server or hosting issue — which is why it requires a developer who builds with performance intentionality from the start.

INP — Interaction to Next Paint

INP replaced FID (First Input Delay) as a Core Web Vital in March 2024, and it is the most technically demanding of the three metrics to optimise. INP measures the responsiveness of a page to all user interactions throughout the entire session — not just the first one. It captures the delay between a user clicking, tapping, or typing and the page visually responding to that input. A good INP score is 200 milliseconds or under. Between 200ms and 500ms needs improvement. Above 500ms is poor.

INP failures are typically caused by heavy JavaScript execution that blocks the browser's main thread, third-party scripts — analytics, chat widgets, advertising tags — that execute synchronously, and inefficient event handlers that do too much work per interaction. Addressing INP often requires a meaningful audit of every script loaded on the page and how it interacts with the browser's rendering pipeline. It is the metric most commonly failed by websites built on bloated CMS platforms or WordPress themes with dozens of active plugins.

Why WordPress and Template-Based Sites Fail Core Web Vitals

The majority of Core Web Vitals failures we see during website audits share a common origin: the site was built on a template-based platform — usually WordPress with a premium theme — without any consideration for performance architecture. This is not a criticism of WordPress as a CMS. It is a statement about how the vast majority of WordPress sites are deployed in practice.

A typical WordPress business website loads six to twelve third-party scripts before a visitor sees any content: a page builder, a forms plugin, an SEO plugin, a cache plugin, a slider plugin, an analytics tag, a chat widget, and a cookie consent tool. Each of these scripts adds to the JavaScript execution budget the browser must process before it can paint the page. Premium themes add their own layer of CSS and JavaScript that was written to support every possible design configuration — which means a site using 5% of a theme's features is still loading 100% of the theme's code.

Custom-built websites avoid this problem entirely by loading only the code required for the specific page being rendered. No plugin bloat. No theme overhead. No third-party scripts loaded synchronously when they could be deferred or eliminated. This is not a marginal difference — it is the primary reason custom-built sites consistently score 90+ on PageSpeed Insights while template-based sites cluster between 40 and 65.

How to Diagnose Your Core Web Vitals in 5 Steps

Before deciding whether your existing site can be optimised or needs to be rebuilt, run this structured diagnostic. It will tell you exactly which metrics are failing, why, and how severe the impact is on your current search performance.

1. Run PageSpeed Insights on your three most important pages. Visit pagespeed.web.dev, test your homepage, your primary service or product page, and your contact or booking page. Note the scores for each Core Web Vital separately — a failing LCP requires different fixes than a failing INP.
2. Check Google Search Console for field data. In Search Console, navigate to Experience → Core Web Vitals. This shows your real-world scores from actual visitors, which are often different from the lab scores in PageSpeed Insights. If Search Console flags URLs as Poor, those pages have a confirmed ranking penalty.
3. Identify your LCP element. In Chrome DevTools, open the Performance panel, record a page load, and look for the LCP marker. The element flagged is your optimisation target. If it is an image, check its format (WebP?), its file size (under 200KB for a hero?), and whether it is being preloaded in the HTML head.
4. Audit your third-party scripts. In PageSpeed Insights, scroll to the "Reduce the impact of third-party code" section. If any single third-party script adds more than 500ms of blocking time, it is a candidate for removal, deferral, or replacement with a lighter alternative.
5. Test on a real mobile device, not just a desktop emulator. Your PageSpeed mobile score uses a throttled connection to simulate a mid-range Android phone. Open your website on an actual mid-range Android device on a 4G connection and measure how long it genuinely takes to feel interactive. This is the experience Google is scoring and ranking against.

What Good Core Web Vitals Architecture Looks Like in Practice

At Peak Web Craft, Core Web Vitals compliance is not a post-build optimisation task — it is a constraint that shapes every technical decision made during development. Here is what that looks like in practice across the sites we build.

• All images converted to WebP format with explicit width and height attributes on every img tag, lazy loading on all below-fold images, and preload directives on hero images to eliminate LCP delays.
• No render-blocking resources in the critical path. CSS is inlined for above-fold content and loaded asynchronously for below-fold styles. JavaScript is deferred or loaded after the page is interactive — including analytics, which has no legitimate reason to block rendering.
• Self-hosted fonts with font-display: swap to prevent invisible text during load and eliminate CLS caused by font substitution. Web font files are preloaded in the HTML head to minimise the swap window.
• Minimal JavaScript footprint by default. We build with vanilla JavaScript and GSAP for animations — not React or heavy frameworks for pages that do not require them — because framework overhead is the single largest contributor to INP failures on marketing sites.
• Fast hosting with edge caching. Every site we deploy is hosted on infrastructure with global CDN distribution and edge caching configured for HTML, CSS, JavaScript, and image assets — so server response time (TTFB) stays under 200ms for visitors regardless of their geographic location.

Wrapping Up

Core Web Vitals are not a niche technical concern for developers. They are a direct determinant of how visible your website is on Google — and therefore how many potential clients ever find you at all. A failing LCP, an unstable CLS, or a sluggish INP is not a cosmetic problem. It is a revenue problem, measured in the organic traffic and leads your competitors are receiving while your pages sit below theirs in the rankings.

Every website built by Peak Web Craft — whether a business website, landing page, or e-commerce store — is engineered to pass Core Web Vitals as a baseline requirement, not an optional extra. If your current site is failing these metrics and you want to understand what it would take to fix it, start a conversation with us. We are currently accepting new projects and typically respond within 24 hours.