Core Web Vitals: LCP, INP & CLS Optimization

Core Web Vitals measure three important parts of real user experience: loading, responsiveness and visual stability.

The current Core Web Vitals are:

• Largest Contentful Paint (LCP) — loading performance.
• Interaction to Next Paint (INP) — responsiveness to user interaction.
• Cumulative Layout Shift (CLS) — visual stability.

Google evaluates Core Web Vitals at the 75th percentile of page visits, segmented by mobile and desktop where appropriate. A good classification means at least 75% of measured visits are at or better than the published threshold for that metric.

Last verified: September 26, 2026. Core Web Vitals definitions, browser APIs and tooling can evolve, so major changes should be rechecked against current Google/web.dev documentation.

---

---

1. Core Web Vitals Thresholds

Use the 75th percentile rather than optimizing for one ideal lab run.

These are user-experience thresholds, not resource budgets. JavaScript size, image weight, CSS size, request count and TTFB need separate project-specific guardrails.

---

2. Field Data vs Lab Data

Field data

Field data reflects actual users, including slower devices, real networks, geographic differences and varied interaction patterns.

Common sources include:

• Chrome User Experience Report (CrUX).
• PageSpeed Insights field data where available.
• Search Console Core Web Vitals reports.
• Real User Monitoring (RUM).

Lab data

Lab tools are useful for debugging specific templates and reproducing problems under controlled conditions.

Common tools include:

• Lighthouse.
• Chrome DevTools.
• WebPageTest.
• Performance panel traces.

A page can pass a lab run and still fail field data if real users encounter slower devices, networks or interactions.

Understand CrUX's 28-Day View

PageSpeed Insights and other CrUX-based tools generally summarize the previous 28 days of eligible Chrome user experience at the 75th percentile. A specific URL may not have enough data; in that case an origin-level view can appear instead, or field data may be unavailable.

Search Console Groups Similar URLs

Search Console's Core Web Vitals report uses CrUX field data but groups similar pages. A failing group is useful for finding affected templates, but one example URL does not necessarily explain the exact code-level cause for every URL in that group.

For detailed diagnosis, use PageSpeed Insights on representative URLs, then reproduce the problem in DevTools. If the site has enough traffic and engineering capacity, site-owned RUM provides the most granular field evidence.

---

3. What Does LCP Measure?

LCP reports the render time of the largest eligible image, text block or video element visible in the viewport, relative to when navigation began.

Typical LCP elements include:

• Hero images.
• Large headings or text blocks.
• Featured images.
• Background images in eligible cases.
• Video poster frames.

The target is 2.5 seconds or less at the 75th percentile.

For deeper LCP diagnosis, use the dedicated Largest Contentful Paint (LCP) guide. It owns LCP element identification, TTFB/resource-load/render-delay subparts, hero-image priority and text-based LCP diagnosis.

---

4. Break LCP Into Subparts

A useful LCP diagnostic model is:

Navigation
   ↓
TTFB
   ↓
Resource Load Delay
   ↓
Resource Load Duration
   ↓
Element Render Delay
   ↓
LCP

This pillar keeps the model at overview level. The dedicated LCP guide linked above owns the full workflow for element identification, discovery timing, fetchpriority, preload, image transfer and post-download render delay.

Chrome's current LCP breakdown insight presents the same four phases directly in the Performance panel. Use the largest delay phase as the starting point instead of assuming image compression is always the main problem.

If the dominant problem is specifically initial document response, use the TTFB Optimization Guide.

---

5. How to Improve LCP

Common LCP improvements include:

• Reduce excessive TTFB.
• Preload the LCP image when appropriate.
• Do not lazy-load the above-the-fold LCP image.
• Use responsive image dimensions.
• Compress images efficiently.
• Serve modern image formats where practical.
• Reduce render-blocking CSS.
• Keep critical assets discoverable in initial HTML.
• Reduce unnecessary client-side rendering before the LCP element appears.

If the problem is image delivery, responsive sources, WebP/AVIF format choice or lazy-loading behavior, use the Image Optimization Guide. If CSS or JavaScript is delaying first paint, use the Render-Blocking Resources Guide. If stylesheet architecture or unused CSS is specifically responsible, use the CSS Performance Guide. If style/layout/paint remains expensive after the resource is available, use the DOM Size & Rendering Performance Guide.

---

6. LCP Images: Common Mistakes

