Free · Fast · Privacy-first

How to Improve Website Speed: A Complete Guide

This guide covers every major technique for improving website speed, from quick wins such as image compression to advanced techniques like CDN implementation, code splitting, and server-side caching.

Quick wins to advanced optimisations

🔒

Specific implementation steps for each technique

Expected impact for each improvement

Platform-specific tips for WordPress, Shopify, and custom sites

Cost
Free forever
Sign-up
Not required
Processing
In your browser
Privacy
Files stay local
FreeNo signupWhite-label

Add this Website Speed Test to your website

Drop the Website Speed Test into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

  • Files stay 100% in the visitor's browser
  • Responsive — adapts to any container width
  • Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/web-tools/website-speed-test?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Website Speed Test by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

The Most Impactful Website Speed Improvements in Order of ROI

Website speed optimisation follows a well-established hierarchy of impact, and respecting that hierarchy is the single most important discipline in performance work. The highest-ROI improvements are server-side because they affect every page load simultaneously and remove constraints that would otherwise cap any subsequent front-end work. Enabling full-page caching on a WordPress or CMS site reduces TTFB from 1 to 3 seconds down to under 200ms, with that one configuration change affecting every page on the site at once. Adding a CDN with edge caching, where Cloudflare's free tier is sufficient for most sites, serves cached pages from servers near each user and reduces latency for geographically distributed visitors by 40 to 80 per cent. These two changes (page caching and CDN) typically achieve 50 to 70 per cent of the maximum possible speed improvement on most sites and should be implemented before any front-end work begins.

Front-end optimisations follow server-side work and layer on top of a healthy server foundation. Image optimisation is the highest-impact front-end change for most sites: compress all images, convert to WebP format which is roughly 30 per cent smaller than JPEG at equivalent visual quality, and implement responsive images with srcset to serve appropriately sized variants for each device class. JavaScript deferral is the second most impactful front-end change: add defer or async attributes to all non-critical scripts, load third-party scripts such as analytics, chat widgets, and heatmaps with async or behind an interaction gate, and remove unused JavaScript identified through the Chrome DevTools Coverage tab. Critical CSS inlining eliminates render-blocking stylesheets for above-fold content by embedding the necessary rules directly in the head. Together, these front-end changes typically add another 15 to 30 per cent improvement on top of server-side optimisations.

Advanced optimisations provide diminishing returns but can push already-optimised sites into top-decile performance where the marginal gains translate into competitive differentiation. Resource hints, including preload for LCP images, preconnect for critical third-party origins, and dns-prefetch for secondary third-party origins, reduce waterfall bottlenecks by parallelising resource discovery so the browser can begin fetching critical assets before it encounters them in the document. HTTP/2 or HTTP/3 multiplexing eliminates the request queuing overhead that limits HTTP/1.1 performance, particularly on pages with many small assets. Service workers and offline caching enable near-instant repeat visits by serving cached assets without network requests. Browser caching with long max-age headers ensures returning visitors load pages from local cache rather than re-downloading unchanged assets.

The most successful performance programmes treat speed as a continuous discipline rather than a one-time project. After the initial optimisation sweep, set up automated monitoring using the PageSpeed Insights API or Lighthouse CI so any regression is caught within days rather than weeks. Add performance gates to the CI/CD pipeline that block deployments which would push key metrics below defined thresholds. Document a performance review step in the standard deployment checklist for any significant site change, including plugin installations, theme updates, and third-party integrations. Without these guardrails, sites that ship at 90 on mobile drift to 65 within a year as new content and scripts accumulate, and recovering that lost ground later is much harder than holding the line through routine measurement and gentle continuous correction.

How to use this tool

💡

Start by running the Website Speed Test to identify which areas need the most improvement, then apply the techniques most relevant to your failing metrics.

How It Works

