1 WordPress Cache Dilemma and Solutions

1 Why Do Many WordPress Webmasters Prefer to Give Up CDNs?

In the world of static sites, CDN is almost a “free performance optimization”: static files are naturally suitable for caching, and HTML pages are rarely updated frequently. Therefore, as long as resources are pushed to CDN nodes, you can immediately get extremely low latency and extremely high concurrency. For front-end developers or static blog users, enabling a CDN costs almost nothing, but the benefits are immediate.

But for a typical dynamic site like WordPress, the situation is completely different. Many webmasters know that Cloudflare offers a free CDN, yet they still choose to run their websites directly on bare VPS. The reasons are roughly as follows:

1. Frustration caused by cache out-of-sync

WordPress content is updated frequently, such as writing blog posts, modifying pages, adjusting styles, and even reader comments. If CDN cache rules are configured improperly, the “front-end still showing the old version” situation will occur. For webmasters, the most painful thing is: after working hard to update an article, visitors can still only see the old content.

2. Complex dynamic content handling

Login status, comments, shopping carts, and personalized content cannot be easily cached. Webmasters need to set bypass rules, but if the rules are too loose, caching loses its meaning, and if they are too strict, they can easily cause false positives. In the end, they are likely to fall into an awkward situation where “nothing feels right no matter how it's adjusted.”

3. Running directly on VPS is more controllable

Many webmasters choose to install cache plugins (such as local page cache, object cache) on their VPS. Although this cannot cover the globe, at least the results are predictable and problems can be troubleshot. In contrast, relying on a CDN means adding another layer of black box. When a problem occurs, it might be neither a server issue nor a WordPress issue, but rather cache inconsistency across CDN nodes, making troubleshooting costs extremely high.

4. Differences in operations mindset

Webmasters generally prefer stability over tinkering. A CDN is “the icing on the cake” for static sites, but for dynamic sites, it can become “adding to the chaos.” Therefore, many people simply adopt a “minimal dependency” approach: if the server performance is sufficient and the bandwidth can hold up, they won't bother with a CDN, and instead focus their time and energy on content and features.

Therefore, WordPress webmasters are generally cautious about CDNs. Even though Cloudflare's free plan looks tempting, some still choose to “abandon it.” To truly integrate WordPress with a CDN, solving the cache out-of-sync issue is the key.

2 Cloudflare Official APO: The Best Practice Solution for WordPress

Before discussing third-party plugins, we must first mention Cloudflare's own APO (Automatic Platform Optimization), which is an optimization solution specially built by Cloudflare for WordPress. It can be said to be the current “official best practice” for WordPress full-site cache management”。

The core idea of APO is very simple: to include the HTML pages of the entire WordPress site into the CDN cache, and through an intelligent cache purging mechanism, ensure that after an article is updated, global Cloudflare nodes can obtain the latest content as quickly as possible. Compared to traditional CDNs that only cache static resources (images, JS, CSS), APO directly solves the long-standing problem of WordPress, a dynamic site, where “HTML cannot be cached site-wide.”

More importantly, the APO experience is almost “seamless”:

• Intelligent Cache Purging: When an article or page is updated, Cloudflare automatically calls the API to purge the corresponding cache, avoiding the tedious operation of manually clearing the cache.
• Mobile Optimization: APO has built-in cache and response optimization for mobile devices, reducing latency for mobile users.
• Edge Node Acceleration: No matter where visitors come from, APO will prioritize returning the cached HTML directly from the Cloudflare node closest to the user, significantly reducing TTFB (Time to First Byte).
• Out-of-the-box: The official WordPress plugin works closely with Cloudflare, so webmasters hardly need any complex configuration to get the full acceleration effect.

In other words, after enabling APO, the access experience of a WordPress site is almost no different from a static site at the CDN level. It can enjoy the speed advantages brought by full-site caching while maintaining the real-time nature of article updates, which is why many webmasters call it the “perfect solution.”

However, the only fly in the ointment is:Cost issue: For Free users, APO requires an additional payment of $5/month, while Pro plan ($20/month) and above comes with it for free. This deters many small personal blog owners;Ecosystem lock-in: APO is Cloudflare's own closed-loop service. If you plan to migrate to another CDN or adopt a self-built solution, you won't be able to continue using it.

