Website speed case studies floating around the internet often show a single best-case result presented as typical. Rather than repeat that pattern, here's the actual playbook I use when a client's site is slow, and the realistic range of impact each step tends to have — so you can judge your own project honestly instead of borrowing someone else's headline number.
Step 1 — Find out what's actually slow first
Before touching code, run the URL through PageSpeed Insights and read the diagnostics, not just the score. Render-blocking resources, unoptimized images, and unused JavaScript point to three completely different fixes — guessing wastes time.
Step 2 — Images, almost always the biggest single win
Unoptimized hero images and product photos are the single most common cause of a slow LCP. Migrating from raw <img> tags serving full-resolution PNGs to next/image with AVIF and WebP output and correct responsive sizes typically cuts image payload by 60 to 85 percent on image-heavy pages. This is usually where the largest, fastest win is.
Step 3 — Cut the JavaScript that never needed to ship
- Audit every "use client" boundary — move it down to the smallest interactive component, not the whole page.
- Replace heavy client-side libraries (a large date-picker or charting library loaded on every page) with dynamic imports so they only load when actually rendered.
- Remove unused dependencies — a bundle analyzer (next build with ANALYZE=true) will show you exactly what's shipping.
Total JS reduction from this step varies a lot by starting point — a site that was over-relying on client components can often cut its client JS bundle by 30 to 50 percent, which shows up directly as a better INP score.
Step 4 — Static generation over server rendering wherever possible
If a page's content doesn't change per request, generate it at build time (SSG) or on a schedule (ISR) instead of computing it fresh on every visit. This mainly improves Time to First Byte (TTFB), which matters more than people think — a slow TTFB delays everything downstream, including LCP.
Step 5 — Fonts and third-party scripts
Self-host fonts via next/font with display: swap. Audit every third-party script (analytics, chat widgets, ad pixels) and load non-critical ones with next/script's lazyOnload strategy so they don't compete with the main content for bandwidth on first load.
Realistic expectations
Combined, these steps commonly take a neglected, image-heavy site from a Lighthouse performance score in the 30s to 50s up into the 80s to 90s range — which in practice often does translate to load-time reductions in the 40 to 70 percent range depending on how unoptimized the starting point was. The honest answer is: it depends entirely on what was wrong to begin with, and the only way to know your own number is to measure your own site before and after.