Step-by-step guide to how to improve website speed: a complete guide:

  1. 1

    Optimise images, the highest-impact quick win

    Compress every image on the site using a tool such as Squoosh or TinyPNG that maintains visual quality while removing unnecessary file weight. Convert images to WebP format, which delivers roughly 30 per cent smaller files than JPEG at equivalent quality. Add explicit width and height attributes to every img tag to prevent CLS. Use loading="lazy" for below-fold images so they only load as the user scrolls toward them. Implement srcset with multiple resolutions so mobile devices receive appropriately sized variants rather than desktop master files.

  2. 2

    Enable server-side caching

    For WordPress sites, install WP Rocket or W3 Total Cache and configure the cache lifetime to match your content update frequency. For Shopify, caching is built into the platform but can be supplemented with app-level optimisations. For custom sites, implement Varnish, Redis, or Nginx FastCGI caching in front of the application layer. Target TTFB under 200ms after caching is correctly enabled, and verify the cache is actually serving responses by checking response headers for the appropriate cache hit indicators rather than assuming the configuration is working.

  3. 3

    Reduce and defer JavaScript

    Add defer or async attributes to every non-critical script so they do not block parsing of the document. Remove unused JavaScript by inspecting the Coverage report in Chrome DevTools, which shows the percentage of each loaded script that actually executes during the page lifecycle. Combine small scripts into fewer files where this does not break dependency ordering. For single-page applications, implement route-based code splitting so only the JavaScript needed for the current view loads on initial visit rather than the entire application bundle being shipped to every user.

  4. 4

    Add a CDN

    A CDN such as Cloudflare, Fastly, or CloudFront serves your assets from servers physically close to each user, which reduces TTFB for geographically distributed audiences and offloads bandwidth from your origin server. Cloudflare's free tier is sufficient for most small and medium sites and takes under thirty minutes to set up by changing DNS to point at their nameservers. Configure cache rules so static assets such as images, CSS, and JavaScript are served from the CDN edge with long cache lifetimes, while HTML pages may need shorter lifetimes depending on how dynamic the content is.

Real-world examples

Common situations where this approach makes a real difference:

WordPress site performance project

A WordPress site owner follows the guide in strict hierarchical sequence over three weeks of incremental changes. Installing a caching plugin drops TTFB from 1.4 seconds to 0.12 seconds in a single afternoon. Compressing all existing images with Imagify reduces the total page weight from 6MB to 1.2MB without any visible quality change. Deferring render-blocking scripts and converting the LCP image to WebP completes the front-end pass. Mobile Lighthouse score rises from 31 to 79 across the audit period, Core Web Vitals all pass Good thresholds, and organic traffic to the affected pages improves measurably over the following two months as field data confirms the improvements.

Shopify speed optimisation

A Shopify merchant applies the guide's Shopify-specific recommendations across their store. They remove eight unused apps that had accumulated over years of experimentation but no longer serve an active purpose. They convert all product images to WebP through a Shopify image optimisation app. They reduce the number of custom fonts loaded on every page from six weights to two, retaining the essential typography while eliminating the rest. They deactivate third-party scripts loaded for non-essential features such as old analytics tools and abandoned chat widgets. Mobile LCP improves from 4.8 seconds to 2.3 seconds, the store passes Core Web Vitals for the first time, and the resulting checkout flow improvement reduces cart abandonment.

Developer performance reference

A front-end developer uses this guide as their primary reference document for performance best practices when building new client sites from scratch, rather than treating performance as a final-week optimisation pass on an otherwise-completed build. Every new build follows the hierarchical sequence from server-side foundations through front-end optimisations during the build phase, which means each site launches with a mobile Lighthouse score of 85 or higher and passing Core Web Vitals from day one. The developer's portfolio of fast launches becomes a competitive advantage when pitching new business against agencies that ship slower work.

When to use this guide

Use this guide after identifying failing performance metrics, as a complete reference for website speed optimisation techniques, or when planning a systematic performance improvement project.

Pro tips

Get better results with these expert suggestions:

1

Fix server-side caching before front-end work

