Most slow websites can recover 60–80% of their speed without a rebuild. The other 20–40% is structural — locked inside the platform — and no plugin-shuffling gets it back. This post is the ordered fix list: what to try first, what each fix buys you in real milliseconds, and the failure modes that mean you've hit the ceiling.

Fixes are ordered by impact-vs-effort, not what's fashionable. Image compression is boring and it's where most sites get back the most speed.

Not sure how slow your site actually is? Run a free 30-second audit → — it pulls your live Lighthouse scores, Core Web Vitals and the top bottlenecks before you start guessing at fixes.

First: diagnose with the right three tools

PageSpeed Insights. Google's own Lighthouse runner. Most important score: mobile Performance. Under 50 is bad, 50–89 is improvable, 90+ is genuinely fast. The Core Web Vitals panel breaks it down — Largest Contentful Paint (load), Interaction to Next Paint (responsiveness), Cumulative Layout Shift (visual stability). These are Google's actual ranking signals.

GTmetrix. Its waterfall shows exactly which file is loading when — the 1.4MB hero, the third-party script blocking render. PageSpeed tells you you're slow; GTmetrix shows you why.

WebPageTest. Test from real devices, real connections, real locations. If you serve AU customers, run it from Sydney on 4G Slow — that's what most mobile visitors actually experience. Sites that score 75 on Lighthouse desktop often look like 35 on a real Android over Sydney 4G.

Fix 1: Image compression and resizing

On 80% of slow sites we audit, images are the biggest single problem. A 3.2MB hero. A logo saved as a 600KB PNG. Stock photos at 4000×3000 resized in CSS.

Resize to display size. A hero shown at 1920×1080 should be that size in the file. Resize in Squoosh before uploading.
Convert to WebP or AVIF. WebP is universally supported, 25–35% smaller than JPEG. Use cwebp for batch, Squoosh for one-offs.
Use the <picture> element so modern browsers get WebP and older ones get JPEG fallback.
Hero under 200KB, content under 80KB, thumbnails under 30KB.

Payoff: image optimisation alone often takes Lighthouse mobile from the 30s to the 60s. Highest-leverage thing you can do in a day.

Fix 2: Lazy-load below the fold

Every image, video and iframe below the fold should be lazy-loaded. Add loading="lazy" to every <img> and <iframe> that isn't visible on first paint. Native browser feature, no library needed. Five-minute job.

Watch out for lazy-loading the LCP image. Your hero — the big one above the fold — should not have loading="lazy". PageSpeed Insights flags this if you get it wrong.

Payoff: 10–25% faster initial load on image-heavy pages.

Fix 3: Font optimisation

A Google Fonts embed pulling four weights ships 200–400KB of font files and blocks text rendering until they download.

Subset your fonts. If you only use Latin, don't ship Cyrillic, Greek and Vietnamese. glyphhanger does this automatically.
Use font-display: swap in your @font-face declarations. Fallback text shows immediately while the custom font loads.
Self-host fonts instead of pulling from Google. Removes a DNS lookup. google-webfonts-helper grabs the optimised files.
Preload critical fonts with <link rel="preload" as="font" type="font/woff2" crossorigin>.

Payoff: 200–800ms faster LCP. Low effort.

Fix 4: Defer render-blocking JS and CSS

PageSpeed Insights names every offender under "Eliminate render-blocking resources."

Add defer or async to non-critical <script> tags. Most analytics, pixels and widgets can be deferred.
Inline critical CSS — the CSS for above-the-fold content goes directly in the <head>. Tools like Critical automate this.
Async non-critical CSS with the media="print" onload="this.media='all'" pattern.

Payoff: 300ms–1.5 seconds off LCP.

Fix 5: Audit and defer third-party scripts

A typical small business site carries 8–15 third-party scripts — Google Analytics, Meta Pixel, LinkedIn Insights, Hotjar, Intercom, chat widgets. Half aren't earning their cost.

Audit. Chrome DevTools → Network → filter by "JS" and "3rd party." Ask of each: is this earning the speed it costs?
Remove what you're not using. Old Hotjar from a dead project. The chat widget marketing trialled and forgot. The pixel from an ended campaign. Each is 30–100KB and a render-blocker.
Defer everything that doesn't need first paint. Analytics doesn't need to load before the user sees the page.
Use Partytown for scripts you can't remove — it moves them off the main thread.

Payoff: 400ms–2 seconds off Total Blocking Time. One of the most consistent wins on sites 2+ years old.

Fix 6: Add a CDN

A CDN serves static files from a server geographically near each visitor. For AU and NZ businesses, a Sydney edge versus a US origin is worth 200–500ms per file request.

Put Cloudflare or Vercel in front of the site. Cloudflare's free tier covers most small business needs. Both handle caching, Brotli and HTTP/2 automatically. Setup is a DNS change — under 30 minutes.

