Website Hosting Performance Audit Checklist: TTFB, Caching, and Resource Usage

Overview

A hosting performance audit is a comparison exercise, not a single speed test. You are looking for patterns across locations, URLs, traffic conditions, and time periods. A homepage that loads quickly in one browser may still have a slow uncached response, an overloaded database, or a resource limit that appears only during busy periods.

Start by recording a baseline before changing anything. Choose three to five representative URLs, such as the homepage, a content page, a search or category page, and an important conversion page. Test each URL in a normal browser and with a performance testing tool. Record the test date, location if available, protocol, cache state, and recent site changes.

Keep these measurements separate:

• TTFB: The time until the first response byte arrives. It reflects DNS, connection setup, network distance, server processing, and cache behavior.
• Total response time: The time needed to receive the document or resource. A quick first byte does not guarantee a small or efficient response.
• Page rendering: The time required for the browser to process HTML, stylesheets, scripts, images, and third-party content.
• Resource usage: CPU, memory, PHP or runtime workers, database activity, disk operations, bandwidth, and account-level limits.

For each result, compare the same URL with caching enabled and, where your platform permits, with caching bypassed. A large difference can indicate that page caching is working for visitors but that origin processing is too slow for cache misses, logged-in users, or dynamic requests.

Checklist by scenario

Before a routine monthly or quarterly review

• Confirm that DNS records point to the intended host and that the test uses the canonical HTTPS URL.
• Test from more than one network or geographic location when your audience is distributed.
• Run both a cold-cache test and a repeat-visit test.
• Record TTFB, response status, redirect count, total page size, and the largest or slowest resources.
• Review hosting-panel graphs for CPU, memory, bandwidth, storage, worker processes, and database connections.
• Check website uptime monitoring reports for short outages, elevated latency, and recurring time windows.
• Compare the current results with the previous baseline rather than relying on a single pass or fail result.

Read the website uptime monitoring guide alongside this review if you need to distinguish slow responses from complete outages.

After a noticeable slowdown

• Write down when the slowdown began and compare it with deployments, plugin updates, content imports, traffic changes, or DNS changes.
• Test a static file, a simple uncached page, and a database-driven page. This helps identify whether the issue affects the server, application, or a specific route.
• Inspect recent error logs, slow-query logs, application logs, and web-server logs if your hosting plan provides them.
• Check whether a cache was cleared, disabled, bypassed by cookies, or prevented by query strings.
• Look for resource throttling or periods when CPU, memory, workers, or database connections reached a limit.
• Repeat the test after each controlled change so you know which action helped.

Before choosing a faster hosting plan or migrating

• Export at least several days of resource and uptime data, not just a single speed-test screenshot.
• Identify whether the constraint is shared account usage, application inefficiency, database load, storage performance, or network delivery.
• Verify the available runtime versions, worker settings, object caching, page caching, CDN integration, backups, and logging on the proposed environment.
• Estimate peak concurrency and background-job activity, including scheduled tasks, imports, backups, and image processing.
• Define a rollback plan and test the migration on a staging or temporary hostname where practical.

For a broader decision framework, see how to choose web hosting for a small business and the website migration checklist.

What to double-check

TTFB and server response time

Use browser developer tools, a controlled command-line request, or a performance testing service. A useful command-line pattern is curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} start:%{time_starttransfer} total:%{time_total}\n" https://example.com/. Replace the URL with a site you control and treat the output as a diagnostic baseline, not a universal score.

Break a slow result into DNS lookup, connection, TLS negotiation, waiting for the first byte, and download time. If waiting for the first byte dominates, inspect application execution, database queries, cache misses, and server capacity. If connection or TLS time varies by location, review DNS, CDN, routing, and network conditions.

Caching, compression, and delivery

• Confirm that public pages send the expected cache headers and that cache-control rules do not conflict.
• Verify that cache keys do not vary unnecessarily by cookies, query parameters, language, or device.
• Check that authenticated, cart, account, and other private responses are excluded from public page caching.
• Confirm that text responses use an appropriate compression method and that images are resized and delivered in suitable formats.
• Check whether the CDN serves static assets from edge locations and whether a recent purge explains a temporary slowdown.

Caching can make anonymous page loads fast while leaving the underlying origin slow. Measure both cached and uncached paths before concluding that the hosting environment is healthy.

Runtime, database, and application load

Confirm that the site uses a supported runtime version compatible with its CMS, plugins, themes, and application dependencies. Do not change versions on production without backups and a rollback path. Review scheduled jobs, external API calls, unoptimized queries, oversized autoloaded settings, and repeated work on every request. For WordPress sites, also check plugin behavior, object caching, revision buildup, and background tasks.

Use logs to find slow routes and recurring errors. A high CPU graph may indicate expensive application code, while memory pressure may cause workers to restart or requests to queue. Database saturation can appear as a slow TTFB even when the web server itself has spare CPU.

SSL, redirects, and DNS

Test the final canonical URL, not an old HTTP address or an alternate hostname. Count redirects and remove unnecessary HTTP-to-HTTPS, www, non-www, or trailing-slash chains. Confirm that the certificate is valid and that mixed-content errors are not forcing failed or repeated requests. Use the SSL certificate troubleshooting guide when HTTPS behavior changes after a DNS or hosting update.

Common mistakes

• Testing only once: A single result may reflect a temporary network route, cache state, or busy server. Repeat tests and compare medians or consistent patterns.
• Optimizing the browser while ignoring the origin: Minifying scripts will not resolve a database timeout or an exhausted worker pool.
• Using a cached homepage as the whole audit: Include dynamic pages, logged-in flows, forms, search, and API requests where they matter.
• Disabling every plugin or optimization at once: Make one change at a time, document it, and preserve the ability to reverse it.
• Confusing bandwidth with speed: A site can have available transfer capacity while suffering from CPU, memory, database, or request-concurrency limits.
• Ignoring recent changes: Compare deployments, DNS edits, cache purges, runtime updates, and content imports with the first appearance of the problem.
• Skipping backups before performance work: Create and verify a recovery point before changing runtime versions, databases, caching rules, or hosting providers. The WordPress backup and restore checklist provides a practical model.

When to revisit

Run a light review monthly or quarterly, depending on how frequently the site changes and how important availability is. Perform a focused audit after a traffic increase, redesign, CMS or runtime update, major plugin installation, database import, DNS change, CDN change, or recurring uptime alert. Repeat the audit before seasonal campaigns, product launches, or a hosting renewal so capacity decisions are based on evidence.

Keep a simple worksheet with these columns: date, URL, cache state, test location, TTFB, total time, status code, page size, CPU, memory, worker usage, database notes, recent changes, and next action. Mark each action as measure, change, or verify. That record turns isolated speed complaints into a trend you can investigate.

Finish every review with one of three decisions: no change, a measured configuration fix, or a capacity and migration investigation. If you plan to move a WordPress site, follow the WordPress migration guide; if the site is still being launched, use the website launch checklist to establish a clean baseline from the start.