Hosting, caching and CDN decisions for WordPress: a diagnostic guide for small agencies
A slow WordPress site does not automatically need a more expensive host or a CDN. The right fix depends on where the delay occurs. This guide shows small agencies how to separate origin, caching and delivery problems, choose the smallest appropriate intervention, and verify whether it actually helped.
Start with the bottleneck, not the product
Hosting, caching and content delivery networks (CDNs) solve different problems. They can work together, but they are not interchangeable. A hosting upgrade cannot fix a layout shift caused by an image without dimensions. A CDN will not necessarily fix slow WordPress database work on an uncached HTML request. A long browser cache lifetime will not help if the main delay is JavaScript running after the page has loaded.
For a small agency, the most useful question is therefore not “Which CDN should we buy?” It is “Where is the time being spent, and which layer controls it?” That approach avoids unnecessary migrations, duplicate caching layers and performance work that looks technical but does not address the measured problem.
The short version: investigate the initial HTML response first, then cache behaviour, then asset delivery. If the problem is mainly interaction delay or visual instability, hosting and CDN changes may be secondary rather than the primary fix.
What each layer actually controls
Hosting is the origin environment that runs WordPress and serves responses. Its performance can be affected by CPU and memory contention, PHP execution, database queries, plugins, server configuration, network latency and upstream services. Time to First Byte (TTFB) is useful for diagnosing this part of the loading path, but it includes more than raw server processing: DNS, connection setup, redirects and request latency can also contribute. web.dev describes TTFB as a diagnostic metric rather than a Core Web Vital, and gives 0.8 seconds or less as a rough target for many sites rather than a universal requirement. See web.dev's TTFB guidance.
Caching avoids doing the same work for every request. In WordPress that can mean several different layers: browser caching for static files, full-page caching for public HTML, object caching for repeated application or database work, and CDN caching at an edge location. These layers have different cache keys, lifetimes and invalidation rules, so “we have caching enabled” is not enough information to diagnose a site.
A CDN places content closer to users and can reduce the distance between a visitor and a cached response. It is especially useful for geographically distributed audiences and cacheable assets. Some CDNs can also cache HTML at the edge, but that requires deliberate rules for logged-in users, personalised content, carts, checkout pages, cookies and purge behaviour. A CDN that only caches images, CSS and JavaScript does not remove the origin processing time of an uncached HTML document.
The HTTP caching standard defines how caches store and reuse responses, while directives such as max-age and s-maxage control freshness for different cache types. The standard does not prescribe one ideal lifetime for every site. RFC 9111 defines HTTP caching behaviour, and MDN explains the practical Cache-Control directives.
A diagnostic workflow that prevents the wrong upgrade
1. Check real-user and lab evidence separately
Start with the symptom users actually experience. The current Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). Google recommends evaluating them at the 75th percentile, with mobile and desktop considered separately. TTFB is useful supporting evidence for loading problems, but it is not itself one of the three Core Web Vitals. web.dev documents the current Core Web Vitals and thresholds.
Use field data where available to understand what real visitors experience, then use repeatable lab tests and server/CDN logs to explain why. A single Lighthouse run can help diagnose a page, but it should not be treated as proof that all users have the same experience.
2. Test the HTML document before blaming static assets
If the initial HTML response is slow, determine whether the delay is present on a cold request, a warm request, or both. Compare an anonymous public page with any page that intentionally bypasses full-page caching. Check for redirect time, backend processing, database work and third-party dependencies before concluding that the hosting plan is underpowered.
A useful distinction is:
- Slow uncached HTML, fast cached HTML: investigate WordPress/PHP/database work and whether safe public pages can be page-cached more effectively.
- Slow cached and uncached HTML: investigate network path, origin capacity, server configuration, DNS/TLS overhead and whether the cache is genuinely being hit.
- Fast HTML, slow LCP: inspect the LCP resource, render-blocking CSS, font loading, image discovery and resource priority before changing hosting.
- Good loading, poor INP: investigate main-thread JavaScript and expensive interactions. A CDN is rarely the main answer.
- Poor CLS: investigate unstable layout, late-inserted content, missing dimensions and font behaviour. Faster delivery can help timing, but it does not automatically remove layout shifts.
For a deeper performance investigation after you have identified the bottleneck, see ScanMySEO's advanced Core Web Vitals troubleshooting guide.
3. Confirm what is actually being cached
Do not infer cache behaviour from the presence of a caching plugin. Inspect response headers and, where possible, the CDN's cache-status information. Confirm whether the HTML, images, CSS, JavaScript and fonts have different policies. Also check whether cookies, query parameters or authentication headers cause avoidable cache misses.
For versioned static assets whose URL changes when the file changes, long freshness lifetimes can be appropriate. MDN describes the common cache-busting pattern of versioned or hashed asset URLs combined with a long max-age and, where suitable, immutable. HTML usually needs a different policy because publishing or editing a page should become visible without waiting for a year-long browser cache.
# Example policy for fingerprinted static assets
Cache-Control: public, max-age=31536000, immutable
# A different policy may be appropriate for HTML that must revalidate
Cache-Control: no-cacheThose are examples, not universal settings. WordPress sites with ecommerce, membership, localisation or personalised responses need rules that prevent one user's private content from being stored in a shared cache.
4. Decide whether a CDN solves a measured problem
A CDN is a strong candidate when users are geographically far from the origin, when large cacheable assets dominate transfer time, when edge caching can safely reduce origin work, or when the current origin cannot efficiently absorb traffic spikes. It is a weaker first move when the site serves a mainly local audience, the HTML is already fast, the main problem is JavaScript execution, or the CDN would simply duplicate features already provided by the host.
If the decision is specifically about CDN configuration and risk rather than general performance diagnosis, the CDN configuration risk framework covers cache rules, ownership and failure modes in more detail.
Before and after: fixing the right layer instead of upgrading everything
Consider a hypothetical small agency managing a brochure-style WordPress site for a client with visitors in the UK and North America.
Before diagnosis: the agency sees a poor loading result and assumes the shared host is the problem. The site already uses a CDN for images, but the initial HTML response is slow on uncached requests. A caching plugin is installed, yet response headers show that the public HTML is regularly bypassing the page cache because of an unnecessary cookie set for every visitor.
The tempting response: migrate to a more expensive host and add another performance plugin.
The targeted response: first remove the unnecessary cache-busting condition, verify that anonymous public pages can be safely served from the page cache, and confirm the CDN is caching the intended static assets. Only then retest. If uncached backend requests remain slow after the application-level issue is addressed, the hosting environment becomes a more defensible next suspect.
| Observation | What it suggests | First action | Do not assume |
|---|---|---|---|
| High TTFB on uncached HTML only | WordPress/PHP/database work may be expensive | Profile backend work and check safe page caching | That a CDN for static files will fix the HTML response |
| High TTFB even on confirmed cache hits | Network, edge, origin or cache configuration may still be slow | Compare regions, headers and origin-versus-edge timings | That WordPress itself is definitely the bottleneck |
| Fast HTML but slow LCP | The largest element or its dependencies may load late | Inspect LCP resource discovery, priority and render blocking | That a hosting upgrade will fix the page |
| Poor INP | Main-thread work or event handling may be delaying interactions | Profile JavaScript and long tasks | That geographic delivery is the main cause |
| Poor CLS | The layout is moving after initial render | Find unstable elements and reserve space | That lower latency alone will eliminate shifts |
This is the important before-and-after difference: the “after” state is not defined by buying a host or CDN. It is defined by matching the change to evidence and removing a verified bottleneck.
When to change hosting, caching or CDN configuration
| Decision | Good reason to consider it | Evidence to gather first | Common false positive |
|---|---|---|---|
| Change or upgrade hosting | Backend processing remains slow or unstable after application and caching issues are ruled out | Server timings, resource saturation, PHP/database profiling, uncached response tests | A slow LCP image being mistaken for a server problem |
| Improve page/object caching | Public pages repeatedly trigger avoidable WordPress work or database queries | Cache hit/miss headers, cookie behaviour, application profiling | A cache plugin being installed but routinely bypassed |
| Change browser cache policy | Versioned static resources are repeatedly downloaded or revalidated unnecessarily | Cache-Control, ETag/Last-Modified behaviour, asset URL versioning | Applying a long lifetime to HTML that changes frequently |
| Add or reconfigure a CDN | Distance, asset delivery or safe edge caching is a measured constraint | Regional timings, CDN cache status, origin versus edge requests | Adding another CDN in front of hosting that already provides equivalent edge delivery |
Verify the change before calling it a performance win
After deployment, repeat the same test that exposed the problem. Keep the test conditions as comparable as possible and confirm that the intended layer changed: a higher cache-hit rate, lower backend processing time, fewer origin requests, faster delivery in distant regions, or a measurable improvement in the affected rendering path.
Then watch field data over time. Google states that Core Web Vitals are used by its ranking systems, but good scores do not guarantee high rankings and should not be treated as an isolated SEO target. The broader goal is a better page experience for users. Google's page experience documentation explains that distinction.
For agency handover, record the change, the reason for it, what was measured before and after, and any cache purge or rollback procedure. This matters because a future plugin update, cookie change or CDN rule can silently undo a successful configuration.
A practical agency checklist
- Identify whether the symptom is loading, interaction or layout stability.
- Check field data where available, then reproduce the issue in a controlled test.
- Measure the initial HTML response separately from static assets.
- Confirm cache hits and misses from headers or provider logs rather than assuming a plugin is working.
- Check whether cookies, login state, query parameters or personalised pages intentionally bypass shared caches.
- Use long cache lifetimes mainly for versioned assets that can safely keep the same content for that lifetime.
- Add or change a CDN only when distance, edge caching or traffic distribution is part of the measured problem.
- Retest the same bottleneck after each meaningful change instead of changing hosting, caching and CDN settings simultaneously.
- Document purge and rollback steps so the client is not dependent on one person remembering the configuration.
A ScanMySEO audit can help surface related performance and technical issues across a site, but an audit finding is a diagnostic input rather than proof that one infrastructure change will improve rankings. Use the evidence from the affected pages to decide what to fix first.