Website Speed Audit Checklist Before Switching Hosts

A slow website does not automatically need a new host. Large images, third-party scripts, cache misses, and database contention can produce similar complaints while requiring completely different fixes.

A useful audit connects a repeatable browser test with network timings and server evidence. This workflow produces a short list of demonstrated bottlenecks, so a hosting change becomes a targeted experiment rather than an expensive guess.

Define the experience you are measuring

Choose representative user journeys before collecting scores: opening a content page, searching a catalog, viewing a product, and reaching a safe checkout step. Include both cached public pages and dynamic requests that must execute application code.

Use the API Latency Tester below as an initial timing check against an accessible read-only endpoint. It helps compare repeated requests under the tool's execution conditions. It does not replace a browser audit, reveal every server-side operation, or prove that a slow response is the host's fault. Cross-origin restrictions or endpoint authentication may prevent some browser-based checks.

Write down the test location, device class, network conditions, URL, cache state, and whether the user is authenticated. Avoid including personal data or tokens in shared reports. Repeat the same procedure after every change so improvements remain attributable to that change rather than a different test environment.

Separate connection timing from application waiting

A request includes DNS resolution, transport setup, TLS negotiation, and waiting for response bytes. Time to first byte includes several of these stages from the client's perspective; it is not a direct measurement of PHP execution or database speed.

Collect a baseline using curl from a machine outside your server's network:

for n in 1 2 3 4 5; do
curl -sS -o /dev/null     -w 'code=%{http_code} dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}
'     https://example.com/
done

These values are cumulative timestamps measured from the start of each transfer. Subtract adjacent milestones when estimating individual stages; do not add all the printed values. Each loop iteration starts a separate curl process, so this is not a model of browser connection reuse.

Record failures and redirects instead of discarding them. The command does not follow redirects, which makes an unexpected redirect visible rather than quietly including another request. Inspect the destination before choosing to test it directly.

Repeat at multiple times and, when possible, from more than one region. Use medians and tail behavior rather than highlighting the fastest run. For option semantics, the curl manual provides the authoritative reference.

Inspect the browser's critical path

Open browser developer tools and record a clean page load. In the Network panel, inspect the document request, redirects, blocking stylesheets, scripts, fonts, and the largest visible image. A fast document response can still produce a slow visual result when the browser downloads and processes too much code.

Run separate cold-cache and warm-cache tests. Disabling the browser cache is useful for repeatability, but it does not necessarily bypass a CDN or origin page cache. Note service-worker activity because it can change which requests reach the network at all.

Use the browser's Performance tools to investigate main-thread work, long tasks, and rendering delays. Compare laboratory findings with available real-user data. Field data reflects actual devices and sessions; a lab run is a controlled diagnostic and may not reproduce the same distribution.

The web.dev performance guidance explains user-centered metrics and measurement techniques. For a script-heavy application, the JavaScript payload reduction guide offers a focused next step when server timing is already healthy.

Keep an evidence note for each issue: affected URL, test conditions, observed delay, likely mechanism, and one proposed experiment. Screenshots of scores without those conditions are difficult to compare and easy to misinterpret.

Correlate slow responses with server evidence

Check resource pressure during the exact slow interval: CPU saturation, memory availability, swap activity, disk latency, application worker utilization, and database waits. Low average CPU does not rule out a short queue or a single saturated execution thread.

For NGINX, add a temporary timing log using the following directives in the correct contexts. The log_format belongs inside http; place the access_log in the relevant server block or HTTP context, then test configuration before reloading.

log_format audit '$time_iso8601 $request_method $uri '
               'status=$status request=$request_time '
               'upstream=$upstream_response_time cache=$upstream_cache_status';
access_log /var/log/nginx/audit.log audit;

This captures request and upstream timing without logging query strings by default. Paths can still contain sensitive information, so restrict access and retention. The cache-status field is meaningful only when applicable NGINX upstream caching is configured; it does not describe a separate CDN's cache.

Consult the NGINX documentation for variable behavior. Upstream values may be empty or contain multiple attempts, and request time can include slow client transfer. Do not interpret either value as a precise database timer.

Correlate logs with application traces, slow-query logs, and provider resource graphs. For PHP deployments, the PHP-FPM worker guide explains why worker queues can produce poor response times even when a larger machine would not fix the underlying external dependency.

Run controlled fixes before comparing hosts

Prioritize one-variable experiments. Compress an oversized image, correct cache headers, remove a blocking script, or optimize a demonstrated query. Retest the same journeys after each change, and preserve the before-and-after evidence rather than relying on memory.

For hosting comparisons, create a safe staging copy with equivalent software versions, data volume, and cache configuration. Disable outbound email, payments, and scheduled jobs. Never load-test infrastructure you do not own or lack permission to test, and agree on rates and stopping conditions with the provider.

To compare an HTTPS origin without changing public DNS, use curl's hostname mapping feature from your own test machine:

curl --resolve example.com:443:192.0.2.20   -sS -o /dev/null   -w 'code=%{http_code} first=%{time_starttransfer} total=%{time_total}
'   https://example.com/

Replace the documentation IP with the authorized test server. It must present a valid certificate for the requested hostname; do not disable certificate verification to hide a configuration failure. This preserves the hostname for HTTP and TLS, but does not reproduce a CDN path or every browser behavior.

Return to the latency comparison tool for accessible endpoint checks using equivalent conditions. Combine those results with server logs and browser measurements. Upgrade evidence should show a persistent origin constraint, not merely a better result from an unusually warm cache.

A migration is more defensible when the present platform repeatedly hits documented resource limits after application fixes, while a comparable target handles the workload with headroom. Include maintenance, backup restoration, and support requirements in that decision, not just a timing chart.

Key takeaways

• Establish repeatable journeys and record device, location, cache state, and authentication conditions.
• Separate connection setup, server waiting, asset transfer, and browser execution before assigning blame.
• Correlate client observations with server-side evidence during the same time window.
• Change one variable at a time, then compare equivalent and authorized test environments.
• Switch hosting only when measured constraints and operational requirements justify the move.