Website CDN Accelerated Optimisation

If you split WordPress performance optimisation into three layers:

• source station layer: Hosting / PHP / Databases / Caching Plugins - Deciding on TTFB and Backend Pressure
• resource layer: Image Optimisation - determining download size and speed of the first big picture
• delivery layer:: CDN -- Decide resources closer to visitors, more consistent hits, easier source stations

this paper CDN Acceleration：

• Knowing what CDN does and does not address
• Select the CDN form and service provider that is right for you (and understand the free version/starter version boundary)
• Go live in low-risk order, without crashing the site or having an incident with the e-commerce/membership cache
• Verify that “it's working” and troubleshoot “why it's not updating/why it's slowing down/why it's stringing content” when it goes live.”

1. Let's get the concepts straight: what CDN does and does not address.

1.1 The CDN addresses 3 main things

1.1.1 Faster delivery of static resources
Static resources such as images / CSS / JS / fonts / icons are closer to the visitor, download faster and render the page more consistently.
For WordPress, especially themes and plugin resources (wp-content/themes/、wp-content/plugins/) as well as media gallery images (wp-content/uploads/) is usually the “bulkier”.

1.1.2 Reduced pressure on source stations
After hitting the edge cache, requests are no longer returned to the source as often, and the bandwidth, concurrent connections, disk IO, and CPU fluctuations at the source are lighter.
This is especially true for wave scenarios such as “event pages, article blasts, and product pages that get a lot of visits”.

1.1.3 Improved stability (more resistant to fluctuations)
When traffic spikes, edge nodes absorb a large number of duplicate requests, and the source station is much less likely to be busted.
You'll see “smoother access”: the edge cache continues to output even when the source site is momentarily stressed.

---

1.2 3 Types of problems that CDN does not solve automatically

1.2.1 Slow source station itself
Slow databases, slow plugin logic, slow PHP calculations -- these are source site level issues.
CDN can make static resources faster, but if you even the home page HTML are generated very slowly, the user will still feel that “open on the slow”. This time the priority back to: hosting / caching plug-ins / database optimisation.

1.2.2 The image itself is too large
CDN can't “magically make” the big picture of 3MB smaller.
You'll want to do image optimisation first: sizing strategy (don't download oversized images), compression, WebP/AVIF, lazy loading strategy, etc.

1.2..3 Slow third-party scripts
Ads, stats, customer service, social media components, etc. come from third-party domains.
CDN usually can't help them to be “faster”, you can only deal with it by reducing/delaying loading, replacing vendors, or doing scripting policy optimisations.

2. 30 second selection: Which CDN form do you need?

For WordPress, there are two main categories. If you choose “Format” and then “Service Provider”, the idea will be very clear.

2.1 All-in-one “reverse proxy type” (less effort, suitable for most sites)

Features: It’s not only CDN, it also takes DNS / SSL / Basic security protection (e.g. DDoS/WAF) Packaged together. You access it and it stands in front of your site as a proxy.

What you'll get:

• HTTPS Easier Certificate and TLS Management
• Unified security portal (basic DDoS, access control, WAF, etc.)
• Edge caching with rules engine (can do more granular caching policies, bypass policies)
• “More room for expansion”: if you want to add security, speed limits, and bot protection later, it's usually all in the same system.

Provider: Cloudflare / Tencent Cloud International EdgeOne / Alibaba Cloud International ESA

If you wish:

• You wish HTTPS + CDN + Basic Security do it all in one go
• Would you like to unify the domain name resolution/proxy layer under one platform?
• You are more interested in the “overall experience and subsequent expansion” and don't want to split DNS, certificates, CDN, security into multiple sets.

---

2.2 Pure “Static Pull CDN” (low-risk start, mainly accelerating images/CSS/JS)

Feature: You only put static resources into CDN edge cache; HTML pages are still handled by the origin site (and the origin cache plugin).

What you'll get:

• Very low business risk: no “stringing of content/cart” if you don't touch HTML”
• Cost modelling is more intuitive: commonly billed by traffic/request/region
• A purer structure: more like a “static resource distribution service”.”

