How To Improve Core Web Vitals: A Developer-Friendly Guide

A website can look polished and still frustrate visitors. A slow hero image, an unresponsive menu or a shifting checkout button can make it harder for people to find information and complete an action.

Core Web Vitals are three Google metrics that measure loading performance, responsiveness and visual stability: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS).

To meet Google’s “good” thresholds, aim for:

• LCP: 2.5 seconds or less
• INP: 200 milliseconds or less
• CLS: 0.1 or less

These targets apply at the 75th percentile of real-user experiences, evaluated separately for mobile and desktop.

Below, we explain what each metric means, how to check your website and which fixes to prioritize.

What Do Core Web Vitals Measure?

Core Web Vitals answer three practical questions about the experience your website delivers.

Metric	What It Measures	Good	Needs Improvement	Poor
Largest Contentful Paint (LCP)	How quickly the largest visible content element appears	≤ 2.5 seconds	> 2.5–4 seconds	> 4 seconds
Interaction to Next Paint (INP)	How quickly the page visually responds to user interactions	≤ 200 milliseconds	> 200–500 milliseconds	> 500 milliseconds
Cumulative Layout Shift (CLS)	How much visible content shifts unexpectedly	≤ 0.1	> 0.1–0.25	> 0.25

These thresholds come from Google’s Web Vitals guidance.

A page needs all three metrics in the good range to pass a full Core Web Vitals assessment. A fast-loading page can still fail if its buttons respond slowly or its content jumps around.

Largest Contentful Paint: Loading Performance

LCP measures how long it takes for the largest eligible image, video or text block within the viewport to render.

Depending on the layout, that element might be:

• A homepage hero image
• A product photograph
• A large heading or introductory text block
• A video poster image

LCP is not the time required to download every resource on the page. It focuses on when a substantial piece of visible content appears.

Common causes of poor LCP include slow server responses, oversized images, late-discovered resources and render-blocking CSS.

Example: A service page displays its navigation immediately, but the large hero image takes four seconds to appear. If that image is the LCP element, visitors experience slow loading even though part of the page is already visible.

Interaction To Next Paint: Responsiveness

INP evaluates how quickly a page produces a visual response after interactions such as clicks, taps and keyboard input.

It includes three sources of delay:

1. Input delay: The browser is busy and cannot begin processing the interaction.
2. Processing time: The interaction’s event handlers run.
3. Presentation delay: The browser completes the rendering work needed to display the result.

INP generally reflects one of the slowest interactions during a page visit, with adjustments for pages that receive many interactions.

Heavy JavaScript, third-party tools and expensive interface updates are common causes of poor responsiveness.

Example: A shopper taps a product filter, but the interface freezes before showing the selected state. That delayed visual feedback can contribute to poor INP.

INP replaced First Input Delay as a Core Web Vital in March 2024. Unlike FID, it evaluates responsiveness beyond the first interaction.

Cumulative Layout Shift: Visual Stability

CLS measures unexpected movement of visible elements.

You have experienced a layout shift if you tried to click a link just as a banner appeared above it, pushing the link somewhere else.

Common causes include:

• Images without reserved dimensions
• Ads and embeds that expand after loading
• Late-loading fonts that change text wrapping
• Promotional banners inserted above existing content
• Dynamically injected recommendations

CLS is a unitless score, not a time measurement. It considers how much of the viewport is affected and how far elements move, using the highest-scoring session window of layout shifts.

Not every movement counts. For example, shifts shortly after certain user inputs are generally excluded. However, delayed updates can still count, so reserving space remains important.

Why Core Web Vitals Matter

Core Web Vitals provide a measurable way to identify friction that visual reviews can miss.

They Support Better Usability

Visitors should not need to wait for a menu to respond or chase a moving button.

Improving performance can make essential journeys easier, including:

• Navigating between services
• Comparing products
• Completing forms
• Adding items to a cart
• Moving through checkout

The business impact depends on your audience and website. Measure conversion rate, form completion and revenue alongside performance rather than assuming every technical improvement produces the same result.

They Are Used By Google’s Ranking Systems

Google confirms that Core Web Vitals are used by its ranking systems.

However, passing the assessment does not guarantee higher rankings. Relevant content, search intent and other signals still matter.

A technically fast page that fails to answer the searcher’s question is not a strong SEO asset.

Treat Core Web Vitals as part of technical SEO and user experience—not as a substitute for useful content.

They Do Not Measure The Entire User Experience

A passing page can still have confusing navigation, inaccessible forms or intrusive overlays.

Core Web Vitals do not directly assess every aspect of:

• Accessibility
• Content quality
• Mobile usability
• HTTPS implementation
• Intrusive interstitials
• Navigation clarity

These require separate checks.

How To Check Your Core Web Vitals

Use field data to understand real-user performance and lab tools to investigate what causes problems.

1. Start With Google Search Console

The Core Web Vitals report in Search Console provides a site-level view, with separate mobile and desktop reports.

