What Are Core Web Vitals and How to Improve Them

Speed feels like respect.

A fast page loads predictably, stays stable while content appears, and responds quickly when people interact. That is exactly what Core Web Vitals measure. In this guide you’ll learn what each metric means, how it is calculated in the real world, what “good” looks like, and a practical playbook to move scores from red to green without guesswork.

Core Web Vitals in plain language

Core Web Vitals are three user-centric metrics Google uses as part of its page experience signals. They focus on how fast the largest thing appears, how much the page jumps while loading, and how quickly the page reacts to taps and clicks. You improve them to make users happier first, search second.

Largest Contentful Paint (LCP): when the largest visible content element finishes rendering. Usually a hero image, background image, or a large block of text.
Cumulative Layout Shift (CLS): total of all unexpected layout shifts that occur while the page loads and during ongoing UI updates.
Interaction to Next Paint (INP): the delay between a user interaction and the next frame that reflects it. It replaced First Input Delay as the responsiveness metric and captures a wider set of interactions.

Each metric has thresholds that categorize performance: fast, needs improvement, and poor. Hitting “good” across real user data is the goal.

How the metrics are measured

There are two ways these numbers appear in tools.

Field data (real users): collected from actual visitors in production. This is the source of truth and what search systems consider. Field data reflects devices, networks, and geography you cannot simulate.
Lab data (synthetic tests): measured in a controlled environment on your machine or a testing service. It is great for debugging and preventing regressions before deploys, but it does not replace field data.

You need both. Lab tests help you fix issues. Field data keeps you honest about what users experience on real devices, including long-tail phones and flaky connections.

Target thresholds you should aim for

LCP: 2.5 seconds or less for the 75th percentile of loads
CLS: 0.1 or less for the 75th percentile
INP: 200 milliseconds or less for the 75th percentile

The 75th percentile requirement means three out of four real user experiences must be “good.” That focuses your work on consistency, not just best-case scenarios.

The forces behind each metric

Largest Contentful Paint (LCP)

LCP times drift based on five common factors:

Render-blocking resources: unoptimized CSS and JavaScript in the <head> delay first paint.
Image heft: a large hero image or background image that downloads late.
Server response time: slow HTML and asset delivery chains.
Resource priority: the browser guesses wrong about what matters most.
Client work: heavy main-thread work prevents painting.

Fixing LCP is about speeding the critical path and prioritizing the right asset.

Cumulative Layout Shift (CLS)

CLS spikes when content pushes other content around. Common culprits:

Images and ads without dimensions
Web fonts that swap late and change text width
Late-loading widgets that insert above content
Cookie banners and consent prompts that push the layout

CLS is about reserving space and staging late content so the layout feels anchored.

Interaction to Next Paint (INP)

INP represents how quickly a page responds after an interaction and paints the result. It includes delay to handle the event, the time handlers take, and the time to paint a new frame.

INP suffers when:

Large JavaScript bundles block the main thread
Heavy event handlers run on every keystroke or pointer move
Long tasks starve the event loop
Expensive layout and style recalculations occur on interaction

Improving INP is a mix of leaner JavaScript, smarter scheduling, and keeping work off the main thread.

A practical, repeatable tuning process

Think system, not heroics. Use this five-stage cycle to raise scores and keep them there.

1) Establish baselines you trust

Real users: connect your site to field telemetry. If you do not have RUM, start with a lightweight script that records Web Vitals and sends anonymized metrics to your analytics store. Track by template so you know which pages hurt users most.
Synthetic tests: automate lab tests in CI for the most important routes. Fix red results before merging.

2) Pick the highest-impact pages and templates

Start where improvements move revenue or conversions. Product detail pages, landing pages, and article templates often drive the most value. Improving one layout can lift thousands of URLs that share it.

3) Fix LCP first, then CLS, then INP

LCP improvements usually help everything else, because they reduce blocking work. CLS fixes are surgical and safe. INP work can be deeper because it touches application code and interactions.

4) Lock wins in your pipeline

When you adopt an optimization, capture it as code or a build rule so future changes inherit it automatically. Add guardrails that fail builds when regressions creep in.

5) Re-measure and repeat monthly

New features add weight. New marketing scripts appear. Make Web Vitals a monthly habit so performance remains a product feature, not a one-time project.

How to improve LCP

Make the LCP element obvious and early

