A one-second delay in page load time reduces conversions by 7%. A three-second load time causes 53% of mobile users to leave. Google uses page speed as a ranking factor.

You already know your website should be fast. Here’s how to actually make it fast — this weekend.

Most slow websites aren’t slow for mysterious reasons. They’re slow because of a handful of well-documented problems that have been the same for years: oversized images, render-blocking scripts, no caching strategy, and hosting that shares a server with hundreds of other sites. Fixing them doesn’t require a rebuild. In most cases, the business you’re trying to beat in search results is running the exact same stack you are — the difference is they’ve done the basics and you haven’t. That’s the opportunity.

Step 1: Measure What You’re Working With

Before you fix anything, benchmark your current performance. Skipping this step is how people spend a weekend “optimising” a site and end up with no idea whether anything actually improved. Use these free tools:

  • Google PageSpeed Insights (pagespeed.web.dev) — gives you Core Web Vitals scores and specific recommendations
  • GTmetrix (gtmetrix.com) — detailed waterfall analysis showing exactly what loads and when
  • WebPageTest (webpagetest.org) — test from different locations and connection speeds

Run your homepage and your most important landing page. The landing page matters more than most people realise — it’s where your ad spend is pointed and where the conversion actually happens, so every tenth of a second there has a direct revenue impact. Note the numbers:

  • Largest Contentful Paint (LCP): Should be under 2.5 seconds
  • First Input Delay (FID): Should be under 100 milliseconds
  • Cumulative Layout Shift (CLS): Should be under 0.1
  • Total page weight: Ideally under 2MB

Write these down. You’ll want something to compare against when you’re done. The other thing to note is that PageSpeed scores can swing by ten or fifteen points run to run, especially on the mobile score. Run each test two or three times and work from the median, not the best.

Step 2: Fix Your Images (Biggest Win)

Images are the number one cause of slow websites. They often account for 50-80% of total page weight. On a typical marketing site, you’ll find a 4MB hero image that was exported from Photoshop with maximum quality, dropped into the CMS, and never touched again. That single image is probably doing more damage to your load time than every plugin on the site combined.

What to do:

  • Convert all images to WebP format (30-50% smaller than JPEG with the same quality)
  • Set explicit width and height attributes on every <img> tag (prevents layout shift)
  • Implement lazy loading — add loading="lazy" to images below the fold
  • Use responsive images with srcset to serve appropriately sized images per device
  • Compress images before uploading — TinyPNG or Squoosh are free tools

If you’re on WordPress, install ShortPixel or Imagify to auto-convert and compress. Both will process your existing media library as a one-off, then handle new uploads automatically. It’s one of the rare occasions where installing a plugin genuinely helps performance rather than hurting it.

The one image you should pay extra attention to is the hero. It’s the largest image on the most visited page, and it’s the first thing the browser has to render to show the page as “loaded.” Get that one right — correct size, correct format, served from a CDN — and your LCP score will often jump before you’ve touched anything else.

Expected impact: 40-60% reduction in page weight.

Step 3: Eliminate Render-Blocking Resources

When your browser loads a page, it has to download and parse CSS and JavaScript before it can show anything. If those files are large or numerous, the page appears blank for seconds. This is particularly painful on mobile, where the browser has less CPU to throw at parsing and the user has already decided you’re slow before any content appears.

What to do:

  • Move non-critical JavaScript to the bottom of the page or add defer attribute
  • Inline critical CSS (the styles needed for above-the-fold content) directly in the <head>
  • Remove unused CSS — tools like PurgeCSS can strip what you don’t need
  • Minimize the number of external scripts (analytics, chat widgets, fonts) — each one adds a network request

The biggest win in this category usually comes from whatever framework the site is built on. A default WordPress theme loads a surprising amount of CSS and JS you’re not actually using — sliders that don’t appear on every page, block editor styles on pages that never render blocks, jQuery libraries loaded for a single form. Audit what’s actually being served, and remove anything that isn’t pulling its weight.

Expected impact: 0.5-2 seconds faster LCP.

Step 4: Enable Caching

Without caching, every visitor downloads every file on every page load. With caching, returning visitors load most assets from their local browser cache, and your server delivers finished HTML instead of running through the database for every request.

