Core Web Vitals optimisation: practical guide for UK business websites

Core Web Vitals are Google's standardised metrics for measuring real-world user experience on the web. They directly influence search rankings, and more importantly, they reflect how fast, responsive, and visually stable your website feels to visitors. For UK businesses competing for organic visibility, poor Core Web Vitals scores mean lost rankings and lost conversions.

Despite their importance, many business websites still fail Core Web Vitals assessments. The reasons are usually straightforward: unoptimised images, render-blocking resources, layout shifts from dynamically loaded content, and slow server response times. Each of these issues has a practical fix.

This guide explains what each Core Web Vital measures, how to diagnose problems, and how to fix them, with specific guidance for both WordPress and Next.js websites.

What are Core Web Vitals and why do they matter?

Core Web Vitals are part of Google's page experience signals, a set of ranking factors that measure how users experience your website. Google introduced these metrics to ensure that search results prioritise pages that are not just relevant but also pleasant to use.

The three Core Web Vitals

Largest Contentful Paint (LCP) measures how long it takes for the largest visible content element to render. This is typically a hero image, heading, or large text block. LCP reflects perceived loading speed: how quickly users see the main content of your page.

• Good: Under 2.5 seconds.
• Needs improvement: 2.5 to 4.0 seconds.
• Poor: Over 4.0 seconds.

Interaction to Next Paint (INP) measures how quickly your page responds to user interactions such as clicks, taps, and keyboard inputs. INP replaced First Input Delay (FID) in March 2024 as a more comprehensive responsiveness metric, because it measures all interactions throughout the page lifecycle rather than just the first one.

• Good: Under 200 milliseconds.
• Needs improvement: 200 to 500 milliseconds.
• Poor: Over 500 milliseconds.

Cumulative Layout Shift (CLS) measures unexpected visual movement of page content. When elements shift position as the page loads, it creates a frustrating experience, particularly on mobile where users may accidentally tap the wrong element.

• Good: Under 0.1.
• Needs improvement: 0.1 to 0.25.
• Poor: Over 0.25.

The business impact

Core Web Vitals matter beyond SEO rankings. Research consistently shows that faster, more stable websites convert better:

• Pages that load within 2 seconds have an average bounce rate of 9%, compared to 38% for pages that take 5 seconds.
• A 100-millisecond improvement in page load time can increase conversion rates by up to 7%.
• Reducing layout shifts improves user trust and reduces accidental interactions.

For UK businesses, where competition for organic visibility is intense in most sectors, Core Web Vitals can be the differentiator between ranking on page one and page two.

How do you measure Core Web Vitals?

Accurate measurement is the foundation of any optimisation effort. Google provides both lab data (simulated) and field data (real user measurements).

Lab tools (simulated testing)

• Google PageSpeed Insights: The most accessible tool. Enter any URL and receive scores for both mobile and desktop, along with specific recommendations. Uses Lighthouse under the hood.
• Chrome DevTools (Lighthouse): Built into Chrome browser. Provides detailed performance audits with waterfall charts and specific element identification.
• WebPageTest: Advanced testing tool that simulates real devices and network conditions. Provides filmstrip views and detailed loading timelines.
• Chrome User Experience Report (CrUX): Accessible through PageSpeed Insights, this shows real-world data from Chrome users visiting your site.

Field tools (real user data)

• Google Search Console: The Core Web Vitals report shows your site's performance based on real user data, grouped by page type and status.
• Google Analytics 4: Web Vitals can be tracked as custom events, giving you page-level performance data.
• web-vitals JavaScript library: Google's open-source library for measuring Core Web Vitals in your own analytics pipeline.

Which data matters more?

Field data always takes precedence over lab data for ranking purposes. Google uses real user measurements from the Chrome User Experience Report to assess your site's Core Web Vitals performance. Lab data is useful for diagnosing issues and testing fixes before deployment, but your ranking impact is determined by real-world user experience.

If your site does not have enough traffic for CrUX data (typically fewer than a few thousand monthly visitors), Google relies on page-level lab assessments. In this case, optimising for Lighthouse scores becomes more directly relevant.

How do you fix a slow Largest Contentful Paint?

LCP is the metric most UK business websites struggle with. The LCP element is usually one of these:

• A hero image or banner.
• A large heading or text block.
• A video poster image.
• A background image rendered via CSS.

