Core Web Vitals are Google's three key metrics for user experience: Interaction to Next Paint (INP) measures responsiveness to clicks and inputs (threshold: 200 ms), Largest Contentful Paint (LCP) measures the loading time of the largest visible element (2.5 s), and Cumulative Layout Shift (CLS) measures visual stability (0.1). Since March 2024, INP has replaced the previous First Input Delay (FID). Google recommends good Core Web Vitals for user experience and as part of page experience in Search.
What Is INP and Why Is It More Important Than FID?
FID only measured the delay on the very first interaction a user had with the page. The problem: most performance issues occur later – when opening a menu, submitting a form, or filtering products. INP evaluates all interactions throughout the entire page visit and takes the worst value (excluding the bottom 2% of outliers) as the result.
The INP value consists of three phases: Input Delay (the time between the user interaction and the start of the event handlers), Processing Time (the execution of the event handlers themselves), and Presentation Delay (the time for rendering and compositing until the next frame). All three phases combined must stay under 200 milliseconds to be rated as good.
Optimizing INP: The Three Phases in Detail
The Input Delay phase is primarily caused by blocking tasks on the main thread. Long JavaScript tasks (over 50 ms) prevent the browser from responding to clicks or keyboard input. The solution: break up large scripts, defer third-party scripts, and split work into smaller units using requestIdleCallback or the Scheduler API.
The Processing phase concerns your event handlers directly. Efficient DOM manipulations, fewer reflows, and avoiding synchronous layout queries within event handlers all help here. Modern frameworks like Angular use Change Detection with OnPush to avoid unnecessary recalculations.
The Presentation phase depends on rendering complexity. Avoid complex CSS animations during interactions, use CSS containment, and reduce DOM size. Websites with over 1,500 DOM elements show measurably worse INP values.
- Input Delay: Keep JavaScript tasks under 50 ms, defer third-party scripts
- Processing: Keep event handlers lean, avoid synchronous layout queries
- Presentation: Reduce DOM size, use CSS containment, minimize rendering load
- General: Identify main thread bottlenecks using Chrome DevTools Performance tab
LCP Under 2.5 Seconds: Practical Tips
Largest Contentful Paint measures how quickly the largest visible element in the viewport loads – usually a hero image, a heading, or a video poster. Google's good threshold is 2.5 seconds at the 75th percentile of page loads.
The most common LCP killers on SME websites: uncompressed hero images (often 2–5 MB instead of 50–100 KB), missing preload hints for critical resources, render-blocking CSS from unused frameworks, and slow server response times (TTFB over 800 ms). Server-Side Rendering (SSR) solves the TTFB problem by generating HTML on the server.
- Convert hero images to WebP/AVIF and serve them responsively (srcset)
- Request LCP resource early with <link rel='preload'>
- Inline critical CSS, defer loading the rest
- Keep TTFB under 600 ms through caching, CDN, or SSR/SSG
- Use fetchpriority='high' only for the actual LCP element
CLS Under 0.1: Ensuring Visual Stability
Cumulative Layout Shift measures how much page elements shift during the loading process. A CLS value under 0.1 is considered good. Layout shifts are particularly frustrating for users: a click on a button suddenly hits the ad above it because an image loaded late and pushed the content down.
The most important measures: specify fixed dimensions for images and videos (width and height attributes or aspect-ratio in CSS), load web fonts with font-display: swap or optional, and place dynamic content like cookie banners or chat widgets in reserved areas. Third-party embeds like Google Maps or social media widgets inserted without a fixed height are especially problematic.
Measurement and Monitoring: Field vs. Lab Data
A crucial point is often overlooked: Google uses exclusively field data from the Chrome User Experience Report (CrUX) for rankings – not lab data from Lighthouse. A page can show perfect scores in Lighthouse tests and still have poor Core Web Vitals because real users access it with slower devices or unstable connections.
Check your field data regularly in Google Search Console under Core Web Vitals and in PageSpeed Insights in the Field Data section. For websites with low traffic (under 1,000 visitors per month), field data is often unavailable – in that case, you need to rely on lab tests and Real User Monitoring (RUM).
Conclusion: Core Web Vitals as a Competitive Advantage
Core Web Vitals are not a theoretical SEO topic but measurable user experience. With INP as the new focus, Google rewards websites that not only load fast but also respond fluidly to every interaction. For SME websites, this is an opportunity: while large portals with their complex JavaScript applications often fail at INP, lean, well-built business sites can excel here.
If you want to know how your website performs on current Core Web Vitals, a detailed look at the Core Web Vitals fundamentals provides the ideal starting point.
Primary sources: Google Search Central on Core Web Vitals and web.dev: Web Vitals .