It groups URLs with similar performance characteristics, helping you identify shared issues.

To begin:

1. Open your verified Search Console property.
2. Select Core Web Vitals.
3. Review the mobile and desktop reports.
4. Open an issue group.
5. Examine the example URLs and identify their shared templates or components.

If hundreds of product pages have poor LCP, investigate the product template before optimizing each page individually.

Search Console depends on sufficient real-user data. Missing URLs do not necessarily indicate good performance.

2. Analyze Representative Pages With PageSpeed Insights

PageSpeed Insights combines two types of information:

Data Type	What It Shows	Best Use
Field data	Aggregated experiences from eligible Chrome users	Assessing real-world Core Web Vitals
Lab data	A controlled Lighthouse test	Diagnosing loading and rendering problems

The field section typically reflects a rolling 28-day period from the Chrome User Experience Report, or CrUX.

Check whether the report displays data for the specific URL or the broader origin. Origin-level results describe the site more broadly and should not be mistaken for measurements of that individual page.

If insufficient field data is available, use lab testing and your own real-user monitoring. “No data” is not a pass or a failure.

3. Investigate With Chrome DevTools

Chrome DevTools helps developers examine:

• Network request timing
• The LCP element
• Long JavaScript tasks
• Slow interactions
• Layout shifts
• Rendering bottlenecks

Record realistic journeys rather than testing only the initial load. Open menus, use filters, type into forms and interact with consent banners.

A basic Lighthouse navigation test does not reproduce a full visit’s INP. Total Blocking Time can help identify responsiveness risks, but it is not a replacement for INP.

4. Add Real-User Monitoring

For more detailed diagnosis, collect performance data using a real-user monitoring platform or Google’s web-vitals library.

Segment results by meaningful dimensions such as:

• Page template
• Device category
• Browser
• Geographic region
• Application release

Avoid collecting personal information in URLs or interaction labels, and apply appropriate privacy and consent controls.

How To Improve Core Web Vitals: 8 Practical Fixes

The right fix depends on the failing metric and its root cause. Start with evidence rather than applying every optimization setting at once.

1. Improve Server Response Time

Primary impact: LCP

The browser cannot render the main content until it receives the necessary HTML.

If the initial response is slow:

• Review hosting capacity and server configuration.
• Cache public pages where appropriate.
• Optimize slow database queries.
• Remove unnecessary redirects.
• Use a CDN to reduce delivery latency.
• Investigate expensive plugins, middleware and backend requests.

Time to First Byte is not a Core Web Vital, but it helps explain why LCP may be slow.

Caching requires care on personalized websites. Account pages, carts and checkout flows should not accidentally serve one visitor’s information to another.

2. Optimize And Prioritize The LCP Element

Primary impact: LCP

Identify the LCP element before changing image settings.

If it is an image:

• Resize it to suit its rendered dimensions.
• Compress it without unacceptable quality loss.
• Evaluate formats such as AVIF or WebP.
• Use responsive image markup.
• Make it discoverable early in the HTML.
• Avoid lazy-loading it.
• Consider fetchpriority="high" when appropriate.

For example:

<img
  src="/images/hero-1280.webp"
  srcset="
    /images/hero-640.webp 640w,
    /images/hero-1280.webp 1280w
  "
  sizes="100vw"
  width="1280"
  height="720"
  fetchpriority="high"
  alt="A project team reviewing a website design"
>

Adapt sizes to the actual layout. The dimensions help the browser reserve space, while CSS can keep the image responsive.

Lazy-load below-the-fold images, not the image visitors need to see immediately.

For deeper diagnosis, break LCP into server response time, resource discovery delay, download duration and rendering delay. A smaller image will not solve a long delay caused by JavaScript hiding it.

3. Reduce Render-Blocking CSS And Unnecessary JavaScript

Primary impact: LCP and INP

Large stylesheets and scripts can delay both content rendering and interaction processing.

Useful changes include:

• Removing unused CSS and JavaScript
• Loading assets only on pages that need them
• Splitting code by route or feature
• Deferring noncritical scripts where safe
• Minifying production assets
• Applying Brotli or gzip compression
• Reducing dependence on large libraries

Do not automatically combine everything into one file. With modern delivery protocols, oversized bundles can force visitors to download code they do not need.

Also test script dependencies carefully. Deferring a file may break navigation, forms or tracking if related code executes in the wrong order.

4. Break Up Long Tasks And Simplify Interactions

Primary impact: INP

The browser’s main thread handles JavaScript execution and much of the work required to update the page.

Long tasks can prevent it from responding promptly.

Developers can improve responsiveness by:

• Breaking large operations into smaller tasks
• Yielding to the browser between nonessential work
• Moving suitable computation into Web Workers
• Simplifying event handlers
• Avoiding repeated synchronous layout calculations
• Reducing unnecessary component re-renders
• Limiting excessive DOM complexity