Representative: bunny.net (clear usage-based billing model)

If you wish:

• You want to take the “surest step” first - static resource acceleration.
• You want to get the revenue quickly before deciding whether or not to go on a proxy type/full site caching
• You want the cost to be closer to “pay for what you use.”

3. How to do it

• Tier 1: Integrated agent type (preferred): Cloudflare / EdgeOne / ESA
• Tier 2: Static Pull CDN (solid start): bunny.net / Cloudways CDN etc.

4. Recommended service providers

4.1 Cloudflare: Reverse proxy integration (free start, ecologically mature)

What is it?
You plug the domain in and it stands in front of the site as a proxy, providing CDN, certificates, base protection and caching rules capabilities.

for whom

• Want to save: HTTPS + CDN + Basic Security in one package
• Want mature ecosystem: follow-up to add WAF, speed limit, edge rules, etc., the path is smooth

risk point

• Updates do not take effect: Longer cache links (browser cache + CDN cache + source cache) after CDN went live, need “versioning policy” to keep updates under control (troubleshooting tree later)
• Be careful with caching HTML: if caching HTML, e-commerce/membership/personalisation pages must be strictly bypassed or they are prone to serious accidents (list of scenarios follows)

instructions：

• Positioning: Reverse Proxy Integration (SSL + CDN + Basic Protection)
• Suitable for: saving on-line, large space for subsequent expansion
• Core value: unified certificate/security/cache portal
• Risks: Updates rely on versioning policies; HTML caching needs to be tightly bypassed

---

4.2 Tencent Cloud International EdgeOne: Reverse proxy integration

What is it?
The form is also an all-in-one platform of “acceleration + security + certificates”, which is suitable for putting sites into the unified agent layer management.

• has a free version like Cloudflare, but there is usually Quota/functional ceiling(number of rules, number of logging tasks, etc.), but no modifications to DNS are required, just cname access to theThe free version is not recommended for commercial websites！
• Meanwhile free plans often mean SLA not guaranteed
  It works, but not as a “commercial SLA package”.

• If you wish to automatically switch between mainland China lines in mainland China, you will usually need to first complete theChina ICP Record; only international routes can be used when they are not filed.

Description:

• Positioning: Reverse proxy integration (acceleration + security + certificates)
• Ideal for: those who want integrated access and are considering node capacity in mainland China
• Free: free plans/free versions exist, but quotas are limited and SLAs are usually not guaranteed
• Risks: rules/logs/subdomain quotas should be planned in advance; HTML caching should be equally cautious

---

4.3 Aliyun International ESA: Reverse proxy integration

• has a free version like Cloudflare, but there is usually Quota/functional ceiling(number of rules, number of logging tasks, etc.), but no modifications to DNS are required, just cname access to theThe free version is not recommended for commercial websites！
• Register for an account on the international site to use
• Go to the ESA console to add a site and select the free Entrance subscription access
• If you want to automatically switch the mainland China line in mainland China, you usually need to complete the ICP filing first; you can only go to the international line when you have not filed.
• Free is more suitable for development/testing/evaluation and is not usually equivalent to commercial SLA packages.
• Free packages often have speed limits/support method restrictions (e.g. SLAs, etc.)

About the mainland China line:

• To enable mainland China nodes, you usually need to meet the filing and regional conditions
• Free Entrance Default international route, wish to take the mainland China route must be completed.China ICP Record Requirements

Description:

• Positioning: reverse proxy integration (site acceleration + security)
• Free: international station account available Entrance free access; the default does not include mainland China acceleration
• Ideal for: evaluation/testing with light use; or subsequent upgrade package
• Risks: free boundaries to look at (SLAs/speed limits/support methods); zones and filings to be planned ahead of time

---

4.4 bunny.net: Static Pull CDN (low-risk start, clear per-volume billing)

