Core Web Vitals and website speed: what to measure and what to fix first

What Core Web Vitals are, and why they matter if you are not a developer

A visitor does not think about your server. They think about three things: “Is anything appearing on the screen?”, “Can I press that button?” and “Why did the page jump just as I was about to tap?” Core Web Vitals are Google’s way of turning those three questions into numbers that you can track, compare and improve.

They matter to a business owner for two reasons. The first is commercial: a slow page loses people before they read your offer, and the visitors you pay for with advertising are the most expensive ones to lose. The second is visibility: Google uses page experience as one of its quality signals, alongside content relevance, links and much else. It is not a magic switch that takes you to the top of the results, but between two equally relevant pages it can tip the balance.

The good news is that you do not need to read code to manage the process. You need to know what is being measured, where the numbers come from and which questions to ask whoever looks after your site.

The three metrics at a glance: LCP, INP and CLS

The thresholds below are the ones Google publishes and uses in its reports. They are usually assessed at the 75th percentile of real visits, which means that three visits in four must fall within the “good” range.

INP replaced the older FID metric in 2024. The difference is real: FID only looked at the first interaction, while INP considers how the page responds across the whole visit. If you have read older articles that talk about FID, that advice is out of date.

Lab data and real-user data: where to find the right numbers

This is where most people get confused. There are two kinds of data, and they should not be mixed up.

Lab data comes from a test run now, in a simulated environment such as Lighthouse. It is useful for finding causes and checking that a fix worked, but it depends on the simulation you choose: connection speed, phone type, even the time of day.

Real-user (field) data comes from actual visitors, collected through Chrome and aggregated in the Chrome UX Report. This is what Google uses, and it tells the truth about your customers on their own phones and networks.

• PageSpeed Insights (pagespeed.web.dev) shows both for a given address: real-user data at the top, lab diagnostics below.
• Google Search Console has a Core Web Vitals report that groups your pages by issue, separately for mobile and desktop.
• Chrome DevTools (the Performance panel) is for developers when a cause needs digging out.

A small site with little traffic may not have enough real-user data. In that case you rely on lab results and common sense, accepting that they are an estimate. A sensible start is to run PageSpeed Insights on your home page and on the page that receives the most visits or enquiries.

What hurts LCP: images, the server and render-blocking files

LCP is often the easiest metric to improve, and the improvement is usually clearly visible. The causes repeat from one site to the next.

A hero image that is too heavy or loads too late

A 3 MB photograph used as the cover image is the classic culprit. The fix is sizes that suit the screen, modern formats such as WebP or AVIF, and sensible compression. One detail that is often missed: the main image should not be lazy-loaded. That technique is meant for images further down the page, not the one at the very top.

A slow server and no caching

If the server responds slowly, everything else waits. An overloaded hosting plan, a busy database or the lack of a caching layer all delay the first byte (the measurement is called TTFB). Better hosting, page caching and, for audiences in several countries, a CDN will help. The reasoning behind the choice is covered in our guide to choosing web hosting.

Files that block rendering

Large CSS and JavaScript files loaded at the top of the page keep the screen blank while the browser downloads them. The remedy is to defer whatever is not needed for the first view and keep only the critical styles up front.

What hurts INP and CLS: scripts, fonts and ads

INP gets worse when the browser’s main thread is busy with too much JavaScript. Typical sources are a pile of plugins, a heavy page builder, chat widgets, tracking pixels, maps and social buttons added over the years without anyone clearing them out. Each looks harmless; together they make the page freeze for a few hundred milliseconds after a tap.

CLS appears when something takes up space after the rest of the page has settled. Common causes:

• images and videos without declared dimensions, which push the text down when they load;
• cookie banners or promotional bars that appear at the top and shift everything;
• web fonts that swap after loading and change the width of the text;
• ads or widgets inserted without reserved space.

The fix for CLS is usually the same: reserve the space in advance. For INP, remove what adds no value and defer the rest.

