WordPress Dual CDN Test: Does a Unified 12-Hour HTML TTL Improve EdgeOne and Cloudflare Hit Rates?

My WordPress site currently uses a split CDN architecture:

• www.shuijingwanwq.com: Tencent Cloud EdgeOne
• en.shuijingwanwq.com: Cloudflare
• media.shuijingwanwq.com: Cloudflare
• admin.shuijingwanwq.com: Independent backend domain, does not pass through the frontend CDN

This architecture is basically stable in terms of access speed and traffic splitting, but while observing the CDN data, I noticed a rather obvious issue:

The cache Hit ratios for both EdgeOne and Cloudflare are not very high, and in particular, there are still a large number of MISSes for HTML pages.

On July 20, 2026, I uniformly adjusted the HTML edge cache rules for both the Chinese and English sites, changing the TTL to 12 hours. After running for about three days, I reviewed the cache data on both sides on July 23 to evaluate whether this adjustment was actually effective.

This article documents the complete analysis, adjustment process, and phased results.

1. Why I Started Focusing on CDN Hit Rate

To determine whether a CDN is working, you cannot just look at whether the domain has been integrated, nor can you just look at whether occasional page accesses are fast.

What is more critical is:

• Whether requests are actually returned by edge nodes;
• Whether the same page can transition from MISS to HIT;
• Whether the cache expires too early;
• Whether a large amount of HTML still frequently falls back to the origin;
• Whether origin server pressure and access latency decrease accordingly as the hit rate improves.

In initial consecutive request tests, both EdgeOne and Cloudflare were able to successfully transition from MISS to HIT.

For example, the first request to the Chinese site homepage was:

eo-cache-status: MISS
TTFB: 6.29 seconds

eo-cache-status: MISS
TTFB: 6.29 seconds

The second and third requests then became:

eo-cache-status: HIT
TTFB: 0.06～0.07 seconds

eo-cache-status: HIT
TTFB: 0.06～0.07 seconds

Chinese article pages were also able to drop from a MISS of about 0.89 seconds to a HIT of about 0.07 seconds.

The English site uses Cloudflare, and it was similarly able to go from:

cf-cache-status: MISS
TTFB: 3.81 seconds

cf-cache-status: MISS
TTFB: 3.81 seconds

to:

cf-cache-status: HIT
TTFB: about 0.93～1.00 seconds

cf-cache-status: HIT
TTFB: about 0.93～1.00 seconds

This shows that the caching mechanisms of both CDNs themselves are not failing.

The real problem is:

Although individual pages can be cached normally, the overall cache reuse rate for the site remains low.

2. EdgeOne Cache Performance Before Adjustment

I first filtered in EdgeOne for:

Host = www.shuijingwanwq.com

Host = www.shuijingwanwq.com

The statistics time period was set to the last 7 days.

Before the adjustment, the Chinese site received about 767,600 requests, of which:

The overall request Hit ratio was about:

38.75 ÷ 76.76 ≈ 50.5%

38.75 ÷ 76.76 ≈ 50.5%

If only counting directly comparable HITs and MISSes:

38.75 ÷（38.75 + 33.71）≈ 53.5%

38.75 ÷（38.75 + 33.71）≈ 53.5%

This means that out of every 100 cacheable requests, only about 53 are returned from the EdgeOne edge cache, while the remaining 47 still require falling back to the origin.

This result cannot be considered a complete failure, but for a WordPress site that has already enabled full-page caching and a CDN, there is still obvious room for improvement.

3. Request Hit Rate is Acceptable, but Traffic Hit Rate is Lower

Looking only at request counts is not enough.

If the hits are all for very small requests, while larger HTML pages frequently MISS, then origin traffic and actual access experience will still not be ideal.

Before the adjustment, EdgeOne response traffic was about 15.73 GB:

The overall traffic Hit ratio was about:

4.19 ÷ 15.73 ≈ 26.6%

4.19 ÷ 15.73 ≈ 26.6%

