Core Web Vitals: What They Are & How to Fix Them Fast

What Are Core Web Vitals?

Core Web Vitals are a set of specific measurements Google uses to evaluate the user experience quality of web pages. They became an official Google ranking factor in May 2021 as part of the Page Experience update, and their weight in Google's ranking algorithm has continued to increase since. Poor Core Web Vitals do not just affect your rankings — they directly harm your users' experience, which in turn affects your bounce rate, time on site, and conversion rates regardless of where you rank.

There are three Core Web Vitals, each measuring a different aspect of page experience: LCP (Largest Contentful Paint) measures loading performance, INP (Interaction to Next Paint) measures interactivity, and CLS (Cumulative Layout Shift) measures visual stability. Google classifies each metric as Good, Needs Improvement, or Poor, and uses the 75th percentile of real user data from the Chrome User Experience Report (CrUX) to assess each page — meaning 75% of your real visitors' experiences must pass the Good threshold for your page to be considered Good overall.

LCP: Largest Contentful Paint

LCP measures how quickly the largest visible element on the page loads. This is usually the hero image, a large heading, or a featured video. The target is LCP under 2.5 seconds. Between 2.5 and 4 seconds is Needs Improvement. Above 4 seconds is Poor and will have a noticeable negative ranking impact.

The four main causes of poor LCP are slow server response times, render-blocking resources, slow resource load times, and client-side rendering. Here is how to fix each.

Slow server response time (TTFB): If your server takes more than 600ms to start responding, LCP will almost certainly fail. Solutions: upgrade your hosting to a faster server or tier (cheap shared hosting is a very common cause of LCP failure), implement server-side caching, use a CDN (Content Delivery Network) to serve content from servers geographically close to your users, and enable server compression (Gzip or Brotli) for HTML, CSS, and JavaScript files.

Render-blocking resources: CSS and JavaScript files that load synchronously in the document head block the browser from rendering anything until they are downloaded and processed. Audit your render-blocking resources using Google's PageSpeed Insights "Eliminate Render-Blocking Resources" diagnostic. Solutions: defer non-critical JavaScript (add the defer or async attribute to script tags), move non-critical CSS to load asynchronously, inline critical CSS directly in the HTML head, and remove unused CSS and JavaScript.

Slow image loading: If your LCP element is an image (it usually is), image optimisation is typically the highest-impact fix. Compress images before uploading — tools like Squoosh, TinyPNG, or Imagify (WordPress plugin) can reduce file sizes by 60–80% without perceptible quality loss. Convert images to next-generation formats: WebP is now supported by all modern browsers and is 25–35% smaller than PNG or JPEG at equivalent quality. Implement responsive images using the srcset attribute to serve appropriately sized images for each device. Add fetchpriority="high" to your LCP image element to tell the browser to prioritise loading it.

Client-side rendering: Sites built with React, Vue, or Angular that rely heavily on JavaScript to render page content can have severe LCP issues because the browser must download, parse, and execute JavaScript before rendering the visible content. Solutions: implement server-side rendering (SSR) or static site generation (SSG), which sends pre-rendered HTML to the browser rather than requiring JavaScript execution before display.

INP: Interaction to Next Paint

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Where FID measured only the delay on the first interaction, INP measures the delay on all interactions throughout the page lifecycle — every click, tap, and keyboard input. The target is INP under 200 milliseconds. 200–500ms Needs Improvement. Above 500ms is Poor.

INP failure is almost always caused by one of three things: long tasks on the main thread that block the browser's ability to respond to interactions, excessive JavaScript execution, or heavy DOM updates triggered by user interactions.

Long tasks: Any JavaScript task exceeding 50ms that runs on the browser's main thread can block interaction responses. Use Chrome DevTools' Performance panel to record interactions and identify long tasks. Common sources include heavy third-party scripts (chat widgets, analytics libraries, ad scripts), complex animation code, and large bundle sizes. Solutions: break long tasks into smaller async chunks using setTimeout or requestIdleCallback, defer or remove non-essential third-party scripts, and implement lazy loading for below-the-fold components.

Reducing JavaScript execution: Only load JavaScript that is needed for the current page. Implement code splitting in your build process so users only download the JavaScript relevant to the page they are on. Use tree shaking to remove unused code from bundles. Regularly audit and remove JavaScript dependencies that are no longer actively used in your project.

Optimising DOM updates: Interactions that trigger large DOM updates — rerendering significant portions of the page — can cause INP failures even when the JavaScript initiating the update runs quickly. Minimise the number of DOM elements affected by any single interaction, use CSS animations rather than JavaScript animations where possible, and implement virtual scrolling for long lists.

CLS: Cumulative Layout Shift

CLS measures how much page content unexpectedly moves while the page is loading — that frustrating experience where you are about to click something and it jumps because an image or ad loaded above it. The target is CLS under 0.1. Between 0.1 and 0.25 Needs Improvement. Above 0.25 is Poor.

Images without dimensions: The most common cause of CLS. When a browser downloads and displays an image without knowing its dimensions in advance, it cannot reserve space for the image while it loads — causing everything below it to shift downward when the image appears. Fix: always specify explicit width and height attributes on every image element in your HTML. This allows the browser to calculate the correct aspect ratio and reserve the right amount of space before the image loads, eliminating the shift entirely.

