Gearboxly
Programming

How to Improve Website Speed (Core Web Vitals)

By Gearboxly7 min read

A slow site loses visitors and rankings — speed is a confirmed Google ranking factor, and every extra second measurably increases bounce rate. The good news: most sites are slow for the same few reasons, and fixing them doesn't require a rebuild.

This guide walks through the changes that move the needle most, roughly in order of impact, so you spend effort where it counts instead of chasing a perfect score.

What you need

  • A speed test result (test the real page, on mobile, more than once).
  • Access to your images, theme/code, and hosting or CDN settings.
  • Your Core Web Vitals from a field-data tool where possible, not just a lab score.

Step-by-step

  1. 1

    Measure first, on mobile

    Run a page speed test on the actual page and on mobile, a couple of times. Note the largest contentful paint (LCP), layout shift (CLS) and interaction delay — fix what the report flags, not guesses.

  2. 2

    Fix your images

    Images are the number-one cause of slow pages. Serve them at the displayed size, use modern formats (WebP/AVIF), compress them, and add width/height so they don't cause layout shift.

  3. 3

    Cut render-blocking code

    Defer or async non-critical JavaScript, and remove unused CSS/JS. Anything that blocks the first paint delays everything the visitor sees.

  4. 4

    Enable caching and compression

    Turn on browser caching and Gzip/Brotli compression so repeat visits and assets load from cache instead of being re-downloaded and re-sent in full.

  5. 5

    Put a CDN in front

    A content delivery network serves your assets from a location near each visitor and absorbs traffic spikes — often the biggest single win for a site on one server.

  6. 6

    Reduce layout shift

    Reserve space for images, ads and embeds with explicit dimensions so content doesn't jump as things load — that's your CLS score, and it's cheap to fix.

Examples

  • Swapping a 2 MB hero JPEG for a properly sized 180 KB WebP cut a page's LCP from 4.1s to 1.9s — the single biggest fix on that site.
  • Adding width and height to images removed the content 'jump' on load, dropping CLS from 0.28 (poor) to 0.02 (good).

Tips

  • Optimise images first — it's almost always the largest, cheapest win.
  • Test on mobile with throttling; a fast desktop hides the experience most visitors actually get.
  • Chase the flagged issues, not a perfect 100 — the last few points rarely affect real users.
  • Lazy-load below-the-fold images so the visible part loads first.
  • A CDN helps most if your server is far from your visitors or you get traffic spikes.

Common mistakes

  • Uploading huge, unsized images. Resize to the displayed dimensions, compress, use WebP/AVIF, and set width/height.
  • Optimising only for desktop. Test on throttled mobile — that's where speed problems and most traffic live.
  • Chasing a perfect score. Fix the flagged Core Web Vitals; the final points rarely change the real experience.
  • Ignoring layout shift. Reserve space for images, ads and embeds so content doesn't jump (CLS).

Conclusion

Website speed comes down to a short list: optimise images, cut render-blocking code, enable caching and compression, and put a CDN in front. Measure on mobile, fix what the report flags, and aim for 'good' Core Web Vitals rather than a perfect score.

Tools for this task

Frequently asked questions

Usually large, unoptimised images, followed by render-blocking JavaScript and CSS. Fixing images alone often produces the biggest improvement.

Google's user-experience metrics: LCP (loading), CLS (visual stability) and INP (responsiveness). They're a ranking factor and a good checklist for real-world speed.

Yes, especially if your visitors are far from your server or you get traffic spikes — it serves assets from a nearby edge location and caches them.

No — aim for 'good' Core Web Vitals. The last handful of points rarely affects real users and can cost disproportionate effort.

Related guides