Therefore, although APO is almost flawless on a technical level, its barrier to entry is not low. After learning about it, many WordPress users still choose to wait and see, or settle for the next best thing by looking for third-party plugins to achieve similar functionality—which leaves room for various subsequent free alternatives.

3 The "Budget" APO Solution Is No Longer Officially Supported by Cloudflare

In a previous article, I introduced a method using Cloudflare Worker to achieve the “budget version of APO” functionality (see article:Home Data Center Series Cloudflare Tutorial (7): Introduction to CF Worker Features and Practical Operation, Verification, and Related Technical Principles of Implementing ”Budget Version of APO for WordPress” Based on Workers to Accelerate Website Access). The principle of this solution is: with the help of a free WordPress plugin, combined with a JS script running on Cloudflare Worker (modified based on the edge-cache-html.js sample script once provided officially by Cloudflare), to achieve static caching of WordPress dynamic content. At the same time, the plugin can automatically trigger version management of Cloudflare cached content when site content is updated, thereby ensuring that the cache is always synchronized with the actual content.

However, this “budget version of APO” solution has always felt less than ideal to me, mainly for two reasons:

Cloudflare no longer provides official support

The official Cloudflare repository on GitHub has removed the download for this plugin:

Although I backed up the plugin to my resource site at the time, since the plugin has not been updated for years, I cannot guarantee it will work properly on the current version of WordPress, let alone the security risks. Meanwhile, the edge-cache-html template directory is no longer available in the cloudflare/templates repository on GitHub. Previously:

Now:

It is clear that Cloudflare no longer provides any official support for this method.

Many limitations for free subscription users

Even if you still use this solution, users on the Cloudflare free plan will face Worker limitations: only 100,000 requests per day, and it also requires additional integration with KV storage. Although the free quota for KV is theoretically sufficient for personal use, during actual deployment, I encountered quite a few “false alarms” or anomalies, and the experience was not stable.

More importantly, as I have used the APO feature myself for a long time, my requirements for caching and acceleration have become higher and higher. In comparison, this “budget version of APO” solution is slightly crude and insufficient to support a stable and sustainable site acceleration system. Therefore, for a long time, I could not find an ideal solution that could both accommodate Cloudflare free subscription users and achieve automated cache management and acceleration.

So, what kind of solution can be considered “relatively perfect”? If we refer to the standards of APO, it must at least meet the following:

• Only requires installing a plugin locally on WordPress;
• No need to configure complex Workers and KV storage;
• Able to automatically refresh and manage Cloudflare's cache versions when content is updated;
• Possesses stable compatibility and continuous maintenance.

And a WordPress plugin I recently discovered: ”Super Page Cache“, happens to provide a near-ideal solution in these aspects.

2 Introduction to the Super Page Cache Plugin

1 Pain Points of Traditional WordPress Local Cache Plugins

Traditional local caching plugins, such as WP Super Cache, W3 Total Cache, WP Fastest Cache, as well as the more comprehensive LiteSpeed Cache, all share the same core idea:Generate static copies of pages in advance on the server side, and then have the Web server (such as Nginx, Apache, LiteSpeed) return them directly to visitors. This avoids having WordPress dynamically parse PHP and execute database queries every time, greatly reducing backend pressure.

These types of local caching plugins have a natural prerequisite:The site needs to be published directly to the outside world through the VPS public IP address. Although cache files can be saved on the local disk, they ultimately still rely on the Web server on the VPS to respond to requests. In other words, their optimization scope mainly remains at the origin server level, rather than CDN-level caching.

The actual effect is:When a request goes back to the origin and reaches the server, the Web server will prioritize hitting the local cache file, avoiding PHP dynamic parsing and database queries, thereby significantly reducing backend pressure. However, whether the page can be cached to CDN edge nodes depends entirely on the CDN's own policies. Taking Cloudflare as an example, it does not cache HTML content by default unless users write their own rules.

And that is where the problem lies:Local caching plugins cannot establish linkage with Cloudflare. When you update an article, although the local cache will be cleared, the cache on Cloudflare's edge nodes may still exist, ultimately leading to “out-of-sync content between the origin server and the CDN cache.” To solve this problem, there are usually only two ways: manually clearing the cache in the Cloudflare dashboard, or just waiting for the cache to expire.