If you want to “get the surest gains first”, a Pull CDN like the bunny is a good fit:
It's more like a “resource delivery service”: you give it static resources to deliver, the cost is usually related to traffic/requests/region, and the model is clear and controllable.

Fit:

• do sth. first Images / CSS / JS / Fonts Static acceleration of
• You want to get “low-risk and stable income” first, and are not in a hurry to hand over the whole site to a proxy-type platform (DNS/SSL/WAF all-in-one).
• You want the cost model to be closer to “pay for what you use” rather than getting into a more complex package right off the bat.

risk point

Static resource “updates don't take effect” is almost always not a bug in CDN., rather, it is a normal behaviour of the caching system:
When you update CSS/JS/images in the backend, but theThe resource URL is unchanged.(same address/filename/path), CDN and the browser will reasonably continue to hit the old cache, and you'll see “why isn't it updated”.

A clear, enforceable principle:

Version numbers take precedence, Purge pockets.

Why this is the most stable:

• Version number/filename changes → URL change → CDN cached as new resource → new version takes effect almost immediately
• **Purge（清缓存）**需要你主动触发，容易范围不准、节点传播有延迟；频繁 Purge 还会导致命中率下降、回源增加、波动变大

Easy to see examples:

• style.css The content has changed, but the URL is still style.css → CDN Continue to give old cache (reasonable)
• The URL becomes style.css?ver=20260103 或 style.abc123.css → CDN Considered new resource → new version effective immediately

Bunny as a “First Step CDN” Best Practice

1. Cover only static resources first(images/CSS/JS/fonts), don't cache HTML right off the bat!
   • Benefit: There are almost no serious incidents such as “user sees someone else's content/cart serial number”.
   • You're also more likely to validate gains: faster static resources, lighter source stations
2. Getting the update strategy right
   • CSS/JS: try to use version number/filename change
   • Images: try to avoid long-term “same name coverage”, more recommended new file name / path changes (especially the home page banner, event map)
3. Confirm the hit with the validation checklist when it goes live
   • Whether the static resource is from CDN
   • Whether hit rates are gradually increasing and source bandwidth/requests are smoother (a list of verifications follows)

5. Road map to the top line: advancing in 3 phases (from stable to strong)

CDN The easiest way to “mess up” on the line is to try to get all the abilities up at once.

Stage 1: Static resources only CDN (highly recommended first)

objectives: Images/CSS/JS/fonts go CDN first; HTML is not in the CDN cache (or is temporarily immobile).

Why is this the safest thing to do first?

• Minimal risk: static resource caching is wrong, up to “style/image not updated”, manageable
• Will not touch login state, e-commerce processes, account information correctness
• You can clearly see the benefits: faster downloads of static resources and smoother source sites!

Common problems at this stage (the troubleshooting tree will be given later)

• Mixed content (HTTPS page loaded with HTTP resources)
• Static resource updates don't take effect (URLs don't change)

---

Stage 2: Refresh strategy (version number first, Purge/failure pockets)

This is the watershed of “CDN done professionally or not”.

A hard rule:

Don't rely on Purge for updates that can be resolved with version number/filename changes.

Why cache links become metaphysical when they get longer:

• Browser caching: You may have old CSS/JS cached locally.
• CDN Caching: Edge nodes may be caching old resources
• Source site caching: Cache plugins/server caches may still be outputting old content

If you don't have a versioning strategy, the release becomes:
“Changed something → Refresh → Doesn't work → Clear cache again → Doesn't work again → Clear another level of cache”
That's the biggest pain point many people have with the CDN.

---

Stage 3 (advanced): to cache or not to cache HTML (high yield, but highest risk)

HTML caching (full-site caching/edge caching) significantly reduces TTFB, but is also a high incident area in WordPress scenarios.

Don't cache HTML if you're not sure. static first CDN + source caching plugin.

If you want to cache HTML, two rules apply:

1. It only starts with the “Visitor State”.: Cache only unlogged visitor pages
2. Write the bypass list first: Correctness comes first, then hits

6. List of scenario rules: what to do for different site types without incident

