How to Improve Page Speed for Better Core Web Vitals
Page speed is a confirmed Google ranking factor and a direct driver of conversion rates — every additional second of load time reduces conversions by an estimated 7 percent. This guide explains Core Web Vitals in plain terms and gives you a prioritized list of improvements you can implement without a complete site rebuild.
Why page speed matters for SEO
Google made page speed a ranking factor for mobile searches in 2018 (the "Speed Update") and expanded its commitment to performance signals with the Core Web Vitals initiative in 2021. Since then, CWV scores have been part of Google's Page Experience ranking signal, a composite score that includes mobile-friendliness, HTTPS, and the absence of intrusive interstitials alongside the three core metrics.
The business case for page speed extends well beyond SEO. Amazon found that every 100ms of latency cost 1% of sales. Walmart reported a 2% conversion increase for every 1-second improvement in load time. For content sites, BBC found that every additional second of load time caused 10% of readers to leave the page.
The compounding effect matters: a slow page that ranks 3rd and converts poorly delivers far less business value than a fast page ranking 5th that converts well. Speed improvements have multiplicative effects across organic traffic, paid traffic, and direct traffic simultaneously.
Google's CWV data comes from two sources: lab data (simulated by Lighthouse in Chrome DevTools and PageSpeed Insights) and field data (real user measurements collected via the Chrome User Experience Report, or CrUX). Field data from real users takes precedence in Google's ranking systems, so optimizing for real-world performance matters more than gaming lab scores.
LCP, INP, and CLS explained
Largest Contentful Paint (LCP) measures how long it takes for the largest visible content element — typically a hero image, a banner, or a large block of text — to appear on screen. Google's threshold is under 2.5 seconds for a "Good" score. LCP is most commonly delayed by slow server response times, render-blocking resources, slow image loading, or client-side rendering that delays the main content block.
Interaction to Next Paint (INP) replaced First Input Delay in 2024. INP measures the delay between a user's interaction (click, tap, keypress) and the next frame that the browser renders in response. A "Good" INP score is under 200 milliseconds. High INP scores typically indicate JavaScript-heavy pages where long tasks block the main thread, preventing the browser from responding quickly to user input.
Cumulative Layout Shift (CLS) measures visual instability — the extent to which page elements jump around as the page loads. A "Good" CLS score is under 0.1. CLS is caused by images without explicit dimensions, ads that inject themselves above existing content, web fonts that cause text to reflow (FOIT/FOUT), and dynamically injected content that pushes elements down.
These three metrics are the current Core Web Vitals. Google updates which metrics comprise CWV approximately every two to three years as measurement science evolves.
Image optimization
Images are the single largest contributor to page weight on most websites — often accounting for 50 to 80% of total page size. Optimizing images typically produces the biggest LCP improvement relative to effort.
Use modern formats: WebP provides 25 to 35% better compression than JPEG at equivalent quality, and AVIF provides another 20% improvement over WebP. Serve AVIF with WebP as a fallback and JPEG as the last resort using the HTML <picture> element with <source> tags.
Set explicit width and height on every image. This single change eliminates the most common source of CLS — images that cause reflow as they load into previously unallocated space. Set dimensions that match the rendered size of the image, not the source file dimensions.
Use loading="lazy" for all images below the fold. This defers network requests for off-screen images until the user scrolls near them. For your hero or LCP image, use loading="eager" and fetchpriority="high" to prioritize it in the browser's loading queue.
Compress aggressively before serving. Most CMS uploads accept images at 3 to 5MB. After compression and format conversion, the same visual result can be served at 50 to 150KB. Tools like Squoosh, ImageOptim, and Sharp (for server-side processing) handle this compression.
Use a CDN with image optimization built in. Cloudflare Images, Cloudinary, and Next.js's built-in Image component automatically handle format conversion, compression, and responsive sizing from a single source image.
JavaScript optimization
JavaScript is the primary cause of poor INP scores and a major contributor to LCP delays. Reducing JavaScript payload and deferring non-critical scripts is typically the second-highest-impact optimization category after images.
Audit your JS bundle. Use Chrome DevTools' Coverage tab (open DevTools → Ctrl+Shift+P → "Coverage") to see what percentage of each JavaScript file is actually executed on the page. Files with 80% or more unused code are candidates for code splitting or removal.
Defer third-party scripts. Analytics, advertising, and chat widgets are rarely needed before the page is interactive. Load them with the async or defer attribute, or use a tag manager that supports delayed loading. Google Tag Manager can be configured to fire tags only after the page loads.
Eliminate render-blocking scripts. Any <script> tag in the <head> without async or defer delays page rendering. Move scripts to the bottom of the body or add defer.
Split your JavaScript bundle. Modern bundlers (webpack, Rollup, Vite) support code splitting, which generates separate chunks for different routes and loads only the code needed for the current page. Dynamic imports — import() instead of static import — enable on-demand loading of large libraries.
Minimize third-party dependencies. Each npm package adds to your bundle. Audit your package.json regularly and remove packages that are no longer used or that can be replaced with smaller alternatives.
Server and hosting choices
The Time to First Byte (TTFB) — how long the browser waits to receive the first byte from the server — affects LCP directly because no rendering can begin before the server responds. A TTFB above 800ms is considered poor; under 200ms is good.
Use a CDN (Content Delivery Network) to serve pages from servers geographically close to your users. Without a CDN, a user in Singapore loading a server hosted in New York adds 150ms of latency purely from the speed of light. Cloudflare, AWS CloudFront, and Vercel Edge Network are commonly used options.
Enable HTTP/2 or HTTP/3. These protocols allow multiplexed requests over a single connection, which reduces the overhead of loading many small resources. Most modern hosting platforms enable this by default.
Enable caching aggressively. Static assets (images, fonts, JavaScript, CSS) should be served with long cache-control headers (Cache-Control: max-age=31536000, immutable). HTML responses can use shorter cache times (10 to 60 minutes) depending on how frequently content changes.
Consider edge rendering or static generation for content that does not change per user. Frameworks like Next.js support static site generation (SSG) that pre-renders HTML at build time, resulting in TTFB under 50ms when served from a CDN edge.
Free testing tools
Google PageSpeed Insights (https://pagespeed.web.dev/) is the primary free tool. It shows both lab scores (simulated on a throttled mobile connection) and field data from the CrUX database of real users. Crucially, the field data is what Google uses in its ranking signal, so if your field data is "Good" even though your lab score is poor, your ranking signal is still good.
Google Search Console's Core Web Vitals report (under Experience) shows field data for your pages segmented by status (Good, Needs Improvement, Poor). This is the most actionable view because it shows which specific URLs are failing.
Chrome DevTools' Lighthouse tab runs a full performance audit locally, including recommendations with estimated savings for each issue. Run Lighthouse in incognito mode to exclude Chrome extensions from the results.
WebPageTest.org provides the most detailed technical analysis available for free: waterfall charts, filmstrip screenshots, connection diagrams, and support for testing from real devices and global locations.
SerpGem's HTTP Headers Analyzer shows which caching, compression, and security headers your server sends — a quick check for missing performance-related headers like Cache-Control and Content-Encoding.
Tools mentioned in this guide
Frequently asked questions
- Are Core Web Vitals a significant ranking factor?
- Core Web Vitals are a confirmed ranking factor as part of Google's Page Experience signal. However, Google has stated that relevance and content quality remain the primary ranking determinants. CWV matters most as a tiebreaker between pages of similar quality, and for high-competition queries where marginal differences matter.
- What is a good PageSpeed Insights score?
- Google's thresholds are: LCP under 2.5s (Good), INP under 200ms (Good), CLS under 0.1 (Good). For the overall performance score, above 90 is "Good." But the field data (from real users) is more important for rankings than the lab score from PageSpeed Insights.
- Does improving page speed help mobile rankings more than desktop?
- Google uses mobile-first indexing, evaluating all sites primarily based on their mobile version. CWV field data is collected from real mobile and desktop users separately. Mobile performance improvements tend to have a larger impact because mobile connections are slower and mobile CWV scores are typically lower than desktop scores.
- How much improvement can I realistically expect from speed optimization?
- Image optimization alone typically improves LCP by 20 to 50% on image-heavy pages. Script deferral can reduce INP by 30 to 60%. The combined effect of a full speed optimization sprint often moves a site from 'Poor' to 'Good' CWV status, which is the meaningful threshold for Google's ranking signal.