Core Web Vitals: What Are LCP, CLS and INP and How to Improve Your Site's Score

Google has used Core Web Vitals as a ranking factor since 2021. That means if your site's LCP is above 2.5 seconds or your CLS is above 0.1, you are losing positions to faster competitors — even if your content is better. It's not a matter of opinion: it's the search algorithm working against you.

The good news is that each metric has specific causes and well-defined solutions. This guide explains what each signal measures, how to diagnose it, and which actions have the greatest practical impact.

What Are Core Web Vitals?

Core Web Vitals are three metrics defined by Google to measure the real user experience on a web page. They evaluate loading speed, visual stability and responsiveness to interactions.

LCP — Largest Contentful Paint

LCP measures how long it takes for the largest visible element on the page — usually a hero image, a banner or a large text block — to be fully rendered on screen.

Thresholds:

✅ Good: up to 2.5 seconds
⚠️ Needs improvement: 2.5 s to 4.0 s
❌ Poor: above 4.0 seconds

A high LCP is the most common performance issue. It directly affects the user's perception of speed: most people decide whether to wait for a page within the first 2 to 3 seconds.

Common causes of high LCP:

Unoptimized images (large PNG or JPEG files without compression)
Web fonts blocking rendering
Slow TTFB (Time to First Byte) from inadequate hosting or no CDN
Third-party scripts loading before the main content

CLS — Cumulative Layout Shift

CLS measures the visual instability of a page: how much elements "jump" on screen while content loads. If you've ever tried to click a button and it moved at the last second, causing you to click something else, you experienced a high CLS.

Thresholds:

✅ Good: below 0.1
⚠️ Needs improvement: 0.1 to 0.25
❌ Poor: above 0.25

Common examples of CLS:

Images without explicit width and height attributes
Ads or banners that appear and push content down
Web fonts replacing placeholder text (FOIT/FOUT)
Dynamic content injected above existing elements

INP — Interaction to Next Paint (and TBT as a proxy)

INP replaced FID (First Input Delay) in March 2024 as the official metric. It measures the latency of all user interactions with the page — clicks, taps, keyboard input — and reports the worst case.

TBT (Total Blocking Time) is the lab-based substitute for INP: it measures the time the browser's main thread is blocked, preventing responses to interactions.

INP Thresholds:

✅ Good: up to 200 ms
⚠️ Needs improvement: 200 ms to 500 ms
❌ Poor: above 500 ms

How to Measure Your Site's Core Web Vitals

Before optimizing, you need to know where the problem is. FlashMon's Speed Test runs a full page analysis and returns:

Score from 0 to 100 (similar to Lighthouse/PageSpeed)
LCP, CLS and TBT measured individually with visual status indicators
Breakdown by resource type — JavaScript, images, CSS, fonts, third-party
Top 10 heaviest resources with file size and load time

This lets you pinpoint exactly which file is pushing your LCP up or which script is blocking the main thread, without installing extensions or running Lighthouse manually.

How to Improve Each Metric

Improving LCP

1. Optimize images

Images are the most frequent cause of high LCP. Use WebP format (20–35% smaller than JPEG at equivalent quality) or AVIF for static images. If you use Next.js, the <Image> component handles this automatically.

For images below the fold (not visible on initial load), add loading="lazy". For your page's hero image — the LCP candidate — do the opposite: add fetchpriority="high" to ensure the browser prioritizes it.

2. Preload critical fonts

Web fonts block rendering by default. Add this to your <head>:

<link rel="preload" href="/fonts/your-font.woff2" as="font" type="font/woff2" crossorigin>

Combine this with font-display: swap in your CSS to display placeholder text while the font loads, avoiding a blank screen.

3. Reduce TTFB with better hosting and a CDN

If your server takes more than 600 ms to send the first byte, LCP will be high regardless of other optimizations. Consider:

Moving to hosting with servers closer to your audience
Using a CDN (Cloudflare, Fastly, Vercel Edge) to serve static content from the edge
Enabling response caching on the server for pages with static content

Improving CLS

1. Set explicit dimensions on images and videos

Every <img> and <video> element should have width and height defined in the HTML. This allows the browser to reserve the correct space before the resource loads, eliminating layout jumps.

<!-- Wrong -->
<img src="banner.jpg" alt="Banner">

<!-- Correct -->
<img src="banner.jpg" alt="Banner" width="1200" height="600">

2. Reserve space for dynamic content

Ads, cookie banners and third-party widgets that appear after load are classic CLS sources. The fix is to reserve the space beforehand: use min-height on the container to ensure the layout isn't pushed when the content appears.

3. Avoid injecting content above existing elements

If you need to show a banner or notification, prefer animations that slide in from the bottom or overlays that don't affect the page flow.

Improving TBT and INP

1. Code splitting and on-demand loading

Shipping a massive JavaScript bundle keeps the main thread blocked while the browser parses and executes the code. Use dynamic imports to split the bundle:

// Load the heavy component only when needed
const ComplexChart = dynamic(() => import('./ComplexChart'), { ssr: false });

2. Defer third-party scripts

Analytics, chat widgets, marketing pixels — these scripts are the biggest TBT culprits. Load them with defer or async, or better yet, use a facade: display a static placeholder and load the real script only when the user interacts with it.

<script src="analytics.js" defer></script>

3. Move heavy work to Web Workers

Intensive processing (data parsing, calculations) should not run on the main thread. Web Workers allow code to execute in parallel without blocking the UI.

Complementary Tools

Improving Core Web Vitals involves more than optimizing assets. Two infrastructure factors have a direct impact:

HTTP/2 and HTTP/3 Support Test

The HTTP/2 protocol enables multiplexing: multiple resources are transferred in parallel over the same connection, reducing latency. HTTP/3 goes further, using QUIC for lower overhead on unstable connections.

Use FlashMon's HTTP Version Test to check whether your server supports HTTP/2 and HTTP/3. If you're still on HTTP/1.1, upgrading can noticeably reduce LCP without any code changes.

HTTP Headers and Redirect Chain Analysis

An unnecessary redirect adds 100–300 ms to the TTFB before the page even begins loading. The Strict-Transport-Security header with preload eliminates the HTTP-to-HTTPS redirect for returning visitors, since the browser already knows to use HTTPS directly.

Check your HTTP status and redirect chain to identify avoidable redirects on the main loading path.

Summary: What to Prioritize

Problem	Most common cause	Priority action
High LCP	Unoptimized hero image	Convert to WebP + `fetchpriority="high"`
High LCP	Slow server	CDN + response caching
High CLS	Images without dimensions	Add `width` and `height` to all `<img>` tags
High CLS	Dynamic content	Reserve space with `min-height`
High TBT	Massive JS bundle	Code splitting with dynamic imports
High TBT	Third-party scripts	Add `defer` or use facades

The recommended sequence is: measure first with FlashMon's Speed Test to identify the real problem, then apply the specific fix. Optimizing blindly — compressing images when the real issue is blocking JavaScript — is the most common mistake and wastes time without moving the score needle.

Core Web Vitals aren't a box to check once. Every new feature, partner script or image added can degrade the metrics. The ideal approach is to integrate them into the deploy process: a PageSpeed score below 70 before going to production should be as serious a warning sign as a failing test.

Test your site's speed now — it's free

Related reading

Cut TLS and redirect overhead on the critical path — see HTTP security headers and use the HTTP Status Checker to audit your redirect chain.
Confirm the server is serving over a modern protocol with the HTTP/2 and HTTP/3 Version Test.