A 2-second TTFB cannot achieve a 2-second LCP no matter how well-optimised the front-end is, because every downstream metric inherits the TTFB delay one for one. Always address server-side caching first. For WordPress sites, WP Rocket or W3 Total Cache can be installed in roughly 10 minutes and typically reduces TTFB by 80 to 95 per cent on previously uncached sites. Only once TTFB is below 200ms should you turn attention to image compression and JavaScript optimisation, because those front-end fixes hit a hard ceiling determined by your server-side performance.

2

Convert images to WebP with fallback for legacy browsers

WebP images are 25 to 35 per cent smaller than JPEG at equivalent visual quality, which translates into proportionally faster image loading and lower bandwidth costs. Use the HTML picture element with WebP as the primary source and JPEG as the fallback for browsers that do not support WebP, which provides graceful degradation without sacrificing performance for the majority who do support it. Squoosh at squoosh.app provides a free browser-based WebP converter with side-by-side quality comparison. Modern CMS plugins handle WebP conversion automatically on upload, so the burden of manual conversion is gone for most teams.

3

Remove third-party scripts you do not actively use

Unused third-party scripts from previous tools, including old analytics platforms, abandoned chat widgets, and removed ad networks, commonly remain in production long after the tool itself was retired because no one circled back to remove the script tag. Each script adds DNS lookup, connection time, and script execution overhead to every page load. Audit your Network panel for third-party domains and remove any that no longer serve an active business purpose. Removing unused third-party scripts typically saves 200 to 500ms across an average page and improves INP by reducing main-thread work that competes with user interactions.

4

Set long cache lifetimes for static assets

Static assets such as images, CSS, and JavaScript that do not change frequently should be cached in the browser with long max-age headers, ideally one year for versioned assets that include a content hash in the filename. Add cache-busting query strings or content-hash filenames such as ?v=abc123 to allow cache invalidation when assets change without requiring users to manually clear their browser cache. Returning visitors will load most of the site entirely from browser cache, making repeat visits near-instantaneous and significantly improving user experience for the audience most likely to convert.

5

Fix the highest-impact issues first

Image compression and lazy loading, server-side caching, and removing unused JavaScript are consistently the three highest-impact improvements across all website types. Start with these before tackling more advanced optimisations.

6

Measure before and after each change

Make one change at a time and re-test after each one. This tells you exactly how much each improvement contributed to the overall score and prevents you from reverting a change that actually improved performance.

7

Performance is ongoing, not a one-time project

New plugins, theme updates, additional tracking scripts, and new content all add performance overhead over time. Schedule a quarterly speed audit to catch regressions before they significantly impact rankings or user experience.

FAQ

Frequently asked questions