2 The Unique Super Page Cache Plugin

In the world of WordPress, Super Page Cache for Cloudflare(SPC for short) is a very special existence: it is not simply a “local page caching tool.” Its uniqueness lies in the fact that it can perform local caching and also link with Cloudflare's API to ensure that edge cache and local content remain synchronized, thereby achieving a global acceleration effect similar to APO. This approach almost replicates the effect of Cloudflare APO, making it the closest ideal alternative for users who do not want to pay for APO.

To understand what makes SPC special, we must first go back to the design concept of APO. Traditionally, Cloudflare mainly caches static resources at edge nodes, such as JS, CSS, and image files, while the WordPress page itself is still dynamically generated, requiring a trip back to the origin server for parsing and database queries with every request. The innovation of APO lies in incorporating the HTML pages generated by WordPress into the caching system, allowing these contents that originally required dynamic generation to be served directly at the edge nodes.

In other words, APO “staticizes” dynamic pages and caches copies on global Cloudflare nodes, thereby significantly reducing origin requests. More importantly, APO is not a one-way cache; it maintains a linkage with WordPress: when site content is updated, such as when posts are added or modified, pages are deleted, or comments are added, the WordPress plugin actively calls Cloudflare's API to notify edge nodes to purge or refresh the corresponding cache. In this way, a balance is achieved between cache hit rate and content freshness, ensuring visitors always see the latest pages while access speeds approach those of a purely static site.

The SPC plugin is designed exactly along this line of thought: it establishes a linkage with the Cloudflare edge network through Cloudflare's API. When you publish or update posts in the backend, or adjust site content, SPC automatically calls the API to notify Cloudflare to purge or refresh the cache of the relevant pages. In other words,The storage action of the cache relies on Cloudflare's cache rules, while the role of SPC is to ensure that the cache is synchronized with the site content. In this way, webmasters barely need any manual intervention to keep the page cache up to date, achieving a high degree of automation and seamlessness.

Compared to the previous “budget APO” solution, the changes brought by SPC are very obvious: First, it does not rely on Workers at all, thus freeing itself from the constraints of daily request limits and KV read/write limits. Second, it is a plugin that is still continuously updated and remains active in the WordPress plugin repository, meaning compatibility and security are guaranteed. Moreover, its configuration is very simple; you only need to fill in a set of Cloudflare Global API Key (or API Token) in the plugin settings to basically achieve cache linkage with Cloudflare.

In practical use, the overall performance of SPC is quite decent. It can push WordPress HTML pages to Cloudflare node caches, thereby reducing origin pressure and providing a certain boost to access speed. However, it should be noted that there is still a clear gap between its experience and APO: the speed at which cache purges take effect is not stable enough, sometimes requiring a wait of several minutes or even longer, especially when using the free Cloudflare plan.

The plugin itself also provides some common flexible options, such as setting which pages participate in caching and which pages need to be excluded, thereby preventing critical dynamic pages from being disrupted by caching. These features allow webmasters to control the caching scope in more detail, avoiding a “one-size-fits-all” situation.

Overall, Super Page Cache is more like a practical alternative: It cannot completely replace APO, but for sites using the free Cloudflare plan that still want to leverage edge caching to improve the access experience, it still holds certain value. It is worth noting that it is not an “out-of-the-box perfect solution”; some dynamic pages (such as shopping carts, backend login, etc.) still require exclusion rules to ensure proper functionality. Fortunately, SPC can automatically generate corresponding cache exclusion rules for common dynamic content, which to some extent reduces the manual configuration burden on webmasters, though debugging and verification based on actual needs are still recommended.

To use an analogy: APO is like a “fully automatic edge cache butler” tailored for WordPress, requiring almost no intervention to ensure instant cache synchronization, proper browser cache handling, and good compatibility with dynamic pages; whereas SPC is more like a “semi-automatic assistant”—while it can automatically sync post updates to Cloudflare and provide manual operation options, it still has certain limitations in cache refresh latency, browser cache control, and compatibility with special dynamic pages. In other words, if you pursue an “out-of-the-box, ultimate experience,” APO is the top choice; if you are a free plan user or want complete control over the caching logic, SPC offers a flexible and viable alternative.