6.1 Content sites / blogs (article-based, many visitors)

testimonials

• Static resources: fully cached
• HTML: consider caching the “unlogged-in visitor page”

It is often necessary to bypass the

• Backend & Login:/wp-admin/*、/wp-login.php
• Preview/draft (preview)
• Search results page (parameters change a lot, it's most economical not to cache them first)
• POST request for form submission/comment submission

Cache Keys should at least distinguish between

• Logged in or not (cookie dimension)
• Languages (multilingual stations)

---

6.2 Corporate site / marketing landing page (forms, activities galore)

testimonials

• Static resources: fully cached
• HTML: public landing pages can be cached (guest state), but be careful with form result pages

The easiest pitfall to step into: tracking parameters leading to cache fragmentation
Landing pages are common utm_* Parameters:

• All Engage Cache Keys → Cache Shredded, Poor Hit Rate
• Ignore all → A few pages that depend on parameter rendering may not be as expected

---

6.3 Membership site / course site / community (high share of logged-in states)

reach a verdict: HTML caching should be done with great care.
Safe practices are usually: static CDN + source/object caching; HTML only caches guest state.

Must bypass

• Login/Register/Retrieve Password
• Account Centre, Orders/Subscriptions, Personal Details
• Any “user-state strongly relevant” pages and interfaces

---

6.4 E-commerce station (WooCommerce)

A list of the most important bypasses

• Shopping Cart, Checkout, Account Page
• Pages related to order confirmation and payment callbacks
• Login/register, coupon/points and other user-state related entrances

Why e-commerce is more prone to accidents

• Once the user has a shopping cart, session, and login state, the page is highly personalised
• Typical consequences of HTML caching that is not bypassed/differentiated are: shopping cart mismatches, account strings, and price display anomalies.
  Correctness takes precedence, don't sacrifice correctness for hits.

---

6.5 Multi-Language / Multi-Currency Sites

testimonials

• Static resources: fully cached
• HTML: guest states can be cached, but cache keys must clearly distinguish between language/currency variants

Cache Key must be considered

• Language (Path) /en/ /zh/ or subdomain en.）
• Whether to log in (cookie)
• Currency/tax rate (if affects presentation)

---

7. Risk alerts

Risk 1: Caching the wrong content (most serious)

• Static resource caching error: mostly old styles/images
• HTML caching error: may string content, string shopping cart, string account - this is a serious incident!

Risk 2: Updates do not take effect (most common)

As the cache link gets longer, “changes don't take effect” will be more common:

• Version number/filename changes take precedence
• Purge/failure peddling
• Publishing process should be reproducible (know what URLs were changed for each publish)

Risk 3: Boundary of commitment for free version/starter version

• Common features of free programmes: limited quota, some capacity excluded, SLA/support approach not equivalent to full commercial use

Risk 4: Mainland China-related competencies are easily misinterpreted

• ESA: China ICP Record Required for Mainland China Routes
• EdgeOne: China ICP Record Required for Mainland China Routes

8 Validation checklist: how to confirm that it “really works” after it goes live”

8.1 Are static resources really gone CDN?

• Image/CSS/JS whether from CDN Domain/Edge Node
• Whether or not you can see clear signs of cache hits (signs vary by platform)

8.2 Has the source station pressure dropped?

• Is the source station bandwidth smoother
• Whether the number of requests/connections from the source site has dropped (especially requests for duplicate resources)

8.3 Are updates manageable?

• Change CSS/JS once or replace an image.
• Whether a new version can be fast-tracked by “version number change/filename change”.
• If you can only update by Purge, you haven't got a good versioning strategy in place (prioritise patching the strategy, don't make Purge a daily routine)

8.4 Are the dynamic key pages correct?

(E-commerce/membership site a must)

• Is the content of the page after login/logout correct
• Shopping cart/checkout/account related pages are always correct
• There is no “different users see the same user-state content” exception (high risk).

8.5 Has the error rate increased?

• Return to source timeout, 5xx, intermittent failure to open
• These usually mean: insufficient bearer at the source, incorrect rules, speed limit triggers, or problems with the link back to the source

9. Updating the non-functionality tree (turning “metaphysics” into steps)

Start by determining what type of problem you are experiencing:

9.1 Static resources not updated (CSS/JS/images still old)

Scenario A: Only you see the old, stealth/swap device is new
Priority suspicion: browser caching

• Direction for resolution: release new resources with version number/filename changes

Scenario B: Everyone sees old (stealth/different devices also old)
Priority suspicion: CDN still hits old cache

• 99% Cause: Resource URL not changed
• Priority solutions: versioning strategies
• Pocket: Purge (temporary means)

Scenario C: The old image keeps showing up after the image is overwritten with the same name.
This is a classic problem with browser cache + CDN cache overlay

• Practical advice: try to avoid long term “same name overwrites”, use new filenames/paths or version numbers

---

9.2 HTML is not updated (page content/modules are still old)

Scenario A: backend/login is new, visitors see old
Priority suspicion: guest HTML is cached

• First things first: should these pages cache HTML?
• If it should be cached: need controlled refresh strategy, otherwise release is uncontrollable

Scenario B: Only some regions/some networks feed back old content
Priority doubt: different edge nodes have different cache states

• Direction for resolution: converge differences with versioning/refresh strategy; do more explicit invalidation if necessary

Scenario C: Abnormalities in logged-in users/shopping carts
High-risk sign: may be caching the wrong content

• Immediately check if user-state pages (cart/checkout/account, etc.) are cached
• Check that the Cache Key ignores key variants such as “userland cookie/language/currency”.

10. Recommendations

Cloudflare

• Reverse proxy integration
• Suitable for: saving start
• Focus: versioning policy to address updates; HTML caching done from guest state
• Risk: Dynamic pages must be bypassed

Tencent Cloud International EdgeOne

• Reverse proxy integration
• Suitable: Consider mainland China node capacity and integrated access
• Free: there are free plans/free versions, but quota and commitment boundaries have to be seen clearly
• Risks: rules/logs/subdomain quotas to be planned; HTML caching with caution

Aliyun International ESA

• Reverse proxy integration
• Free: International accounts available Entrance Free Access
• Risk: Free boundaries (SLA/support/speed limit) and zones/filing conditions to be confirmed in advance
• Suitable for: evaluation/testing and light access; or subsequent package upgrade, or considering mainland China node capacity and integrated access

bunny.net

• Static Pull CDN
• Suitable: low-risk static acceleration first
• Focus: version number first, Purge undercover; avoid same-name overrides
• Risk: Frequent encounters with “old resources” if update strategy is not done properly.”

11. Recommendations for action

1. First choice of form: reverse proxy integration (Cloudflare/EdgeOne/ESA) or static Pull CDN (bunny)
2. Go live by stage:Static first → then versioning policy → finally consider HTML caching
3. Check by validation checklist after go-live: hit/return to source/update/dynamic bypass/error rate
4. Need to be faster: go back to “Cache Plugin”, “Image Optimisation”, and compress the source and resource layers again!

WordPress CDN Frequently Asked Questions

1. Why is it still slow after using CDN?

The most common reason is not that CDN doesn't work, but that the bottleneck is not in the “delivery layer”.

You can judge them in that order:

• TTFB is still high.: Explanation of slow HTML generation from source (database/plugin/cache plugin configuration/hosting performance) → back to source level optimisation
• The first big picture is very slow: indicates incorrect image volume, size or format → do image optimisation first (compression, WebP/AVIF, sizing strategy)
• Third-party scripts slow down: ads/stats/customer service scripts are common → CDN Usually not helpful, needs to be reduced or delayed loading
• Only certain areas are slow: it could be a node overwrite, a return line, or a cache miss (low hit rate) → look at hit rate and returns

CDN is responsible for delivering “optimised resources” faster; slow source sites, large images and slow scripts should be handled separately.

---

2. Why do users still see the old version even though I've updated the CSS/JS/images?

This is the most common problem in CDN scenarios and the core reason is usually:The resource URL is unchanged., the caching system will reasonably continue to hit the old cache.

The principle of the most stable treatment:

• version number priority: Let the resource URL change (e.g. style.css?ver=xxxx or filename hash)
• Purge Underwriting: Clearing the cache as a stopgap when you don't have a versioning policy in place.

If you often replace the homepage banner / campaign image, it is recommended to avoid “same name overwrite”, preferring to use the new file name / new path (more controllable).

---

3. Do I need to cache HTML? Is there no point in not caching it?

Not necessarily needed.

For many sites, the greatest value of CDN comes from:

• Faster for static resources (images/CSS/JS/fonts)
• Source Station Stress Reduction and Stability Improvement

Caching HTML The benefits may indeed be greater (TTFB would be lower), but the risks are also the greatest: e-commerce, memberships, personalised content, multi-language/multi-currency are all prone to caching the wrong content.

Steady Route:

1. Static first CDN (low risk, high reward)
2. Run through the versioning policy and validation checklist
3. Re-evaluate whether to cache HTML (starting with “guest state”)

---

4. Can the e-commerce site be on CDN and will it mess up the shopping cart?

It can be on, and should be (at least for static resources), but avoid caching userland pages.

• Static resources can be cached: images, CSS, JS
• The userland page must bypass the: Don't cache shopping cart, checkout, and account related pages HTML
• As long as you don't HTML cache these pages, the risk of “crosstalk” is greatly reduced!

---

5. How can a multi-language/multi-currency site do CDN without stringing languages/prices?

centre Cache Key Is it correct.

• Language (path or subdomain)
• Currency (if it affects the price display)
• Whether to log in (cookie)
• Region/tax rate (if the page is subject to change by region)

If these dimensions don't enter the caching logic, it's easy to have: language A users see language B content, or inconsistent prices.

---

6. Should I go for reverse proxy integration (Cloudflare/EdgeOne/ESA) or static Pull CDN (bunny)?

You can select by “Target” and “Risk Preference”:

• Would like to get HTTPS + CDN + basic security, with subsequent expansion of rules/WAF in one go:Reverse proxy integration
• Want to do the first step of the most stable first step (static resources are faster) and don't want to move the whole agent:Static Pull CDN(e.g. bunny)

If you're hesitant, default advice:Pre-static CDN → Run through the versioning policy and validation checklist → then decide whether to go to the proxy/HTML cache.

---

7. Can the free version be used directly on the official website?

It can be used, but think of “free” as “starter/evaluation/light use”, not as a “formal programme with commercial SLAs”.

• Are you comfortable with a free programme ofQuota caps, missing features, differences in support, and possible lack of SLA commitments？
• If you can't, you should treat the free as a trial and subsequently upgrade to a more suitable package

---

8. How can I be sure that CDN is actually in effect and not just a mental note?

Confirm with these three steps (without any complicated tools):

1. See if static resources are returned from CDN(whether the source of the image/CSS/JS has changed)
2. See if the hit rate and return source improve(Hit up, source back down for real gains)
3. Change the CSS/image validation update strategy once(version number in effect, indicating that the link is controllable)

If you can't do #3, the more you optimise, the more likely you are to be tormented by “updates don't take effect”, so it's recommended that you prioritise the versioning policy.

---

9. Why do I often get stuck when I enable acceleration for mainland China?

The most common cause is:Mismatch between regional choices and filing conditions。

• If you want to select an acceleration region that includes mainland China, you will usually need to complete the ICP Filing; Undocumented can only select regions that do not include mainland China.

---

10. Should I install the caching plugin or CDN first?

The general recommended order is:

1. Source site layer: cache plugin/hosting base stabilised first (TTFB down, backend pressure down)
2. Resource layer: image optimisation to keep the size down
3. Delivery Layer: CDN Delivering Resources Faster and More Consistently

If you only want to do one thing right now and are afraid of flipping:Static first CDN (Phase 1), with stable returns and minimal risk.