Show useful visual feedback promptly. For example, a filter can immediately display its selected state while updated results load.

However, do not confuse responsiveness with completion time: INP measures the delay to the next paint, not the total time needed to finish a network request.

5. Audit Third-Party Scripts

Primary impact: INP and LCP

Chat widgets, analytics, advertising tags, review tools and personalization software can compete for network and processing resources.

Create a script inventory that records:

Audit Question	Decision It Supports
Who owns this tool?	Identify someone accountable for its use
Is it still needed?	Remove abandoned integrations
Does it belong on every page?	Restrict loading to relevant templates
When must it load?	Separate essential from noncritical functionality
Does it duplicate another tool?	Reduce redundant code and requests

Do not delay everything until the first click without testing. That approach can make an initial loading test look better while triggering heavy processing exactly when someone interacts.

Protect consent behavior and essential measurement when adjusting tag-loading rules.

6. Reserve Space For Images, Ads And Dynamic Content

Primary impact: CLS

The browser needs to know where content will fit before it finishes loading.

To reduce unexpected movement:

• Add image width and height attributes.
• Define aspect ratios for videos and embeds.
• Reserve responsive space for advertising slots.
• Give loading placeholders dimensions that match the final content.
• Avoid inserting banners above content after visitors start reading.
• Keep empty slots stable when collapsing them would move surrounding content.

For a video container, a starting point is:

.video-container {
  aspect-ratio: 16 / 9;
  width: 100%;
}

Test multiple viewport sizes. A banner that fits on one line on desktop may wrap onto three lines on mobile.

The element that moves is not always the root cause. A heading may shift because an image or banner above it expands.

7. Streamline Font Loading

Primary impact: LCP and CLS

Fonts can delay visible text or alter its dimensions after the first render.

To improve font performance:

• Remove unused families, weights and styles.
• Use modern font formats such as WOFF2.
• Subset fonts where appropriate.
• Preload only essential font files.
• Choose fallback fonts with similar dimensions.
• Evaluate font metric overrides to reduce layout changes.

font-display: swap can make text visible sooner, but it does not automatically eliminate CLS. The replacement font may still change line breaks and element heights.

There is no universal “safe” number of font variants. File size, character coverage and loading behavior matter more than an arbitrary count.

8. Reduce The Initial Cost Of Video And Embeds

Primary impact: LCP, INP and CLS

Third-party video hosting can simplify delivery, but embedded players may still load substantial JavaScript.

For nonessential videos:

• Show a lightweight poster image first.
• Load the full player when the visitor requests playback.
• Lazy-load below-the-fold embeds.
• Reserve the player’s dimensions.
• Avoid unnecessary autoplay.
• Provide accessible playback controls.

For decorative hero videos, consider whether a static image provides similar visual value at a lower performance cost.

Third-party hosting is not automatically faster. Measure the player’s impact rather than assuming the provider handles every performance concern.

Which Core Web Vitals Issues Should You Fix First?

Prioritize work based on business importance, affected traffic, severity and the reach of the fix.

Problem	First Investigation	Likely Priority
Slow product images across the catalog	Shared image delivery and product template	High
Unresponsive mobile navigation	Menu handlers and long tasks	High
Shifting checkout controls	Dynamic messages and missing reserved space	High
Poor performance on one low-traffic archive page	Page-specific assets	Usually lower
Slow rendering across all templates	Server response and global assets	High

Build a baseline for representative pages before making changes. Include your homepage, key service pages, campaign landing pages, product pages and important conversion flows.

Then:

1. Identify the failing metric.
2. Reproduce the problem.
3. Confirm its root cause.
4. Make a targeted change.
5. Retest performance and functionality.
6. Monitor production results.

Template-level fixes often offer more value than isolated page edits.

How To Validate Your Improvements

Lab results can improve immediately after deployment. Field data takes longer to reflect changes.

Because CrUX uses a rolling 28-day window, early results contain a mix of visits from before and after the release.

After deploying a fix:

• Repeat lab tests under comparable conditions.
• Test key journeys on mobile and desktop.
• Check forms, navigation, consent tools and checkout.
• Monitor real-user measurements.
• Use Search Console’s validation process when applicable.
• Compare business outcomes over an appropriate period.

Record deployment dates so you can connect performance changes to specific releases.

Once performance is healthy, establish budgets for image weight, JavaScript and third-party tools. Ongoing checks help prevent new campaigns or integrations from undoing earlier improvements.

Build A Faster Website Around Real User Needs

Core Web Vitals turn three common frustrations into measurable targets: slow loading, delayed responses and unexpected movement.

The most effective approach is to identify the failing metric, diagnose its cause and fix the components that affect your most important pages. Validate the result with real-user data and business outcomes—not just a single test score.

Digital Silk helps brands approach website performance as part of a broader design and development strategy, connecting technical improvements with usability and conversion goals.

Need a faster, more usable website? Connect with Digital Silk to discuss your website’s performance and growth priorities.