Core Web Vitals: How to Improve Website Speed and Search Rankings

Core Web Vitals optimisation is no longer a technical curiosity for developers — it's a factor Google factors directly into how it evaluates page quality, and one that feeds through into both search rankings and visitor behaviour. A slow website, or one that "shifts" while it loads, loses visitors before they've even had a chance to read the content. In this article we look at what Core Web Vitals actually measure, why they matter, and the concrete technical steps that improve them.

Core Web Vitals are a set of metrics Google uses to measure a user's real experience of a page — not just how quickly a page "technically" loads, but how it feels to the person who clicked on it. There are three main metrics:

• LCP (Largest Contentful Paint) — how quickly the largest visible element on the page appears (typically the main image or heading).
• CLS (Cumulative Layout Shift) — whether elements on the page stay put while it loads, rather than shifting content around under the cursor.
• INP (Interaction to Next Paint) — how quickly the page responds to a click, tap, or other user input.

Google uses these metrics as part of its broader page experience signals when assessing page quality. Core Web Vitals optimisation, then, isn't about speed for speed's sake — it's about making a page behave predictably and not frustrate visitors.

LCP is the metric most websites underestimate, because its causes tend to be hidden in implementation details.

The Most Common Causes of Slow LCP

• Unoptimised images in large resolutions and older formats (JPEG, PNG instead of WebP or AVIF).
• Render-blocking CSS and JavaScript files that the browser must download and process before it can display content.
• Slow server response times (TTFB), often caused by unsuitable hosting or missing caching.
• Fonts that load late and cause text to redraw.

Solutions That Work

• Compression and modern image formats, ideally with automatic size selection based on the device (responsive images).
• Preloading key resources using preload for the main image or font.
• Moving rendering to the server (SSR) or using static page generation where possible — modern frameworks such as Next.js have image and font optimisation built directly into their core, which we cover in more detail in our article on why agencies increasingly favour Next.js for corporate websites.
• Choosing hosting and a CDN that shorten the distance between the server and the user.

Layout shift most often happens when the browser doesn't know in advance how large an element that's still loading will be — an image, an ad, an embed, or a web font.

Practical measures:

• Always define width and height (or aspect-ratio) for images and video, so the browser reserves space for them in advance.
• Reserve space for dynamic content — banners, carousels, embedded widgets — before it loads.
• Use font-display: optional or swap with a carefully matched fallback font, so that the font swap doesn't change line height.
• Avoid inserting new content above existing content without a user interaction triggering it.

INP replaced the older FID metric and measures the delay between a user's interaction and the page's visual response. High INP is typical of pages with heavy JavaScript that blocks the browser's main thread.

Steps that genuinely improve INP:

• Code splitting, so only the JavaScript needed for a given page is loaded.
• Deferring processing of non-essential scripts (analytics, chat widgets, third parties) until after the main content has rendered.
• Breaking long JavaScript tasks into smaller chunks that don't block the thread for tens of milliseconds at a time.
• Reducing reliance on heavy libraries where a native browser solution will do.

The chart below illustrates the general principle of how image format and compression affect the amount of data the browser must download before it can render the main content:

Google publishes specific threshold values used to rate metrics as good, needs improvement, or poor.

You'll find precise, up-to-date definitions in the official documentation at web.dev/articles/vitals.

Website speed and SEO aren't just a question of algorithms — they're also a question of visitor behaviour. A slow page, or one with unexpected content shifts, increases the bounce rate and reduces the chance that a visitor completes the action they came for — filling in a form, browsing your references, or saving the page to return to later. Improving Core Web Vitals is therefore worth treating as part of a site's overall technical quality, not as an isolated SEO task.

Rather than making random changes, it's more effective to work from data:

1. Measure the current state using tools such as PageSpeed Insights or Search Console (the Core Web Vitals report).
2. Identify which metric — and on which page types (mobile vs. desktop) — performs worst.
3. Address the causes in order of priority — images and render-blocking scripts usually deliver the most visible improvement.
4. Measure again after each change, since optimisations affect one another.

The scope of work optimisation requires depends on the technology the site runs on, how many third parties are integrated into the page, and whether the site is built on a modern framework or an older architecture carrying technical debt. If you need to assess exactly where your website is losing points, it's worth starting with an audit — take a look at our web application development solutions or arrange a no-obligation consultation.

Core Web Vitals optimisation combines frontend technical work with a real impact on both SEO rankings and visitor behaviour. LCP, CLS and INP measure three distinct aspects of the page experience, and each calls for a different set of measures — from image optimisation, through reserving space for dynamic content, to splitting JavaScript. Companies that want to improve these metrics systematically and sustainably are increasingly turning to modern technologies and proven development practices — you can read more about our approach in the custom development section, or take a look at our references.