Page speed has evolved from a hygiene factor to a real ranking signal and a critical part of user experience. With Core Web Vitals, Google has given us three concrete metrics that capture the essence of how users perceive performance: how quickly content loads (LCP), how responsive interactions are (INP), and how visually stable the layout is (CLS). According to Google, only 43% of mobile websites pass all three Core Web Vitals thresholds (Chrome UX Report, 2025). That means the majority of websites have a concrete improvement opportunity that directly affects ranking, conversion, and user satisfaction. This guide gives you practical strategies for optimizing each vital.
What Core Web Vitals are: LCP, INP, and CLS
Core Web Vitals are three user-centric performance metrics defined by Google. Largest Contentful Paint (LCP) measures how long it takes for the largest visible content element in the viewport to finish rendering. Interaction to Next Paint (INP) measures responsiveness — the time from when a user clicks, taps, or presses a key until the browser visually responds. Cumulative Layout Shift (CLS) measures visual stability — how much content unexpectedly shifts during loading.
The thresholds are clear: LCP should be under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. Anything above these thresholds is rated as poor. "Needs improvement" is the middle tier: LCP between 2.5 and 4 seconds, INP between 200 and 500 milliseconds, and CLS between 0.1 and 0.25.
INP replaced First Input Delay (FID) as an official Core Web Vital in March 2024. The change was significant: FID only measured the delay of the first interaction, while INP measures all interactions throughout the entire page visit and reports the worst one (approximately). This means pages that passed the FID test can fail on INP, especially pages with heavy JavaScript interactions.
Why speed matters for SEO and user experience
Google confirmed in 2021 that Core Web Vitals are part of Page Experience ranking signals, and has since reaffirmed that this remains the case (Google Search Central, 2025). It is not the strongest ranking signal — content relevance and links carry more weight — but in competitive situations where content is similar, speed can tip the outcome.
But the real impact is on user experience and conversion. A study from Portent shows that websites loading in 1 second have 3x higher conversion rates than websites loading in 5 seconds (Portent, 2023). Google reports that 53% of mobile users abandon pages that take more than 3 seconds to load (Google, 2018). These numbers make speed optimization a direct revenue factor.
For SEO, poor speed also means lower crawl efficiency. Googlebot has a crawl budget for each website, and slow pages consume more of that budget. The result is that fewer pages get crawled and indexed, which is especially damaging for large websites with thousands of pages.
How to measure Core Web Vitals correctly
There are two types of performance data: field data (from real users) and lab data (from simulated tests). Google uses field data from the Chrome UX Report (CrUX) for ranking purposes. Lab data from Lighthouse is useful for diagnostics, but it is the field data that counts for SEO.
PageSpeed Insights (pagespeed.web.dev) is the best starting point because it shows both field data and lab data for a specific URL. Field data appears at the top under "Discover what your real users are experiencing" — this is the CrUX data Google uses. Lab data below provides diagnostics and specific recommendations.
Google Search Console provides an overview of Core Web Vitals for the entire website, grouped by URL patterns. Chrome DevTools Performance panel provides detailed diagnostics for individual page loads. For continuous monitoring, the web-vitals JavaScript library from Google is the best option for collecting field data directly from your own users.
- PageSpeed Insights: Field data + lab data for individual URLs
- Google Search Console: Overview of CWV across the entire website
- Chrome DevTools: Detailed diagnostics for individual page loads
- web-vitals JS library: Collect your own field data from real users
- Lighthouse CI: Automated lab testing in CI/CD pipeline
LCP optimization: Faster content loading
LCP measures when the largest visible element finishes rendering — typically a hero image, a large text block, or a video. The four main causes of poor LCP are: slow server response time (TTFB), render-blocking resources, slow resource loading, and slow client-side rendering.
Start with server response time. Time to First Byte (TTFB) should be under 800 ms. Use a CDN for static resources, enable server-side caching, and optimize database queries. For Next.js websites, Static Site Generation (SSG) and Incremental Static Regeneration (ISR) deliver dramatically better TTFB than Server-Side Rendering (SSR) on every request.
For images — the most common LCP source — the preload attribute is critical. Add <link rel="preload"> for the hero image in <head>, use modern formats (WebP or AVIF), and serve responsively with srcset and sizes. Avoid lazy loading on the LCP image — it should load immediately. Remove render-blocking CSS and JavaScript by inlining critical CSS and deferring non-critical scripts.
INP optimization: Faster interaction response
INP is the newest vital and the hardest to optimize, because it deals with JavaScript performance throughout the entire page visit. Poor INP is almost always caused by the browser's main thread being blocked by long-running JavaScript tasks when the user attempts to interact.
The most important strategy is to break up long JavaScript tasks (over 50 ms) into smaller chunks. Use requestIdleCallback or scheduler.yield() to give the browser room to respond to user interactions between tasks. In React/Next.js, this means avoiding heavy computations in the render cycle and instead using useTransition or useDeferredValue for non-critical updates.
Also reduce the amount of JavaScript loaded and executed. Use code splitting to only load what is needed for the current page. Implement tree shaking to remove unused code. And consider whether heavy client-side operations can be moved to server-side or Web Workers. According to HTTP Archive, the median JavaScript per page is 509 KB compressed (HTTP Archive, 2024) — the fastest websites are well below this.
CLS optimization: Stable visual experience
CLS problems are extremely frustrating for users — you are about to click a link, and suddenly the content jumps because an image loaded or an ad appeared. The most common causes are images without dimensions, dynamically loaded content, web fonts causing FOUT/FOIT, and late-loading ads.
The simplest and most effective fix is to always specify width and height (or aspect-ratio) on all images and videos. This lets the browser reserve space before the resource loads. In Next.js, this is handled automatically by the Image component. For ads and dynamic content, reserve space with CSS (min-height) based on the expected dimensions.
Web fonts are a hidden CLS source. When a font loads after text has already been rendered with the fallback font, a layout shift occurs. Use font-display: swap combined with a carefully matched fallback font to minimize the shift. Better yet: use font-display: optional, which does not show the font at all if it is not loaded in time, eliminating CLS entirely.
Image optimization: WebP, AVIF, lazy loading, and responsive images
Images typically make up 50–70% of a page's total weight. Modern image formats like WebP and AVIF deliver 25–50% smaller file sizes than JPEG at the same visible quality. WebP is supported by all modern browsers, while AVIF provides an additional 20% savings but has slightly narrower support (95% globally as of 2025).
Use the <picture> element with AVIF as the first choice, WebP as fallback, and JPEG as last resort. Implement responsive images with srcset and sizes so mobile users do not load desktop versions. A 2000px-wide hero image served to a 375px mobile phone is wasted bandwidth and load time.
Lazy loading (loading="lazy") should be used on all images below the fold — that is, images not visible when the page first loads. But never use lazy loading on the hero image or other images visible in the initial viewport. For these, use fetchpriority="high" and preload instead to ensure fastest possible loading.
Font loading strategy
Fonts block rendering if not handled properly. The browser waits by default up to 3 seconds for the font before showing text with a fallback — this is called Flash of Invisible Text (FOIT). Use font-display: swap to show text immediately with a fallback font, and switch to the correct font when it is loaded.
Preload the most important font files with <link rel="preload" as="font" type="font/woff2" crossorigin>. Limit the number of font variants — each variant (weight, style) is a separate file. Use variable fonts where possible, so one file covers multiple weights. For a typical website with two font families, you should not load more than 4–5 font files total.
An advanced strategy is to use the CSS Font Loading API to detect when the font is ready, then add a CSS class that adjusts line height and letter spacing to match the new font. This minimizes the CLS contribution from font swapping. For web design projects, we recommend choosing Google Fonts optimized for web delivery.
Third-party script management
Third-party scripts — analytics tools, chatbots, ad platforms, heatmap tools, CRM widgets — are the most common cause of poor performance that developers do not have direct control over. A study from HTTP Archive shows that the median page loads 21 third-party requests (HTTP Archive, 2024).
Audit all third-party scripts regularly: Do you still need that tool? Can it be lazy-loaded? Can it be replaced with a lighter alternative? Use Chrome DevTools Network panel to identify the heaviest third-party scripts and evaluate each one critically. Google Tag Manager makes it easy to add scripts — perhaps too easy. Old tags that nobody uses accumulate and drag down performance.
For scripts you must keep, use the async or defer attribute to avoid render blocking. Consider loading chatbots and other non-critical scripts only after user interaction (click, scroll). For analytics tools, you can use Partytown or a Web Worker approach to move execution off the main thread.
Speed monitoring and regression prevention
Performance optimization is not a one-time project — it is a continuous process. Without monitoring, performance will gradually degrade as new content, new features, and new third-party scripts are added. Set up performance budgets that define maximum acceptable values for page size, number of requests, and Core Web Vitals metrics.
Integrate Lighthouse CI in the build pipeline to automatically test performance on every deploy. Set up alerts in Google Search Console when Core Web Vitals data deteriorates. Use SpeedCurve or Calibre for continuous synthetic monitoring, and the web-vitals library for real user data (RUM). Define thresholds that trigger alerts before performance becomes critical.
Document all performance-related decisions. When someone adds a new third-party script, it should go through a performance review. When images are added in the CMS, they should be automatically compressed and served in modern formats. Performance should be part of the culture, not just a technical task. If you need help with performance optimization, LeapJet offers this as part of our SEO services.
Sources and further reading
This article draws on the following sources and industry reports:
- Google Search Central — Core Web Vitals and Page Experience (2025)
- Chrome UX Report — Web Vitals Technology Report (2025)
- Portent — Site Speed and Conversion Rate Study (2023)
- Google — Think with Google: Mobile Page Speed Statistics (2018)
- HTTP Archive — State of the Web: JavaScript and Third-Party Usage (2024)
- web.dev — Optimize Largest Contentful Paint, INP, and CLS (2025)