When counting only HITs and MISSes, the traffic hit rate was about:

4.19 ÷（4.19 + 11.33）≈ 27.0%

4.19 ÷（4.19 + 11.33）≈ 27.0%

This means:

Although EdgeOne hits about half of the requests, larger responses are more likely to MISS.

Therefore, what really needs to be optimized now is not a small number of static small files, but a large number of WordPress HTML pages.

4. MISS Traffic Mainly Comes from Normal 200 Pages

To confirm whether MISSes were mainly caused by 404s, attack scans, or abnormal redirects, I further filtered for:

Cache status = MISS

Cache status = MISS

Then I checked the traffic distribution by HTTP status code.

The results are as follows:

Among them, normal responses with status code 200 accounted for about 85% of all MISS traffic.

Therefore, it can be confirmed that:

The main cause of the low hit rate is not a large number of 404s or abnormal requests, but frequent MISSes for normal WordPress frontend pages.

The 301s and 404s combined also exceeded 1.6 GB, which is still worth paying attention to later, but they are not the core of this problem.

5. About 97% of Normal MISS Traffic Comes from Extensionless Pages

Continuing to filter for:

Cache status = MISS
Status code = 200

Cache status = MISS
Status code = 200

Then I viewed by resource type.

In the data, about 9.39 GB was classified by EdgeOne as “Field does not exist”, which also includes:

“Field does not exist” accounts for about 97% of the 9.68 GB normal MISS traffic.

Combined with the URL Path data, it can be determined that these requests are mainly WordPress routes without file extensions, such as:

/
/page/2/
/page/3/
/page/132/
/2026/07/11/19354/
/category/...
/tag/...

/
/page/2/
/page/3/
/page/132/
/2026/07/11/19354/
/category/...
/tag/...

In other words:

What is currently dragging down the Hit is mainly HTML pages like the homepage, articles, categories, tags, and pagination, rather than CSS, JavaScript, or image files.

6. Homepage and Many Pagination Pages Repeatedly MISS

Paths with higher traffic include:

The homepage generated 244.07 MB of MISS traffic in a week.

More notably, deep pagination like /page/132/ had MISS traffic close to that of the first few pages. This indicates that search engines and bots continuously traverse the site archives, rather than only accessing the homepage and the first few pages.

When further looking by request count, the Top paths were:

However, these Top paths combined only account for a small portion of all normal MISS requests.

The vast majority of MISSes are still scattered across a large number of long-tail pages.

This matches my site’s actual situation quite well:

• A large number of published articles;
• Many category, tag, and pagination pages;
• Many pages have low access frequency;
• The same page might only receive its next visit after the cache has expired;
• Different edge nodes may all experience an initial cold cache.

7. The Core Problem Finally Found: EdgeOne HTML Only Cached for 1 Hour

In the EdgeOne rule engine, the rule responsible for normal frontend HTML is:

HTML Page Cache (SEO Security)

HTML Page Cache (SEO Security)

The rule excludes:

/wp-admin/
/wp-login.php
/wp-json/
/feed/
/xmlrpc.php
/wp-cron.php

/wp-admin/
/wp-login.php
/wp-json/
/feed/
/xmlrpc.php
/wp-cron.php

But the node cache TTL used for normal HTML pages is only:

1 hour

1 hour

Forced caching is turned off.

For sites with few articles and concentrated traffic, 1 hour might still achieve a decent hit rate.

But for a technical blog with a lot of long-tail pages, 1 hour is obviously too short.

After a page is accessed for the first time on a certain edge node and enters the cache, if there is no second visit within the next hour, the next request may fall back to the origin again.

When a site has thousands of articles, numerous tags, and hundreds of pages of pagination, this situation becomes very common.

8. Cloudflare English Site Also Has a Low Hit Rate Problem

The English site uses:

en.shuijingwanwq.com

en.shuijingwanwq.com

CDN services are provided by Cloudflare.

Before the adjustment, over the past 24 hours and limited to the English site Host, the Cloudflare data was:

