How to speed up a website: what to measure and fix first
How to speed up a website: Core Web Vitals, field and lab data, fixing LCP, INP and CLS, images, server response and third-party scripts – in the right order.
In short
Measure first: PageSpeed Insights shows real-visitor data (Core Web Vitals) and a lab test. Then fix what slows you down most – usually the largest above-the-fold image (compress it, don't lazy-load it), a slow server response (caching, CDN), too many third-party scripts and a layout that jumps around. A speed plugin bolted on top rarely fixes the cause.
Key takeaways
- Measure speed with real-visitor data: Google assesses the 75th percentile, separately on mobile and desktop, while the lab test helps you find causes.
- Good Core Web Vitals: LCP within 2.5 s, INP within 200 ms, CLS within 0.1. In 2025 only 48% of sites reached them on mobile.
- On 76% of mobile pages the largest above-the-fold element is an image, so its size, format and loading priority often matter most.
- Server response accounts for roughly 40% of a good LCP; only 44% of mobile sites have a good TTFB.
- Third-party scripts and a large DOM slow down the response to taps and clicks (INP) – often more than the design itself.
Why speed matters and what “fast” means
A slow site rarely gets complaints – visitors simply leave. So speed often becomes a problem only when enquiries or sales drop, and then everyone rushes to install a “speed plugin”. This article is about finding the real cause and the order in which to fix it.
- Core Web Vitals
- Three Google metrics that measure real visitors' experience: LCP (Largest Contentful Paint) – how long until the largest above-the-fold element is visible; INP (Interaction to Next Paint) – how quickly the page responds to a tap or click; CLS (Cumulative Layout Shift) – how much content moves while loading.
48%
Share of websites that met good thresholds for all three Core Web Vitals on mobile in July 2025 (56% on desktop).
Source: HTTP Archive, 20266
+8.4%
In a study commissioned by Google from 55 and Deloitte (37 European and US brand sites, 2019), improving mobile site speed by 0.1 seconds lifted retail conversion rates by 8.4%.
Source: web.dev (Google), 20268
Measurement
What PageSpeed Insights shows and which numbers actually matter.
How to measure: field data and lab data
PageSpeed Insights shows two kinds of data, and it's important to tell them apart. At the top is the experience of real Chrome users over the last 28 days (the Chrome UX Report). Below is a Lighthouse test that loads the page once on a simulated device.
| Field data | Lab data | |
|---|---|---|
| Source | Chrome UX Report – real visitors | Lighthouse – a simulated load |
| Period | The last 28 days | One run, now |
| Device | A range of devices and connections | A mid-tier phone on a mobile network (or an emulated desktop) |
| Use it for | Whether the problem is real and how big it is | Why the page is slow and whether a fix helped |
75th percentile
The percentile Core Web Vitals are assessed at: at least 75% of page loads should meet the good threshold, separately on mobile and desktop.
Source: web.dev (Google), 20261
- Check your key templates, not just the home page: category, product or service, article.
- The Core Web Vitals report in Search Console groups similar pages – so you can see which template is slow.
- A low-traffic site may have no field data – then rely on the lab test, remembering that it's a single simulated load.
- The request waterfall in the browser's developer tools shows what loads, in what order and what blocks what.
In our SEO work we check technical health, including speed, with PageSpeed Insights every month – because speed matters for search too.
What counts as good
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Loading of the largest above-the-fold element | within 2.5 s | 2.5–4 s | over 4 s |
| INP | Response to taps, clicks and input | within 200 ms | 200–500 ms | over 500 ms |
| CLS | Layout shifts while loading | within 0.1 | 0.1–0.25 | over 0.25 |
62% / 77% / 81%
Share of mobile pages with good LCP, INP and CLS in 2025 – LCP remains the hardest metric to pass.
Source: HTTP Archive, 20266
What to fix
Three metrics – three different groups of causes.
LCP: the first screen within 2.5 seconds
LCP has four parts: server response (TTFB), the delay before the LCP resource (usually an image) starts loading, the time that resource takes to load, and the delay before it's rendered. Google recommends that most of the time be spent loading the HTML and the LCP resource, not waiting.
~40 / <10 / ~40 / <10%
The recommended split of LCP time: server response (~40%), resource load delay (<10%), resource load duration (~40%) and element render delay (<10%). These are guidelines, not strict rules.
Source: web.dev (Google), 20262
44%
Share of mobile sites with a good server response time (TTFB) in 2025; 40% needed improvement and 17% were poor.
Source: HTTP Archive, 20266
Server response
- Cache pages that are the same for everyone and serve them from a CDN
- Cut down plugins that run on every request
- Check server resources and database queries on the slowest templates
- Avoid redirect chains before the final address
The LCP image
- Never lazy-load the LCP image (loading="lazy")
- Mark it fetchpriority="high"
- If the image isn't discoverable in the HTML (a CSS background, say), preload it
- Inline small critical styles so rendering doesn't wait for a separate CSS file
16–17%
Share of pages that lazy-loaded their LCP image in 2025 – a common mistake that directly slows the first screen.
Source: HTTP Archive, 20266
Images: the most common speed reserve
76%
Share of mobile pages whose largest above-the-fold element (LCP) was an image in 2025; on desktop it was 85.3%.
Source: HTTP Archive, 20266
> 50%
The saving AVIF has shown against JPEG in some cases; WebP and AVIF compress better than older formats.
Source: web.dev (Google), 20264
What to change
- Use WebP or AVIF, keeping an older format only as a fallback
- Serve a correctly sized variant for each screen width (srcset and sizes), not one large file
- Give every image a width and height so the layout doesn't jump
- Lazy-load only images below the first screen
On this blog, every image is served at two widths and in two formats (AVIF and WebP) – the browser picks the smallest suitable one.
INP: when the page is slow to respond
INP measures the time from a tap or click to the next frame showing the result. It has three parts: input delay (while the browser is busy with other work), processing (while your code runs) and presentation delay (while the new frame is painted).
200 ms
A good INP is 200 milliseconds or less, assessed at the 75th percentile of page loads.
Source: web.dev (Google), 20263
What to change
- Review third-party scripts – chat widgets, tracking tags, A/B testing tools; each one occupies the main thread
- Break up long tasks and let the browser respond to the user in between
- Reduce DOM size: a large page tree is expensive to repaint after every interaction
- Show feedback immediately after a tap (a button state, say) and do the heavy work afterwards
CLS: when content jumps
A shopper aims for “Add to cart”, and at the last moment a cookie bar or an ad appears at the top – and they tap the wrong thing. CLS measures exactly these shifts.
What to change
- Reserve space for images, video and embeds (width and height, or an aspect ratio)
- Show the cookie bar and notices over the content rather than pushing it down
- Load fonts so that swapping fonts doesn't change the size of the text
- Leave space in advance for dynamic content (reviews, recommendations)
WordPress, Shopify and static sites
The causes are similar everywhere; only where they hide differs. On WordPress and WooCommerce sites, speed usually comes down to the theme, the number of plugins, caching and the server. On Shopify the platform runs the servers, but themes and apps add their own scripts – every new app is worth a speed test.
A speed plugin on top
- Yet another plugin is installed to “optimise everything”
- The LCP image is lazy-loaded along with everything else
- Third-party scripts stay as they were
- The lab score rises; field data barely moves
Fixing the cause
- It's established which metric is poor and on which template
- The LCP image is compressed and loaded first
- Unneeded scripts are removed, the rest deferred
- The result is checked in field data after 28 days
In what order to fix things
Speed checklist
Check your site
- Do you know your Core Web Vitals field data on mobile and desktop?
- Have you checked your key templates, not just the home page?
- Is the server response fast, with identical pages cached and served from a CDN?
- Is the LCP image loaded eagerly and marked high priority?
- Are images in WebP or AVIF and correctly sized for each screen?
- Does every image have a width and height?
- Do you know which third-party scripts load, and whether you need them all?
- Do the cookie bar and notices avoid pushing content around?
- Do you check speed after every update or new app?
How we can help
Speed isn't a one-off job: every update, plugin or new app can make it worse. Our website maintenance plans start at €149/mo and cover updates, daily backups, monitoring and a monthly report that includes security and speed notes.
For a new website, a speed check is included in every package, and a custom Next.js website (from €2,990) also includes Core Web Vitals optimisation. If a slow online store is losing sales, it's worth looking at the other reasons visitors don't buy too.
Write to us with your site's address and what feels slow. We reply within 1 business day. Before taking over maintenance of a site we didn't build, we carry out a technical audit first.
About the data in this article
Methodology
- Date
- Sample
- HTTP Archive Web Almanac 2025 (Performance chapter, Chrome UX Report data from July 2025), web.dev and Google for Developers documentation, a web.dev case study
- Criteria
- Figures only from primary sources, reproduced as published, with a link
- Thresholds and recommendations from Google's official documentation, checked on 2026-10-01
- The order of fixes and insights reflect how Oxtren Labs works and are marked separately
- Limitations
- Web Almanac data covers millions of websites worldwide, so it reflects the overall picture rather than a specific country or sector. Google's metrics and thresholds can change.
Frequently asked questions
Why does my PageSpeed Insights score change every time?
The score comes from the lab test – a single simulated load affected by server load and network fluctuations. The field data at the top matters more: it's the experience of real visitors over 28 days.
Does speed affect Google rankings?
Google recommends good Core Web Vitals for success in Search and says that, together with other page experience aspects, they align with what its core ranking systems seek to reward. But they are one factor among several – good scores don't guarantee rankings. Speed mostly decides whether a visitor who arrives stays.
Is installing a speed plugin enough?
Rarely. A plugin can compress files and switch on caching, but it won't fix a slow server, oversized images or third-party scripts. Badly configured, it can even lazy-load the LCP image – and slow the first screen down.
How long until I see results?
A lab test shows the change straight away. Field data in PageSpeed Insights covers the last 28 days, so the full change shows up there after about a month.
Sources and methodology
- web.dev (Google)Web Vitalsaccessed
- web.dev (Google)Optimize Largest Contentful Paintaccessed
- web.dev (Google)Optimize Interaction to Next Paintaccessed
- web.dev (Google)Image performanceaccessed
- Google for DevelopersAbout PageSpeed Insightsaccessed
- HTTP ArchiveWeb Almanac 2025: Performanceaccessed
- Google Search CentralUnderstanding Core Web Vitals and Google search resultsaccessed
- web.dev (Google)Milliseconds make millionsaccessed