• Lazy-loading the hero image: delays discovery/download.
• Oversized source files: waste bandwidth.
• CSS-only discovery: can delay resource discovery.
• Huge JavaScript dependency: may delay rendering.
• Missing responsive sources: mobile devices may download unnecessarily large files.

---

7. What Does INP Measure?

INP measures responsiveness across qualifying user interactions over the lifetime of the page visit. The final value represents the page's high-latency interaction experience, with the metric allowed to discount outliers on pages with many interactions.

It considers interaction latency for events such as:

• Mouse clicks.
• Touch interactions.
• Keyboard input.

The good threshold is 200 milliseconds or less at the 75th percentile.

For interaction-level debugging, long-task analysis and responsiveness tuning, continue with the dedicated INP optimization guide.

For diagnosis, break one slow interaction into input delay, processing duration and presentation delay. Chrome's current INP breakdown insight exposes these phases directly when a qualifying interaction is captured in the Performance panel.

---

8. Why INP Becomes Slow

Common causes include:

• Long JavaScript tasks.
• Large event handlers.
• Excessive DOM work.
• Layout recalculation.
• Rendering large UI updates.
• Third-party scripts.
• Main-thread contention.

INP is primarily a responsiveness metric. Buying faster hosting alone will not fix heavy main-thread JavaScript.

For deeper frontend diagnosis, use the JavaScript Performance Optimization Guide for long tasks, script loading and event work; the DOM Size & Rendering Performance Guide for excessive document complexity; and the Third-Party Script Performance Guide for ads, analytics, chat and external JavaScript.

---

9. How to Improve INP

• Break long tasks into smaller work units.
• Reduce unnecessary JavaScript.
• Defer non-critical third-party scripts.
• Avoid expensive synchronous work inside event handlers.
• Minimize DOM size and large rendering updates.
• Provide fast visual feedback.
• Profile real slow interactions rather than optimizing only startup JavaScript.

---

10. Total Blocking Time Is Not INP

Lighthouse commonly reports Total Blocking Time (TBT), which is a lab metric.

TBT can help identify main-thread blocking during page load, but it is not the same as INP. A normal Lighthouse page-load audit has no real user interaction, so Lighthouse reports TBT rather than field INP.

INP is a field metric based on real interactions over the lifetime of the visit. Use DevTools interaction traces to reproduce specific problems in the lab, then use field/RUM data to validate the real-user outcome.

---

11. What Does CLS Measure?

CLS measures the largest burst of unexpected layout-shift scores during the page lifecycle, not simply every pixel of movement added together forever.

Common causes include:

• Images without dimensions.
• Ads or embeds inserted without reserved space.
• Late-loading fonts.
• Banners injected above existing content.
• Dynamic UI elements that push content.

The good threshold is 0.1 or less.

CLS uses session windows: shifts occurring less than 1 second apart are grouped, and each window is capped at 5 seconds. The metric reports the largest such window. Expected shifts closely tied to a recent user interaction can be excluded, which is why debugging should focus on unexpected movement.

For deeper layout-shift tracing, unstable element diagnosis, image/embed space reservation and font-related shifts, continue with the dedicated CLS Optimization Guide.

---

12. How to Improve CLS

• Add width and height attributes or CSS aspect ratios to images/video.
• Reserve space for ads and embeds.
• Avoid inserting new content above existing content unless triggered by user action.
• Use font-loading strategies that reduce geometry changes.
• Prefer transforms/animations that do not trigger layout shifts.

If web-font loading or font swaps contribute to layout instability or delay visible text, use the Web Font Performance Optimization Guide.

Chrome's current Layout shift culprits insight can highlight likely causes such as unsized media, injected iframes, non-composited animations and web-font changes. Confirm the suspected culprit in the Layout Shifts track before changing production code.

---

13. WordPress-Specific LCP Problems

Common WordPress causes include:

• Theme hero sliders.
• Page-builder CSS and JavaScript.
• Oversized featured images.
• Plugin-generated render-blocking assets.
• Slow uncached PHP requests.
• Too many third-party scripts.

Start by determining whether the delay is backend, resource-loading or rendering-related before replacing plugins or hosts.

If stylesheet size, unused rules or CSS delivery is the bottleneck, use the CSS Performance Optimization Guide rather than expanding this pillar into a full CSS tutorial.

---

14. WordPress-Specific INP Problems

Typical causes include:

• Page builders with large client-side bundles.
• Analytics/tag-manager overload.
• Chat widgets.
• Popup/marketing scripts.
• Complex product filters.
• Large DOM trees.