Inline small critical CSS. Extract the CSS needed for the above-the-fold layout and inline it. Load the rest asynchronously.
Defer non-critical scripts. Use defer or load after first paint. Avoid async when inline scripts depend on order.
Preload the LCP asset. If the LCP is a hero image or background image, preload the exact candidate the browser should fetch. Add fetchpriority="high" to signal importance.

<link rel="preload" as="image"
      href="/img/hero-1600.avif"
      imagesrcset="/img/hero-800.avif 800w, /img/hero-1600.avif 1600w"
      imagesizes="100vw"
      fetchpriority="high">

Deliver the smallest bytes that still look right

Use modern formats. Prefer AVIF or WebP with a JPEG fallback.
Resize to realistic display sizes. Serve width-based srcset with accurate sizes.
Compress to a target. For photographic content, AVIF around quality 45–55 and WebP around 70–82 are solid starting points.
Strip metadata. Remove EXIF unless you require it, keep color profiles as needed, and convert to sRGB.

Reduce server and network delay

Cache HTML where possible. If you can cache whole pages, do it. If not, cache fragments or use edge rendering.
Adopt HTTP/2 or HTTP/3. Parallelism and better congestion control shorten transfer.
Use a CDN. Bring assets closer to users and shield origins from spikes.

Keep the main thread free to paint

Split bundles. Load only what the first screen needs.
Avoid large synchronous work on load. Schedule analytics and non-critical code after first paint.
Use decoding="async" for images. Let the browser decode off the main thread.

How to improve CLS

Always define intrinsic size

Set width and height for images, or use CSS aspect-ratio. That gives the browser the box size before bytes arrive.

<img src="/img/card-800.webp" alt="Cover"
     width="800" height="533" loading="lazy" decoding="async">

Reserve space for ads and embeds

Allocate a stable container. Use min-height that matches typical creative sizes, and let the ad fill the box, not push content down.
Load below the fold when possible. Ads that appear above the main content cause the worst shifts.
Use placeholders for embeds. Reserve space for video players, maps, and social widgets before they load.

Control font swaps

Use font-display: swap or optional. Prevent invisible text.
Size fallback fonts carefully. Use a fallback with similar metrics to your web font to minimize reflow when the real font loads.
Preload key font files. Bring crucial fonts earlier in the waterfall.

Stage late-loading UI

Insert notifications and banners in reserved regions. Do not push content down after load.
Schedule UI updates after idle. If your app inserts content dynamically, use transitions within reserved containers.

How to improve INP

Shrink your JavaScript cost

Ship less code. Audit dependencies, remove unused libraries, and lazy-load heavy features behind user actions.
Defer hydration. For islands or component frameworks, hydrate only when elements enter the viewport or on explicit interaction.
Split route bundles. Load only the code a route needs.

Make interactions lightweight

Keep handlers small. Avoid blocking the main thread with long functions. If work exceeds 50 ms, break it into chunks.
Move expensive work off thread. Use Web Workers for parsing, formatting, or heavy calculations.
Batch DOM writes. Read layout once, then perform writes together to avoid forced synchronous layout.
Throttle continuous listeners. Debounce input handlers and scroll events so they run at sane intervals.

Render quickly after events

Minimize synchronous re-renders. Reconcile state changes in batches.
Use requestIdleCallback and requestAnimationFrame to schedule non-critical updates and align paints to frames.
Avoid layout trashing. Reuse DOM nodes and avoid style recalculation hotspots.

Measurement and tooling that keep you honest

Field telemetry you can rely on

Real User Monitoring (RUM): Add a small script to collect LCP, CLS, and INP for real users. Record by route and device class.
Percentile focus: Track the 75th percentile over time. Do not chase averages.
Anomaly detection: Alert when any vital regresses past thresholds so engineers catch issues early.

Lab checks for developers

Run synthetic tests on each PR. Use a fixed device profile and connection. Store LCP, CLS, and a representative interaction trace.
Trace waterfalls. Look for render-blocking resources that do not belong in the critical path.
Diff budgets. Fail builds if JavaScript or image budgets exceed limits.

Images, fonts, and CSS: three levers that move all vitals

Images

Serve modern formats with fallbacks
Provide responsive srcset and accurate sizes
Preload the LCP image and give it high fetch priority
Lazy-load below-the-fold media
Cache with immutable URLs using content hashes

These steps reduce bytes, advance paints, and prevent layout shifts.

Fonts

Subset to needed glyphs to shrink files
Use font-display: swap or optional
Preload the one or two hero fonts
Choose fallback system fonts with matching metrics

That keeps text readable immediately and avoids reflow spikes.