Common causes of slow LCP

1. Unoptimised images: The most frequent cause. Images that are too large, served in outdated formats (JPEG, PNG instead of WebP or AVIF), or not properly sized for the viewport add seconds to LCP.

2. Slow server response time: If the server takes over 600 milliseconds to respond (measured as Time to First Byte or TTFB), LCP will struggle to meet the 2.5-second threshold regardless of front-end optimisation.

3. Render-blocking resources: CSS and JavaScript files in the document head that must be downloaded and parsed before the browser can render content.

4. Lazy loading the LCP element: A common mistake where the hero image is lazy loaded, which actually delays its rendering instead of prioritising it.

5. Client-side rendering: Single-page applications that render content via JavaScript force the browser to download, parse, and execute scripts before any content is visible.

How to fix LCP issues

Optimise images:

• Convert images to WebP or AVIF format (30-50% smaller than JPEG with equivalent quality).
• Use responsive images with srcset and sizes attributes to serve appropriately sized images for each viewport.
• Set explicit width and height attributes to reserve space and prevent layout shifts.
• Preload the LCP image using <link rel="preload" as="image"> in the document head.
• Never lazy load the LCP image. Use loading="eager" or fetchpriority="high" instead.

Improve server response time:

• Upgrade hosting if TTFB exceeds 600 milliseconds. For WordPress, consider managed hosting (Kinsta, WP Engine, Cloudways). For Next.js, deploy on Vercel or a CDN-backed platform.
• Enable server-level caching (page caching, object caching).
• Use a CDN to serve content from edge locations closer to UK users.
• Optimise database queries if using WordPress or other database-driven platforms.

Eliminate render-blocking resources:

• Inline critical CSS (the CSS needed for above-the-fold content) directly in the HTML.
• Defer non-critical CSS and JavaScript using async or defer attributes.
• Remove unused CSS and JavaScript. Tools like PurgeCSS can identify unused styles.
• Reduce the number of third-party scripts loaded in the document head.

Next.js-specific LCP optimisation:

• Use the built-in next/image component, which handles responsive sizing, format conversion, and priority loading automatically.
• Set priority={true} on the LCP image component to ensure it is preloaded.
• Use static generation (SSG) or incremental static regeneration (ISR) to pre-render pages as static HTML.
• Configure next/font to load fonts without blocking rendering.

How do you improve Interaction to Next Paint?

INP measures how quickly your page responds to user interactions. Unlike FID, which only measured the first interaction, INP considers all interactions throughout the page session and reports the worst one (with some statistical adjustment).

Common causes of poor INP

1. Long JavaScript tasks: JavaScript operations that take more than 50 milliseconds block the main thread, preventing the browser from responding to user input.

2. Heavy third-party scripts: Analytics, chat widgets, advertising scripts, and social media embeds often execute long tasks that block interaction responsiveness.

3. Large DOM size: Pages with thousands of DOM nodes require more processing time for layout calculations and event handling after user interactions.

4. Complex event handlers: Click handlers or input processors that trigger expensive calculations, API calls, or DOM manipulation delay the visual response.

How to fix INP issues

Break up long tasks:

• Use requestIdleCallback or setTimeout to defer non-urgent processing.
• Split complex operations into smaller chunks using yield patterns.
• Move heavy computations to Web Workers to keep the main thread responsive.

Manage third-party scripts:

• Audit all third-party scripts and remove any that are not essential.
• Load non-critical scripts after the page becomes interactive using defer or dynamic import.
• Use a tag manager with trigger conditions to control when scripts execute.
• Consider server-side analytics alternatives that eliminate client-side JavaScript entirely.

Reduce DOM complexity:

• Virtualise long lists and tables (render only visible items).
• Simplify page structure by reducing unnecessary wrapper elements.
• Use CSS for visual effects instead of JavaScript where possible.

Optimise event handlers:

• Debounce input handlers (search fields, resize handlers) to limit execution frequency.
• Use event delegation instead of attaching handlers to individual elements.
• Avoid synchronous layout reads followed by writes (forced reflows).

Next.js-specific INP optimisation:

• Use React Server Components (available in Next.js App Router) to reduce client-side JavaScript.
• Implement dynamic imports with next/dynamic for components that are not immediately needed.
• Use useTransition and useDeferredValue hooks to keep the UI responsive during state updates.
• Minimise client-side state management; fetch data on the server where possible.

