Website Speed Audit: Diagnose and Fix Slow Page Load Times

Why Speed Matters

Page speed directly impacts three things that determine your website's success: search rankings, user experience, and conversions. Google has used speed as a ranking factor since 2010 for desktop and 2018 for mobile. But the business impact goes beyond SEO.

Research consistently shows that every additional second of load time reduces conversions by 7-12%. Amazon famously found that a 100ms increase in load time cost them 1% in sales. For smaller businesses, the impact is proportionally similar — slow sites lose money.

• 53% of mobile users abandon sites that take longer than 3 seconds to load
• A 1-second improvement in load time can increase conversions by 27% on mobile
• Slow sites rank lower — Google's Page Experience update made Core Web Vitals (which include speed metrics) a ranking factor
• Bounce rate increases 32% when page load goes from 1 to 3 seconds

Key Speed Metrics

Understanding which metrics matter is the first step in a speed audit:

• Time to First Byte (TTFB): How long the server takes to respond. Target: under 600ms. This is the foundation — if TTFB is slow, everything else will be slow too.
• First Contentful Paint (FCP): When the first text or image appears. Target: under 1.8 seconds. A slow FCP means users see a blank screen for too long.
• Largest Contentful Paint (LCP): When the main content is visible. Target: under 2.5 seconds. This is a Core Web Vital and ranking factor.
• Total Blocking Time (TBT): How much time the main thread is blocked by JavaScript. Target: under 200ms. High TBT means the page feels unresponsive.
• Speed Index: How quickly content is visually populated. Target: under 3.4 seconds. Measures the perceived loading experience.
• Total Page Size: The total weight of all resources. Target: under 2MB for most pages. Larger pages take longer to download, especially on mobile.
• Number of Requests: Total HTTP requests. Target: under 50. Each request has overhead; reducing requests improves speed.

How to Test Your Speed

• Google PageSpeed Insights: Shows both field data (real users) and lab data (simulated). Field data matters for rankings; lab data helps identify specific issues. Test both mobile and desktop.
• GTmetrix: Provides detailed waterfall charts showing exactly what loads, when, and how long each resource takes. The waterfall is your primary debugging tool for speed issues.
• WebPageTest: The most detailed speed testing tool. Test from multiple locations, on different connection speeds, and see filmstrip comparisons of how the page loads over time.
• Chrome DevTools Network tab: Real-time view of every resource your page loads. Sort by size or time to identify the worst offenders.
• Lighthouse: Built into Chrome DevTools. Run an audit to get a performance score and specific recommendations.

Always test on mobile with throttled connections. Desktop on fast Wi-Fi hides real-world performance problems that mobile users on 4G experience.

Server-Side Optimisation

Server performance sets the floor for your page speed. No amount of front-end optimisation can compensate for a slow server.

• Upgrade hosting if needed: Cheap shared hosting often has slow TTFB (1-3 seconds). Moving to a quality managed host or VPS can cut TTFB to under 200ms.
• Enable server-side caching: Page caching stores the generated HTML so the server doesn't rebuild it for every request. For WordPress, use WP Super Cache or W3 Total Cache. For Node.js apps, use Redis.
• Enable Gzip or Brotli compression: Compresses text-based resources (HTML, CSS, JS) by 60-80%. Most modern servers support Brotli, which compresses better than Gzip.
• Optimise database queries: Slow database queries are a common cause of high TTFB. Add indexes to frequently queried columns, reduce the number of queries per page, and use query caching.
• Use HTTP/2 or HTTP/3: Modern HTTP protocols allow multiplexing (multiple requests over one connection), header compression, and server push. Most modern hosts support HTTP/2 by default.

Image Optimisation

Images are typically 50-70% of a page's total weight. Optimising images is usually the single biggest speed win.

• Use modern formats: WebP offers 25-35% smaller files than JPEG at equivalent quality. AVIF is even better (20% smaller than WebP) but has slightly less browser support. Use the picture element with fallbacks.
• Serve responsive images: Use srcset and sizes attributes to serve different image sizes based on the user's viewport. A 2000px hero image shouldn't load on a 375px mobile screen.
• Lazy load below-fold images: Add loading="lazy" to images that aren't visible on initial page load. This defers their download until the user scrolls near them.
• Preload hero images: The LCP image should be preloaded with <link rel="preload" as="image"> to start downloading before the browser discovers it in the HTML.
• Set explicit dimensions: Always include width and height attributes to prevent layout shifts (CLS) while images load.
• Compress aggressively: Most images can be compressed to 60-80% quality with no visible difference. Use tools like Sharp, ImageOptim, or Squoosh.

Code Optimisation

• Minify CSS and JavaScript: Remove whitespace, comments, and unnecessary characters. Most build tools (Webpack, Vite, esbuild) do this automatically.
• Remove unused CSS: Most sites load CSS for components that aren't on the current page. Use PurgeCSS or the Coverage tab in Chrome DevTools to identify and remove unused CSS.
• Defer non-critical JavaScript: Add async or defer to script tags that aren't needed for initial render. Move analytics, chat widgets, and social scripts to defer.
• Code-split JavaScript: Instead of one large bundle, split JS into smaller chunks that load on demand. Modern bundlers support this with dynamic imports.
• Inline critical CSS: Extract the CSS needed for above-the-fold content and inline it in the HTML head. This eliminates a render-blocking request.
• Audit third-party scripts: Each third-party script (analytics, ads, chat, social) adds weight and execution time. Audit which are essential and remove or defer the rest.

Caching Strategy

• Set Cache-Control headers: Static assets (images, CSS, JS) should have long cache lifetimes (max-age=31536000 with immutable). Use content hashing in filenames for cache busting.
• Cache HTML pages appropriately: Dynamic pages might use short cache times (max-age=300) with stale-while-revalidate. Static pages can be cached longer.
• Use service workers for offline caching: Progressive Web Apps can cache critical resources so the site loads instantly on repeat visits, even offline.
• Implement stale-while-revalidate: This strategy serves cached content immediately while fetching a fresh version in the background. It combines speed with freshness.

CDN Setup

A CDN (Content Delivery Network) serves your content from edge servers geographically close to your users, reducing latency. For a site with global traffic, a CDN can cut load times by 50% or more.

• Cloudflare: Free tier available. Excellent for most sites. Provides CDN, DDoS protection, and performance features like auto-minification and image optimisation.
• AWS CloudFront: Pay-per-use. Best for sites already on AWS infrastructure. Highly configurable.
• Fastly: Premium CDN with instant purging and edge computing. Used by major sites like GitHub and The New York Times.

Speed Audit Checklist

• TTFB under 600ms on target markets
• LCP under 2.5s on mobile
• Total page size under 2MB
• Under 50 HTTP requests per page
• All images in WebP/AVIF with responsive srcset
• Below-fold images lazy loaded
• Hero image preloaded
• CSS and JS minified
• Non-critical JS deferred
• Gzip/Brotli compression enabled
• Browser caching configured
• CDN active for static assets
• No render-blocking resources above the fold
• Third-party scripts audited and non-essential removed

Need help improving your site speed? Our professional audit includes a detailed speed analysis with specific, prioritised recommendations for your site.