How to fix a slow website.

Most slow websites are slow for boring reasons: oversized images, too many third-party scripts, and cheap hosting. The fix is usually not a rebuild — it's an hour of measuring followed by a day of targeted work. Here's the order we do it in.

1. Measure first, guess never

Open PageSpeed Insights (pagespeed.web.dev) and run your homepage. You get two numbers that matter:

• LCP (Largest Contentful Paint) — when the biggest element appears. Under 2.5s is good, over 4s is a problem.
• Total page weight — check with your browser's Network tab. Under 1.5 MB is healthy; many slow sites ship 8–15 MB.

Run the test on a page that matters (homepage, top landing page), not just the one you happened to open.

2. Images — 70% of the problem

Almost every slow site we audit serves photos straight from a camera or stock site. Fixes, in order of impact:

• Resize. A photo displayed at 800px wide should not be a 5000px file.
• Convert to WebP or AVIF. Typically 60–80% smaller than JPEG at the same quality.
• Lazy-load everything below the fold: loading="lazy" on the <img> tag is enough.
• Set width and height attributes so the page doesn't jump while loading.

3. Fonts

Two font families is plenty. Host the files yourself instead of loading them from a third party, use font-display: swap, and ship only the weights you actually use. A "light" site that loads six font files is not light.

4. Third-party scripts

Chat widgets, analytics, heatmaps, social embeds — each one adds a network round-trip and a chunk of JavaScript. Open your Network tab and count them. Remove what you don't read the reports for. Defer the rest (defer or load after user interaction).

5. Hosting and caching

• Turn on compression (gzip/brotli) — one server setting, instant 60–70% text savings.
• Set cache headers so returning visitors don't re-download your CSS, fonts and images.
• If your audience is global, use a CDN or host static files in the region your visitors are in. A server 8,000 km away adds 200–300ms to every single request.

When it's not any of this

If your site is a heavy CMS with dozens of plugins, the database queries themselves can be the bottleneck — look at "Time to First Byte" in the Network tab. Over ~800ms on a cached page means the server, not the assets, is the problem. That's when a rebuild starts to make sense; see redesign or rebuild?

Don't have the time or the access to do this yourself? This is exactly our "Redesign & repairs" job — from $150, typically 1–7 days. Get an estimate.