How to speed up your website

Faster pages feel better to use and are easier on mobile connections. Google’s Core Web Vitals describe real-visitor experience with three main measures: LCP, INP and CLS. This guide explains them in plain English, lists fixes that usually help small sites, and points you at a free test you can run yourself.

Measure your site with our free speed test (powered by Google PageSpeed Insights). Lab scores are a simulated test on a set device and network. Field data shows real Chrome visitors when Google has enough samples. Neither is a promise of search ranking, and scores can change between runs.

Core Web Vitals — good thresholds

• LCP (Largest Contentful Paint) — when the main content appears. Good: at or under 2.5 seconds.
• INP (Interaction to Next Paint) — how quickly the page responds to taps and clicks. Good: at or under 200 milliseconds. INP replaced FID as a Core Web Vital in March 2024.
• CLS (Cumulative Layout Shift) — how much the layout jumps while loading. Good: at or under 0.1.

Lab tools also report First Contentful Paint, Speed Index and Total Blocking Time. Those help debugging. For real users, focus on field LCP, INP and CLS when the Chrome UX Report has data for your URL or origin.

Improve LCP

LCP is often a big image, a heading block or a hero video poster. Practical moves:

• Compress and correctly size the hero image; serve modern formats (WebP or AVIF) when your stack allows.
• Preload only the true LCP image; do not lazy-load it.
• Cut slow server response (TTFB): caching, a leaner home page, nearer hosting, fewer heavy plugins on first paint.
• Avoid long redirect chains before the first HTML response — see redirects and broken links.
• Inline a tiny bit of critical CSS if your tooling supports it; defer the rest.

Improve INP

INP reflects how long the page takes to respond after a tap, click or key press. Heavy JavaScript is the usual suspect.

• Reduce first-load JavaScript; split bundles; delay non-essential scripts until after interaction or idle.
• Break long tasks so the browser can handle input sooner.
• Audit third-party tags (chat widgets, heavy analytics, tag managers, embeds). Each one competes for the main thread.
• Prefer simpler UI patterns over large client-side frameworks on marketing pages that do not need them.

Improve CLS

Layout shift happens when something appears or resizes without reserved space — late images, web fonts, embeds, or banners injected above existing content.

• Set width and height (or CSS aspect-ratio) on images and iframes.
• Avoid inserting cookie banners or ads above content in a way that pushes everything down after first paint; reserve space or overlay carefully.
• Load fonts with a strategy that limits reflow (for example font-display: swap with fallback metrics that are close to the final face).
• Watch carousels and sticky headers that change height as they initialise.

Lab vs real visitors

A lab test (Lighthouse via PageSpeed Insights) uses a controlled environment. It is excellent for finding opportunities and regressions. Real-visitor data needs enough Chrome traffic over a recent period; new or low-traffic sites often show “not enough real-visitor data”. Use lab data to fix; use field data, when present, to confirm real users are seeing healthy LCP, INP and CLS.

We label the two clearly on the speed test results. Google does not endorse this site; we call their API and show a plain-English summary.

A sensible order of work

1. Fix huge images and obvious redirect chains.
2. Remove or delay third-party scripts you do not need on first load.
3. Add caching and compression at the host or CDN.
4. Reserve space for media and embeds to calm CLS.
5. Re-test on mobile after each change; then check desktop if you care about that profile separately.

Hosting, caching and compression

Many small sites gain more from basic platform hygiene than from micro-optimising CSS. Turn on HTTPS-aware caching for static assets, enable Brotli or gzip text compression, and ensure HTML for logged-out visitors can be cached safely at the edge when the page is public. Avoid shipping multi-megabyte page builders on a simple brochure home page. If a plugin is only needed on one form page, do not load it everywhere.

Monitor the first server byte time after a host move. A distant origin or a cold server-side render can dominate LCP before images even start. A CDN in front of static files is often enough; dynamic personalisation should be layered carefully so the default page stays fast.

Practical next steps

1. Run the speed test on mobile (default), then desktop as a separate run if you need it.
2. Work through the top opportunities it lists.
3. Re-test; expect small score wobble between runs.
4. Still run the full free scan for HTTPS, headers, email auth and links — speed is only one slice.

Informational only. Not a security audit, legal advice or a guarantee.

All guides · Free scan