Slow website? How to measure and improve your site speed (Core Web Vitals)

Website speed is now measured with three metrics defined by Google, the Core Web Vitals: how fast the main content appears (LCP), how quickly the page responds to interactions (INP), and how stable the layout stays while loading (CLS). Measuring them is free and takes minutes; improving them usually comes down to better-prepared images, fewer scripts and a layout that reserves space for every element.

The three metrics in plain English

The Web Vitals guide on web.dev, published by Google, covers three aspects of user experience: loading, interactivity and visual stability.

LCP (Largest Contentful Paint): loading. The time it takes to render the largest element visible on screen — often the hero image or main heading. According to web.dev’s LCP page, it can be an image, a video’s poster image or first frame, a CSS background image or a block of text.

INP (Interaction to Next Paint): responsiveness. INP looks at the latency of all clicks, taps and key presses during a visit. A menu that is slow to open or a button that seems unresponsive hurts INP. web.dev’s INP page describes it as the successor to First Input Delay (FID).

CLS (Cumulative Layout Shift): stability. CLS measures unexpected layout shifts — the classic case being an image loading above the link you were about to tap, pushing it out of the way.

Google’s thresholds

Metric	Good	Poor
LCP	2.5 seconds or less	over 4 seconds
INP	200 milliseconds or less	over 500 milliseconds
CLS	0.1 or less	over 0.25

In between, the page “needs improvement”. These thresholds apply at the 75th percentile of page loads, separately for mobile and desktop: at least three visits out of four must meet them, including on slower phones and average connections — not just on your office computer.

Speed and SEO: what Google says

Google Search Central’s Core Web Vitals documentation strongly recommends that site owners achieve good scores, and says this aligns with what its core ranking systems seek to reward.

Keep it in proportion, though. Google’s page experience documentation states that good scores don’t guarantee top rankings, and that Search always seeks to show the most relevant content, even if the page experience is sub-par. Speed mainly serves your visitors — and it is one foundation of good SEO among several.

Measuring: two free tools

PageSpeed Insights analyses a single URL and returns two kinds of results:

• Field data from the Chrome User Experience Report (CrUX), over the previous 28 days — your real visitors’ experience. If a page lacks data, PSI falls back to site-wide data; very low-traffic sites may have none.
• Lab data from Lighthouse, in a simulated environment — useful for diagnosing and testing a fix right away.

It reports on both mobile and desktop. Start with the mobile results: that’s usually where problems show.

The Core Web Vitals report in Search Console uses real-world usage data for the whole site. It groups similar URLs and labels each group Good, Needs improvement or Poor, per platform; a group’s status is that of its worst metric. Once you’ve fixed an issue, click Start Tracking to validate the fix; Google then monitors the affected URLs for 28 days.

Common causes and fixes

Slow LCP

web.dev’s LCP optimisation guide recommends:

• Serving images at the right size, using responsive images.
• Compressing images and using modern formats such as AVIF or WebP.
• Never lazy-loading the main image, and giving it fetchpriority="high".
• Making the main image discoverable in the initial HTML, so the browser finds it early.
• Minimising redirects and bringing the server closer to visitors with a CDN.

High CLS

From web.dev’s CLS optimisation guide:

• Always set width and height on images and videos, or reserve space with CSS aspect-ratio.
• Reserve space for late-loading content: banners, ads, booking widgets.
• Handle web fonts carefully: preload critical fonts and minimise size differences with the fallback font.
• Avoid animating layout properties such as top or left.

Poor INP

INP suffers when the browser is busy running JavaScript as the visitor clicks. web.dev’s INP optimisation guide advises breaking up long tasks to yield to the browser, doing as little work as possible in event callbacks, and notes that very large DOMs make rendering more expensive. On a brochure site, the usual culprit is scripts piled up over the years — plugins, tracking tools, widgets. Auditing what’s actually used is a good start.

A worked example

Take a restaurant website in Juan-les-Pins. On mobile, PageSpeed Insights reports a poor LCP and a CLS that needs improvement. The cause: a multi-megabyte terrace photo in the header, lazy-loaded by a plugin, and a booking banner that appears late and pushes content down. The fixes follow the guidance above: resize the photo, convert it to WebP or AVIF and load it with high priority; give the banner reserved space from the start. Check lab data first, then follow field data as it updates over its 28-day window.

Prevention beats cure

Speed is largely decided when a site is built: technology, template weight, number of plugins. Our comparison of WordPress, Webflow and custom sites covers this, and the story of our own website rebuild shows measurements on a static site. It then has to be maintained, because every new image or tool can erode it — one of the roles of ongoing website maintenance, and something we build in from the start of every website design project.

Does your site feel slow, or do its PageSpeed Insights results puzzle you? Get in touch and we’ll look at what’s holding it back.