A common reflex is to add yet another optimisation plugin on top of the existing ones. Without measurement you can end up with the opposite result: more scripts, not fewer. Change one thing at a time and measure again.

What to fix first: a six-step plan

The order matters more than the number of fixes. Start with whatever delivers the most for the least effort.

1. Pick the pages that matter. The home page, the main service or product pages and any landing pages used for ads. Do not optimise a page nobody visits.
2. Take a baseline. Note LCP, INP and CLS from PageSpeed Insights for mobile, not just desktop. For many sites most visits come from phones.
3. Deal with images. Resize, compress, use modern formats, declare dimensions and do not defer the hero image.
4. Clean up scripts. List everything that loads: plugins, pixels, widgets. Remove what you no longer use and defer what is not vital at the start.
5. Check hosting and caching. If the server is slow even on a simple page, the problem is not the design.
6. Measure again after a week. Real-user data updates with a delay. Compare with the baseline from step 2 and keep a note of what you changed.

For a quick first impression of a landing page, you can use the landing page audit in our Lab. It does not replace a full technical test, but it shows what to check next.

How much does speed matter for SEO and for sales?

There is no simple rule such as “one second faster means X% more sales”. The figures that circulate online come from different contexts and do not apply automatically to your business. What can be said with confidence is the direction: a page that loads quickly and stays stable causes less frustration, and a less frustrated visitor is more likely to read, call or buy.

On the search side, Core Web Vitals belong to page experience, a group of signals Google uses. Content relevance remains far more important. A site with excellent text and average speed can outrank a fast but thin one. That is why speed should be treated as a baseline condition, not as a strategy in itself.

For paid ads the effect is more direct: you pay for every click, and if the page loads slowly, some of the people you paid for leave before seeing the offer. A fast site makes the same ad budget go further.

Terms you will meet in reports

TTFB (Time to First Byte) is the time until the server starts sending its response. Cache is a store holding a ready-made copy of the page, so it does not have to be built from scratch on every visit. CDN is a network of servers that delivers static files from a point close to the visitor. Lazy loading means loading images only when they get near the screen. 75th percentile is the value below which 75% of visits fall; this is why a few very slow visits do not ruin the result, while consistently slow traffic does.

Common mistakes when trying to speed up a site

• Looking only at the 0–100 Lighthouse score. The score is a lab summary; Google assesses Core Web Vitals on real data. You can score 95 in a test and still deliver a poor experience on older phones.
• Testing only on desktop. A phone on a mobile network is the real scenario for many customers.
• Installing three caching plugins at once. They can conflict and cause errors that are hard to trace.
• Compressing images until the flaws show. The result is a fast site that looks unprofessional. Look for balance, not the smallest file.
• Ignoring updates. Old themes, plugins and PHP versions slow things down and open security gaps; see also our WordPress security guide.
• Leaving optimisation until just before launch. Speed is designed in from the start; see the website launch checklist.

How we approach it

We begin by measuring the pages that bring in revenue or enquiries, not by optimising at random. We record the real-user values, find the two or three causes that weigh most and fix them in order, checking after each change. Where a problem cannot be solved without better hosting or replacing a heavy plugin, we say so plainly, with the alternatives and their approximate cost.

On a WordPress site, speed erodes slowly, through accumulation. That is why part of our WordPress maintenance is regular housekeeping: updates, unnecessary scripts, new images that were never resized, the database. If a site is being built from scratch, these rules go in from the design stage of a new WordPress website.

In short

• Core Web Vitals = LCP (display), INP (response) and CLS (stability); targets are 2.5 s, 200 ms and 0.1.
• Real-user data from Search Console and PageSpeed Insights matters more than the lab score.
• First fixes: images, server and caching, then third-party scripts.
• Reserve space for images, banners and ads to avoid layout jumps.
• Speed is a baseline for SEO and advertising, not a substitute for good content.