How do you fix Cumulative Layout Shift?

CLS measures unexpected layout movement. Even small shifts are frustrating when they cause users to click the wrong button or lose their reading position.

Common causes of CLS

1. Images without dimensions: When images load without explicit width and height, the browser cannot reserve space, causing content below to jump when the image appears.

2. Web fonts causing text reflow: When a web font loads and replaces a fallback font, text can shift due to differences in character widths and line heights.

3. Dynamically injected content: Cookie consent banners, advertising slots, notification bars, and late-loading widgets push existing content down the page.

4. Embeds and iframes without dimensions: Third-party embeds (maps, videos, social media) that load without reserved space cause layout shifts.

How to fix CLS issues

Always set image and video dimensions:

• Add width and height attributes to all <img> and <video> elements.
• Use CSS aspect-ratio for responsive containers: aspect-ratio: 16/9.
• The Next.js Image component handles this automatically when you provide width and height props.

Optimise font loading:

• Use font-display: swap to show fallback text immediately while the web font loads.
• Better yet, use font-display: optional to prevent any layout shift from font swapping.
• Use next/font in Next.js projects to automatically optimise font loading and eliminate font-related CLS.
• Size your fallback font to match your web font's metrics using the size-adjust CSS descriptor.

Reserve space for dynamic content:

• Use CSS min-height on containers that will receive dynamically loaded content.
• Load cookie consent banners as overlays rather than pushing content down.
• Reserve space for ad slots using fixed-dimension containers.
• Insert dynamic elements at the bottom of the viewport rather than the top to minimise visible shifts.

Handle embeds properly:

• Wrap iframes and embeds in containers with defined aspect ratios.
• Use lazy loading with placeholder containers that match the final embed dimensions.
• For Google Maps, set a fixed height container.

What tools should you use for ongoing monitoring?

Fixing Core Web Vitals is not a one-time project. Performance can degrade as content is added, plugins are updated, or third-party scripts change their behaviour.

Recommended monitoring setup

• Google Search Console Core Web Vitals report: Check weekly to catch regressions early. This uses real user data and directly reflects what Google sees.
• PageSpeed Insights: Run monthly checks on your top 10 landing pages to catch page-level issues.
• Real User Monitoring (RUM): Implement the web-vitals library to track performance in your own analytics, giving you page-level and segment-level insights.
• Automated Lighthouse CI: For development teams, integrate Lighthouse into your CI/CD pipeline to catch performance regressions before deployment.

Performance budgets

Set performance budgets to prevent regressions:

• Maximum JavaScript bundle size per page.
• Maximum image file sizes.
• LCP, INP, and CLS thresholds that must pass before deployment.
• Total page weight limits.

Teams that enforce performance budgets through automated checks maintain better Core Web Vitals scores over time than those who optimise reactively.

How do Core Web Vitals affect SEO rankings?

Core Web Vitals are a confirmed Google ranking factor, but their impact should be understood in context.

Content relevance, authority, and backlinks remain the strongest ranking signals. Core Web Vitals act as a tiebreaker: when two pages are equally relevant and authoritative, the one with better user experience metrics will rank higher.

However, in competitive UK markets where multiple businesses have strong content and authority, this tiebreaker effect is significant. Moving from "poor" to "good" Core Web Vitals status has been shown to correlate with ranking improvements of 1-5 positions for competitive terms.

The indirect effects are arguably more important than the direct ranking signal:

• Faster pages have lower bounce rates, which improves engagement signals.
• Better responsiveness increases conversion rates, which generates more business regardless of ranking.
• Visual stability builds user trust, particularly for healthcare and financial services websites where credibility is paramount.

Next steps

Core Web Vitals optimisation delivers measurable improvements in both search visibility and user conversion. Start by measuring your current scores using PageSpeed Insights and Google Search Console, then work through the fixes in priority order: LCP first (usually the biggest impact), then CLS (usually the easiest fix), then INP (usually the most technically complex).

If your business website is struggling with Core Web Vitals scores and you need expert support to diagnose and fix performance issues, we specialise in technical optimisation for UK business websites.

About the Author

Pankaj Karad

Founder & CEO

Pankaj Karad is the founder of Karad Infotech, a London-based agency specialising in web design, SEO, and software development for healthcare businesses across the UK.

Connect on LinkedIn