Hosting services with real-time fast performance?
LCP vs INP vs CLS: Understanding Core Web Vitals
A website can look fast yet still feel slow to visitors. It may also respond poorly or move content without warning. These problems affect different parts of the user experience. Therefore, website performance needs more than one measurement.
Google uses three Core Web Vitals to assess key aspects of page experience. These metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). LCP focuses on loading performance. INP measures how quickly a page responds to interactions. CLS measures visual stability during the page experience. Each metric answers a different performance question. Together, they help developers understand how real users experience a website. Understanding LCP vs INP vs CLS also makes optimisation more practical. Each problem needs a different technical solution.
What Are Core Web Vitals?
Core Web Vitals are user-focused metrics for measuring important aspects of web performance. The current set contains LCP, INP, and CLS. They cover loading, responsiveness, and visual stability. Google evaluates these metrics using real-world user data. Site owners should aim for good results at the 75th percentile.
This means most page visits should meet the recommended thresholds. Results can also differ between mobile and desktop users. Core Web Vitals do not measure every aspect of a website. They also do not guarantee strong search rankings. Google considers many signals when assessing search results. Therefore, performance should support useful content rather than replace it.
LCP: Largest Contentful Paint
LCP measures how quickly the main content becomes visible. It therefore focuses on the loading stage of the user experience.
What LCP Measures
LCP measures the render time of the largest qualifying content element within the viewport. The measurement starts when the user begins loading the page. It then records when the largest visible image, text block, or video renders. A lower LCP generally means users can see important content sooner. However, the metric does not measure every part of page loading.
What Counts as LCP
The browser identifies the largest qualifying element visible in the viewport. This element can be a large image or video poster. It can also be a substantial text block. The LCP element can change while the page loads. Therefore, developers should identify the final LCP element before optimising it.
For example, a hero image may become the LCP element on one page. A large heading may become the LCP element on another.
LCP Performance Thresholds
Google recommends an LCP of 2.5 seconds or less for a good experience. A result above 2.5 seconds needs improvement. A result above 4 seconds falls into the poor range. Teams should assess LCP at the 75th percentile. They should also separate mobile and desktop results.
Common LCP Problems
Slow server responses can delay the entire loading process. High Time to First Byte can therefore hurt LCP. Large images can also take longer to download. Render-blocking CSS and JavaScript can delay the main content. Multiple redirects can add extra network time. Poor caching can create further delays. Client-side rendering can also postpone important content. Third-party resources may add additional network or processing work.
How to Improve LCP
Start by improving server response time. Use effective caching and suitable hosting infrastructure. Next, optimise the resource that becomes the LCP element. Compress large images and use efficient formats. Avoid loading unnecessarily large assets. Also, make important resources available to the browser as early as possible. Reduce render-blocking CSS and JavaScript. Remove unnecessary redirects where possible. Google recommends examining TTFB, resource loading delays, resource duration, and rendering delays when diagnosing LCP.
INP: Interaction to Next Paint
INP focuses on responsiveness after users interact with a page. It replaced First Input Delay as a Core Web Vital in March 2024.
What INP Measures
INP measures how quickly the page responds to user interactions. These interactions can include clicks, taps, and keyboard actions. The metric considers the delay before the browser presents the resulting visual update. Therefore, INP reflects responsiveness throughout the visit. It does not focus only on the first interaction.
How INP Is Calculated
INP observes qualifying interactions during a page visit. An interaction can involve three stages. These include input delay, processing time, and presentation delay. The metric considers the interaction with the longest response time after accounting for certain outliers. This approach can expose responsiveness problems that a first-interaction metric could miss.
For example, a page may respond quickly to its first click. Later interactions may trigger heavy JavaScript and produce much slower responses.
INP Performance Thresholds
A good INP is 200 milliseconds or less. A result above 200 milliseconds needs improvement. A result above 500 milliseconds is poor. Developers should assess INP at the 75th percentile. They should also compare mobile and desktop performance.
Common INP Problems
Long JavaScript tasks often create poor INP. Heavy scripts can occupy the browser’s main thread. The browser then has less opportunity to process user interactions. Large JavaScript bundles can create similar delays. Complex event handlers can also require excessive processing. Third-party scripts may compete for main-thread resources. Expensive rendering work can further delay visual feedback.
How to Improve INP
Begin by identifying long tasks on the main thread. Break large tasks into smaller pieces. This allows the browser to process interactions sooner. Remove unused JavaScript where possible. Also, defer non-essential scripts until they become necessary. Keep interaction handlers efficient. Avoid expensive calculations during user actions. Review third-party scripts as well. Remove unnecessary services and limit scripts that provide little value.
The goal is not simply to reduce JavaScript. The goal is to give the browser enough time to respond to users.
CLS: Cumulative Layout Shift
CLS measures visual stability rather than loading speed or interaction response. It identifies unexpected movement of visible content during the page experience.
What CLS Measures
CLS measures unexpected layout shifts that affect visible page content. A shift occurs when an element changes position without the user expecting it. For example, a visitor may begin reading a paragraph. An image can then load above it and push the paragraph downward. This movement can interrupt reading. It can also cause visitors to click the wrong element.
How CLS Is Calculated
CLS uses individual layout shift scores to measure unexpected movement. Modern CLS uses session windows instead of adding every shift across the entire page lifetime. A session window contains shifts that occur close together. The largest window determines the page’s CLS result. A session window can contain shifts with less than one second between them. Its total duration cannot exceed five seconds. This method focuses more closely on bursts of disruptive movement.
CLS Performance Thresholds
A CLS score of 0.1 or less represents good visual stability. A score above 0.1 needs improvement. A score above 0.25 is considered poor. As with LCP and INP, teams should evaluate CLS at the 75th percentile.
Common CLS Problems
Images without defined dimensions can cause layout movement. Ads and embedded content can create similar problems. Their dimensions may remain unknown until they load. Dynamically inserted content can also push existing elements downward. Web fonts can cause movement when fallback and final fonts have different dimensions. Animations can contribute to instability when they change layout properties.
How to Improve CLS
Set dimensions for images and videos before they load. Reserve space for advertisements, embeds, and other dynamic content. Avoid inserting content above existing content unless users expect that change. Use appropriate font-loading strategies. Also, avoid animations that repeatedly change layout dimensions. CSS transforms can often animate elements without triggering layout changes. These techniques help keep important content in a predictable position.
LCP vs INP vs CLS: Key Differences
The main difference lies in what part of the experience each metric evaluates. LCP evaluates the loading stage. It focuses on when the main visible content appears. INP evaluates interaction performance. It focuses on how quickly the page responds after user actions. CLS evaluates visual stability. It focuses on whether visible content moves unexpectedly. The metrics also use different units. LCP uses seconds, while INP uses milliseconds. CLS uses a unitless score. Their causes also differ. LCP often involves network, server, resource, or rendering delays. INP commonly involves JavaScript and main-thread work. CLS often involves missing dimensions or dynamically changing layouts.
Therefore, a single optimisation cannot reliably improve all three metrics.
LCP vs INP vs CLS: Comparison Table
| Metric | Primary Stage | User Experience Area | Unit | Good Score |
|---|---|---|---|---|
| LCP | Loading | Perceived loading | Seconds | ≤ 2.5 s |
| INP | Interaction | Responsiveness | Milliseconds | ≤ 200 ms |
| CLS | Page lifetime | Visual stability | Score | ≤ 0.1 |
These thresholds represent the current Google recommendations for good Core Web Vitals performance. Teams should assess them at the 75th percentile.
How the Three Core Web Vitals Complement Each Other
A website can perform well in one metric while failing another. For example, a page may display its main content quickly. However, heavy JavaScript can still make interactions feel slow. Another page may respond quickly to clicks. Yet advertisements can shift its content while the page loads.
These examples show why one metric cannot describe the complete experience. LCP helps establish a strong loading experience. INP supports responsive interaction after loading begins. CLS then helps maintain a stable interface as content continues to appear. Together, the three metrics cover different stages of real-world page use. This makes them more useful as a group than as isolated scores.
Measuring Core Web Vitals
PageSpeed Insights
PageSpeed Insights provides performance information for individual URLs. It can show field data when sufficient real-user data exists. It also provides laboratory testing through Lighthouse. This combination helps teams compare real-world performance with controlled testing conditions.
Google Search Console
Google Search Console provides a Core Web Vitals report for eligible websites. The report groups URLs based on their performance. It can therefore help site owners identify groups that need attention. Search Console is especially useful when a site contains many pages with similar templates.
Chrome DevTools
Chrome DevTools helps developers investigate technical causes. Teams can inspect network requests, JavaScript activity, rendering behaviour, and layout changes. This makes DevTools useful after a performance tool identifies a problem.
Real User Monitoring
Real User Monitoring collects performance information from actual visitors. Field data captures differences in devices, browsers, networks, locations, and usage patterns. This information can reveal problems that controlled laboratory tests may miss. Google’s Core Web Vitals guidance recommends using real-world measurements when assessing the experience of actual users.
Prioritizing Core Web Vitals Improvements
Do not start by changing everything at once. First, identify which metric fails and determine the underlying cause. For poor LCP, examine server response, resource loading, and rendering delays. For poor INP, investigate long JavaScript tasks and expensive interaction processing. For poor CLS, identify which elements move and why they lack stable space. Next, prioritise issues that affect many users. Consider mobile performance separately because mobile devices can have different processing and network conditions.
After each major change, test the affected pages again. Field data should remain important because laboratory results cannot represent every visitor.
Core Web Vitals and Google Search
Core Web Vitals form part of Google’s page experience considerations. Google recommends achieving good Core Web Vitals for Search success and a better user experience. However, good scores do not guarantee top search rankings. Google’s ranking systems consider many signals. Content relevance and usefulness remain essential. Therefore, businesses should not remove valuable content simply to achieve a perfect performance score.
Instead, performance improvements should support the overall quality of the page. A technically fast website still needs useful information. Likewise, strong content should not ignore serious performance problems. The best approach combines useful content, accessibility, security, mobile usability, and strong Core Web Vitals.
Conclusion
The difference between LCP, INP, and CLS becomes clear when each metric has a specific role. LCP measures how quickly the main content appears. INP measures responsiveness after user interactions. CLS measures whether visible content remains stable during the page experience. Each metric therefore identifies a different type of performance problem. A slow LCP may require better resource delivery. A poor INP may require JavaScript optimisation. A high CLS may require stronger layout planning and reserved space for dynamic elements.
For that reason, website owners should monitor all three metrics together. Use PageSpeed Insights and Search Console to identify problems. Then use tools such as Chrome DevTools to investigate their technical causes. Most importantly, optimise for real users rather than chasing scores alone. Good Core Web Vitals can support a faster, more responsive, and more stable website. They work best as part of a broader strategy focused on useful content and a strong overall page experience.
