BunnyCDN Setup Checklist for WordPress

This article assumes something is already wrong: a poor PageSpeed Insights result, a GTmetrix waterfall that looks noisy, a WordPress admin warning, a checkout complaint or a DNS change that has not landed cleanly.

Do not rely on one score. Combine PageSpeed Insights, GTmetrix, DevTools, LiteSpeed Cache state, BunnyCDN headers and the relevant WordPress admin screen before deciding what to change.

Do not start in the settings screen. Start with the failing behaviour, then work backwards. The first half hour should produce a short note: affected URL, visitor state, metric or error, likely layer and the next low-risk test.

Proof the CDN is doing work

A BunnyCDN workflow for BunnyCDN WordPress setup only works when the origin file, CDN hostname, SSL and cache rule all agree. A CDN should reduce distance, not hide an avoidable origin problem.

• old images or CSS appear after replacement
• assets still load from the origin domain
• cache MISS appears on repeat requests
• SSL works on the site but not the CDN hostname

For BunnyCDN work, always keep one origin URL and one CDN URL for comparison. If the origin is slow, the CDN may still help assets, but it will not make dynamic WordPress generation disappear.

Headers, hostnames and cache status

Use the tools for different questions rather than running them all and hoping one gives a simple answer.

• browser Network headers
• BunnyCDN pull zone settings
• DNS lookup for the CDN hostname
• GTmetrix geographic test
• WordPress asset URLs

Purge decisions after content changes

• 1. verify the pull zone origin
• 2. serve static files through the custom CDN hostname
• 3. purge the exact changed URL where possible
• 4. compare origin TTFB with CDN delivery

A CDN validation pass should prove three things: the browser is requesting the CDN hostname, the edge has a cacheable object, and the origin is not still the slowest part of the path. If any of those fail, the fix is architectural rather than cosmetic.

Decision point for BunnyCDN WordPress setup

For BunnyCDN WordPress setup, separate CDN delivery from origin performance. BunnyCDN can shorten the distance for images, CSS, JavaScript and downloads, but it cannot repair a slow uncached WordPress request, a 3 MB source image, a broken SSL hostname or a cache rule that serves the wrong content.

Keep a small change log beside the work. Record the previous value, the new value, the cache purge performed and the exact URL retested. That makes rollback possible when a later plugin update changes the behaviour.

Artefacts to keep for BunnyCDN WordPress setup

Evidence is most useful when it is boring and exact. Include timestamps, URLs, status codes, cache states and the admin screen connected to the change.

• CDN asset URL with response headers and cache status.
• Pull zone origin, custom hostname and SSL status.
• Before-and-after request timing for origin URL versus CDN URL.

Validation mistakes

• serving oversized images through the CDN
• caching private HTML at the edge
• changing DNS before SSL is ready

Close the work only when the visitor journey still works. A cleaner waterfall is not enough if a form, checkout, login, menu, redirect or CDN-served asset now behaves differently.

How to know the fix held

• Compare the origin asset URL with the BunnyCDN URL.
• Check cache status and SSL on the CDN hostname.
• Purge a single changed asset and confirm the new version is served.

Questions about CDN checks

How does BunnyCDN affect BunnyCDN WordPress setup?

BunnyCDN WordPress setup should be checked against the failing URL, not a generic checklist. Use the symptom, the tool output and the WordPress layer involved to decide the next action.

What proves the CDN is being used?

BunnyCDN WordPress setup should be checked against the failing URL, not a generic checklist. Use the symptom, the tool output and the WordPress layer involved to decide the next action.

When should I purge the whole zone?

Purge the smallest useful scope. A changed image usually needs that asset purged from BunnyCDN and possibly the page HTML from LiteSpeed Cache; it should not require deleting every cache object on the site.

Keep the final test boring and repeatable. Same URL, same device class, same login state and same metric. That is how you avoid mistaking noise for progress.

For a CDN article, add the request path. Browser asks for cdn.example.co.uk, DNS resolves the hostname, BunnyCDN checks its edge cache, and a MISS goes back to origin. The fix depends on which step is slow, stale or misconfigured.

If the CDN looks inconsistent, check whether the file name changed. Versioned CSS, JavaScript and image URLs make purging easier because the browser and edge cache can both see a new object.

Keep the failing page unchanged as the reference point until one fix has been measured.

When the next result is noisy, improve the test conditions before adding more fixes.

A reversible change is safer than a heroic one, especially on checkout, DNS and cache rules.

When the issue involves Core Web Vitals, record which metric you are trying to move before changing settings. LCP, INP and CLS often need different fixes, so one combined score is not enough evidence.

Save the note with the test result so the next fix starts from evidence, not memory.

Summary

A good fix leaves the site easier to support. The cache rules are known, the CDN behaviour is verified, the WordPress setting is documented and rollback is possible if the next update changes the result.