A slow website is easier to fix when you treat it as a sequence of measurable stages rather than a single score. This repeatable checklist shows how to isolate DNS, hosting, server, database, cache, and frontend problems, then verify that each change improves TTFB and Core Web Vitals.
Overview
Begin with a baseline before changing configuration. Test the same URL from the same region, device type, and connection profile, and record the date, deployment version, cache state, and test tool. Run several tests because one request can be affected by a cold cache, connection reuse, traffic, or a temporary origin delay.
Use both synthetic and real-user data when available. A lab website speed test is useful for controlled comparisons; field data shows how actual visitors experience the site across devices and networks. Track the median and the slower portion of results rather than relying on a single best run.
TTFB is a useful starting signal, not a complete diagnosis. It includes the time spent resolving the domain, establishing a connection, negotiating security, waiting for the server, and receiving the first response byte. Once the first byte arrives, inspect the browser work that affects Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Commonly used working thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1; confirm the definitions and reporting windows used by your current monitoring tools.
Checklist by scenario
When DNS or connection setup looks slow
- Check DNS lookup time separately from connection, TLS, waiting, and download time.
- Test the hostname from more than one location. A problem limited to one region may indicate resolver, routing, or edge coverage issues rather than an application problem.
- Review unnecessary redirects, especially redirects between HTTP and HTTPS or between alternate hostnames.
- Confirm that the primary domain, www host, API host, and static asset host use the intended records and do not create avoidable lookup chains.
- Review DNS TTL settings before a migration or infrastructure change. For practical guidance, see DNS TTL Best Practices for Websites, Email, and Migrations.
When TTFB is high on uncached requests
- Compare a cached request with a deliberately uncached or cache-bypassed request. If only uncached requests are slow, investigate origin processing rather than adding more browser optimization.
- Inspect web-server timing, application logs, database query time, external API calls, PHP or runtime worker saturation, and queue depth.
- Check CPU, memory, storage latency, network throughput, and connection limits during the slow period. A quiet server test can hide a capacity problem.
- Review page-cache behavior. Nginx FastCGI cache, Varnish, LiteSpeed Cache, and managed WordPress caching can have different bypass and purge rules.
- For WordPress, test whether plugins, theme code, scheduled tasks, or uncached admin-ajax requests are contributing to origin time.
When cache performance is inconsistent
- Inspect response headers for cache status, Age, Cache-Control, ETag, and Vary. Confirm that the response being measured is the response visitors receive.
- Check whether cookies, authorization headers, query strings, device rules, or geography force a bypass.
- Compare the first request with repeated requests from the same location. A warm cache should be tested separately from a cold cache.
- Review CDN rules, origin cache rules, and purge events as one chain. A CDN hit cannot compensate for an origin rule that prevents useful content from being stored.
- Use the CDN Cache Miss Troubleshooting guide when static assets or pages repeatedly return to the origin.
When frontend metrics are poor but TTFB is acceptable
- Identify the LCP element and determine whether it is delayed by image discovery, CSS, fonts, JavaScript, or layout work.
- Resize and compress images, provide appropriate responsive variants, and avoid loading below-the-fold media before the primary content.
- Reduce render-blocking CSS and JavaScript, but test each change for regressions in interaction behavior.
- Reserve space for images, advertisements, embeds, and dynamic components to reduce layout shifts.
- Inspect long tasks and third-party scripts when INP is poor. A fast server cannot resolve main-thread contention in the browser.
What to double-check
Make sure the test URL represents a real visitor path. A homepage may be cached while product, search, account, checkout, and personalized pages are not. Ecommerce sites should test product, category, cart, and checkout flows independently; do not cache private or transaction-sensitive responses merely to improve a score. See rules for bypassing cache on login, cart, and personalized pages.
Check the full request chain: browser cache, DNS, CDN or edge cache, load balancer, web server, application runtime, database, and external services. Page cache and object cache solve different problems. A page cache can avoid generating an entire response, while Redis object cache can reduce repeated database or application lookups. The distinction is explained in Page Cache vs. Object Cache vs. CDN Edge Cache.
After each change, record the exact configuration, affected URL, cache state, test location, and result. Roll back changes that improve one metric while damaging availability, correctness, accessibility, or conversion-critical interactions.
Common mistakes
- Optimizing from one test: A single run cannot show normal variation or distinguish cold and warm cache behavior.
- Chasing a score instead of a bottleneck: Performance tools provide clues. Confirm the responsible request, resource, or server process before changing it.
- Purging everything too often: Frequent global purges create avoidable origin load. Prefer targeted invalidation and versioned assets where appropriate.
- Enabling every optimization: Minification, script delay, image replacement, and lazy loading can conflict with themes, plugins, or application behavior. Change one related group at a time.
- Ignoring cache correctness: A fast response with stale pricing, private account data, or broken variation logic is a production defect, not an optimization.
- Testing only from the server: Server timing does not reveal mobile CPU limits, font delays, layout shifts, or third-party script costs.
When to revisit
Run this checklist before seasonal traffic planning, a hosting or CDN migration, a major WordPress update, a redesign, a database change, or a new analytics and advertising integration. Repeat it after deployments that alter caching, DNS, server configuration, image handling, JavaScript, or authentication.
Keep a small performance log with monthly or release-based snapshots of TTFB, LCP, INP, CLS, cache-hit behavior, error rate, and origin resource use. Revisit the baseline when workflows or testing tools change, because a different device profile, region, browser, or field-data window can change the interpretation.
Finish every investigation with three actions: identify the largest confirmed bottleneck, apply the smallest safe change, and schedule a follow-up test. That habit turns website speed optimization from a one-time tuning exercise into an operational process.