Core Web Vitals 2026: how to improve them with and without a CDN | Technical guide

The three Core Web Vitals metrics in 2026

Google measures user experience through three main metrics that make up the Core Web Vitals. Since late 2024, INP has replaced FID as the official metric. Here's what each one measures.

LCP — Largest Contentful Paint

LCP measures the time it takes for the largest content element visible in the initial viewport of the page to fully load. The LCP element is typically a hero image, a video, or a large block of text.

Google's threshold: under 2.5 seconds is "good", between 2.5 and 4 seconds is "needs improvement", above 4 seconds is "poor".

LCP is the most impactful metric for ranking because it directly measures the user's perception of speed — how much time passes between clicking the link and seeing the page's main content.

CLS — Cumulative Layout Shift

CLS measures the visual stability of the page during loading. Every time an element moves after appearing — an image that "pushes" text downward, a banner that appears and reorganizes the layout, a font that changes size during rendering — a layout shift is generated with a shift score.

Google's threshold: under 0.1 is "good", between 0.1 and 0.25 is "needs improvement", above 0.25 is "poor".

CLS particularly affects mobile users — where elements tend to shift more during loading — and sites with ads or dynamically loaded content.

INP — Interaction to Next Paint

INP is the most recent metric, which replaced FID in March 2024. It measures the page's responsiveness to user interactions: clicks, taps, key presses. More precisely, it measures the time between the user's interaction and the moment the browser visually updates the page in response.

Google's threshold: under 200ms is "good", between 200 and 500ms is "needs improvement", above 500ms is "poor".

INP is harder to optimize than FID because it measures all interactions throughout the page's lifetime, not just the first one. A site that responds well to the first click but slows down after the user has interacted several times — a common scenario on pages with heavy JavaScript — gets penalized by INP but would not have been penalized by FID.

How to measure Core Web Vitals correctly

There's a fundamental distinction that many overlook: lab data and field data are two different things, and Google uses field data for ranking.

Lab data vs field data

PageSpeed Insights shows both. Lab data — the "Diagnostics" section — simulates the conditions of a user on a 4G mobile connection with a mid-range device. It's reproducible and useful for debugging, but it's not what Google uses for ranking.

Field data — the "Field Data" section — comes from the Chrome User Experience Report (CrUX): real measurements aggregated from Chrome users who visit your site. This is the data Google uses to evaluate Core Web Vitals for ranking purposes. If your site has little traffic, CrUX may not have enough data and the "Field Data" section will appear empty.

The right tools

PageSpeed Insights is the starting point — free, straightforward, and shows both types of data. But it has a limitation: it analyzes one page at a time.

Google Search Console has an "Experience" → "Core Web Vitals" section that shows the aggregated performance of all pages on the site, divided by URLs with issues. This is the right tool for understanding the overall status of the site and identifying which groups of pages have problems.

For a deeper analysis: WebPageTest allows tests with customizable conditions and a detailed loading waterfall. Lighthouse (built into Chrome DevTools) is useful for local debugging.

The real causes of poor LCP and how to fix them

An LCP above 2.5 seconds almost always has one of these causes. Let's look at them in order of frequency.

Slow server — high TTFB

Time to First Byte is the time the browser waits before receiving the first byte of response from the server. If TTFB exceeds 600ms, you're already starting at a disadvantage: the browser can't even begin loading the page's resources until it receives the initial response.

Causes of high TTFB: shared hosting with insufficient resources, a non-optimized database with slow queries, lack of server-side caching, a CMS that generates every page dynamically without caching. On WordPress with many plugins, each request can generate dozens of database queries — TTFB rarely drops below 800ms without an aggressive caching system.

The structural solution is hosting with optimized PHP-FPM, active OPcache, and properly configured server-side caching. The definitive solution is a CMS with an architecture optimized for speed — where a TTFB under 200ms doesn't depend on the hosting configuration but on the application's own architecture. You can see KeideaCMS's performance benchmarks here.

LCP image not preloaded

The browser discovers the LCP image only after parsing the page's HTML and CSS. If the hero image is set as a CSS background-image, or if it's loaded with lazy loading, the browser discovers it late and LCP gets worse.

The solution: add a <link rel="preload"> tag in the page's head for the LCP image. This tells the browser to start downloading the image immediately, even before processing all the CSS.

```html ```

Warning: preload should only be used for the LCP image, not for all images. Preloading too many resources worsens performance instead of improving it.

Unoptimized images