CSS

Extract and inline critical CSS for above-the-fold layout
Load the rest with rel="preload" followed by rel="stylesheet" swap or via non-blocking techniques your framework supports
Remove unused rules and ship smaller files

Faster CSS means faster first paint and less time waiting on style calculation.

Mobile networks and low-end devices

Remember that many users live on slower networks and older phones. Plan for that reality.

Reduce connection count. Every new domain requires handshakes. Consolidate where reasonable.
Prefer compression that plays well with slow CPUs. Heavy codecs can saturate low-end devices; balance AVIF gains with decode costs on entry-level phones.
Test on throttled hardware. Use a real device or a slow simulation to catch issues you never see on a powerful laptop.

Governance: keep performance from drifting

Performance budgets: set size and timing budgets per route and enforce them in CI.
Definition of done: require passing Web Vitals checks for new templates before release.
Owner for vitals: assign a rotating “performance gardener” who reviews metrics weekly and creates small, continuous fixes.
Documentation: write a short guide for engineering and content teams so everyone knows how to keep pages fast.

Tradeoffs and sequencing that work in the real world

Security headers and performance: HTTP security headers like HSTS, CSP, and COOP/COEP do not hurt Web Vitals when configured well. Add them early.
Third-party scripts: marketing and analytics tools can crush INP and LCP if they block the main thread. Load them after first paint, use consent-gated loading where appropriate, and set clear budgets.
Framework defaults: modern frameworks ship image, font, and script helpers that solve half the battle. Use them, then tune the edges.

A two-week improvement plan you can copy

Days 1–2: Find the worst offenders

Enable RUM if you lack it.
Identify the top three templates with the worst 75th percentile vitals.

Days 3–5: Fix LCP on one template

Preload the LCP image and set fetch priority.
Inline critical CSS for the hero and header.
Defer non-critical scripts.
Resize and compress the hero assets with modern formats.

Days 6–7: Eliminate CLS

Add dimensions to all images in the template.
Reserve space for ads and late widgets.
Preload hero fonts and switch to swap or optional.

Week 2: Improve INP and lock it in

Split the main bundle and lazy-load the heaviest feature.
Remove one third-party script or switch it to delayed load.
Add budgets and CI checks so changes do not regress.
Repeat the same sequence on the next most valuable template.

By the end of two weeks you will see field numbers trend downward. Keep at it for the remaining templates and you will feel the site get calmer and faster.

Final Takeaway

Core Web Vitals measure how respectful your site feels. If the largest content appears fast, the layout stays put, and taps respond right away, people stick around and convert. Improve LCP by prioritizing the right bytes and shipping less work before paint. Improve CLS by reserving space and staging late content. Improve INP by shipping less JavaScript and doing less on every interaction. Measure in the field, enforce budgets in CI, and capture your wins as code. Do that, and performance becomes a quiet habit, not a scramble.

Frequently Asked Questions

Are Core Web Vitals a ranking factor

They are one of many page experience signals, but they do not replace great content or relevance. Treat them as table stakes that help users and search visibility together.

Do I need a CDN to pass Core Web Vitals

No, but a CDN makes it easier by shortening distance, enabling HTTP/2 or HTTP/3, and handling caching well. You can still pass on a simple host if you control render-blocking resources and image weight.

What is a good INP target for a JavaScript heavy app

Aim for 200 ms at the 75th percentile. To reach it in SPAs, split bundles, avoid long tasks, and move heavy logic off the main thread using workers.

Why did my CLS get worse after adding web fonts

If fonts swap late or have different metrics than fallbacks, text reflows. Preload the font, use font-display: swap or optional, and pick fallbacks with similar width metrics to reduce shifts.

How often should I measure Web Vitals

Continuously in production via RUM, and per pull request in CI for critical routes. A weekly review catches regressions before they become trends.

My LCP is a background image. Does `<img>` help

Often yes. Browsers prioritize <img> elements better and support srcset, sizes, and fetch priority. Consider moving critical backgrounds into <picture> or <img> for more control.

Can I fix poor Web Vitals without changing design

Usually. Many wins come from how you load assets and scripts, not from changing layouts. When design must change, it is often about reserving space, not redesigning the look.

References

Guides on measuring Core Web Vitals with field and lab tooling
Best practices for responsive images, font loading, and critical CSS
Performance budgeting and CI integration examples
Browser documentation for fetchpriority, decoding, and aspect-ratio
Real User Monitoring implementation patterns for Web Vitals