3 Installation and Configuration of Super Page Cache

1 Plugin Installation and Activation

Enable the plugin after installation is complete:

Activate the plugin's caching feature:

Activation successful:

2 Plugin Settings

2.1 Overview

After entering the settings interface, you can see 5 option areas:

2.2 General: Core configuration (Local Cache Settings)

This area is the core configuration area of Super Page Cache, mainly determining the plugin's local cache switch and global rules. It provides several key features: whether to enable local disk caching, control over skipping cache for specific cookies or URL paths, and unified handling of marketing parameters (Pro feature). These options ensure that while page speed is improved, users' dynamic operations or sensitive interfaces are not affected. In addition, you can choose whether to display advanced settings, making it easy for users with more detailed caching logic needs to expand:

“The ”Advanced Settings" section actually has many very practical options, but there are too many of them, and I'm too lazy to explain them one by one, so I'll just take a screenshot of the translated interface for everyone to see:

---

Important Reminder:

“The ”General: Core configuration" functional area is mainly used to set SPC's local caching feature. Although it and Cloudflare edge caching belong to different levels, they are not mutually exclusive. After enabling local caching, the VPS host will save a static copy of the page on the disk: when a Cloudflare edge node hits the cache, the local cache will not participate and the result is returned directly; when there is a Cloudflare cache miss and the request goes back to the origin, the local cache can respond quickly, avoiding frequent calls to PHP and the database.

In other words, local caching and Cloudflare caching can complement each other:the former ensures origin server performance, while the latter enhances global acceleration effects. Therefore, for most sites, it is not recommended to disable “Disk Page Cache”; instead, let SPC keep the two layers of cache synchronized for purging via the API, thereby obtaining a more efficient and reliable caching system.

This “dual-layer caching” is particularly suitable for the following scenarios:

• Limited origin server performance: For example, low-end VPS. If relying solely on Cloudflare, once a cache miss occurs, the origin server might be overwhelmed, whereas the local cache can act as a safety net.
• High traffic volume: During high concurrency, local caching can significantly reduce database query pressure and improve stability.
• Insufficient flexibility in caching strategies: Cloudflare does not cache HTML by default, and local caching can make up for this, working in tandem with Cloudflare edge caching for layered acceleration.

Of course, local caching may also cache dynamic pages that should not be cached (such as shopping carts, backend login), so exclusion rules may still be needed to avoid accidental caching issues.

---

2.3 Cloudflare: CDN & Edge Caching

This area is used to connect the plugin with the Cloudflare account, which is the biggest difference between SPC and traditional local caching plugins. Through the settings in this section, WordPress's caching logic can extend directly to Cloudflare edge nodes, achieving site-wide dynamic page acceleration.

Here, users need to configure Cloudflare authentication information, with the option to choose the traditional Global API Key, or use the more recommended API Token. The latter allows for targeted permission control, offering higher security and aligning better with Cloudflare's official best practices. Once the connection is complete, the plugin can automatically interact with Cloudflare to push and purge cache, without requiring the user to manually operate in the backend:

After clicking the ”Connect to Cloudflare” button below:

After successfully saving the domain name, activate the Cloudflare CDN & Cache feature and update the settings:

Then SPC will automatically create a cache rule in the Cloudflare backend:

The cache rule content is as follows (it is too long to display completely, so here is a screenshot to give you an idea):

The full content of the matching condition expression generated by SPC is as follows:

(http.host wildcard "blog.tangwudi.cc*" and not http.cookie contains "comment_" and not http.cookie contains "woocommerce_" and not http.cookie contains "wordpress" and not http.cookie contains "xf_" and not http.cookie contains "edd_" and not http.cookie contains "jetpack" and not http.cookie contains "yith_wcwl_session_" and not http.cookie contains "yith_wrvp_" and not http.cookie contains "wpsc_" and not http.cookie contains "ecwid" and not http.cookie contains "ec_" and not http.cookie contains "bookly" and not http.request.uri contains "ao_noptirocket" and not http.request.uri contains "jetpack=comms" and not http.request.uri contains "kinsta-monitor" and not http.request.uri contains "ao_speedup_cachebuster" and not http.request.uri contains "removed_item" and not http.request.uri contains "/my-account" and not http.request.uri contains "/wc-api" and not http.request.uri contains "/edd-api" and not http.request.uri contains "/wp-json" and not http.request.uri contains "/wp-admin" and not http.request.uri contains "/wp-login" and not http.request.uri.path contains ".xml" and not http.request.uri.path contains ".xsl" and not http.request.uri.path contains "robots.txt")

