Website Speed Optimisation: The Complete 2026 Playbook

How do I make my site faster? comes with the same answer nine times out of ten: fix the images, cut the third-party scripts, and use a modern host. Every other trick is a footnote to those three.

That said — the details matter. This is the full 2026 speed optimisation playbook. Every technique we use to hit Lighthouse 95+ on real client sites, in order of impact, with the specific settings that actually work.

1. Images — the biggest single lever

Images are typically 50–70% of a page's total weight. Halve their weight and you've almost halved the load time.

• Use AVIF first, WebP fallback. AVIF is 20–50% smaller than WebP; both are far smaller than JPEG/PNG.
• Ship responsive sizes — one hero image at 400w, 800w, 1200w, 1600w, 2000w. Browser picks the right one via srcset.
• Lazy-load below-the-fold images — native loading="lazy" on <img>.
• Prioritise the LCP image — fetchpriority="high" and loading="eager" on the hero.
• Use `next/image` if you're on Next.js — it handles all of the above automatically.

See our image optimisation guide for the deeper pipeline setup.

2. Third-party scripts — the invisible tax

Every third-party script adds weight, blocks the main thread, and depends on a network you don't control. Common offenders: chat widgets (Intercom, Drift), analytics stacks (GA4 + Hotjar + Segment), review widgets, live-chat popups, tag managers, ad tags.

Audit ruthlessly:

1. List every script — open DevTools → Network → filter by Script. Note what each one does.
2. Kill anything you can't justify — the maybe useful someday scripts are net negative today.
3. Defer everything non-critical — use next/script strategy="afterInteractive" or "lazyOnload".
4. Load chat widgets only after user interaction — most chat SDKs support a delayed init.

3. Hosting + CDN — the network layer

TTFB (Time to First Byte) is capped by your host. If your server takes 500ms to start responding, no amount of frontend optimisation gets you below that.

• Move off shared hosting if your TTFB is over 300ms consistently.
• Use a CDN — Vercel, Netlify, Cloudflare Pages all include one. See our CDN explained piece.
• Enable full-page caching where possible — static HTML at the edge is essentially free.
• Preconnect to critical third-party origins (<link rel="preconnect">) so DNS/TLS is done before the first request.

4. Fonts — the render-blocking sneak attack

Web fonts are render-blocking by default. A 100 KB font waterfall can add 500ms to LCP without anyone noticing.

• Self-host fonts via next/font or similar — no third-party DNS/TLS penalty.
• Preload the critical font (<link rel="preload" as="font">).
• Use `font-display: swap` to render text immediately with a system fallback.
• Ship variable fonts — one file, all weights, no waterfall.
• Load only the weights you actually use — 400 and 600 is usually enough for most sites.

5. CSS + JavaScript — cut the fat

Tailwind + Next.js already handle most of this — dead code elimination, tree-shaking, code-splitting per route. But watch for:

• Unused CSS from bloated frameworks — audit with Coverage tab in DevTools.
• Heavy client-side libraries — a 200 KB date picker for one date input is a red flag. Prefer native <input type="date"> or lightweight alternatives.
• Inline critical CSS — for above-the-fold styles, so first paint doesn't wait on a network request.
• Defer non-critical JS — anything not needed for first render should load after.

6. Caching — the compounding win

Every visit after the first should be near-instant thanks to caching. Set aggressive cache headers for static assets:

Cache-Control: public, max-age=31536000, immutable

For HTML: shorter cache times (max-age=3600) or use stale-while-revalidate patterns. See our caching guide for the full pattern.

7. Framework-level wins

If you're on Next.js:

• Use Server Components by default — they ship zero JS to the client.
• Static-generate what you can via generateStaticParams.
• ISR for content that updates occasionally — best of both worlds.
• Partial Prerendering (PPR) for pages with mixed static + dynamic content.
• Turbopack for faster dev builds (dev only; production is unchanged).

8. The measurement loop

Speed optimisation is a loop, not a one-shot:

1. Measure baseline — PageSpeed Insights on 5 representative pages.
2. Identify top 3 issues from the report.
3. Fix them — usually the biggest LCP contributor first.
4. Re-measure in a few days (field data has lag).
5. Repeat until you're green on Core Web Vitals.

9. The full audit checklist

The bottom line

There's no single silver bullet for speed. There are twenty small optimisations that compound into a fast site. Fix the images first — that's the biggest win. Then work down the list in order. Two weeks of disciplined work turns most red-scoring sites into green ones.