Website CDN Accelerated Optimization

If you split WordPress performance optimization into three layers:

• source station layer: Hosting / PHP / Database / Cache Plugins - Deciding on TTFB and Backend Pressure
• resource layer: Image Optimization - Determining download size and speed of first-screen big picture
• delivery layer:: CDN -- Deciding on resources closer to the visitor, more consistent hits, easier on the source site

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: CDN What it does and does not address

1.1 CDN addresses 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 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 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 problems that CDN does not automatically solve

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

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 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 help them to be “faster”, you can only deal with it by reducing/delaying loading, replacing vendors, or doing scripting policy optimizations.

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, but also brings 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 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 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 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 image/CSS/JS acceleration)

**特点：**你只把静态资源放到 CDN 边缘缓存；HTML 页面仍由源站（以及源站缓存插件）负责。

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 usage-based 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 (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 make updates controllable (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: 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 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.

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

• 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 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, clear per-volume billing)

If you want to “get the most stable 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, 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
• You want to get “low-risk and stable income” first, do not rush to hand over the whole site to the 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 behavior of the caching system:
When you update the 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** 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 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 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
   • Whether the static resource is 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)

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

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

goal: Images/CSS/JS/fonts go CDN first; HTML is not in 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 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 load HTTP resource)
• 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 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 → It doesn't work → Clear cache again → It doesn't work → Clear another layer of cache”
That's the biggest pain point many people have with the 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.

Don't cache HTML if you're not sure. static first CDN + source 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 submission/comment submission

Cache Key should be distinguished at least

• Whether 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.
Safe practices are usually: static CDN + source/object caching; HTML only caches guest state.

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 to log 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 gone CDN?

• Image/CSS/JS whether from 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 suspect: CDN still hitting 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 the classic problem of 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 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 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 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. First choice of form: reverse proxy integration (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 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 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 “optimized resources” faster; slow source stations, 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 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 sites, 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. Static first 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 be on 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!

---

5. How can a multilingual/multicurrency site do CDN without stringing languages/prices?

center on Cache Key (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 seeing language B content, or inconsistent prices.

---

6. Should I go with 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 + 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 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 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 caching plugin or 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 Delivering resources faster and more consistently

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