Site speed is not just a technical nicety – it directly affects your search rankings, user experience and conversion rates. Google has used page speed as a ranking factor for over a decade, and with Core Web Vitals now embedded into the page experience signal, the bar for performance continues to rise.
But speed optimisation is about much more than chasing a perfect Lighthouse score. It is about ensuring that real users on real devices and real connections can access your content quickly and interact with it smoothly. A site that loads in under two seconds on a developer's MacBook may struggle on a mid-range Android phone over a 4G connection – and that latter scenario represents a significant portion of your audience.
This guide covers everything you need to know about site speed optimisation in 2026, from the metrics that matter to the practical techniques that deliver measurable improvements.
Why Site Speed Matters
The business case for speed is well established. Research consistently shows that slower sites see higher bounce rates, lower engagement and fewer conversions. Every additional second of load time has a compounding negative effect on user behaviour.
From an SEO perspective, Core Web Vitals are a confirmed ranking signal. While content relevance and backlinks remain more influential, speed can be the tiebreaker between otherwise comparable pages. On highly competitive SERPs, that margin matters.
Beyond rankings, there is the indirect impact on crawl efficiency. Faster sites allow Googlebot to crawl more pages within the same crawl budget, which is particularly important for large sites. Use our Page Speed Impact Calculator to estimate the revenue implications of improving your load times.
Understanding Core Web Vitals
Core Web Vitals are the specific metrics Google uses to evaluate page experience. Getting these right should be the primary focus of any speed optimisation effort.
Largest Contentful Paint (LCP)
LCP measures how long it takes for the largest visible content element to render on screen. This is typically a hero image, a large heading or a video poster frame. Google considers an LCP of 2.5 seconds or less to be "good".
Common causes of poor LCP include:
- Slow server response times (high Time to First Byte)
- Render-blocking JavaScript and CSS
- Unoptimised or oversized hero images
- Client-side rendering that delays content visibility
- Lazy-loading the LCP element (which should be eagerly loaded instead)
Interaction to Next Paint (INP)
INP measures the responsiveness of a page to user interactions throughout the entire visit. Unlike the old First Input Delay metric, which only measured the first interaction, INP captures the worst-case latency across all clicks, taps and keyboard inputs. An INP of 200 milliseconds or less is considered "good".
Poor INP is almost always caused by JavaScript – specifically, long tasks that block the main thread and prevent the browser from responding to user input promptly. Heavy analytics scripts, chat widgets, A/B testing tools and complex client-side rendering logic are frequent culprits.
Cumulative Layout Shift (CLS)
CLS measures visual stability – how much the page layout shifts unexpectedly during loading. A CLS score below 0.1 is considered "good". Layout shifts are frustrating for users and can lead to accidental clicks, particularly on mobile devices.
The most common causes are images without explicit dimensions, dynamically injected content (such as ads or cookie banners), web fonts that cause a flash of unstyled text (FOUT) and late-loading embeds.
Image Optimisation
Images typically account for the largest share of page weight on most websites. Optimising them is one of the fastest ways to improve load times.
Choose the Right Format
- WebP is now widely supported and typically delivers 25–35% smaller file sizes than JPEG at comparable quality. It should be your default format for photographs and complex images.
- AVIF offers even better compression than WebP, though browser support is slightly narrower. Use it with a WebP or JPEG fallback via the
<picture>element. - SVG remains the best choice for logos, icons and illustrations that can be represented as vectors.
- PNG should only be used when you need transparency and cannot use WebP or AVIF.
Responsive Images
Serving a 2400px-wide hero image to a mobile device on a narrow viewport is wasteful. Use the srcset and sizes attributes to serve appropriately sized images for each device and viewport.
Lazy Loading
Apply loading="lazy" to images that are below the fold. This defers loading until the user scrolls near them, reducing the initial page weight. However, do not lazy-load images that are visible in the initial viewport, particularly your LCP element.
Compression and Quality
Use tools like Squoosh, ShortPixel or your build pipeline's image optimisation plugin to compress images. For photographs, a quality setting of 75–85% is usually indistinguishable from the original to the human eye while delivering meaningful file-size savings.
Code Minification and Bundling
Reducing the size and number of CSS and JavaScript files your pages request can meaningfully improve load times.
- Minify CSS and JavaScript – remove whitespace, comments and unnecessary characters. Most build tools (Webpack, Vite, esbuild) do this automatically in production builds.
- Remove unused CSS – tools like PurgeCSS can analyse your HTML and strip out CSS rules that are never applied. On sites using large frameworks like Bootstrap or Tailwind, this can reduce CSS file sizes by 80% or more.
- Bundle strategically – while HTTP/2 has reduced the penalty for multiple requests, excessive numbers of small files still add overhead. Aim for a sensible balance between bundling and code splitting.
- Tree-shake JavaScript – modern bundlers can eliminate unused exports from your dependency tree. Ensure this is enabled in your production build configuration.
Content Delivery Network (CDN)
A CDN distributes your static assets across a global network of edge servers, ensuring that users receive content from a server geographically close to them. This reduces latency and improves load times, particularly for international audiences.
Key considerations when choosing and configuring a CDN:
- Ensure your CDN has strong coverage in your primary markets. For UK-focused businesses, European edge nodes are essential.
- Configure appropriate cache headers so that static assets are cached at the edge for as long as practical.
- Use cache-busting techniques (such as content hashing in filenames) so that updated assets are served immediately after deployment.
- Consider a full-site CDN like Cloudflare or Fastly that can also cache dynamic HTML, reducing server load and time to first byte.
Server Response Time (TTFB)
Time to First Byte (TTFB) measures how long it takes for the server to send the first byte of the response after receiving a request. While not a Core Web Vital itself, a slow TTFB makes it nearly impossible to achieve a good LCP score.
- Upgrade your hosting if your server is consistently slow. Shared hosting is rarely adequate for performance-sensitive sites.
- Implement server-side caching – tools like Varnish, Redis or your CMS's built-in caching can dramatically reduce response times for repeat requests.
- Optimise database queries – slow database lookups are a common cause of high TTFB on dynamic sites, particularly WordPress installations with many plugins.
- Use HTTP/2 or HTTP/3 – these protocols offer multiplexing, header compression and other improvements over HTTP/1.1.
Font Optimisation
Custom web fonts add personality to your design, but they can also slow down your site and cause layout shifts if not handled carefully.
- Self-host your fonts rather than loading them from Google Fonts or other third-party services. This eliminates a DNS lookup and connection to an external server.
- Use
font-display: swapto ensure text remains visible while custom fonts are loading. Better still, usefont-display: optionalif you are comfortable with the system font being displayed when the custom font is not cached. - Subset your fonts – if you only use Latin characters, there is no need to load Cyrillic, Greek and other character sets. Tools like
glyphhangerorpyftsubsetcan create minimal subsets. - Use modern formats – WOFF2 offers the best compression for web fonts and is supported by all modern browsers.
- Preload critical fonts using
<link rel="preload" as="font">to ensure they are fetched early in the loading process.
Third-Party Script Management
Third-party scripts are one of the most common – and most overlooked – causes of poor site performance. Analytics tools, chat widgets, social media embeds, A/B testing platforms, retargeting pixels and consent management platforms all add weight and execution time to your pages.
Audit Your Third-Party Scripts
Start by listing every third-party script on your site and assessing whether each one is genuinely necessary. It is not unusual to find scripts for services that are no longer in use, duplicate tracking codes or plugins that have been replaced.
Load Strategically
- Use
asyncordeferattributes on script tags to prevent them from blocking the initial render. - Consider loading non-essential scripts only after user interaction (such as scrolling or clicking) rather than on page load.
- Use a tag manager to centralise and control when scripts fire, but be aware that the tag manager itself adds overhead.
Monitor Impact
Use Chrome DevTools' Performance panel or WebPageTest to measure the impact of each third-party script on your Core Web Vitals. If a script is significantly degrading INP or LCP, consider whether its value justifies the performance cost.
Advanced Optimisation Techniques
Once you have addressed the fundamentals, there are several more advanced techniques that can squeeze additional performance gains from your site.
- Resource hints – use
preconnectfor critical third-party origins,prefetchfor resources needed on the next likely navigation andpreloadfor critical assets needed on the current page. - Critical CSS inlining – extract and inline the CSS needed to render above-the-fold content, then load the remainder asynchronously. This eliminates render-blocking CSS for the initial viewport.
- Service workers – implement a service worker to cache key assets and serve them from the local cache on repeat visits, enabling near-instant load times for returning users.
- Speculative loading – the Speculation Rules API allows you to prefetch or prerender pages that the user is likely to navigate to next, making subsequent page loads feel instantaneous.
Measuring and Monitoring
Speed optimisation is not a one-time project. You need ongoing monitoring to catch regressions and track the impact of your improvements.
Lab Data vs Field Data
Lab data (from tools like Lighthouse, WebPageTest and Chrome DevTools) is useful for debugging specific issues in a controlled environment. Field data (from the Chrome User Experience Report, or CrUX) reflects the real experience of actual users. Google uses field data for ranking purposes, so this is the metric that ultimately matters.
Recommended Tools
- Google Search Console – the Core Web Vitals report shows field data aggregated across your site.
- PageSpeed Insights – combines lab and field data for individual URLs.
- WebPageTest – provides detailed waterfall charts and filmstrip views for deep analysis.
- Chrome DevTools Performance panel – essential for debugging JavaScript execution issues and identifying long tasks.
- Real User Monitoring (RUM) – services like SpeedCurve or web-vitals.js give you continuous field data with more granularity than CrUX.
Speed and Conversion Rate Optimisation
Speed does not exist in a vacuum. Faster sites convert better. Our experience with conversion rate optimisation consistently shows that reducing load times leads to measurable improvements in engagement metrics – lower bounce rates, longer session durations and higher completion rates on forms and checkouts.
The relationship between speed and conversions is particularly pronounced on mobile, where users are less patient and connections are less reliable. If your mobile experience is sluggish, you are likely leaving revenue on the table.
Start Improving Your Site Speed Today
Site speed optimisation requires a systematic approach – diagnose the issues, prioritise by impact and implement changes methodically. Whether you need to address Core Web Vitals failures, reduce your page weight or overhaul your hosting infrastructure, the techniques in this guide will set you on the right path.
If you would like expert help improving your site's performance, our technical SEO team can conduct a comprehensive speed audit and implement the changes needed to deliver a faster, more competitive website. Get in touch to discuss your project.