Website Speed Optimisation: The Complete 2026 Guide to a Faster Site

Why website speed is both a ranking and a revenue factor

Google has used page speed as a ranking signal since 2010 and, since 2021, uses Core Web Vitals (which centre heavily on loading performance) as an explicit ranking factor. But the more direct business impact of website speed is on conversion rate: research by Portent found that e-commerce sites loading in 1 second convert 5× better than sites loading in 10 seconds, and even the improvement from 3 seconds to 1 second delivers a 2× conversion uplift.

For UK, Australian and US service businesses, a page that loads in 1.5 seconds will consistently generate more enquiries than the same page loading in 4.5 seconds — from the same traffic volume, with no other changes. Speed optimisation is often the highest-ROI technical investment available to businesses that haven't yet addressed it.

Diagnosing your site's speed problems

Start with Google's PageSpeed Insights (pagespeed.web.dev) for both mobile and desktop scores. The report provides a field data section (real CrUX data from actual Chrome users) and a lab data section (Lighthouse scores from a controlled test). Both matter — field data is what Google uses for ranking; lab data is what you optimise against.

Chrome DevTools' Performance panel provides the most granular diagnosis available. Load your page with the Performance recorder running and examine the waterfall view: which resources take the longest to load? Which JavaScript tasks block the main thread? What is the LCP element and when does it load relative to page start?

Screaming Frog's site audit and the Chrome extension WebPageTest provide additional perspectives — particularly for identifying page weight outliers across your site at scale, rather than one page at a time. WebPageTest's filmstrip view shows visually exactly when different parts of your page become visible, which is invaluable for diagnosing perceived performance (what users experience) versus technical metrics.

Image optimisation: the biggest single speed improvement for most sites

Images account for an average of 50–60% of total page weight on most business websites. Unoptimised images — large JPEG files loaded at full resolution regardless of the device viewing them — are the most common cause of poor LCP and slow overall page load times.

Convert all images to WebP format: WebP files are typically 25–35% smaller than equivalent JPEG files at the same visual quality. AVIF offers even better compression (50% smaller than JPEG) and is supported by all major browsers in 2026. For hero images and above-the-fold content, implement AVIF with WebP and JPEG fallbacks using the HTML `<picture>` element.

Implement responsive images with `srcset` and `sizes` attributes: serve a 400px wide image to a mobile viewport and a 1200px wide image to a desktop viewport rather than loading the full-resolution image on every device. This single change can reduce mobile page weight by 60–70% for image-heavy sites.

Lazy-load all images that are not visible in the initial viewport: add `loading='lazy'` to all `<img>` elements except those in the hero section (lazy-loading the LCP image delays it unnecessarily — it should load eagerly with high fetchpriority). Lazy loading defers the loading of off-screen images until the user scrolls toward them, reducing initial page weight significantly.

JavaScript and CSS optimisation

JavaScript is the most common cause of poor INP (Interaction to Next Paint) and contributes significantly to slow LCP through render-blocking. Audit your JS bundle with Chrome DevTools' Coverage tab — it shows which JavaScript code is actually executed on page load versus which is loaded but unused. Unused code is pure overhead.

Code splitting (loading only the JavaScript needed for the current page) is the structural fix for large JS bundles. React applications built with Next.js, and Vue applications built with Nuxt, both support automatic code splitting. Manual code splitting using dynamic `import()` statements works for non-framework JavaScript.

Third-party scripts — chat widgets, analytics, A/B testing tools, retargeting pixels, cookie consent managers — often contribute more to load time than your own code. Audit every third-party script in your `<head>`: does it load synchronously? How large is it? What does it do to main thread blocking time? Load non-critical scripts with `defer` or `async` attributes, and consider whether chat widgets (often 100–200KB of JavaScript) are worth the performance cost on pages where they're rarely used.

Minify and compress all CSS and JavaScript. HTTP compression (Gzip or Brotli) should be enabled at the server or CDN level — Brotli achieves 15–25% better compression than Gzip for text resources. Most CDNs and managed hosting providers enable this by default, but verify with the Network tab in Chrome DevTools (check Content-Encoding header).

Server, hosting and CDN optimisation

Server response time (TTFB — Time to First Byte) is the upstream factor that all other optimisations depend on. If your server takes 1.5 seconds to respond, your LCP cannot be under 2.5 seconds regardless of how optimised your front end is. Target TTFB under 200ms for UK and Australian users.

Upgrade hosting infrastructure if your TTFB is over 600ms: shared hosting (£2–£5/month plans) consistently under-performs for business websites. Managed WordPress hosting (Kinsta, WP Engine, Cloudways at £20–£80/month) typically delivers 10× better TTFB than shared hosts. For custom applications, server-side caching (Redis, Varnish) combined with optimised database queries resolves most TTFB issues.

A CDN (Content Delivery Network) caches your static assets and, in some cases, full page responses at edge nodes geographically close to your users. Cloudflare's free tier provides a CDN for static assets and meaningful TTFB improvement from their global network. UK businesses serving Australian or US users (or vice versa) benefit most dramatically from CDN adoption — latency from a single UK server to an Australian visitor can be 300–400ms; a Sydney CDN edge node reduces this to under 50ms.

Enable HTTP/2 or HTTP/3 on your server: HTTP/2 allows multiple requests to be served simultaneously over a single connection (eliminating the request waterfall of HTTP/1.1), and HTTP/3 (QUIC protocol) reduces connection establishment latency further. Most modern hosting platforms and CDNs support HTTP/2 by default in 2026.

Validating and monitoring your improvements

After implementing speed improvements, validate with PageSpeed Insights (lab data) and wait 28 days to see updated field data (CrUX) in Search Console's Core Web Vitals report. The field data reflects real user experience and is what Google uses for ranking — it's a rolling 28-day average, so improvements take time to appear.

Set up continuous performance monitoring with Calibre, SpeedCurve or the free WebPageTest API to alert you when performance metrics regress — new deployments, plugin updates and content changes all have the potential to reintroduce performance issues. Catching regressions within 24 hours of deployment is far less costly than discovering them in your next monthly audit.

Correlate performance improvements with conversion rate and bounce rate changes in GA4. Speed optimisation that improves LCP from 4.5s to 1.8s should produce a measurable uplift in conversion rate within 2–4 weeks — if it doesn't, the conversion constraint lies elsewhere (content, trust signals, CTA) and should be investigated with CRO methods.