Core Web Vitals and Website Speed Optimization: LCP, INP, CLS Explained and Fixed

Visitors judge a website within moments. If the main content takes too long to appear, if buttons respond slowly, or if the page jumps around while loading, people leave, often for a competitor. Google formalised these experiences into a set of metrics called Core Web Vitals, which measure how real users experience the speed, responsiveness, and stability of a page. This guide explains each metric in plain language, how to measure them correctly, and the specific technical fixes that improve them.

What are Core Web Vitals?

Core Web Vitals are a subset of Google's Web Vitals initiative, chosen because they capture essential aspects of user experience and can be measured in real browsers. There are three metrics:

A page passes when at least 75 percent of page loads meet the good threshold for each metric, separately for mobile and desktop. INP replaced the older First Input Delay metric in March 2024, because it measures responsiveness across all interactions rather than only the first one. Supporting metrics such as Time to First Byte (TTFB) and First Contentful Paint (FCP) are not Core Web Vitals, but they help diagnose problems, especially with LCP.

Why Core Web Vitals matter for SEO and business

Core Web Vitals are part of Google's page experience signals, which are used by its ranking systems. Relevance and content quality remain far more important, so a fast page with weak content will not outrank a slower page that answers the query much better. However, when competing pages are similarly relevant, a better experience can help, and poor performance can hold good content back. The bigger impact is on business results. Faster, more stable pages reduce abandonment, increase engagement, and improve conversion rates, particularly on mobile connections. Performance improvements also help paid campaigns, because landing page experience influences Google Ads Quality Score, as explained in our Google Ads management guide. Speed is one of the most reliable levers in conversion rate optimization.

Field data vs lab data

There are two types of performance data, and understanding the difference prevents a lot of confusion. Field data, also called real user monitoring, is collected from actual visitors in their real browsers, devices, and networks. Google's Chrome User Experience Report (CrUX) provides field data for sites with enough traffic, and this is what Google uses to assess Core Web Vitals. It appears in Search Console's Core Web Vitals report and at the top of PageSpeed Insights. Lab data is collected in a controlled test, for example by Lighthouse, with a simulated device and network. Lab data is repeatable and excellent for diagnosing causes, but it may not match real user experience. A page can score well in Lighthouse and still fail in the field because real users have slower devices, or because interactions that affect INP do not happen in a lab test. Use field data to decide what to fix and to confirm improvements, and lab tools to find out why.

How to measure Core Web Vitals

• Google Search Console groups URLs by status for mobile and desktop and highlights which issue affects each group.
• PageSpeed Insights shows field data for a URL or origin when available, plus a Lighthouse lab audit with specific recommendations.
• Chrome DevTools, particularly the Performance panel, shows exactly which resources, scripts, and layout shifts affect a page, and can show live Core Web Vitals for your own interactions.
• The web-vitals JavaScript library lets you collect field data from your own visitors and send it to analytics, with attribution showing which element or script caused a problem.
• Real user monitoring services provide dashboards and alerts across your whole site.

Measure templates rather than individual pages. Most performance problems come from shared templates, such as product pages, blog posts, or landing pages, so fixing a template improves many URLs at once.

Improving Largest Contentful Paint (LCP)

LCP is affected by four phases: the time for the server to respond, the delay before the browser discovers the LCP resource, the time to download that resource, and the time to render it. Common fixes include:

• Reduce server response time. Use caching, a content delivery network, efficient database queries, and static or pre-rendered pages where possible. A slow TTFB delays everything else.
• Make the LCP image discoverable early. Use a standard image element in the HTML rather than loading the hero image via JavaScript or a CSS background, and add a high fetch priority hint to it.
• Never lazy-load the LCP image. Lazy loading is excellent for images further down the page but delays the main image when applied above the fold.
• Optimise image size and format. Serve modern formats such as AVIF or WebP, compress images, and use responsive images so mobile devices download appropriately sized files.
• Remove render-blocking resources. Inline critical CSS, defer non-critical CSS and JavaScript, and avoid large synchronous scripts in the document head.
• Preconnect to critical origins, such as an image CDN, so connection setup happens early.

Improving Interaction to Next Paint (INP)

INP measures the delay between a user interaction and the next visual update. It is usually caused by JavaScript keeping the browser's main thread busy, so the page cannot respond. Fixes include:

• Reduce JavaScript. Remove unused libraries, split code so pages load only what they need, and replace heavy components with lighter alternatives.
• Break up long tasks. Split work that takes more than about 50 milliseconds into smaller chunks, yielding to the main thread so the browser can handle input in between.
• Audit third-party scripts. Chat widgets, tag managers, analytics, advertising, and A/B testing scripts often dominate main thread time. Remove what you do not need, and load the rest after the page becomes interactive or on user interaction.
• Keep event handlers light. Do the minimum needed to update the screen immediately, and defer non-urgent work such as analytics calls.
• Avoid large, complex DOM updates. Very large pages and frequent re-renders in frameworks increase rendering work. Virtualise long lists and avoid unnecessary re-rendering.
• Use server rendering wisely. Rendering HTML on the server improves initial display, but large hydration costs can still delay interactivity, so reduce the amount of client-side JavaScript sent with each page.

Improving Cumulative Layout Shift (CLS)

Layout shifts happen when content moves after it has been displayed, for example when an image loads without reserved space, or when a banner is inserted above content. Fixes include:

• Always set dimensions on images and videos, using width and height attributes or CSS aspect ratio, so the browser reserves space.
• Reserve space for ads, embeds, and dynamic content, such as cookie banners, using fixed containers or placeholders.
• Avoid inserting content above existing content unless it is in response to a user interaction.
• Load web fonts carefully. Use font-display settings, preload critical fonts, and choose fallback fonts with similar metrics, or use size adjustment, so text does not reflow significantly when the web font loads.
• Use CSS transforms for animations rather than changing properties that affect layout, such as top, left, width, or height.

Images, fonts, and third parties: the usual suspects

In most audits, a small number of causes explain the majority of problems. Oversized, uncompressed images are the most common cause of slow LCP. Excessive JavaScript, particularly from third-party tags accumulated over years of marketing campaigns, is the most common cause of poor INP. Images without dimensions, late-loading fonts, and injected banners cause most CLS problems. A periodic review of every third-party script, asking who owns it, what it does, and whether it is still needed, often produces large improvements with little development work.

Hosting, caching, and CDNs

Front-end optimisation cannot compensate fully for a slow server. Choose hosting that matches your traffic and architecture, enable HTTP caching with appropriate cache headers, serve static assets from a content delivery network close to your users, and use compression such as Brotli. Modern frameworks support static generation and incremental regeneration, which serve pre-built pages from the edge while keeping content fresh. For dynamic applications, cache expensive database queries and API responses, and monitor server performance under real traffic. Our guide to cloud infrastructure architecture and cost optimization covers infrastructure choices in more detail.

Platform-specific considerations

WordPress sites often slow down because of heavy themes, page builders, and many plugins. Use a lightweight theme, remove unused plugins, use a quality caching and image optimisation setup, and audit what each plugin loads on each page. Shopify and other hosted ecommerce platforms handle hosting well, but apps and themes can add significant JavaScript; remove unused apps fully, including leftover code. JavaScript frameworks such as React and Next.js can be extremely fast when they use server rendering, static generation, image optimisation, and code splitting well, but slow when they send large client bundles. Monitor bundle size as part of development, and treat performance budgets like any other requirement. Our web application development guide explains how to build performance into projects from the start.

A prioritised speed optimisation plan

1. Measure. Review Search Console's Core Web Vitals report and PageSpeed Insights field data for your key templates, separately for mobile and desktop.

2. Prioritise. Focus first on templates with the most traffic or revenue that fail a metric, such as product, service, or landing pages.

3. Diagnose. Use Lighthouse and the Chrome DevTools Performance panel to identify the LCP element, long tasks, and layout shift sources.

4. Fix quick wins. Compress and resize images, add image dimensions, remove unused third-party scripts, and stop lazy-loading the LCP image.

5. Address structural issues. Improve server response and caching, reduce JavaScript bundles, and refactor heavy components.

6. Validate. Field data in CrUX uses a rolling 28-day window, so improvements appear gradually. Use Search Console's validation feature and your own real user monitoring to confirm results.

7. Prevent regressions. Set performance budgets, run Lighthouse checks in continuous integration, and review new third-party scripts before adding them.

Common misconceptions

• "A Lighthouse score of 100 means we pass." Google assesses field data from real users; lab scores are diagnostic only.
• "Speed is all that matters for rankings." Relevance and quality matter more; performance is one signal among many.
• "Desktop results are enough." Mobile performance is assessed separately and is usually worse.
• "Fixing one page fixes the site." Problems usually come from templates and shared scripts, which must be fixed at the source.

Speed up your website with Vertex Cyber Tech

We audit Core Web Vitals using field and lab data, fix performance problems in front-end code, hosting, and third-party scripts, and build fast websites and applications from the ground up. Explore our web development services and SEO and digital marketing services, or book a free consultation. For the wider technical picture, see our technical SEO checklist.

Sources and further reading

• web.dev: Web Vitals
• web.dev: Largest Contentful Paint
• web.dev: Interaction to Next Paint
• web.dev: Cumulative Layout Shift
• Google Search Central: Core Web Vitals and Google Search
• PageSpeed Insights