In addition, I changed the browser TTL to ”Bypass cache”, but it doesn't feel much different from the default ”Respect origin server TTL”, as it is still mainly limited by the refresh time of the Cloudflare edge cache:

2.4 Other Additional Optimization Features

In addition to the core integration between cache and Cloudflare edge nodes, Super Page Cache also comes with some common built-in local optimization options. These features are not unique selling points of the plugin, but they are well-integrated, saving webmasters the trouble of installing additional small plugins.

在 Files In this regard, the plugin provides optimization options for Google Fonts, which can combine multiple font requests into a single file, or even download Google Fonts directly to the local server for loading, avoiding latency and potential compliance issues caused by external requests:

在 Media In this regard, the plugin supports image lazy loading (Lazy Load). Webmasters can either enable the browser's native lazy loading mechanism or switch to the plugin's built-in solution for more granular loading control. This effectively reduces bandwidth consumption for the first screen, making the page feel “faster” to users:

在 Database In this aspect, the plugin provides tools to clean up and optimize the database. This includes regularly cleaning up old post revisions, drafts, spam comments, expired transient data, etc., and defragmenting database tables. For sites that have been running for a long time and have accumulated a lot of redundant data in the database, these tools can help reduce the load and speed up the site:

These additional features are actually not that important and can only be considered the icing on the cake. If your site is already using something like WP Rocket、LiteSpeed Cache 或 Autoptimize comprehensive optimization plugins like these, there might be some overlap with SPC. In this case, you can choose to enable or disable the corresponding features as needed to avoid duplicate optimization or potential conflicts.

4 The Key to SPC and Cloudflare Account Integration

In Section 2.2, I mentioned: “When you publish or update posts in the backend, or adjust site content, SPC will automatically call the API to notify Cloudflare to purge or refresh the cache of the relevant pages. In other words,the prerequisite for whether a cache “can enter the edge” depends on Cloudflare's own caching rules; whereas SPC's responsibility is to purge what needs to be purged and refresh what needs to be refreshed when content changes, keeping the edge copy synchronized with the site content”." The true meaning of this sentence is to “who does the caching” 与 “and ”who manages the cache lifecycle" clearly divide the work.

Cloudflare's default policy is very conservative: the edge only caches static resources (such as CSS, JS, images),and does not cache HTML by default. Therefore, even if SPC staticizes pages locally and does a great job with “linked purging”, without additional policies, the edge nodes will still treat HTML as dynamic content and fetch it from the origin, resulting in “cf-cache-status” being DYNAMIC every time.

To change this, the SPC plugin has a built-in solution: in the “Cloudflare: CDN & Edge Caching” options, enable Enable Cloudflare CDN & Caching and click Update settings, SPC will automatically call the Cloudflare API to generate a Cache Rule(see 3.2.3 for details). The purpose of this rule is to allow HTML to be cached and automatically exclude sensitive scenarios such as the backend, login status, APIs, and checkout processes to avoid accidental caching. In other words,SPC is not only responsible for linked purging, but also configures the “Cache Everything” rule for you, so you don't need to manually write it on CF again.。

Comparing it with APO makes it even clearer:APO is equivalent to “letting HTML enter the edge cache by default + linking with WordPress”. Whereas SPC “s combined logic is: the plugin automatically creates a Cache Rule to solve ”letting HTML enter the cache“, and then uses the API for precise purging to solve ”linked refreshing". The mechanisms are different, but the experience is relatively close; the difference is thatSPC itself does not “push” pages to the edge; it merely ensures that the edge copy is refreshed or deleted in a timely manner after you modify content.。

In the scenario of a Cloudflare free subscription account (paid subscriptions have APO, so SPC is not needed~), there are three key points to make SPC truly effective:

First,Eligibility first: Ensure that Cloudflare CDN & Caching is enabled in the SPC settings, and the cache rules on Cloudflare are generated synchronously, so that HTML is eligible to be cached.