Although Cloudflare’s HTML rules do not explicitly set an Edge TTL, the origin response contains:

cache-control: max-age=14400

cache-control: max-age=14400

Which is 4 hours.

The fact that the Age of the homepage response was still a HIT after exceeding 3600 seconds also proves that Cloudflare’s actual cache time does exceed 1 hour.

However, an overall hit rate of 16.76% is still low.

Especially:

EXPIRED：1.64k

EXPIRED：1.64k

This indicates that many resources were successfully cached, but had already expired before the next visit.

Therefore, simply adjusting EdgeOne from 1 hour to Cloudflare’s current 4 hours would not fully solve the problem.

9. Final Decision: Unify Both Sides to 12 Hours

After the previous analysis, I ultimately decided not to continue designing multi-layer rules for article pages, homepages, and category pages.

Although layered rules can theoretically be more refined, they also bring additional maintenance costs.

For my current needs, what is more important is:

• Improving the overall Hit;
• Keeping the logic unified between EdgeOne and Cloudflare;
• Not making the rule system too complex;
• Avoiding mistakenly caching backend and personalized pages in order to increase the hit rate;
• Being able to easily observe the results after adjustment.

The final unified plan adopted is:

Normal WordPress HTML edge cache TTL: 12 hours

Normal WordPress HTML edge cache TTL: 12 hours

EdgeOne Configuration

Set to:

Node cache TTL: 12 hours
Forced cache: Off

Node cache TTL: 12 hours
Forced cache: Off

Other matching conditions and rule order remain unchanged.

Cloudflare Configuration

Set to:

Cache eligibility: Eligible for cache
Edge TTL: Ignore cache-control header, use 12 hours
Browser TTL: Do not set separately
Cache key: Do not set separately

Cache eligibility: Eligible for cache
Edge TTL: Ignore cache-control header, use 12 hours
Browser TTL: Do not set separately
Cache key: Do not set separately

Cloudflare only overrides the edge node cache time; there is no need to force the user’s browser to also cache for 12 hours.

10. Simultaneously Improving Personalized Cookie Cache Bypass

After extending the HTML edge TTL to 12 hours, the bypass rules for personalized requests also needed to be more complete.

The original rule only matched:

wordpress_logged_in_

wordpress_logged_in_

It only covered WordPress logged-in users.

To prevent password-protected articles and commenter-related pages from being publicly cached, I expanded the rules on both sides to:

wordpress_logged_in_
wp-postpass_
comment_author_

wordpress_logged_in_
wp-postpass_
comment_author_

The rule name was also changed from:

WordPress Logged-in User Bypass Cache

WordPress Logged-in User Bypass Cache

to:

WordPress Personalized Cookie Bypass Cache

WordPress Personalized Cookie Bypass Cache

EdgeOne Regex

wordpress_logged_in_|wp-postpass_|comment_author_

wordpress_logged_in_|wp-postpass_|comment_author_

Upon match, execute:

Node cache TTL: Do not cache

Node cache TTL: Do not cache

Cloudflare Expression

(http.host eq "en.shuijingwanwq.com" and
 (
  http.cookie contains "wordpress_logged_in_" or
  http.cookie contains "wp-postpass_" or
  http.cookie contains "comment_author_"
 ))

(http.host eq "en.shuijingwanwq.com" and
 (
  http.cookie contains "wordpress_logged_in_" or
  http.cookie contains "wp-postpass_" or
  http.cookie contains "comment_author_"
 ))

Upon match, execute:

Bypass cache

Bypass cache

This extends the public HTML cache time for anonymous visitors while preserving the security boundary for logged-in, password-protected, and commenter pages.

11. After Running for Three Days, Cloudflare Hit Rate Significantly Improved

On July 23, 2026, I reviewed the English site’s data for the past 24 hours.

The adjusted data is:

Cache Hit Rate went from:

16.76%

16.76%

up to:

20.25%

20.25%

an increase of 3.49 percentage points.

