How to speed up your website: what actually makes a difference

A one-second delay doesn’t sound like much, but visitors on phones feel every extra request and every oversized image. The good news: on most sites, three or four changes deliver the majority of the improvement. The trick is to measure first so you fix the real bottleneck rather than the one a plugin advertises.

Step 1: measure before changing anything

Run your homepage and one or two key templates (a product page, a blog post) through our website speed test. Note three things:

• Time to First Byte (TTFB): how long the server takes to start responding. Above about 0.8 seconds usually points to hosting, the database or missing page caching.
• Largest Contentful Paint (LCP): when the main content, often a hero image or headline, appears. The target is 2.5 seconds or less.
• Total page weight and request count: a typical content page should not need 5 MB and 150 requests.

Distinguish lab data (a simulated test run) from field data (real Chrome users, collected in the Chrome UX Report). Google ranks on field data; lab data is for debugging. Our Core Web Vitals guide explains the metrics in depth.

Step 2: fix images (usually the biggest win)

Images are typically the heaviest part of a page. Common problems and fixes:

Use the image compressor and WebP converter before uploading. Always set width and height attributes so the browser reserves space, and never lazy-load the hero image: give it fetchpriority="high" instead. Our image optimisation guide goes further.

Step 3: caching at every layer

• Page caching: on WordPress, a caching plugin or host-level cache serves pre-built HTML instead of running PHP and database queries on every visit. This alone can take TTFB from 1.5 s to under 0.3 s.
• Browser caching: static files with versioned names can be cached for a year:

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

• HTML should use a short cache or revalidation so updates appear quickly.
• Object caching (Redis, Memcached) helps database-heavy sites such as WooCommerce and membership sites.

Step 4: reduce JavaScript and third-party scripts

JavaScript is expensive: it has to download, parse and execute, often on a mid-range phone. Audit what each script is doing:

• Remove unused plugins, sliders, and “just in case” libraries.
• Load non-critical scripts with defer (or async for independent ones).
• Delay chat widgets, heatmaps and social embeds until user interaction.
• Review tag managers: ten marketing tags can cost more than your entire theme.
• Replace embedded YouTube iframes with a lightweight preview that loads the player on click.

Heavy JavaScript also hurts Interaction to Next Paint, the metric for how quickly the page responds to taps and clicks.

Step 5: CSS, fonts and the critical path

• Minify and combine CSS where your stack allows; remove unused CSS from page builders if possible.
• Self-host web fonts in WOFF2, limit yourself to two families and a few weights, and use font-display: swap.
• Preload only what’s truly critical, typically the hero image and one font file:

<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>

Over-preloading competes with the resources that matter and makes things slower.

Step 6: hosting, protocol and CDN

• Hosting: cheap shared hosting with an overloaded server is a ceiling no plugin can break. If TTFB stays high after page caching, upgrade or move.
• HTTP/2 or HTTP/3 and compression: confirm your server supports modern protocols and serves text with Brotli or gzip.
• PHP and runtime versions: newer PHP versions are measurably faster than old ones.
• CDN: a CDN such as Cloudflare, Bunny or Fastly serves static files from locations near the visitor. Useful for international audiences; less dramatic if all visitors are in one city near your server.
• Redirects: each redirect adds a round trip. Link directly to the final HTTPS URL.

Where to start on WordPress, Shopify and builders

• WordPress: use one well-configured caching plugin (or your host’s built-in cache), audit plugins (anything unused goes), choose a lightweight theme, and keep PHP current. Page builders add a lot of CSS and JavaScript; if speed is critical, a block theme is leaner.
• Shopify: you can’t change the hosting, so focus on the theme and apps. Each app can inject scripts into every page, and uninstalled apps sometimes leave code behind in the theme files.
• Wix and Squarespace: limited server control, so the main levers are image sizes, fewer embedded widgets and less animation.

Whatever the platform, measure again after each change so you know what actually helped.

Common mistakes

• Installing three optimisation plugins that fight each other (double minification, conflicting caches).
• Chasing a perfect 100 lab score while field data is already “good”.
• Lazy-loading the LCP image, which makes LCP worse.
• Testing only on desktop over office fibre. Test mobile with throttling.
• Forgetting third-party scripts added by marketing tools months later.

Website speed checklist

1. Measure TTFB, LCP, page weight and requests on key templates.
2. Resize, compress and convert images; add width/height; lazy-load below the fold only.
3. Enable page caching and long browser caching for versioned static assets.
4. Remove or defer non-essential JavaScript and third-party tags.
5. Self-host fonts in WOFF2 with font-display: swap.
6. Confirm HTTP/2+, Brotli/gzip and a current runtime version.
7. Add a CDN if your audience is spread out geographically.
8. Re-test, compare against the baseline, and keep a log of what changed.