WordPress CDN Acceleration

If you split WordPress performance optimization into three layers:

• source station layerHost / PHP / Database / Cache Plugin — Determines TTFB and Backend Load
• resource layer: Image Optimization - Determining download size and speed of first-screen big picture
• delivery layer: CDN — Bring resources closer to visitors, improve cache hit stability, and lighten the load on the origin server

this paper CDN Acceleration：

• What CDN can and can’t solve
• Choose the right CDN setup and provider for you, and understand the limits of the free and starter plans
• 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. First, clarify the concept: what CDN solves and what it doesn’t solve

1.1 CDN solves 3 main things

1.1.1 Faster delivery of static resources
Images / CSS / JS / Fonts / Icons and other static resources are closer to the visitor, download faster and render the page more stable.
For WordPress, especially the theme and plugin resources (wp-content/themes/、wp-content/plugins/) as well as media gallery images (wp-content/uploads/) is usually a “volume hog”.

1.1.2 Reduced pressure on source stations
After the edge cache is hit, requests no longer need to frequently go back to the origin, reducing the origin server's bandwidth usage, concurrent connections, disk I/O, and CPU fluctuations.
This is especially true for wave scenarios such as “event pages, article blasts, and product pages that are heavily visited”.

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 pressurized.

---

1.2 3 types of issues that CDN won’t resolve automatically

1.2.1 Slow source station itself
Slow database, slow plugin logic, and slow PHP calculations — these are source site-level issues.
CDN can speed up static assets, but if your homepage HTML is still generated very slowly, users will still feel that the site is slow to open. In that case, prioritize going back to: hosting, caching plugins, and database optimization.

1.2.2 The image itself is too large
CDN cannot magically shrink 3MB's large image.
You'll want to do image optimization 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 make them faster; you can only handle them by reducing or delaying loading, replacing vendors, or optimizing script strategy.

2. 30-second selection: Which CDN form factor 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)

**特点：**它不仅是 CDN，还把 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're gonna get:

• HTTPS certificate and TLS management made simpler
• Unified security gateway
• 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 in the future, 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
• Are you willing to unify the domain name resolution/proxy layer under one platform?
• You care more about the overall experience and future expansion, and don’t want to split DNS, certificates, CDN, and security into multiple separate sets.

---

2.2 Pure Static Pull CDN (low-risk start, mainly speeding up images/CSS/JS)