The relative improvement is about:

(20.25% - 16.76%) ÷ 16.76% ≈ 20.8%

(20.25% - 16.76%) ÷ 16.76% ≈ 20.8%

Although the total number of requests decreased, the number of HITs actually increased from 3.87k to 4.12k.

This shows that the improved hit rate is not just due to the drop in total requests; cache reuse itself has genuinely improved.

12. Cloudflare’s EXPIRED Drops by About 42%

The most direct effect of this adjustment is reflected in the number of expired requests.

Before adjustment:

EXPIRED：1.64k

EXPIRED：1.64k

After adjustment:

EXPIRED：951

EXPIRED：951

A decrease of about:

(1640 - 951) ÷ 1640 ≈ 42%

(1640 - 951) ÷ 1640 ≈ 42%

This is consistent with the expectation of increasing the Edge TTL from about 4 hours to 12 hours.

Previously, some pages entered the cache but expired before the next visit. After extending to 12 hours, these pages gained a longer reuse window, allowing some of these requests to continue returning HITs.

After the adjustment, Cloudflare still has a large number of MISSes, mainly because:

• The English site has lower traffic than the Chinese site;
• There are many long-tail English articles;
• Visitors are distributed across different countries and regions;
• Different Cloudflare nodes need to experience cold caches separately;
• There are many 404 and bot scan requests.

Therefore, 12 hours can improve the hit rate, but it cannot eliminate all initial MISSes.

13. EdgeOne’s Request Hit Rate Also Significantly Improved

On July 23, I selected in EdgeOne:

2026-07-22 11:30 ～ 2026-07-23 11:30
Host = www.shuijingwanwq.com

2026-07-22 11:30 ～ 2026-07-23 11:30
Host = www.shuijingwanwq.com

to view the data for the past 24 hours.

Total requests were about 106,500:

The overall request Hit ratio is about:

6.23 ÷ 10.65 ≈ 58.5%

6.23 ÷ 10.65 ≈ 58.5%

If only counting HITs and MISSes:

6.23 ÷（6.23 + 3.74）≈ 62.5%

6.23 ÷（6.23 + 3.74）≈ 62.5%

The data for the 7 days before adjustment was:

• Overall request Hit ratio: about 50.5%
• HITs and MISSes only: about 53.5%

After adjustment, they reached:

• Overall request Hit ratio: about 58.5%
• HITs and MISSes only: about 62.5%

An increase of about 8 to 9 percentage points.

It should be noted that the data before adjustment was from the last 7 days, and the data after adjustment was from the past 24 hours; the two are not exactly the same statistical period.

However, the fact that both request Hit and traffic Hit improved simultaneously still shows that the adjustment direction is effective.

14. EdgeOne’s Traffic Hit Rate Improved Synchronously

In the past 24 hours, EdgeOne response traffic was 2.24 GB:

The overall traffic Hit ratio is about:

796.86 MB ÷ 2.24 GB ≈ 35.6%

796.86 MB ÷ 2.24 GB ≈ 35.6%

When counting only HITs and MISSes, the result is also about 35.7%.

The traffic hit rate before adjustment was about:

27%

27%

After adjustment, it is about:

35.7%

35.7%

An increase of nearly 9 percentage points.

This improvement is particularly important.

Because it shows that this adjustment didn’t just allow more small requests to get HITs; more of the larger HTML responses have also started being returned directly by EdgeOne edge nodes.

15. Final Results Summary

From the results, both the Chinese and English sites showed clear improvements.

Especially:

• Cloudflare EXPIRED significantly decreased;
• EdgeOne request Hit improved;
• EdgeOne traffic Hit improved synchronously;
• The rule structure on both sides remains unified;
• Global forced caching was not enabled;
• Backend, login, REST API, and personalized Cookies still remain bypassed.

16. Why Not Continue Increasing to 24 Hours for Now

Since 12 hours is effective, should we continue increasing it to 24 hours or even longer?

I have currently decided not to continue adjusting for the time being.

