INP replaced FID as a Core Web Vital on 12 March 2024. In 2026, the three metrics remain LCP, INP and CLS. INP assesses responsiveness throughout a visit rather than just the delay before the first interaction. That changes which problems you need to investigate.
Google evaluates good field values at the 75th percentile, separately for mobile and desktop: LCP at most 2.5 seconds, INP at most 200 milliseconds and CLS at most 0.1. A Lighthouse lab run cannot replace that assessment. Good values help the user experience; rankings, enquiries or sales are not guaranteed.
LCP (Largest Contentful Paint): Perceived Load Speed#
LCP measures how long it takes for the largest visible element in the viewport to be fully rendered. Typically, this is a hero image, a video poster, or a large text block. Google expects an LCP value under 2.5 seconds.
Most Common LCP Issues#
- Uncompressed images: A hero image at 2.4 MB instead of 180 KB as WebP
- Render-blocking CSS/JS: Stylesheets and scripts that delay rendering
- Slow server response times (TTFB): Database queries taking 800ms+
- Missing preload hints: The browser discovers the LCP element too late
Optimization Strategy#
Image Optimization:
- WebP or AVIF as the standard format (30-50% smaller than JPEG)
- Responsive
srcsetwith defined breakpoints: 640w, 768w, 1024w, 1280w, 1920w loading="eager"andfetchpriority="high"for the LCP element<link rel="preload" as="image">in the head for the hero image
Server-Side:
- Static Generation (SSG) where possible. Pre-rendered HTML can reduce server work per request
- CDN caching with stale-while-revalidate headers
- Edge Functions for personalized content without backend round-trips
- TTFB under 200ms as a target
INP (Interaction to Next Paint): The New King Metric#
INP measures a page's responsiveness across all user interactions. Clicks, taps, keyboard inputs. Unlike FID, which only evaluated the first interaction, INP captures one of the slowest interactions during the entire page visit. Google expects an INP value at most 200 milliseconds.
With many interactions, INP ignores some outliers: one slowest interaction is excluded for every 50 interactions. Scrolling and hovering do not count as INP interactions, though their handlers can occupy the main thread.
Why INP Is More Demanding Than FID#
FID was relatively easy to optimize because only the first click counted. INP is stricter: if a user clicks a button after 30 seconds and the main thread is blocked by a heavy JavaScript bundle, that degrades the INP score for the entire page.
Optimization Strategy#
JavaScript Optimization:
- Code Splitting: Load only the JavaScript code needed for the current page. With Next.js, this happens automatically per route
- Dynamic Imports: Load heavy libraries (map views, charts, editors) only on demand
- Web Workers: Offload computation-intensive tasks from the main thread
- Debouncing and Throttling: Limit scroll and resize handlers
Rendering Optimization:
content-visibility: autofor off-screen sections- CSS Containment (
contain: layout style paint) for isolated components - Virtualization for long lists (react-window, @tanstack/virtual)
requestAnimationFrameinstead ofsetTimeoutfor visual updates
Third-Party Scripts:
- Load analytics and tracking asynchronously or defer them
- Check consent management platforms for performance impact (some block the main thread for 300ms+)
- Keep tag managers lean. Additional tags can affect responsiveness
CLS (Cumulative Layout Shift): Visual Stability#
CLS measures how much visible elements shift during loading. Nothing frustrates users more than a button that jumps away at the last moment. Google expects a CLS value under 0.1.
Most Common CLS Culprits#
- Images without dimensions: The browser does not reserve space until the image loads
- Dynamically injected ad banners: Push content downward
- Web fonts: Font swap (FOUT/FOIT) shifts text blocks
- Dynamic content: Cookie banners, chat widgets, notification bars
Optimization Strategy#
Layout Reservation:
widthandheightattributes on all<img>and<video>elementsaspect-ratioin CSS as a fallback- Skeleton screens for dynamic content (placeholders in the exact size of the final element)
Font Loading:
font-display: optional: The browser decides whether to show the web font based on timing and connection. Check the fallback font and potential layout shifts.- Preload font files with
<link rel="preload"> - Use subset fonts (embed only required characters)
- Variable fonts instead of multiple font files
Dynamic Elements:
- Cookie consent banners with
position: fixedinstead of flow layout - Ads with reserved min-height
- Chat widgets as overlays, not part of the document flow
Measure improvements consistently#
Record the URL, date, device, connection and tool for each measurement. Compare field values over matching time windows. A normal Lighthouse load test does not provide INP for an entire visit; use real interactions, CrUX field data or your own RUM. Document changes separately where practical. A higher score alone does not establish a revenue or ranking effect.
SSR vs. Static Generation: Choosing the Right Rendering Strategy#
The rendering strategy has a massive impact on Core Web Vitals:
- Static Site Generation (SSG): Pages are generated at build time. Can speed up delivery; LCP also depends on images, CSS, the network and device. Ideal for landing pages, blog posts, product catalogs
- Server-Side Rendering (SSR): Pages are generated per request. More flexible but slower TTFB. Necessary for personalized or highly dynamic content
- Incremental Static Regeneration (ISR): Combination of both. Static pages that update in the background. Best compromise for most websites
Recommendation: Use SSG as the default and SSR only where truly necessary. Every page that can be served as static HTML can reduce server work; measure the actual effect on LCP.
CDN Configuration: Optimizing the Last Mile#
A misconfigured CDN can nullify all optimizations. These settings are critical:
- Cache-Control Headers:
public, max-age=31536000, immutablefor static assets - Stale-While-Revalidate: Serves cached version while updating in the background
- Brotli Compression: 15-20% smaller than Gzip, supported by all modern browsers
- HTTP/3: Reduces latency through the QUIC protocol
- Edge Computing: Execute compute-intensive tasks closer to the user
Conclusion: Performance Is Not a Project but a Process#
Core Web Vitals optimization is not a one-time task. Every new feature, every plugin, every third-party integration can degrade scores. Build performance monitoring into your development process:
- Lighthouse CI in the build pipeline (blocks deployments on score regression)
- Real User Monitoring (RUM) using your own user interactions; use CrUX as an additional aggregated field source
- Weekly performance reviews within the team
Measure regularly which changes actually help visitors. Compare enquiries and completed actions as well, rather than treating a better lab result as automatic business success.