Use DevTools performance traces to find the actual interaction and main-thread task responsible.

---

15. WordPress-Specific CLS Problems

• Images missing dimensions.
• Cookie banners that push page content.
• Ad placements without reserved height.
• Web fonts changing text dimensions.
• Late-loading sticky headers.
• Dynamic blocks inserted above the viewport.

---

16. Caching and Core Web Vitals

Full-page caching can reduce backend work and TTFB, which may improve LCP when initial server response is a limiting factor.

But caching does not directly solve:

• Heavy JavaScript interactions.
• Layout instability.
• Oversized LCP images.
• Third-party scripts.

For asset reuse and browser revalidation, use the Browser Caching Guide. For transfer compression of HTML, CSS and JavaScript, use the Brotli & Gzip Compression Guide.

---

17. CDN and Core Web Vitals

A CDN can reduce latency for cacheable content and static assets, especially for geographically distributed users.

It may improve LCP by shortening asset delivery, but it will not automatically improve INP or CLS.

When adding or changing CDN/cache rules, avoid weakening security controls. Use the Website Security Checklist for HTTPS, origin protection, WAF, backup and access-control considerations.

---

18. PHP-FPM and Core Web Vitals

PHP-FPM tuning can matter when backend queueing or slow dynamic PHP execution is materially increasing initial response time.

It does not directly fix frontend INP or CLS.

If your self-managed VPS shows worker exhaustion or inefficient process configuration, use our PHP-FPM Tuning Guide.

---

19. When Hosting Is Actually the Problem

Consider the hosting platform as a likely bottleneck when measurements show issues such as:

• Persistent high TTFB after application optimization.
• Resource throttling.
• Insufficient PHP worker capacity.
• CPU or RAM limits under normal workload.
• Database resource constraints.
• Poor geographic fit for the audience.
• Missing caching capabilities required by the workload.

If the managed WordPress environment itself is the limiting factor, compare provider fit in our Best WordPress Hosting guide.

---

20. Do Core Web Vitals Directly Determine Rankings?

Do not reduce SEO to a formula such as:

Pass Core Web Vitals = Rank Higher

Google's current Search documentation states that Core Web Vitals are used by its ranking systems, but there is no single “page experience signal” and good Core Web Vitals results do not guarantee top rankings. Google's systems still prioritize relevance and helpful content, and page experience is evaluated alongside many other signals.

Optimize Core Web Vitals because better loading, responsiveness and stability help users and can contribute to Search success—not because one passing score guarantees a ranking position.

---

21. PageSpeed Insights vs Search Console

PageSpeed Insights

Useful for URL-level or origin-level CrUX field data when available, plus Lighthouse lab diagnostics. If URL-level CrUX data is unavailable, do not assume the origin-level field result represents that exact page.

Search Console

Useful for grouped Core Web Vitals status across similar URL patterns using CrUX field data, with separate mobile and desktop views.

Use both, but remember that Search Console groups similar URLs and does not identify the exact code-level cause. Move from the failing group to representative URLs, then into DevTools traces.

---

22. Lighthouse & Performance Insights: What They Can and Cannot Tell You

Lighthouse 13.x uses the newer Performance Insights model. Current diagnostics include LCP breakdown, LCP request discovery, INP breakdown, layout-shift culprits, render-blocking requests, third-party resources, DOM-size issues and cache-lifetime problems.

Lighthouse remains a synthetic lab tool. It can help reproduce load-time problems and highlight likely causes, but it cannot fully reproduce the devices, networks, sessions, interactions, ads, consent states and post-load behavior of real users.

For INP especially, a normal Lighthouse page-load run reports TBT instead of real INP. Use field data first, then use DevTools interaction traces and the current Insights sidebar to investigate the slow interaction.

---

23. Prevent Performance Regressions

Passing Core Web Vitals once does not mean a site will stay fast. New ads, analytics tags, plugins, fonts, images, theme changes and JavaScript can reintroduce regressions.

Use measurable limits for transfer size, JavaScript, CSS, image weight and selected runtime metrics, then review them during releases. Keep those lab/release budgets distinct from the field Core Web Vitals thresholds. The Web Performance Budgets & Regression Monitoring Guide covers that ongoing process.

---

24. A Practical Core Web Vitals Workflow

1. Check CrUX / RUM field data
        ↓
2. Identify failing metric + affected template
        ↓
3. Reproduce representative URL / interaction
        ↓
4. Use current DevTools Performance Insights
        ↓