Reasons include:

1. 12 hours has already brought clear improvements;
2. The homepage, categories, tags, and pagination are aggregate pages that are subject to change;
3. If the TTL continues to increase, the risk of content update delays will also increase;
4. A large portion of the remaining MISSes consist of initial visits and cross-node cold caches;
5. Continuing to simply increase the TTL may yield diminishing returns;
6. The current configuration is simple and maintenance costs are low.

Therefore, the more reasonable choice at this stage is:

Maintain the stable operation of the 12-hour configuration, and do not continue adding complex rules in pursuit of higher numbers.

If I later find that the homepage or category pages are not updating in a timely manner, I can consider setting a shorter TTL for the homepage and a longer TTL for article pages.

But there is no need to enter this level of refinement yet.

17. Practical Experience Brought by This Adjustment

This troubleshooting confirmed a few rather important conclusions for me.

1. Normal Single Test Does Not Mean Ideal Overall Hit Rate

The fact that a page can transition from MISS to HIT only proves that the rule can cache it.

The overall hit rate also depends on:

• Cache TTL;
• Page access frequency;
• Number of long-tail URLs;
• Edge node distribution;
• Query parameters;
• Page updates and cache purging;
• Bot access patterns.

2. Request Hit and Traffic Hit Must Be Viewed Together

A high request hit rate does not mean that high-traffic pages are also well cached.

My situation before adjustment was:

• Request Hit about 50%
• Traffic Hit only about 27%

This indicates that larger HTML pages were still frequently falling back to the origin.

3. Large WordPress Content Sites Cannot Use Only Very Short HTML TTLs

When there are many articles, tags, and pagination pages, a 1-hour TTL will cause a large number of long-tail pages to expire before they even receive a second visit.

For the current site, unifying to 12 hours has proven to be significantly more reasonable.

4. Improving Hit Should Not Come at the Expense of Personalized Security

When extending public HTML cache, you need to continue bypassing:

wordpress_logged_in_
wp-postpass_
comment_author_

wordpress_logged_in_
wp-postpass_
comment_author_

Paths like the backend, login, REST API, Feed, and XML-RPC should also continue to be processed independently.

5. No Need to Analyze Infinitely for a Single Metric

During the troubleshooting process, I considered creating a custom Cloudflare dashboard to further break down requests, traffic, and various cache statuses.

But for the current goal, the existing data was sufficient to support a judgment.

The actions that were ultimately effective were not complicated:

Unify the normal HTML edge cache for EdgeOne and Cloudflare to 12 hours

Unify the normal HTML edge cache for EdgeOne and Cloudflare to 12 hours

This also shows that technical analysis needs to stop at a certain point.

When evidence is already sufficient to support a low-risk adjustment, continuing to add analytical dimensions may only increase time costs without necessarily bringing equal value.

18. Conclusion

This adjustment did not introduce any new WordPress plugins, nor did it modify the origin code.

In the end, only two configuration optimizations were completed:

1. Unified the normal HTML edge cache TTL for EdgeOne and Cloudflare to 12 hours;
2. Expanded the personalized Cookie bypass rules to include logged-in users, password-protected articles, and commenter Cookies.

After running for three days, both sides showed clear improvements in cache hit rates:

• Cloudflare Cache Hit Rate increased from 16.76% to 20.25%;
• Cloudflare EXPIRED decreased by about 42%;
• EdgeOne request Hit increased from about 50.5% to about 58.5%;
• EdgeOne traffic Hit increased from about 26.6% to about 35.6%.

This did not turn all requests into HITs.

For sites with many articles, tags, and pagination pages, a large number of long-tail pages, initial visits, and cold caches across different edge nodes will still generate MISSes.

However, judging from current data, 12 hours is already a more suitable balance for this site’s current situation:

It significantly improved cache reuse rates without extending content update delays to an unacceptable degree.

At this stage, I will continue to maintain this configuration, will not further increase cache times, and will not add more layered rules.