Dynamically injected content: Ads, cookie consent banners, newsletter popups, and other content injected above existing page content after the initial render causes layout shift. Fix: reserve space for dynamically inserted content upfront using min-height on the container. For ads, use fixed-size ad slots that maintain their dimensions regardless of whether an ad loads or the ad size varies.

Web fonts causing text reflow (FOUT): When custom web fonts load, browser may initially render text in a fallback font, then reflow the text when the custom font loads — shifting any content around it. Fix: use font-display: swap in your @font-face declarations to ensure text is immediately visible using a fallback font. Preload critical fonts using a link element with rel="preload" in your document head. Use font matching tools to ensure your fallback fonts have similar metrics to your custom fonts, minimising the shift when the swap occurs.

Animations and transitions: CSS animations that affect layout properties (top, left, width, height, margin, padding) cause layout shifts. Fix: use CSS transform and opacity for animations — these trigger compositing rather than layout recalculation and do not cause CLS.

How to Measure Your Core Web Vitals

Use Google Search Console's Core Web Vitals report for field data — real measurements from actual Chrome users visiting your site. This is the authoritative source Google uses for ranking purposes. The report groups pages by URL pattern and shows which groups are passing, failing, or need improvement, with specific issue breakdowns. This should be your primary monitoring dashboard for Core Web Vitals at scale.

Use Google PageSpeed Insights for page-level analysis of both field data (real user measurements from CrUX) and lab data (simulated measurements from Lighthouse). PageSpeed Insights provides specific diagnostic recommendations for each issue it identifies — use these recommendations as your fix checklist. The tool is free and at pagespeed.web.dev.

Chrome DevTools' Performance panel and Lighthouse audit provide the deepest diagnostic data for developers — showing exactly where time is spent during page load and interaction, identifying specific long tasks and their causes. Essential for developers investigating root causes of complex CWV failures.

Fixes for WordPress Sites

WordPress is the most common CMS and frequently has Core Web Vitals challenges due to plugin bloat, unoptimised themes, and the inherent complexity of serving PHP-generated pages. These specific optimisations address the most common WordPress CWV failures.

Install WP Rocket (the gold standard WordPress performance plugin — paid) or LiteSpeed Cache (free and excellent if your host supports LiteSpeed). Configure page caching, browser caching, GZIP compression, CSS and JavaScript minification and concatenation, and image lazy loading. These single-plugin implementations resolve the majority of basic WordPress performance issues.

For images, install Imagify or ShortPixel for automatic image compression and WebP conversion on upload. Both integrate directly with the WordPress media library and will retroactively convert your existing image library. Enable the "Convert to WebP" option and set compression to Lossy for maximum file size reduction with acceptable quality.

Audit your installed plugins and remove any that are not actively contributing value. Every active plugin adds load to your site — plugin bloat is a primary cause of WordPress LCP and INP issues. Use Query Monitor (free plugin) to identify plugins generating slow database queries or high server response times.

Choose a hosting provider with genuinely fast response times. Cheap shared hosting frequently produces TTFB values of 800ms–2 seconds before any content optimisation — making it nearly impossible to achieve good LCP regardless of other fixes. Providers like Kinsta, WP Engine, and Cloudways (with appropriate server configuration) are designed for WordPress performance and typically deliver TTFB under 200ms.

Fixes for Shopify Sites

Shopify provides a managed hosting environment that handles server performance, CDN delivery, and basic caching automatically. Core Web Vitals issues on Shopify sites are typically caused by theme code quality, heavy app installations, and unoptimised product images rather than server infrastructure.

Audit your installed apps and remove any that are not providing clear commercial value. Shopify apps frequently inject JavaScript and CSS that loads on every page — each app adds overhead. A store with 20+ apps installed will almost certainly have INP and LCP issues regardless of other optimisations.

Choose a performance-optimised Shopify theme or have your current theme audited for render-blocking code. Dawn (Shopify's free default theme) is well-optimised for Core Web Vitals. Many premium themes prioritise visual design over performance — verify CWV scores before purchasing any theme.

Optimise all product images before uploading: target under 200KB for product images, use WebP format, and upload at the actual size they will display on the largest screen rather than uploading oversized images and relying on Shopify to resize them. Use tools like Squoosh or TinyPNG for manual optimisation.

Fixes for Custom-Built Sites

Custom-built sites have the most flexibility for Core Web Vitals optimisation but also the most variables. The fundamental principles are the same — optimise TTFB, eliminate render-blocking resources, compress and properly format images, avoid layout shifts — but implementation depends heavily on your specific technology stack.

For server-side rendered sites: implement HTTP/2 or HTTP/3 on your server, configure aggressive browser caching headers, use a CDN for static assets, implement server-side compression, and investigate your database query performance if TTFB is consistently above 600ms.

For JavaScript framework sites (React, Vue, Next.js): evaluate whether server-side rendering or static site generation is viable for your key pages. Next.js and Nuxt.js provide built-in SSR/SSG capabilities that dramatically improve LCP compared to pure client-side rendering. Implement code splitting at the route level and lazy load components below the fold. Analyse your JavaScript bundle with tools like webpack-bundle-analyzer to identify opportunities for reduction.

Core Web Vitals is a technically complex area — the root causes of failures vary significantly across different tech stacks and site configurations. If you need a professional assessment and fix plan, this is covered as part of my Technical SEO service and SEO Audit. You can also book a free strategy call to discuss your specific situation.