Static resources are placed in the CDN edge cache; HTML pages remain handled by the original source (including the source server's cache plugins).

What you're gonna get:

• Very low business risk: “Stringing content/cart” is virtually non-existent if HTML is not touched.”
• Cost modeling is more intuitive: commonly billed by traffic/request/area
• More purely structured: more like a “static resource distribution service”

Representative: bunny.net (clear pay-as-you-go pricing 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 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 (Steady 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 peace of mind: HTTPS + CDN + basic security all-in-one
• Want mature ecosystem: follow-up to add WAF, speed limit, edge rules, etc., the path is smooth

risk point

• Updates do not take effect: After enabling CDN, the cache chain becomes longer (browser cache + CDN cache + origin cache), so a “versioning strategy” is needed to make updates controllable (there is a troubleshooting tree later)
• Cache HTML with caution: if caching HTML, e-commerce/membership/personalization pages must be strictly bypassed or they are prone to serious incidents (list of scenarios follows)

clarification：

• Positioning: All-in-one Reverse Proxy (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 strictly 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.

• Like Cloudflare, it has a free plan, but usually there will be Quota/functional ceiling(e.g., number of rules, number of log tasks), but there is no need to modify DNS; only CNAME access is required.The free version is not recommended for commercial sites！
• 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 taken when they are not filed.

Description:

• Positioning: Reverse proxy integration (acceleration + security + certificates)
• Suitable 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

• Like Cloudflare, it has a free plan, but usually there will be Quota/functional ceiling(e.g., number of rules, number of log tasks), but there is no need to modify DNS; only CNAME access is required.The free version is not recommended for commercial sites！
• 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 switch to mainland China automatically, you usually need to complete the ICP file first; you can only go to international routes when you have not filed.
• Free is better suited for development/testing/evaluation and is usually not 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 a mainland China node, you usually need to fulfill the filing and regional conditions
• Free Entrance Default international routes, wish to go to mainland China routes must be completed.China ICP Filing 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 packages
• Risks: free boundaries to look at (SLAs/speed limits/support methods); zones and filings to plan ahead of time

---

4.4 bunny.net: Static Pull CDN (Low-risk start, transparent pay-as-you-go pricing)

If you want to “lock in the most reliable gains first,” Bunny-style Pull CDN is a great fit:
It's more like a “resource delivery service”: you give it static resources to deliver, and the cost is usually related to traffic/requests/region, with a clear and controllable model.

Fit:

• do sth. first Images / CSS / JS / Fonts Static acceleration of
• Do you want to first secure low-risk, stable returns without rushing to hand your entire site over to an agent platform?
• 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 behavior of the caching system:
When you update the CSS/JS/images in the backend, but theThe resource URL is unchanged.(Same address/file name/path), both CDN and the browser will reasonably keep hitting the old cache, so you end up seeing “why hasn'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** requires you to initiate the trigger, which is prone to inaccurate range and delayed node propagation; frequent Purge can also result in lower hit rates, increased source returns, and higher volatility.

Easy to see examples:

• style.css The content has changed, but the URL is still style.css → CDN Keep using old cache (reasonable)
• The URL becomes style.css?ver=20260103 或 style.abc123.css → CDN is considered a new resource → New version takes effect immediately

bunny as a best practice for “Step 1 CDN”

1. Cover only static resources first(images/CSS/JS/fonts), don't cache them right off the bat HTML
   • Benefit: 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 changes
   • 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 a validation checklist after going live
   • Are static assets from CDN
   • Whether hits are progressively higher 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)

The biggest reason CDN goes off the rails is trying to turn on every capability to the max right from the start.

Phase 1: Static assets only CDN (strongly recommended to do first)

goalImages/CSS/JS/Fonts use CDN first; HTML is not cached in CDN (or leave it unchanged for now)

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 the 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 HTTP resources)
• Static resource updates do not take effect (URLs do not change)

---

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

This is the watershed between whether “CDN” is 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 Cache: Edge nodes may have cached outdated 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 → It doesn't work → Clear cache again → It doesn't work → Clear another layer of cache”
This is the biggest pain point many people have with CDN.

---

Stage 3 (advanced): whether to cache HTML (high benefit, but highest risk)

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

If unsure, don’t cache HTML. First use static CDN + the origin server caching plugin.

If you want to cache HTML, two principles:

1. It only starts with the “Visitor State”.: Cache only unlogged visitor pages
2. Write the bypass list first: Prioritize correctness before talking about hits

6. List of scenario rules: what to do without incidents at different site types

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

testimonials

• Static resources: fully cached
• HTML: Consider caching “unlogged-in visitor pages”

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/comment submission

Cache Key should be distinguished at least

• Whether or not you are logged in (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 is shredded, poor hit rate
• Ignore all → A few pages that depend on parameter rendering may not meet expectations

---

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

reach a verdict: HTML Cache to be very careful.
A safe approach is usually: static CDN + origin cache/object cache; cache HTML only for visitor mode.

It must be bypassed.

• Login/Register/Retrieve Password
• Account Center, Orders/Subscriptions, Profile
• 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/registration, coupons/points, and other user-state related portals

Why e-commerce is more prone to accidents

• Once the user has a shopping cart, session, and login state, the page is highly personalized
• HTML Cache if not bypassed / not differentiated state, the most typical consequences: shopping cart error, account serial number, 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 logged in (cookie)
• Currency/tax rate (if affecting presentation)

---

7. Risk alerts

Risk 1: Caching the wrong content (most serious)

• Static resource caching error: mostly old styles/images
• HTML Cache error: may string content, string 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 programs: limited quota, some capabilities not included, SLA/support approach not equivalent to full commercialization

Risk 4: Relevant capacities in mainland China can be easily misinterpreted

• ESA: China ICP filing is required for those wishing to travel through mainland China.
• EdgeOne: China ICP Record Required for Routes to Mainland China

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

8.1 Are static resources really using CDN?

• Are images/CSS/JS served from the CDN domain/edge node
• Whether or not you can see clear signs of cache hits (signs vary from platform to 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 the only way to update is to Purge, the versioning strategy isn't ready (prioritize patching the strategy, don't make Purge a daily routine)

8.4 Are the dynamic key pages correct?

(A must for e-commerce/membership sites)

• 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)

First determine 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 is still hitting the old cache

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

Scenario C: Old image keeps showing up after image is overwritten with the same name
This is a classic issue caused by overlapping browser cache and CDN cache

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

---

9.2 HTML not updated (page content/module still old)

Scenario A: Backend/login is new, visitors see the old one
Priority suspicion: guest state HTML is cached

• First things first: should these pages be cached HTML
• If it should be cached: need controllable refresh strategy, otherwise posting is not controllable

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

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

Scenario C: Exception for logged in user/cart
High-risk sign: may be caching the wrong content

• Immediately check for cached user-state pages (cart/checkout/account etc.)
• Check if 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 Cache 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
• Good for: 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. Choose mode first: integrated reverse proxy (Cloudflare/EdgeOne/ESA) or static Pull CDN (bunny)
2. Go live by phase:Static first → then versioning policy → finally consider HTML caching
3. Check by validation checklist after go-live: hits/returns to source/updates/dynamic bypasses/error rates
4. Need to be faster: go back to “Cache Plugin” and “Image Optimization” 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 isn’t that CDN is useless, but that the bottleneck isn’t in the “delivery layer.”

You can judge them in that order:

• TTFB is still high.: Explanation of source generation HTML slow (database/plugin/cache plugin configuration/host performance) → back to source level optimization
• The first big picture is very slow: indicates incorrect image volume, size or format → do image optimization first (compression, WebP/AVIF, sizing strategy)
• Third-party scripts slow down: ads/stats/customer service scripts common → CDN Usually not helpful, need to reduce or delay 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 “already optimized resources” faster; a slow origin, large images, and slow scripts each need to 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 issue in the CDN scenario, 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 takes precedence: 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”, and prioritize 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 websites, the greatest value of CDN comes from:

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

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

Steady Route:

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

---

4. Can the e-commerce site use CDN? 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: Do not cache shopping cart, checkout, account related pages HTML
• As long as you don't HTML cache these pages, the risk of “stringing carts/accounts” is greatly reduced!

---

How to build a multilingual/multi-currency site with CDN without mixing up languages or prices?

center on Cache Key (cache key) Is it correct.

• Language (path or subdomain)
• Currency (if it affects the price display)
• Whether logged 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 seeing language B content, or inconsistent prices.

---

6. Should I choose the integrated reverse proxy (Cloudflare/EdgeOne/ESA) or static Pull CDN (bunny)?

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

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

If you hesitate, default advice:Pre-static CDN → Run through the versioning policy and validation checklist → then decide whether to go to the proxy-based/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” and not as a “formal program with commercial SLAs”.

• Are you comfortable with a free program 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 confirm that CDN is actually working, rather than just a placebo?

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

1. Check whether static assets are returned from CDN(whether the source of the image/CSS/JS has changed)
2. See if the hit rate and return to source improves(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 optimize, the more likely you are to be tormented by “updates not taking effect”, so it's recommended that you prioritize the versioning strategy.

---

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

The most common cause is:Mismatch between area selection and filing conditions。

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

---

10. Should I install the cache plugin first or use CDN first?

The general recommended order is:

1. Source site layer: cache plugin/hosting base stabilized first (TTFB down, backend pressure down)
2. Resource layer: image optimization to keep the size down
3. Delivery layer: CDN delivers resources faster and more reliably

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.