The fastest high-impact improvements available to most sites are enabling page caching on your CMS, where WP Rocket for WordPress takes 10 minutes to install and can reduce TTFB by 80 per cent or more on previously uncached sites; adding Cloudflare's free CDN by changing DNS to point at their nameservers, which typically completes in under 30 minutes; and compressing and converting images to WebP across the site using a bulk-conversion plugin or tool. These three changes are achievable in a single afternoon without code changes for the average WordPress or CMS site, and they typically produce the largest speed improvements per hour of time invested anywhere in the optimisation toolkit.
The three quickest high-impact improvements consistently across thousands of audited sites are image compression and WebP conversion, which often reduces total page size by 50 per cent or more without any visible quality change; enabling full-page caching, which can reduce TTFB by 90 per cent on uncached CMS sites in a single configuration step; and deferring render-blocking scripts, which often reduces mobile FCP and LCP by 1 to 2 seconds with no functional change to the page. These three changes can be applied in roughly one working day on most sites and produce visible improvements in the next Lighthouse audit run, which makes them the right starting point for any speed optimisation programme regardless of the site's starting condition.
Google needs to re-crawl and re-evaluate pages after performance improvements before ranking impact appears in search results. Core Web Vitals field data uses a 28-day rolling window of real Chrome user measurements, so improvements in real user experience take 4 to 8 weeks to fully reflect in Search Console depending on how much traffic the affected URL groups receive. Ranking changes typically follow 1 to 4 weeks after Search Console data improves. The full cycle from deployment to visible ranking change is typically 6 to 12 weeks, which is why patience and continuous monitoring matter more than expecting immediate validation in the days following the deployment.
A Content Delivery Network stores copies of your site's assets on servers distributed worldwide so that when a user visits, assets are served from the nearest server rather than from your origin server alone. For geographically distributed audiences, a CDN can reduce TTFB and asset load times by 40 to 80 per cent for users far from your origin server, which is a transformative improvement that no application-level optimisation can match. Cloudflare's free tier is sufficient for most small and medium sites and takes under 30 minutes to set up by changing DNS to point at their nameservers. For any site with audience outside its origin region, a CDN is functionally mandatory rather than optional.
Whether to hire depends on the severity of the issues and your team's technical capability. For WordPress sites with moderate performance problems, a non-technical site owner can achieve significant improvements by installing WP Rocket, configuring Cloudflare, and following a structured guide such as this one. For complex custom-built sites or severe performance issues where the mobile score sits under 30, a specialist developer or performance consultant can deliver more comprehensive improvements faster than a self-directed effort. The ROI of speed investment is typically high: a 2x speed improvement on a site generating £10,000 per month from organic search is worth substantial spend because the resulting revenue lift compounds over time.
Three practices prevent regressions reliably and should be implemented together rather than in isolation. Set up automated weekly Lighthouse monitoring using the PageSpeed Insights API or a service such as SpeedCurve, with any score drop above a threshold triggering investigation. Add performance tests to your CI/CD pipeline using Lighthouse CI so builds fail if key scores drop below documented thresholds before they reach production. Document a performance review step in the standard deployment checklist for any significant site change. Regressions are most often caused by new plugins, new third-party scripts, or new unoptimised images added after the initial optimisation work shipped, so the guardrails focus on catching exactly these patterns early.
Several tools automate common optimisations and reduce the burden on engineering teams. WP Rocket handles WordPress caching, image optimisation, code minification, and several other tasks behind one paid plugin. Cloudflare provides CDN coverage, minification, image optimisation, and a generous free tier suitable for most sites. NitroPack offers all-in-one WordPress and WooCommerce performance automation as a paid service that handles complex optimisations without configuration. Imagify provides automatic WebP conversion and image compression as a WordPress plugin. Automatic tools handle the most common optimisations well, but manual optimisation is still required for advanced work such as JavaScript bundle splitting and critical CSS extraction tailored to specific page templates.
Focus on mobile first for almost every site, because Google uses mobile-first indexing and the mobile audience is dominant for nearly every consumer-facing category. Mobile performance is also structurally harder to achieve because mobile CPUs are slower, mobile networks are higher-latency, and mobile devices have less RAM and battery to spend on rendering. A site that performs well on mobile generally also performs well on desktop, but the inverse is not true. Test mobile as the priority and treat desktop as a secondary check, except in specific B2B or enterprise contexts where the audience genuinely lives on laptops and the mobile traffic is incidental rather than primary.
Yes, but with diminishing returns and a different risk-reward profile from sites starting at 40. A site at 80 already passes most Core Web Vitals on most pages and enjoys the basic Page Experience signal benefit, so the marginal ranking gain from reaching 90 is smaller than the gain from reaching 80 was originally. However, pushing into the top decile of performance for your category can become a competitive differentiator in tight SERPs where rivals also score in the 80s. Evaluate whether the engineering hours required would produce more value if invested in performance polish or redirected to content, links, or other parts of the marketing programme.

Related guides

More use-case guides for the same tool:

Ready to get started?

Open the full Website Speed Test — free, no account needed, works on any device.

Open Website Speed Test →

Free · No account needed · Works on any device