Payoff: 200–700ms faster TTFB.

Fix 7: Server response time (TTFB)

TTFB above 600ms means the server is the bottleneck. Above 800ms means hosting tier or database is the problem.

Hosting tier. Shared WordPress hosting at $5/mo will be slow. Move to managed (WP Engine, Kinsta, Cloudways) or a proper VPS. Budget $30–$150/mo.
Database queries. A WordPress DB with 50,000+ post revisions and orphan metadata slows every query. WP-Optimize cleans it up.
Caching. A WordPress site without page caching rebuilds every page on every request. WP Rocket, W3 Total Cache or LiteSpeed Cache cuts TTFB dramatically.

Payoff: 300ms–1.2 seconds off TTFB.

WordPress-specific: plugins, theme, hosting

If you're on WordPress and slow, it's almost always one of three things — too many plugins, a heavy theme, or cheap hosting. In that order.

Plugin audit. Deactivate every non-essential plugin. Reactivate one at a time, retesting in PageSpeed after each. Ones that drop the score 5+ points are removal candidates. Common offenders: Elementor, WPBakery, Divi, social sharing, popups, form plugins loading on every page.

Theme weight. Some themes ship 2–3MB of CSS and JS regardless of content. Avada, BeTheme, The7 are notorious. A lighter theme (GeneratePress, Kadence, Blocksy, Astra) usually halves page weight. Significant migration but cheaper than a rebuild.

Hosting. On $10/mo shared, no plugin work fixes TTFB. Move to managed — conversion math usually justifies $80–$150/mo within a month.

This recovers 40–60% of speed on most WordPress sites. The other 40% is structural — a Divi or Elementor site has a ceiling that won't move — and that's rebuild territory.

Shopify-specific: theme apps and script pile

On Shopify, look at two things first: theme apps and script tags.

Theme apps. Many Shopify apps inject JavaScript into every storefront page, used or not. A review widget on the about page. A countdown timer on the contact page. Each adds 50–200KB and a render-blocker. Open theme.liquid and audit every <script> tag — many apps have page-targeting options you've never configured.

Theme weight. Dawn (Shopify's free reference theme) typically scores 80+ on mobile Lighthouse. Some premium themes score 40–60. Switching to a custom theme built on Dawn's foundation is usually a one-week project, not a rebuild.

Payoff: 30–50% speed gain from a good app and theme audit, without leaving the platform.

The diminishing-returns ceiling

There's a point where every reasonable optimisation is done and the site is still slow. The signs:

Lighthouse mobile won't move above 60 no matter what you remove
TTFB stays above 700ms after caching and CDN
HTML payload is 500KB+ before any JS loads
Stripping every third-party script only gains 5–10 points

When you hit this wall, the platform itself is the problem. Webflow ships its runtime on every page. WordPress with a heavy page builder ships render-blocking weight you can't strip. Squarespace's CSS alone is 400KB+ before content. Wix is its own category of slow.

Hand-built sites that consistently score 90+ do so because they were architected for performance from day one, not retrofitted into it. We wrote up the platform mechanics in why Webflow sites break in six months — the same forces that cause decay also cap the speed ceiling.

When to rebuild instead

A rebuild is the right call when:

You've done the fixes above and you're still under Lighthouse mobile 60.
Your platform ships render-blocking weight you can't remove (Webflow, Squarespace, Wix, heavy WordPress page builders).
The site is measurably costing you money — fewer enquiries, lower rankings, higher bounce.
You'd also benefit from the other things a rebuild brings (cleaner brand, better CMS, real ownership).

If three or four are true, the rebuild pays back faster than another year of patches. We did the maths in the real cost of a slow website for small business — for most AU small businesses a one-second mobile speed gain is worth $20,000–$60,000 a year. And if rankings have slipped while the site got slower, why your Google rankings dropped walks through whether speed is the cause or something else.

The honest closing

Most slow sites can recover 60–80% of their speed through the fixes above. Image compression, lazy loading, fonts, deferring third-party scripts, a CDN, a hosting upgrade — cheap, fast, real wins. Done in a focused week, they take a typical Lighthouse 35 to a 70+. Enough for most businesses.

The remaining 20–40% is structural. It lives inside platform choices and render-blocking runtimes. Fixing it requires rebuilding, and rebuilding is a different project with a different budget. If you've worked through every fix here and the score won't move, you've hit the ceiling.

Want the diagnostic done for you? Run a free 30-second audit → — we pull your live Lighthouse scores, Core Web Vitals and the specific top-three bottlenecks dragging you down. If the fix is a one-week optimisation pass, we'll tell you. If it's a rebuild, we'll tell you that too. No pitch, just the actual answer for your site.

Related reading: the real cost of a slow website for small business, why Webflow sites break in six months, and our custom web design service in Melbourne if you've decided the rebuild is the right call.