What to do:

  • Set browser cache headers for static assets (images, CSS, JS) — aim for 1 year expiry
  • Enable server-side caching if you’re on WordPress — WP Super Cache or W3 Total Cache
  • Use a CDN (Content Delivery Network) — Cloudflare offers a free tier that caches and serves your site from 300+ locations worldwide

A CDN is the highest-leverage change in this post. Routing your traffic through Cloudflare takes roughly twenty minutes to set up, costs nothing for most sites, and immediately cuts your Time to First Byte for every visitor outside your server’s region. For a site hosted in the US with visitors in Europe or Asia, the difference can be more than a second of latency saved per request — before you’ve touched a single line of code.

Expected impact: 50-80% faster load times for returning visitors.

Step 5: Optimize Your Fonts

Custom fonts look great but often add 200-500KB of extra downloads, plus blocking time while the browser waits for them.

What to do:

  • Limit font weights — do you really need 300, 400, 500, 600, 700, and 800? Most sites need 2-3 weights.
  • Use font-display: swap so text is visible immediately while fonts load
  • Self-host your fonts instead of loading from Google Fonts — eliminates a third-party connection
  • Consider variable fonts — one file covers all weights

Expected impact: 100-300KB reduction and faster text rendering.

Step 6: Reduce Third-Party Scripts

Every third-party script (analytics, chat widgets, marketing pixels, social embeds) adds load time, blocks rendering, and often loads its own additional scripts. Third-party scripts are particularly dangerous because they’re outside your control. A chat widget that was fine last month might ship a new version that adds half a megabyte of JavaScript, and you won’t find out until your PageSpeed score drops.

Audit your scripts:

  • Do you still use that chat widget? Is it generating conversations?
  • Are you running three analytics tools when one would do?
  • That social media share bar — is anyone clicking it?

What to do: Remove anything that isn’t delivering measurable value. For scripts you keep, load them asynchronously with async or defer. For marketing pixels you can’t fully remove, consider using Google Tag Manager to consolidate them and load them after the page has rendered — you still get the tracking, but the user isn’t waiting on it.

Expected impact: Varies widely — removing a single heavy widget can save 1-2 seconds.

Step 7: Upgrade Your Hosting

If you’ve done everything above and your site is still slow, the problem might be your server. Cheap shared hosting puts hundreds of sites on one server, and performance suffers. You can optimise your front-end perfectly and still get a TTFB of 800ms because the server is overloaded with other people’s traffic.

Options:

  • Managed WordPress hosting: Kinsta, WP Engine, or Cloudways — purpose-built for WordPress performance
  • Static hosting: If your site doesn’t need a database, deploy to Vercel or Netlify for sub-second loads
  • Edge hosting: Cloudflare Pages or similar — your site is served from the server closest to each visitor

The hosting upgrade is the change people put off the longest, usually because it involves a migration. But the math is straightforward: if your site is generating any revenue at all, the difference between $5/month shared hosting and $30/month managed hosting is trivial compared to the conversions you’re losing to slow load times. Run the numbers on your own traffic before assuming the cheaper option is saving you money.

Expected impact: 30-50% faster server response time (TTFB).

The Quick Wins Checklist

If you only have a few hours this weekend, do these in order:

  1. Compress and convert images to WebP
  2. Enable a CDN (Cloudflare free tier)
  3. Enable browser caching
  4. Remove unused third-party scripts
  5. Add loading="lazy" to below-fold images
  6. Add defer to non-critical JavaScript

These six changes alone can transform a 5-second load time into a 2-second one.

Why This Matters Beyond Speed

Fast websites rank higher in Google. They convert more visitors. They reduce bounce rates. They improve user satisfaction scores. They cost less in hosting and CDN bandwidth.

But the more interesting effect is cumulative. Every search session a user runs compares your site to your competitors. If yours loads first, the user reads your content first, forms their first impression based on your copy, and is primed to treat you as the default. The competitor whose page took another second and a half to appear is already at a disadvantage, regardless of whether their content is actually better. Speed buys attention, and attention is what everything else downstream depends on.

Performance is not a technical detail. It’s a business advantage. And unlike most business advantages, this one is fixable in a weekend.