Website Speed Audit: Diagnose and Fix Slow Page Load Times

Why Speed Matters

A website speed audit uses field data to identify slow user experiences and controlled tests to trace the delay to a resource, request or main-thread task. Segment results by page template, device and geography before choosing fixes.

Google's core systems seek to reward good page experience, but no fixed speed score or conversion rate applies to every site. Measure conversions and user behaviour on your own traffic before assigning a business impact.

• Field experience: Read the 75th-percentile LCP, INP and CLS values for the page or origin when CrUX has enough data.
• Lab diagnosis: Repeat tests with the same device, location, network and cache state.
• Business effect: Compare conversion or task-completion data before and after a release with other variables controlled.

Key Speed Metrics

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

• Time to First Byte (TTFB): The time from navigation request to the first response byte. Use it to separate connection and origin delay; interpret it by cache state and test location.
• First Contentful Paint (FCP): A lab and field diagnostic for when the first text, image or other qualifying content paints. Interpret it with the tested device, network, page template and available field distribution.
• Largest Contentful Paint (LCP): When the largest qualifying viewport element renders. Google's good field threshold is within 2.5 seconds at the 75th percentile.
• Total Blocking Time (TBT): A Lighthouse lab diagnostic that totals blocking portions of long tasks. Use it to investigate main-thread work rather than as a field pass criterion.
• Speed Index: A Lighthouse lab metric estimating how quickly visible content is populated. Compare like-for-like runs and use the trace and filmstrip to identify the delayed content.
• Total Page Size: The transferred bytes for the tested page state. Set a template budget that reflects your users and essential features.
• Number of Requests: The requests made during the tested state. Investigate their dependency chain and cost before merging or removing them.

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: A configurable browser performance 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.

Include a documented mobile device and network profile that represents the audience. Compare lab traces with field data when available; a fast desktop run does not describe every user.

Server-Side Optimisation

Origin response consumes part of the loading timeline. Measure it alongside connection, resource discovery, transfer, main-thread and rendering work before assigning the bottleneck.

• Change hosting only with evidence: Compare cached and uncached TTFB and capacity under a defined workload. Trace origin delay before changing providers.
• 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 content encoding: Check Brotli or gzip negotiation for compressible HTML, CSS, JavaScript and text responses. Compare transferred bytes and CPU cost on the actual assets.
• 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.
• Verify protocol behaviour: Record negotiated HTTP versions, connection reuse and request scheduling. Do not recommend HTTP/2 server push: Chrome removed support; use current discovery and priority mechanisms where traces justify them.

Image Optimisation

Use the network trace to determine each image's transfer and rendering cost. Prioritise the LCP image and oversized assets rather than assuming images dominate every page.

• Compare formats: Generate WebP, AVIF and appropriate legacy candidates from the source, inspect visual quality and measure the bytes for each supported browser path.
• 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.
• Prioritise the LCP image when needed: Inspect when the browser discovers and requests it. Preload or fetchpriority can help a late-discovered LCP image, but unnecessary high-priority requests can compete with critical resources.
• Set explicit dimensions: Always include width and height attributes to prevent layout shifts (CLS) while images load.
• Choose encoding quality: Compare representative outputs at several settings and select the smallest version that meets the page's visual requirements. Save the tool and settings for repeatable production.

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 content delivery network can reduce network distance and offload an origin. Measure from target regions before and after configuration because cache rules, dynamic content and origin behaviour determine the gain.

• Cloudflare: Offers CDN and security features with current plan details on its site. Verify cache behaviour and required features against the live configuration.
• AWS CloudFront: Pay-per-use. Best for sites already on AWS infrastructure. Highly configurable.
• Fastly: A CDN and edge-computing provider. Evaluate required cache controls, locations, contracts and measured behaviour for the application.

Speed Audit Checklist

• TTFB compared by location and cache state with the delay attributed to a layer
• LCP within 2.5 seconds at the 75th percentile
• Page weight within the project's per-template budget
• Request chains reviewed for avoidable dependencies
• Image candidates compared for format, dimensions, quality and browser path
• Off-screen image loading tested without delaying content needed in the initial viewport
• LCP image discovery and priority checked before adding preload or priority hints
• CSS and JavaScript transfer and execution measured before changing the build output
• Non-critical JavaScript scheduling reviewed against dependencies and user interaction
• Gzip/Brotli compression enabled
• Browser caching configured
• CDN effect measured where used by location, cache status and origin load
• Render-blocking resources traced and changed only when the critical rendering path supports it
• Third-party scripts audited and non-essential removed

Use Google's Core Web Vitals guidance and web.dev's field-versus-lab explanation to interpret results. The performance audit extends this page-level method to server capacity, databases and monitoring.