Website Performance Audit: Beyond Page Speed

A website performance audit measures user-facing speed and the systems that produce it: origin capacity, database work, cache behaviour, application code, asset delivery and third-party resources. Record the workload and environment for every test so results remain comparable.

This guide covers the performance audit process from the server up, explaining what to measure at each layer, what the measurements mean, and what to do when they indicate problems. The focus is on practical diagnostics and actionable fixes, not theoretical performance engineering.

Performance vs Speed

Page speed describes a page load or interaction. Website performance also covers capacity, error rates, backend latency and behaviour under load. Lighthouse supplies a controlled lab result; PageSpeed Insights may also show CrUX field data when available.

Website performance encompasses everything that contributes to how the site behaves under real-world conditions. This includes server response time under varying loads, database query efficiency, cache hit rates, CDN effectiveness, API response times, background process efficiency, and the site's behaviour during traffic spikes. A site can have perfect Lighthouse scores while being fundamentally fragile because the server collapses under moderate load or the database locks up during peak hours.

A thorough performance audit evaluates both dimensions. Client-side rendering performance determines the experience for individual page visits. Server-side and infrastructure performance determines whether that experience is consistent across all visitors, all pages, and all traffic levels. Optimising only the client side is like putting a sports body kit on a car with a failing engine. It looks fast while standing still.

The distinction matters for prioritisation. If your Time to First Byte (TTFB) is 2 seconds, no amount of image optimisation or JavaScript deferral will make your site feel fast. The server needs to respond before the browser can even begin rendering. Fix server-side performance first, then optimise client-side delivery.

Server Performance

Server performance determines the baseline speed of every page on your site. It is measured primarily through Time to First Byte (TTFB): the time between the browser sending a request and receiving the first byte of the response.

How to interpret TTFB: Compare cached and uncached requests from locations that represent the audience. Split DNS, connection, TLS, edge and origin timing where the tool permits. A fixed threshold cannot identify which layer caused the delay.

Measuring TTFB: Use WebPageTest (which shows TTFB in the waterfall chart), your browser's developer tools (Network tab), or a dedicated monitoring service like Pingdom or UptimeRobot. Measure from multiple geographic locations if you serve an international audience. Measure at different times of day to identify patterns related to traffic volume.

Common server bottlenecks: Shared hosting where your site competes for CPU and memory with hundreds of other sites. Insufficient PHP worker processes causing requests to queue during traffic spikes. Slow disk I/O affecting file reads and database operations. Misconfigured web server settings that prevent efficient connection handling. Each bottleneck requires a different solution, from upgrading hosting to tuning server configuration.

Load testing: Your site's server performance under normal traffic does not predict its behaviour under elevated load. Use a load testing tool (k6, Locust, Apache JMeter) to simulate concurrent users at levels exceeding your typical peak traffic. Record TTFB, error rates, and response times as load increases. The point where performance degrades identifies your capacity ceiling and indicates whether you need to scale before your next traffic spike.

PHP version and configuration (for PHP-based sites): Each major PHP version brings significant performance improvements. PHP 8.2 is approximately 3 times faster than PHP 7.0 for typical WordPress workloads. Check your PHP version and upgrade if possible. Also check OPcache configuration: OPcache stores precompiled PHP scripts in memory, eliminating the overhead of parsing and compiling on every request. It should be enabled with sufficient memory allocation for your entire codebase.

Database Optimisation

Most dynamic websites generate pages by querying a database. Database performance directly determines how quickly pages can be built and served.

Slow query identification: Enable slow query logging on your database server (MySQL, PostgreSQL, or whatever your site uses) and set the threshold to 1 second. Monitor the log for queries that consistently exceed this threshold. Slow queries usually indicate missing indexes, inefficient JOIN operations, or queries that scan entire tables when they should use indexed lookups. Fix slow queries and you often fix TTFB problems at their source.

Index analysis: Database indexes make queries faster by allowing the database to find records without scanning every row. Use EXPLAIN on your slowest queries to see whether they use indexes effectively. Missing indexes on frequently queried columns (particularly in WHERE, JOIN, and ORDER BY clauses) are the most common database performance problem and often the easiest to fix.

Query count per page: Monitor how many database queries each page request generates. CMS-based sites, particularly WordPress with many plugins, can generate 50-200+ queries per page request. Each query adds latency. Reduce query counts by eliminating redundant queries (plugins querying for the same data separately), implementing object caching (storing query results in memory), and disabling unnecessary features that generate background queries.

Connection pooling: Each database connection has overhead. If your application opens and closes database connections for every query, connection management itself becomes a bottleneck under load. Connection pooling maintains a pool of reusable connections, eliminating the overhead of establishing new connections. Most modern application frameworks support connection pooling, but it often needs to be explicitly configured.

Database server resources: Use database and host telemetry to inspect memory pressure, disk reads, query latency and the working set. For MySQL, review InnoDB buffer-pool use alongside the other processes sharing memory; size it from the measured workload and vendor guidance rather than a universal RAM percentage.

Caching Layers

Caching can reuse the result of page generation, database queries or API calls. Compare repeatable cached and uncached requests, cache status, origin work and freshness requirements to quantify the effect for this application.

Page caching: Full-page caching stores the complete HTML output of a page and serves it to subsequent visitors without executing any application code. This is the highest-impact caching layer. For anonymous visitors (the majority on most sites), every page view should be served from cache. Verify page caching by checking response headers for cache indicators (X-Cache: HIT, X-WP-Super-Cache, or similar) and by comparing TTFB between first and subsequent requests.

Object caching: Object caching stores the results of individual database queries or API calls in memory (typically Redis or Memcached). This benefits pages that cannot be fully page-cached, such as pages for logged-in users or pages with personalised content. Object caching reduces database load even when page caching is not applicable.