5. Break the metric into its real cause
        ↓
6. Fix the highest-impact bottleneck
        ↓
7. Retest under the same lab conditions
        ↓
8. Monitor field data over the next reporting window

---

25. LCP Optimization Checklist

• Identify the actual LCP element.
• Check whether TTFB consumes too much of the budget.
• Do not lazy-load the LCP image.
• Compress and resize the LCP resource.
• Preload only when justified.
• Reduce render-blocking CSS.
• Keep the LCP resource discoverable early.

---

26. INP Optimization Checklist

• Find slow real interactions.
• Break the interaction into input delay, processing duration and presentation delay.
• Profile long tasks.
• Reduce event-handler work.
• Break up long JavaScript tasks.
• Reduce third-party script impact.
• Minimize unnecessary DOM updates.
• Provide immediate visual feedback where possible.

---

27. CLS Optimization Checklist

• Set image/video dimensions.
• Reserve ad/embed space.
• Review font swaps.
• Avoid inserting content above existing content.
• Test banners, sticky elements and consent interfaces.
• Check the largest CLS session window and post-load shifts, not just initial load.

---

28. Common Core Web Vitals Mistakes

• Optimizing Lighthouse score instead of the failing field metric.
• Treating TTFB as a Core Web Vital.
• Changing hosts before profiling the page.
• Lazy-loading the LCP image.
• Assuming minification fixes INP.
• Ignoring post-load layout shifts.
• Installing multiple optimization plugins that conflict.
• Claiming one plugin or CDN guarantees passing scores.
• Testing only desktop when mobile field data is failing.
• Reading origin-level CrUX as if it were exact URL-level data.
• Using one Lighthouse run as proof of field performance.
• Calling TBT the site's INP.
• Optimizing outdated Lighthouse audit names instead of the current Performance Insights workflow.
• Treating all layout movement as CLS without considering user-triggered exclusions/session windows.

---

29. Core Web Vitals Specialist Guide Map

LCP specialist: use the dedicated LCP guide for element identification, LCP subparts, hero-image priority, resource discovery and render-delay troubleshooting. This pillar intentionally stays at framework level.

---

30. Final Core Web Vitals Decision Framework

LCP Failing?
   ↓
Check TTFB → resource discovery → image/CSS → render delay

INP Failing?
   ↓
Profile interactions → long tasks → JS → DOM/render work

CLS Failing?
   ↓
Find shifting element → reserve space → stabilize fonts/layout

Hosting Change?
   ↓
Only after measurements show infrastructure is limiting

Good Core Web Vitals come from fixing the actual bottleneck, not from collecting optimization plugins or chasing one synthetic score.

---

Frequently Asked Questions

What are the current Core Web Vitals?

The current Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS).

What is a good LCP?

A good LCP is 2.5 seconds or less at the 75th percentile.

What is a good INP?

A good INP is 200 milliseconds or less at the 75th percentile.

What is a good CLS?

A good CLS is 0.1 or less at the 75th percentile.

Is TTFB a Core Web Vital?

No. TTFB is a useful diagnostic metric that can affect the loading timeline, especially LCP, but it is not one of the three Core Web Vitals.

Does passing Core Web Vitals guarantee higher rankings?

No. Google says Core Web Vitals are used by its ranking systems, but there is no single page-experience ranking signal and good CWV scores do not guarantee top positions.

How much history does PageSpeed Insights field data use?

CrUX-based field data in PageSpeed Insights generally summarizes the previous 28 days at the 75th percentile. A specific URL may not have enough eligible data, in which case origin-level data may be shown or field data may be unavailable.

Does Lighthouse measure INP?

Not as real field INP in a normal page-load audit. With no user interaction, Lighthouse reports Total Blocking Time as a lab responsiveness signal. Use DevTools interaction traces and field/RUM data for INP diagnosis and validation.

How is CLS grouped?

CLS reports the largest session window of unexpected layout shifts. Shifts less than one second apart are grouped, and each window is capped at five seconds.

Can hosting affect Core Web Vitals?

Yes, mainly when backend response time or resource limits delay content delivery. Hosting does not directly solve JavaScript-heavy INP or layout-instability problems.

Can a CDN fix Core Web Vitals?

A CDN can improve delivery of suitable content and may help LCP, but it does not automatically fix INP or CLS.

Should I trust Lighthouse or field data?

Use field data to understand real-user performance and Lighthouse as a controlled diagnostic tool. They serve different purposes.