A 2MB image in JPEG format is the most common cause of poor LCP on sites that have never undergone optimization. The solution has three components: format (WebP or AVIF instead of JPEG/PNG), size (serving the image at the size it's displayed, not larger), and compression (quality 75-85 for WebP is sufficient for most use cases).

The srcset attribute allows you to serve different images for different screen sizes — essential for mobile, where desktop images are massively oversized.

Render-blocking resources

CSS and JavaScript loaded in the page's head block rendering — the browser can't display anything until it has downloaded and processed these resources. A site with many CSS and JS plugins in the head can block rendering for 1-2 seconds before the user sees any content.

The solution: load critical CSS inline in the head and defer the rest, use defer or async for non-critical JavaScript, and eliminate unused resources. On WordPress with many plugins, this requires manual intervention or optimization plugins — which in turn add complexity and potential conflicts.

The real causes of poor CLS and how to fix them

Images without defined dimensions

When the browser loads a page, it reserves space for elements based on the dimensions declared in the HTML. If an image doesn't have the width and height attributes defined, the browser doesn't know how much space to reserve, and when the image loads the layout shifts.

The solution is simple: always add width and height to every image tag. They don't need to be exact pixel values — they're used to define the aspect ratio that the browser uses to reserve the correct space.

Web fonts with FOUT or FOIT

When the browser needs to download an external font, it either shows the text first with a system font (FOUT — Flash of Unstyled Text) or hides it until the font is ready (FOIT — Flash of Invisible Text). When the web font arrives, if its metrics differ from the system font, the layout shifts.

The solution: use font-display: optional for non-critical fonts (the browser uses the system font if the web font isn't ready in time), or preload the critical web font to minimize wait time. The CSS property size-adjust allows you to calibrate the fallback font's metrics to minimize layout shift when the web font arrives.

Dynamically injected content

Cookie banners, chat widgets, advertising elements, popups — any element inserted into the DOM after the page's initial load can cause layout shift if it moves already visible elements. The solution is to reserve fixed space for these elements in the layout, or to place them in positions that don't shift existing content (fixed-position overlays, elements at the end of the page).

The real causes of poor INP and how to fix them

INP almost always depends on JavaScript. When the user interacts with the page, the browser must execute all the JavaScript code associated with that interaction before it can update the display. If the JavaScript is heavy or poorly structured, the visual update is delayed.

Long tasks on the main thread

The browser's main thread does everything: it executes JavaScript, calculates CSS style, updates layout, paints pixels. If a JavaScript task occupies the main thread for more than 50ms, it creates a "long task" that delays all user interactions.

The solution is to break long tasks into smaller chunks using scheduler.postTask() or strategic setTimeout() calls, or to move heavy work to Web Workers that operate on separate threads.

Excessive JavaScript dependencies

A site that loads 500KB of JavaScript — a common scenario on WordPress with many plugins — has a limited execution budget. On mid-range mobile devices, parsing and compiling JavaScript takes much longer than on a MacBook Pro. INP on mobile worsens proportionally to the amount of JavaScript loaded.

The solution is to reduce total JavaScript by eliminating unnecessary dependencies, using code splitting to load only the code needed for the current page, and preferring native browser solutions over heavy JavaScript libraries.

Core Web Vitals and CDN: when it's really needed and when it's useless

CDN is one of the most recommended interventions for improving Core Web Vitals — and one of the most misunderstood. The reality is that a CDN solves a specific problem, not all performance problems. Understanding when it's really needed avoids spending money on infrastructure that doesn't move the numbers.

What a CDN actually does

A Content Delivery Network distributes the site's static resources — images, CSS, JavaScript, fonts — across geographically distributed servers. When a user requests the page, they receive these resources from the node closest to their location instead of from the origin server. The result is a reduction in network latency for transferring static files.

For LCP, a CDN can improve the download time of the hero image if the user is far from the origin server. For CLS it has no effect — layout shift depends on code structure, not network latency. For INP it has no direct effect — responsiveness depends on JavaScript execution in the user's browser, not network speed.

When a CDN concretely improves Core Web Vitals

A CDN has a measurable impact on LCP in two specific scenarios. First: your audience is geographically distant from the server — if the server is in Italy and you have users in Australia, the CDN significantly reduces latency. Second: your static resources are unoptimized heavy files — 1-2MB images that a CDN can compress and convert to WebP on-the-fly.

In both cases, the improvement concerns resource transfer, not page generation. TTFB — Time to First Byte — depends on the origin server, not the CDN. If your server takes 800ms to respond, the CDN won't speed it up: the page's HTML is always generated and served by the origin server.

When a CDN is useless and the money is wasted

If your audience is Italian and the server is in Italy, the latency reduction from a CDN is measurable in tens of milliseconds — not enough to move an LCP from 3.5 to 2.4 seconds. In this case the problem is almost always a high TTFB, meaning a server that's slow to generate the page, or unoptimized resources regardless of their geographic location.

A CDN on a slow WordPress site with a TTFB of 900ms produces a site with a CDN and a TTFB of 900ms. The CDN hasn't touched the real problem. The same applies to CLS caused by images without defined dimensions, or INP caused by poorly structured JavaScript — no geographic distribution solves architectural problems.

The comparison that matters: CDN vs architecture

The real comparison isn't "CDN yes or CDN no" — it's "CDN on top of a slow system" vs "system that's fast by architecture". A CMS designed with TTFB under 200ms, images served in the correct format at the correct size, zero unnecessary JavaScript in the main thread, achieves green Core Web Vitals without a CDN for an Italian audience. Adding a CDN to this system further improves performance for distant users — but it's not a prerequisite for passing Google's thresholds.

A CDN is a useful tool in the right context. It isn't the solution to Core Web Vitals — it's an additional optimization on an already solid foundation.

Core Web Vitals and CMS: why architecture matters more than optimization

There's a pattern that emerges when working on the Core Web Vitals of WordPress sites: you optimize, you improve, you reach green on PageSpeed — and then you install a new plugin or update the theme and you're back to square one.

The reason is that on WordPress, performance optimization is ongoing work on a system that structurally tends toward slowness. Every plugin adds CSS, JavaScript, database queries. Every theme has its own overhead. Optimization compensates for this tendency but doesn't eliminate it.

A CMS designed with speed as an architectural requirement — not as an added optimization — starts from a different baseline. TTFB under 200ms, zero unnecessary JavaScript, images served in modern format with correct dimensions, no render-blocking resources in the head: these aren't optimizations applied on top of the system, they're features of the system itself.

The practical result is that Core Web Vitals stay green even as you add content, even as the catalog grows, even without periodic optimization work. If you're considering a migration from WordPress for exactly this reason, we've written a complete technical guide on migrating without losing your SEO rankings.

If you want to check the state of your current site's Core Web Vitals and understand what impacts your ranking most, you can request a free audit.

KeideaCMS

Are you still paying for separate hosting, plugins and maintenance?

KeideaCMS includes everything in one fixed annual fee: dedicated hosting, maintenance, direct support in Italian and setup. From €49/month, no surprises.

Discover plans and pricing →Book a Demo