A slow website is not always a hosting problem, but hosting can affect every request your site serves. This troubleshooting workflow helps you separate server response issues from caching, DNS, database, PHP, CDN, image, and frontend problems, then measure the result before and after each change.
Overview
Website speed is best treated as a chain rather than a single setting. A visitor’s request may pass through DNS resolution, a CDN or reverse proxy, the web server, application code, a database, cache layers, and the browser. A delay at any point can make the site feel slow. Changing hosting before identifying the bottleneck can add cost without addressing the cause.
Start by separating two broad categories:
- Server-side delay: the browser waits too long before receiving the first response. This is commonly reflected in a high time to first byte (TTFB).
- Browser-side delay: the server responds promptly, but the page takes too long to become useful or stable because of scripts, stylesheets, images, fonts, or layout changes.
Test the same URL several times from more than one location, and record the page, device type, protocol, cache state, and test date. A homepage tested from a nearby region may produce very different results from a product page tested by a visitor far from the origin server. For a broader infrastructure review, compare your findings with the deployment considerations in this guide to hosting for developers.
Do not make several major changes at once. A reliable troubleshooting process changes one variable, retests, and keeps a short record of what happened.
What to track
Use a simple performance log. Each entry should include the URL, test location, device or connection profile, date, and the change made. Track these measurements and signals:
1. TTFB and server response
TTFB indicates how long it takes before the browser receives the beginning of a response. It includes network and connection time as well as the time required for the server or application to produce a response. A consistently high TTFB on uncached pages points toward the origin, application, database, server resources, or network path. A high result only from distant locations may instead suggest routing, CDN, or geographic coverage issues.
2. Core Web Vitals
Track the current Core Web Vitals for the pages that matter most, such as the homepage, a landing page, a product page, and a representative article. The key signals cover loading performance, interaction responsiveness, and visual stability. Review both field data, when available, and controlled lab tests. Lab tests are useful for repeatable comparisons; field data reflects the varied devices and networks used by real visitors.
3. Cache behavior
Confirm whether HTML, API responses, images, stylesheets, and scripts are cached as intended. Check response headers for cache status, cache-control instructions, age, and validation behavior. A page that is fast on a second visit but slow on the first may need better origin performance or edge caching rather than more browser caching.
4. CDN and DNS path
Record whether requests pass through a CDN, whether static files are served from it, and whether dynamic HTML is eligible for caching. Verify that DNS points to the intended service and that old records are not sending some visitors to a slower or retired origin. The DNS records guide can help when checking how a domain connects to hosting.
5. Application, database, and runtime load
Review CPU, memory, storage I/O, process limits, PHP or other runtime versions, database query time, and background jobs. For WordPress, compare performance before and after plugin, theme, and object-cache changes. A site can have adequate hosting capacity but still be slowed by an inefficient query, an unbounded search, or a plugin that performs work on every request.
6. Frontend weight
Measure total transfer size, request count, JavaScript execution, render-blocking resources, image dimensions, font loading, and third-party scripts. Compress and resize images, serve modern formats where appropriate, defer nonessential scripts, and remove assets that are no longer used. Faster web hosting cannot fully compensate for a page that asks the browser to download and execute excessive resources.
| Symptom | Likely area to inspect | First check |
|---|---|---|
| High TTFB on uncached pages | Origin server, application, database, runtime | Server resource graphs, slow queries, application logs |
| Fast repeat visits but slow first visits | Origin generation, CDN, cache rules | Cache headers and cache-hit status |
| Good desktop results, poor mobile results | JavaScript, images, layout, device resources | Mobile waterfall and main-thread activity |
| Slow only for distant visitors | CDN coverage, routing, origin distance | Regional tests with and without the CDN |
| Speed worsened after a release | Theme, plugin, code, assets, queries | Compare the deployment diff and test the changed components |
Cadence and checkpoints
Run a baseline before changing the hosting plan, enabling a CDN, or replacing a cache layer. Save the results rather than relying on memory. A baseline should include at least one uncached request, one repeat request, a mobile test, a desktop test, and a test from a location relevant to your visitors.
For a normal site, review performance monthly or quarterly. A monthly check is appropriate for sites with frequent releases, advertising scripts, changing catalogs, or active campaigns. A quarterly review may be sufficient for a stable brochure site. At each review:
- Test the same priority URLs using the same test profiles.
- Compare TTFB, cache status, Core Web Vitals, transfer size, and request count with the previous record.
- Check hosting resource usage for sustained CPU, memory, storage, or process-limit pressure.
- Review recent theme, plugin, framework, runtime, DNS, CDN, and configuration changes.
- Choose one or two corrective actions, then retest.
Run an additional checkpoint after a traffic increase, migration, redesign, major plugin update, database change, or CDN configuration change. If you are moving providers, test before and after the cutover and keep the old environment available until the new results are stable. See how to migrate a website without downtime for a related migration workflow.
How to interpret changes
Look for patterns instead of reacting to one test. A small variation between runs is normal, especially on shared networks or busy servers. A repeated change across several runs, pages, and regions is more useful evidence.
TTFB improves while page rendering remains slow: the server is responding sooner, but frontend work remains. Inspect image delivery, CSS, JavaScript, fonts, and third-party code.
TTFB remains high only on dynamic pages: investigate application execution, database queries, authentication, personalization, and cache exclusions. Increasing server resources may help, but only after confirming that capacity is the limiting factor.
Every page becomes slower under traffic: compare resource graphs with request volume and inspect concurrency, process limits, database connections, and queueing. This pattern may justify a more scalable hosting design, but an application bottleneck can produce the same symptom.
The CDN appears enabled but results do not improve: verify that the intended assets are actually served from the edge, that cache rules are not bypassed, and that the origin is not still generating every request. Purging a cache can temporarily make results look worse, so note when a purge occurred.
Core Web Vitals decline after a design change: compare the page waterfall and layout behavior before and after the release. New hero images, carousels, consent tools, chat widgets, and analytics scripts are common sources of regression. Roll back or isolate the change if it affects important pages.
Keep performance and reliability checks together. A faster site is not a successful improvement if caching causes stale content, deployment invalidates critical files, or a configuration change creates errors. Confirm HTTPS, backups, monitoring, and restore procedures as part of infrastructure work; the backup testing guide covers the recovery side.
When to revisit
Return to this workflow on your regular monthly or quarterly schedule and whenever the site changes materially. Revisit immediately after a migration, traffic surge, CMS or runtime update, theme or plugin installation, database maintenance, DNS change, CDN rollout, or unexpected increase in support reports about slowness.
Refresh your test instructions and recorded assumptions when browser testing tools, Core Web Vitals guidance, hosting technology, cache software, or your CMS stack changes. Keep the historical log, but label changes in test method so that an apparent improvement is not mistaken for a real one.
To finish each review, write down the next action: for example, “test database queries on the product page,” “verify HTML cache headers,” or “compare mobile performance after removing the carousel.” Assign an owner and a retest date. That small habit turns website speed from a one-time project into an infrastructure control you can monitor as the site, traffic, and hosting environment evolve.