Browser caching: Browser caching stores static assets (CSS, JavaScript, images, fonts) in the visitor's browser so they are not re-downloaded on subsequent page views. Check that your server sends appropriate Cache-Control headers with long max-age values for static assets. Use file name versioning (style.v2.css or style.abc123.css) to enable aggressive caching while ensuring visitors get updated files when you deploy changes.

CDN caching: A content delivery network may serve cacheable responses from an edge. Inspect response headers and logs by asset class and location, and compare hit ratio, latency, freshness and origin load with project-specific targets.

Cache invalidation: Caching introduces a cache management responsibility. When content changes, the cached version must be invalidated so visitors see the updated content. Check that your caching system correctly purges pages when content is updated. Common problems include caches that never expire (showing stale content) and caches that invalidate too aggressively (negating the performance benefit). Well-configured caching should invalidate only the specific pages affected by a change, not the entire cache.

Third-Party Impact

Third-party resources are scripts, styles, fonts, and other files loaded from external domains. They are among the most significant and least controlled performance factors on most websites.

Catalogue all third-party resources. Use your browser's Network tab or a tool like WebPageTest to list every resource loaded from a domain other than your own. Common third-party resources include Google Analytics, Google Tag Manager, Facebook Pixel, live chat widgets (Intercom, Drift, Zendesk), A/B testing tools (Optimizely, VWO), heatmap tools (Hotjar, Crazy Egg), advertising scripts, social sharing buttons, and embedded content (YouTube, Google Maps).

Measure individual impact. Each third-party resource adds DNS lookup time, connection time, and transfer time. Some also execute significant JavaScript that blocks rendering or competes for the main thread. Use Chrome DevTools Performance tab to identify which third-party scripts consume the most execution time. Block individual third-party domains (using Chrome DevTools Request Blocking) and measure the speed improvement to quantify each one's impact.

Evaluate necessity. For each third-party resource, measure transfer, main-thread and rendering cost on representative devices and compare it with the feature's observed use or business need. Remove, defer or conditionally load resources whose measured cost is not justified.

Optimisation strategies for necessary third parties. Load non-essential scripts after the page has rendered (using defer or async attributes, or dynamically loading after user interaction). Self-host resources where possible (Google Fonts, for example, can be downloaded and served from your own domain, eliminating the external DNS lookup and connection). Use resource hints (preconnect, dns-prefetch) for critical third-party domains to reduce connection time.

Tag Manager discipline. Google Tag Manager makes it easy to add scripts without developer involvement, which means scripts accumulate without performance review. Audit your Tag Manager container quarterly. Remove unused tags, verify that triggers are specific (loading tags only on pages where they are needed rather than all pages), and check that tag firing order does not create rendering bottlenecks.

Performance Budgets

A performance budget sets maximum acceptable values for performance metrics, preventing gradual degradation as features and content are added over time.

What to budget: Set budgets for transferred bytes, script execution, requests and user-facing metrics that the team can measure consistently. Keep Google's good LCP threshold of 2.5 seconds distinct from project-specific limits for page weight, request count and TTFB.

Enforcement mechanisms: A budget without enforcement is just a wish. Integrate performance budget checks into your deployment pipeline using tools like Lighthouse CI, SpeedCurve, or bundlewatch. When a deployment exceeds a budget threshold, block the deployment or flag it for review. Automated enforcement prevents the "just one more script" creep that gradually degrades performance.

Per-page-type budgets: Different page types have different performance characteristics and requirements. Your homepage might load a hero video that your blog posts do not. Product pages might load image carousels that your about page does not. Set separate budgets for each major page template rather than applying a single budget across the entire site.

Accountability: Assign performance budget ownership to a specific person or team. When a budget is exceeded, someone needs to investigate why and determine whether the budget should be adjusted or the change should be reverted. Without clear ownership, budgets become advisory guidelines that are routinely ignored.

Monitoring

Performance is not a one-time fix. It requires ongoing monitoring to detect degradation and maintain standards.

Real User Monitoring (RUM): RUM collects performance data from actual visitors using real devices on real networks. This gives you the truest picture of your site's performance because it captures the diversity of devices, connection speeds, and geographic locations your real audience experiences. Google provides free RUM data through the Chrome User Experience Report (CrUX), accessible via PageSpeed Insights or the CrUX API. For more detailed RUM, consider tools like SpeedCurve, Datadog, or New Relic.

Synthetic monitoring: Synthetic monitoring runs automated performance tests from controlled environments at regular intervals. Unlike RUM, which depends on real visitor volume, synthetic monitoring provides consistent, comparable measurements on a fixed schedule. Use WebPageTest's API or Lighthouse CI to run daily tests of your key page templates. Synthetic monitoring catches regressions quickly and provides the controlled conditions needed for accurate before/after comparisons when you make changes.

Core Web Vitals tracking: Monitor LCP, INP and CLS through Search Console and your own RUM where available. Search Console groups similar URLs from CrUX data. Treat deterioration as a user-experience investigation trigger rather than proof of a ranking change.

Alert configuration: Set up alerts for performance metric thresholds that indicate genuine problems. A TTFB spike above 2 seconds, a LCP regression above 4 seconds, or a significant drop in cache hit rate all warrant immediate investigation. Avoid alerting on minor fluctuations that are within normal variation. The goal is to be notified about meaningful degradation, not to receive daily noise.

Regular performance reviews: Review monitoring after releases and on a cadence matched to traffic and change frequency. Examine trends, regressions and alert quality before adjusting the budget.

Use web.dev's user-centric metric definitions and Google's Core Web Vitals documentation as primary references. The speed audit gives a page-level diagnostic sequence.