Second,Then comes linkage: SPC calls the Cloudflare API to perform targeted purging when you publish, update, delete, or when comments change, avoiding the out-of-sync issue where “the local site is updated but the edge lags behind”.

Third,Keep exceptions: The backend, login status, checkout processes, APIs, and previews must bypass the cache, otherwise they will be cached by mistake. The rules automatically generated by SPC already cover these common exclusions, but users can still further fine-tune them in the Cloudflare dashboard according to their needs.

In practice, the idea can be simplified into one sentence:“Let Cloudflare handle the storage and make it clear what to store; let SPC handle the management and make it clear when it expires.” For free users, this means two steps: enable Cloudflare CDN & Caching in the SPC plugin (which automatically generates the Cache Rule), and leave the rest to SPC's automatic purging. Cloudflare's official “Default Cache Behavior” and “Cache Rules” documentation clarify the legitimacy and boundaries of this approach. Combined with SPC's “purge by URL” logic, it can stably replicate an experience close to APO.

Here, I would also like to correct a common misunderstanding. When no ”Cache Everything” type of caching policy is configured on Cloudflare by default, seeing the response header cf-cache-status: DYNAMIC does not mean SPC has failed:

Note: To prevent the local caching feature from interfering with observing the results of the SPC plugin and Cloudflare cache linkage, I turned off this feature in the subsequent tests. It does not need to be turned off in actual use.

It only indicates that “the HTML of this request was not considered a cacheable object by Cloudflare”. Once SPC's automatic rules are enabled, the first visit is usually MISS(Fetch from origin and write to edge):

You will see it later HIT:

And when you update content in WordPress, SPC will clear the edge copy of the relevant URL, and the next request will fetch from the origin and write to the edge again, continuing to hit thereafter. This is the true “rule + linkage” collaboration rhythm.

Finally, let's clarify the different paths to help you make a decision: if you are using the Pro / Business / Enterprise plan, simply install the official Cloudflare plugin in WordPress and enable it according to the processAPO, and Cloudflare will automatically put HTML into the edge cache without any extra steps; if you are a Free user, you will need to rely on the cache rules automatically generated by the SPC plugin, which can also cache HTML to edge nodes. Although the two paths differ in approach, their goal is the same:to make WordPress HTML “faster” at global edges and “keep up” when you modify content”。

---

This chapter explains how SPC works with Cloudflare accounts (mainly free subscription accounts) to achieve a linkage mechanism for HTML page caching. It should be noted that for readers without a basic understanding of APO or edge caching concepts, even if I write this chapter as clearly as possible, it may still be difficult to fully understand the true advantages of SPC. In other words, the core essence here relies on the understanding of edge caching, HTML cache policies, and API purge mechanisms .

For users who are new to WordPress or CDN caching principles, you can first understand SPC as a “local cache plugin + a tool that helps you automatically configure cache rules in Cloudflare and purge the cache when content changes”. This way, you don't have to worry about how to write rules or when the cache is purged. Establish the core concept first, and then gradually understand the full picture of the linkage mechanism combined with the knowledge from previous chapters.

---

5 Verification of SPC's Actual Performance

1 Access Acceleration Verification

Logically speaking, this chapter should have included a section dedicated to testing the acceleration effect of SPC's ”local cache” feature on access speed. However, in practice, this part of the test is not easy to achieve “pure validation of SPC”, for reasons already explained in Chapter 4 when discussing the linkage mechanism between SPC and Cloudflare:

• Cloudflare does not cache HTML pages by default:Even if SPC is working properly, the cf-cache-status you see in the developer tools will still be DYNAMIC. This is not because SPC has failed, but is determined by Cloudflare's own policy.
• To verify the acceleration effect, you must rely on the cache rules automatically added by SPC to achieve the ”Cache Everything” effect:Only by letting Cloudflare actually cache HTML content can you see obvious HIT and MISS transitions. However, this already introduces additional rule configurations, so the test results can no longer be solely attributed to SPC.

In addition, for various local cache plugins of WordPress, the acceleration effects achieved (i.e., improving access speed by generating static copies of pages locally) are actually very similar (which is also why the cache linkage mechanism between SPC and Cloudflare stands out so exceptionally). Therefore, I don't think there is much need for extensive testing; the focus of this article remains on verifying the linkage effect.

