A website speed audit helps you separate page-level problems from hosting bottlenecks. This repeatable process shows what to measure on mobile and desktop, how to connect Core Web Vitals to likely causes, and when optimization is more sensible than a hosting upgrade.
Overview
Website speed is not one number. A page can have a quick server response but still feel slow because of oversized images, blocking JavaScript, third-party scripts, or an inefficient rendering process. Conversely, a well-optimized page may remain slow when the server is overloaded or the hosting plan has restrictive CPU, memory, or database resources.
The goal of a speed audit is to establish a reliable baseline, identify the largest sources of delay, make one controlled change at a time, and measure the result. Run tests under similar conditions so that a busy network, temporary traffic spike, or warm cache does not lead you to the wrong conclusion.
Use at least one field-data source, when available, and one controlled testing tool. Field data reflects the experience of real visitors over time. Lab tests are useful for comparing changes because you can repeat them under consistent conditions. Neither view tells the whole story by itself.
Core Web Vitals to record
- Largest Contentful Paint (LCP): how quickly the main visible content becomes available. A commonly used good target is 2.5 seconds or less.
- Interaction to Next Paint (INP): how promptly the page responds after user interaction. A commonly used good target is 200 milliseconds or less.
- Cumulative Layout Shift (CLS): how much visible content moves unexpectedly. A commonly used good target is 0.1 or less.
These targets are useful working references, but performance guidance can change. Check the current documentation for the testing tool or search platform you use when maintaining this audit.
What to track
Create a simple worksheet with the URL, date, device type, test location, template or page type, and whether the test used a logged-in or logged-out session. Record the result before and after each significant change.
1. Test representative pages
Do not audit only the homepage. Choose a small sample that represents the site: the homepage, a high-traffic article, a landing page, a search or category page, and a conversion page such as a contact, checkout, or booking page. If the site uses several templates, test at least one page from each important template.
Run each page on mobile and desktop. Mobile tests often expose image, script, and layout problems that are less visible on a fast desktop connection. Compare a fresh visit with a repeat visit where the browser cache is populated, but keep the two results separate.
2. Measure server response and hosting behavior
Record time to first byte, or TTFB, as a diagnostic clue rather than a complete definition of speed. A consistently slow response before the browser receives meaningful page content can point to hosting capacity, database work, uncached requests, DNS delays, or application code.
Check whether response time changes during busy periods. Review hosting dashboards for CPU, memory, concurrent processes, storage, inode, bandwidth, and database limits where those metrics are available. A shared hosting plan can be perfectly adequate for a small site but struggle when traffic, background jobs, or complex queries increase.
Also note the cache status, compression, HTTP protocol, TLS setup, and whether static files are delivered through a content delivery network (CDN). A CDN can reduce the distance between visitors and static assets, but it will not automatically fix slow database queries or an inefficient page-generation process.
3. Inspect the page itself
- Images: list the largest files, check whether they are displayed much smaller than their source dimensions, and use an appropriate modern format when your browser and CMS workflow support it. Provide responsive sizes rather than sending a large desktop image to every device.
- Caching: confirm that static assets have useful browser cache settings and that page caching is working for pages that do not need to be generated for every visitor. Purge caches carefully after changes.
- Scripts and styles: identify render-blocking files, unused code, large bundles, and scripts loaded by plugins, extensions, analytics, chat tools, advertising, or embedded media.
- Fonts: limit unnecessary families and weights, use appropriate loading behavior, and avoid allowing font downloads to delay visible content.
- Database and CMS work: review slow queries, oversized autoloaded settings, revisions, scheduled tasks, and plugins or extensions that add work to every request.
- Third-party services: test the page with nonessential tags disabled in a staging environment or controlled test. A service that loads slowly can affect the visitor even when your own server is healthy.
4. Use this prioritization table
| Priority | Typical action | Why it comes first |
|---|---|---|
| High impact, low effort | Resize oversized images, enable page and browser caching, remove unused plugins, defer nonessential scripts | Often improves loading without architectural changes |
| High impact, medium effort | Improve database queries, replace heavy extensions, configure CDN delivery, change image loading rules | Addresses recurring work across many pages |
| High impact, high effort | Move to stronger hosting, redesign a template, refactor application code, introduce server-side caching | Worth considering after evidence shows a structural limit |
| Low impact | Minor markup cleanup or small cosmetic adjustments | Do after the largest bottlenecks are measured and addressed |
Cadence and checkpoints
A practical schedule is a short monthly check for important pages and a fuller audit each quarter. The monthly check can include field Core Web Vitals, uptime or error alerts, response time, and the size of the largest page assets. The quarterly review should repeat mobile and desktop lab tests, inspect plugins and scripts, review hosting resource usage, and compare results with the previous quarter.
Run an additional audit after a redesign, CMS or theme update, hosting migration, new analytics or advertising installation, major content import, checkout change, or traffic increase. Take a baseline before the change whenever possible. For a migration, test the old and new environments separately before switching DNS, then retest after propagation and caching have settled.
Keep a change log with four fields: date, change made, pages affected, and measured result. This prevents repeated experiments and helps reveal whether a short-term improvement survives normal traffic.
How to interpret changes
Slow server response across many pages
If unrelated templates all show elevated response time, investigate hosting resources, database load, background jobs, DNS, and origin configuration before rewriting individual pages. Review your hosting limits and upgrade triggers alongside this audit. A hosting change is more defensible when resource usage is consistently constrained, response time worsens under ordinary traffic, or application and caching improvements have already been tested.
Fast response but slow visible content
This pattern often points to the page payload: a large hero image, blocking CSS, web fonts, client-side rendering, or scripts that delay the main content. Optimize the largest content element first, then retest LCP and the waterfall rather than changing hosting immediately.
Good lab results but poor field results
Look for differences in geography, device capability, connection quality, cache state, and visitor behavior. A lab test may not reproduce third-party service delays or the experience of returning users. Check field data over a sufficient comparison period and segment by page type before making a broad infrastructure decision.
Layout shifts or slow interactions
For CLS, reserve space for images, ads, embeds, banners, and dynamically inserted components. For INP, identify long JavaScript tasks, expensive event handlers, and scripts that run during interaction. Reducing plugin or extension overhead can help, but test each removal because functionality and tracking may depend on it.
Results vary widely between tests
Repeat the same test several times and compare the pattern rather than one score. Confirm that you are testing the same URL, location, device profile, protocol, and cache state. Record outages, deployments, and traffic events that may explain an unusual result.
When to revisit
Use this audit monthly for a lightweight health check and quarterly for a fuller review. Revisit immediately when search visibility, conversions, bounce behavior, or customer complaints change without an obvious content explanation. Also review performance before a seasonal campaign, after publishing a feature-rich page, and whenever traffic approaches the limits of the current hosting plan.
During each review, compare the same representative URLs and keep the previous worksheet. If a metric declines, isolate the change: compare the page template, asset list, script inventory, hosting resource graph, and deployment history. Make one or two high-confidence fixes, then measure again under comparable conditions.
Do not treat a hosting upgrade as the default answer, and do not assume a plugin, image, or CDN change worked because a single test improved. The useful outcome is a repeatable record showing which change affected which metric. Once the largest bottleneck is resolved, set a new baseline and continue the monthly or quarterly cycle. For related operational planning, see our guide to web hosting resource limits, website migration checklist, and small-business hosting comparison.
