Website Speed and Core Web Vitals: How to Make Your Site Faster

Website speed optimisation starts with measurement in Google PageSpeed Insights and Search Console. According to Google, a site is fast when at least 75% of visits meet the Core Web Vitals: LCP within 2.5 s, INP within 200 ms and CLS of 0.1 or less. The usual culprits are heavy images, slow hosting, third-party scripts and bloated themes.

• Measure: PageSpeed Insights shows real-user data as well as a lab test.
• Find the weak metric: slow loading (LCP), slow response to clicks (INP) or content jumping around (CLS).
• Fix the common causes: images, caching and hosting, third-party scripts, fonts.
• Check the result in field data after 28 days, not just in the lab score.

Why website speed affects conversions and SEO

A slow site loses customers before they see the offer. The Deloitte study for Google, “Milliseconds Make Millions” (37 European and US brands, over 30 million sessions, data from late 2019), found that a 0.1-second improvement in mobile site speed was associated with a 9.1% increase in progression from product page to basket for retail sites and a 10% increase in bookings for travel sites. These are large brands and no guarantee for every site, but the direction is clear.

For SEO, Google confirms that Core Web Vitals are used by its ranking systems. At the same time it states that it always tries to show the most relevant content, even if the page experience is sub-par, and that good scores do not guarantee top rankings. Speed is a baseline rather than a shortcut – and a slow site also loses the visitors it has already won from search.

Core Web Vitals: LCP, INP and CLS

Core Web Vitals are three metrics Google uses to measure user experience. Since 12 March 2024, INP has been one of them, replacing the older FID metric.

Google rates LCP above 4 s, INP above 500 ms and CLS above 0.25 as poor; anything in between needs improvement. The assessment uses the 75th percentile of visits, separately for mobile and desktop. Being fast on your office connection is not enough – the site has to be fast for most real visitors, often on a phone.

How to run a website speed test

The standard website speed test is Google PageSpeed Insights (pagespeed.web.dev). It is free: enter a URL and you get separate results for mobile and desktop.

Field data vs lab data

PageSpeed Insights shows two kinds of data, and it helps not to mix them up:

• Field data (top of the report) comes from the Chrome User Experience Report (CrUX) – real Chrome users over the previous 28 days. This is what the Core Web Vitals assessment is based on.
• Lab data (Lighthouse) comes from a simulated page load on one device and network. A score of 90 or above is good, 50–89 needs improvement, below 50 is poor. It is useful for finding causes.

Smaller sites often have no field data: if a page lacks enough visits, PageSpeed Insights falls back to data for the whole origin, and if that is not enough either, the field section is missing. Then work with the lab test, but treat it as a guide – a perfect 100 is not a goal in itself.

Core Web Vitals report in Search Console

Google Search Console has a Core Web Vitals report that groups similar pages (for example all product pages) and shows how many URLs are good, need improvement or are poor. A group’s status is set by its worst metric. It is the quickest way to tell whether one page has a problem or the whole template does. For more tools, see our overview of SEO tools.

The most common causes of a slow website and how to fix them

Images

Images are often the heaviest part of a page. Convert them to WebP or AVIF, resize them to the width they are actually displayed at (a 4,000 px photo in an 800 px block is wasted data) and always set width and height attributes so the browser reserves space and content does not jump.

Lazy loading

Lazy loading (the loading attribute set to lazy) defers off-screen images until the visitor scrolls to them. The exception is the main image at the top: it must not be lazy-loaded, otherwise LCP gets worse. Instead, you can raise its priority with the fetchpriority attribute set to high.

Caching and hosting

Before the browser can render anything, it waits for the server’s first response (TTFB). Google’s web.dev guidance suggests most sites should aim for 0.8 s or less. Server-side caching (a caching plugin on WordPress or caching at hosting level), proper browser caching, a CDN for visitors from several countries and good hosting all help. The cheapest shared hosting is often the first place seconds get lost.

Third-party scripts

Chat widgets, maps, embedded videos, ad pixels, heatmaps – every script competes for the browser’s main thread and mainly hurts INP. Review what you actually use, remove the rest and load what remains later or only on interaction, for example a video only after a click on its preview.

Fonts

Each font weight is another file. Use the WOFF2 format, limit the number of fonts and weights (a system or variable font can replace several files) and set font-display so text is visible straight away. A size difference between the fallback and the web font can also cause layout shift.

Page builders and heavy themes

Visual page builders and do-it-all themes add code and styles you do not use, and a large DOM slows down responses to interaction (INP). When a site runs on a heavy builder and the problems repeat on every page, piecemeal fixes hit a ceiling. At that point a rebuild on a lighter foundation is worth considering – see website development.

What you can do yourself and when to call a developer

You can handle:

• testing the site in PageSpeed Insights and reviewing the Search Console report,
• compressing and resizing images before upload,
• removing unused plugins, widgets and scripts,
• enabling caching via a plugin or your host.

You need a developer when:

• INP is poor and the problem lies in JavaScript or the theme,
• server response stays slow even with caching enabled,
• the problem affects a whole template or an online store with thousands of products,
• changes could break key functions such as orders, forms or tracking.

Speed is not a one-off task: every new plugin, script or banner can slow the site down again. That is why we monitor it continuously as part of our website maintenance.

When it makes sense to bring in an expert

If PageSpeed Insights reports problems you do not know how to read, or you have optimised and the numbers have not moved, start with a website SEO audit – speed is part of it, alongside indexing and content. Speed optimisation is also a standard part of our SEO services. Get in touch via our contact form, and if you are considering a new website, our website price configurator gives you an estimate.