2 Verification of SPC and Cloudflare Cache Integration Effect

Taking the test URL ”https://blog.tangwudi.cc/game/trinitycore1/“ as an example.

First, ensure that ”cf-cache-status” is ”HIT”:

Add a new piece of content in the post editing interface:

Wait a few minutes and refresh the page. In theory, SPC should have already notified Cloudflare to purge the content corresponding to this URL in the cache, so ”cf-cache-status” should be ”MISS” at this point (note that the post content has not been updated yet):

After waiting a bit longer and refreshing the page again, the content is successfully added to the post, and ”cf-cache-status” becomes ”HIT”:

Note: After a post is updated, SPC will automatically notify Cloudflare via API to purge the corresponding page cache, but the speed of cache purging is affected by the Cloudflare plan—free accounts are usually slower, while accounts using APO take effect almost instantly. In addition, the visitor's network environment (ISP, region, network type, etc.) and the browser's own caching policy will also affect the display of updates: even if Browser Cache-Control is set to 60 seconds or shorter, refreshing the page in the same browser window may still display old content because the browser prioritizes local cache. Conversely, when accessing from a newly opened browser window or in incognito mode, the browser has no cache history and will fetch the latest HTML directly from the Cloudflare edge node, which may update faster. In short, SPC guarantees eventual content synchronization, but purge delay is a normal phenomenon.

---

From the test results in this section, SPC is indeed capable of automatically calling the API to purge the Cloudflare edge cache after post content changes, though the time it takes for the edge cache content to take effect is hard to predict. In addition, it also provides a manual trigger update feature, such as clearing the cache for the current post only, as operated below.

Delete the previously added content in the post editing interface and click update:

Then find the SPC Cache icon in the top bar of the WP admin panel, and click ”Purge cache for this page only” at the bottom:


Of course, you can also perform the same operation here in the post list:

---

6 Afterword

Compared to APO, the actual experience of SPC is generally quite good. Although there is still a certain gap with APO in terms of cache purge speed, browser cache handling, and compatibility with some dynamic pages, it is already an outstanding choice among current free WordPress solutions. Especially when the budget version of APO is no longer recommended, SPC provides a relatively clear and controllable caching solution for individual webmasters or small-to-medium sites using Cloudflare's free plan.

From the operational experience, SPC's automatic purge feature can synchronize to the Cloudflare cache via API after post content is updated, reducing the hassle of manual clearing; at the same time, it provides options to manually clear the cache of the current page or the entire site, providing a “safety net” for webmasters. Even with delays, this semi-automated mechanism is much more convenient than relying entirely on local cache or frequently logging into the Cloudflare dashboard to clear the cache.

Compared to other CDN or caching solutions, SPC's uniqueness lies in the fact that it is one of the few plugins that can directly link with Cloudflare in a standard WordPress environment. Most mainstream CDNs—whether Akamai, Fastly, AWS CloudFront, or KeyCDN—provide purge APIs, but usually require webmasters to write their own scripts or use third-party tools to achieve the “post update -> automatic cache purge” feature. A few managed WordPress services automatically manage caching in the background, but this is proprietary to the provider and cannot be used directly in any environment. SPC, in a free and open-source form, allows webmasters under Cloudflare's free plan to also enjoy conveniences such as automatic purging, manual control, and cache policy visualization, making it an extremely rare and practical choice among current free WordPress caching solutions.

Of course, caching is never about tweaking for the sake of tweaking; its goal is to give webmasters less to worry about and provide visitors with a smooth access experience. By understanding the underlying principles and mastering how to use the tools, even the simplest plugin can deliver extraordinary value. Whether it is SPC or APO, they are essentially helping you optimize site performance with limited resources. Mastering cache logic is like getting a “key” that can make your small WordPress site more stable and efficient in terms of global access experience.

Returning to the “WordPress caching dilemma” mentioned at the beginning of the article, many webmasters were once deterred by complex dynamic pages and tedious CDN configurations. Through the analysis in this article, we can see that even with a free solution, there is a viable path: understanding cache layers, properly configuring local and edge caches, and combining automatic and manual clearing mechanisms will ultimately allow visitors to enjoy a smooth access experience while ensuring content synchronization.