1 WordPress caching dilemma and solutions

1.1 Why do many WordPress webmasters prefer to give up CDN?

In the world of static sites, CDNs offer practically free performance optimization: static files are naturally suitable for caching, and HTML pages rarely update frequently. Therefore, simply pushing resources to a CDN node instantly yields extremely low latency and high concurrency. For front-end developers or static bloggers, enabling a CDN comes at no cost, yet the benefits are immediate.

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

1. The frustration of out-of-sync caches

WordPress content is frequently updated, whether it's writing blog posts, revising pages, adjusting styles, or even leaving comments. If your CDN caching rules aren't configured correctly, the frontend might still display an outdated version. For webmasters, the most frustrating thing is working so hard to update a post, only to have visitors continue to see the old content.

2. Dynamic content processing is complex

Login states, comments, shopping carts, and personalized content—these can't be easily cached. Webmasters need to set bypass rules, but if the rules are too loose, caching becomes meaningless, while if they are too strict, they can easily cause unintended consequences. Ultimately, you're likely to find yourself in an awkward situation where "no matter how you adjust it, it just doesn't work."

3. Using VPS directly is more controllable

Many webmasters choose to install caching plugins (such as local page cache and object cache) on their VPSs. While these plugins may not provide global coverage, they at least provide predictable results and allow for troubleshooting. In contrast, relying on a CDN creates an additional black box. Problems may not be caused by the server or WordPress, but rather by cache inconsistencies across CDN nodes, making troubleshooting extremely expensive.

4. Differences in Operations Mentality

Webmasters generally prefer stability over hassle. While CDNs are a nice bonus for static sites, they can be a nuisance for dynamic ones. Consequently, many adopt a "minimum dependency" approach: as long as the server performance and bandwidth are adequate, they avoid CDNs and focus their time and energy on content and functionality.

Therefore, WordPress website owners are generally cautious about using CDNs. Even though Cloudflare's free plan seems attractive, some still choose to abandon it. To truly integrate WordPress with CDNs, resolving the cache asynchrony issue is key.

1.2 Cloudflare Official APO: Best Practices for WordPress

Before discussing third-party plugins, we have to mention Cloudflare's own APO (Automatic Platform Optimization)This is a set of optimization solutions specially created by Cloudflare for WordPress. It can be said that it is currently WordPress Site-Wide Cache Management: Official Best Practices.

The core idea of APO is simple: The entire WordPress site's HTML pages are also included in the CDN cacheAPO also uses an intelligent cache refresh mechanism to ensure that after an article is updated, Cloudflare nodes around the world can quickly access the latest content. Compared to traditional CDNs that only cache static resources (images, JS, and CSS), APO directly solves the long-standing problem of "HTML not being fully cached" for dynamic sites like WordPress.

More importantly, the APO experience is almost "nothing":

• Smart cache refresh：When an article or page is updated, Cloudflare will automatically call the interface to refresh the corresponding cache, avoiding the tedious operation of manual cache cleanup.
• Mobile Optimization: APO has built-in caching and response optimization for mobile devices to reduce latency for mobile users.
• Edge node acceleration：No matter where the visitor comes from, APO will prioritize returning cached HTML directly from the Cloudflare node closest to the user, significantly reducing TTFB (time to first byte).
• Ready to use out of the box: The official WordPress plug-in works closely with Cloudflare, and webmasters can get the complete acceleration effect with almost no complex configuration.

In other words, after turning on APO, the access experience of a WordPress site is almost the same as that of a static site at the CDN level. It can enjoy the speed advantage brought by the full-site cache while maintaining the real-time nature of article updates. This is why many webmasters call it the "perfect solution."

However, there is a drawback:Cost issues：APO requires additional payment for Free users $5/month,and Pro plan ($20/month) and above This makes many small personal blog owners discouraged;Binding Ecosystem: APO is Cloudflare's own closed-loop service. If you plan to migrate to other CDNs or adopt a self-built solution, you will not be able to continue using it.

Therefore, although APO is technically impeccable, its entry level is not low. After learning about it, many WordPress users still choose to wait and see, or settle for third-party plug-ins to achieve similar functions - this leaves room for various subsequent free alternatives.

1.3 The Basic APO plan is no longer officially supported by Cloudflare

In the previous article, I introduced a method of Cloudflare Worker To implement the "beggar version of APO" function (see article:Home Data Center Series Cloudflare Tutorial (VII) Introduction to CF Worker Functions and Practical Operation, Verification and Research on Related Technical Principles of Implementing "Beggar Version APO for WordPress" Function to Accelerate Website Access Based on WorkerThis solution works by using a free WordPress plugin and a JavaScript script running on Cloudflare Worker (modified from the edge-cache-html.js example script previously provided by Cloudflare) to statically cache dynamic WordPress content. The plugin also automatically triggers versioning of Cloudflare's cached content when site content is updated, ensuring the cache is always in sync with the actual content.

However, this "beggar version of APO" solution has always struck me as less than ideal for two main reasons:

1. Cloudflare no longer provides official support

The official cloudflare repository on GitHub has removed the download of the plug-in:

Although I backed up the plugin to my resource site at the time, since it hadn't been updated for years, I couldn't guarantee it would work properly on the current version of WordPress, not to mention the security risks. At the same time, the edge-cache-html template directory was no longer available in the cloudflare/templates repository on GitHub. Previously:

Now:

It can be seen that CloudFlare no longer provides official support for this method.

2. Free subscription users have more restrictions

Even if you still use this solution, users of Cloudflare's free plan will still face Worker restrictions: a daily quota of only 100,000 requests, and the need for additional KV storage. While the free KV quota is theoretically sufficient for personal use, in actual deployments, I encountered numerous false positives and anomalies, resulting in an unstable experience.

More importantly, as I've used APO for a long time, my requirements for caching and acceleration have become increasingly demanding. By comparison, this "beggar version of APO" solution is somewhat rudimentary and insufficient to support a stable and sustainable site acceleration system. Therefore, for a long time, I couldn't find an ideal solution that would both work with Cloudflare's free subscribers and provide automated cache management and acceleration.

So, what kind of solution is considered "relatively perfect"? If we refer to the APO standards, it must at least meet the following requirements:

• Just install a plugin locally on WordPress;
• No need to configure complex Worker and KV storage;
• Ability to automatically refresh and manage Cloudflare's cached version when content is updated;
• With stable compatibility and continuous maintenance.

And a WordPress plugin I recently discovered:Super Page Cache", and it just provides a nearly ideal solution in these aspects.

2. Introduction to Super Page Cache plugin

2.1 Pain Points of Traditional WordPress Local Cache Plugins

Traditional local cache plugins, such as WP Super Cache, W3 Total Cache, WP Fastest Cache, and more comprehensive LiteSpeed Cache, their core ideas are the same:Generate a static copy of the page ahead of time on the server, which is then returned directly to the visitor by the web server (such as Nginx, Apache, LiteSpeed). This avoids having WordPress dynamically parse PHP and execute database queries every time, greatly reducing the pressure on the backend.

This type of local cache plug-in has a natural premise:The site needs to be published directly through the VPS public network addressAlthough cache files can be stored on the local disk, they still rely on the web server on the VPS to respond to requests. In other words, their optimization scope mainly stays in Origin server level, rather than CDN-level caching.

The actual effect is:When the request returns to the server, the web server will prioritize hitting the local cache file., avoiding PHP dynamic parsing and database queries, significantly reducing backend pressure. However, whether a page can be cached at a CDN edge node depends entirely on the CDN's own policies. Cloudflare, for example, does not cache HTML content by default unless users set their own rules.

This is where the problem lies:The local cache plug-in cannot establish linkage with CloudflareWhen you update an article, your local cache will be cleared, but the cache at Cloudflare's edge nodes may still exist, ultimately causing the origin server and CDN cache to become out of sync. To fix this, there are usually only two solutions: manually clear the cache in the Cloudflare dashboard, or wait for the cache to expire.

2.2 Unique Super Page Cache plugin

In the WordPress world, Super Page Cache for CloudflareSPC (SPC for short) is a very special tool: it's not simply a "local page caching tool." Its uniqueness lies in its ability to cache locally, but also to work with Cloudflare's API to ensure that edge cache and local content remain synchronized, achieving global acceleration similar to APO. This approach nearly replicates the effectiveness of Cloudflare's APO, making it a nearly ideal alternative for users who don't want to pay for APO.

To understand the uniqueness of SPC, we must first return to the design of APO. Traditionally, Cloudflare's edge nodes primarily cache static resources, such as JavaScript, CSS, and image files. WordPress pages themselves are still dynamically generated, and each request must return to the server for parsing and database queries. APO's innovation lies in incorporating WordPress-generated HTML pages into the cache system, allowing this content, which would otherwise require dynamic generation, to be served directly at the edge nodes.

In other words, APO "staticizes" dynamic pages and caches copies on Cloudflare nodes around the world, significantly reducing back-to-origin requests. More importantly, APO isn't a one-way cache; it's linked to WordPress: whenever site content is updated—for example, when an article is added or modified, a page is deleted, or a comment is added—the WordPress plugin proactively calls Cloudflare's API, notifying edge nodes to clean or refresh the corresponding cache. This creates a balance between cache hit rate and content timeliness, ensuring visitors always see the latest page while maintaining access speeds similar to a purely static site.

The SPC plug-in is designed along this line of thought: it establishes a linkage with the Cloudflare edge network through Cloudflare's API. When you publish, update an article, or adjust the site content in the background, SPC will automatically call the API to notify Cloudflare to clean up or refresh the cache of the relevant page. In other words,The cache storage action depends on Cloudflare's cache rules, and the role of SPC is to ensure that the cache is synchronized with the site content.In this way, the webmaster can keep the page cache up to date with almost no manual intervention, achieving a high degree of automation and seamlessness.

Compared to the previous "beggar version of APO" solution, SPC brings significant changes: First, it does not rely on Workers at all, thus getting rid of the problems of daily request limits and KV read and write limits. Second, it is a plugin that is still being updated and remains active in the WordPress plugin library, which means compatibility and security are guaranteed. Moreover, its configuration is very simple. Simply fill in a set of Cloudflare Global API Keys (or API Tokens) in the plugin settings to basically achieve linkage with Cloudflare's cache.

In actual use, SPC works quite well overall. It pushes WordPress HTML pages to the Cloudflare node cache, reducing back-to-origin traffic and significantly improving access speeds. However, it's important to note that the experience is still significantly different from APO: the refresh of the cache is not always reliable, sometimes requiring several minutes or even longer to take effect, especially when using Cloudflare's free tier.

The plugin itself also provides some common flexible options, such as which pages can be cached and which pages should be excluded, thus preventing key dynamic pages from being interfered with by the cache. These features allow webmasters to more finely control the scope of caching and avoid a "one-size-fits-all" situation.

In general, Super Page Cache is more like a Practical alternativesWhile it can't completely replace APO, it still offers value for sites using Cloudflare's free tier and seeking an improved user experience with edge caching. It's important to note that it's not a "perfect out-of-the-box solution," and some dynamic pages (such as shopping carts and login pages) still require exclusion rules to ensure proper functionality. Fortunately, SPC can automatically generate cache exclusion rules for common dynamic content, which reduces the manual configuration burden on site administrators. However, debugging and verification based on actual needs are still recommended.

To put it in a different way, APO is like a fully automated edge cache manager tailored for WordPress, ensuring instant cache synchronization, effective browser caching, and excellent compatibility with dynamic pages with virtually no intervention. SPC, on the other hand, is more like a semi-automated assistant. While it can automatically synchronize article updates to Cloudflare and offers manual override options, it still has limitations regarding cache refresh latency, browser cache control, and compatibility with special dynamic pages. In other words, if you're looking for an out-of-the-box, premium experience, APO is the preferred choice. If you're a free tier user or prefer complete control over caching logic, SPC offers a flexible and viable alternative.

3. Installation and Configuration of Super Page Cache

3.1 Plugin installation and activation

Once the installation is complete, enable the plugin:

Activate the plugin's caching feature:

Activation successful:

3.2 Plugin Settings

3.2.1 Overview

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

3.2.2 General: Core configuration (local cache function settings)

This section is the core configuration area for Super Page Cache, primarily determining the plugin's local cache enable and disable as well as global rules. It provides several key features: whether to enable local disk caching, control over caching for specific cookies or URL paths, and unified handling of marketing parameters (Pro feature). These options ensure that page speeds are improved without impacting dynamic user operations or sensitive interfaces. Additionally, you can choose whether to display advanced settings, allowing users with more refined caching logic requirements to expand upon them:

The "Advanced Settings" section actually has a lot of very useful options, but there are too many options and I am too lazy to explain them one by one. I will just take a screenshot of the translation interface for everyone to see for themselves:

---

Important reminder:

The "General: Core configuration" function area is mainly used to set the SPC Local cache functionWhile it's a different layer from Cloudflare's edge cache, it's not an either-or relationship. With local caching enabled, your VPS will save a static copy of your page to disk: when a Cloudflare edge node hits the cache, the local cache won't participate and will return the result directly. When a Cloudflare cache misses and a request is made back to the origin, the local cache will respond quickly, preventing frequent calls to PHP and the database.

In other words, local caching and Cloudflare caching can complement each other:The former ensures the performance of the origin station, while the latter improves the global acceleration effect.Therefore, for most sites, it is not recommended to turn off "Disk Page Cache". Instead, let SPC keep the two layers of cache cleared synchronously through the API, so as to obtain a more efficient and more stable cache system.

This "double-layer cache" is particularly suitable for the following scenarios:

• Limited origin server performanceFor example, if a low-spec VPS relies solely on Cloudflare, the origin server may be overwhelmed if a cache miss occurs, but the local cache can provide a backup.
• Large number of visits: When concurrency is high, local cache can significantly reduce database query pressure and improve stability.
• Insufficient flexibility in caching strategies：Cloudflare does not cache HTML by default, but local cache can make up for this, and then combine with Cloudflare edge cache to add acceleration.

Of course, the local cache may also cache dynamic pages that should not be cached (such as shopping carts and login backends), so it may still be necessary to use exclusion rules to avoid the problem of incorrect caching.

---

3.2.3 Cloudflare: CDN&Edge Caching

This section connects the plugin to your Cloudflare account, which is the biggest difference between SPC and traditional local caching plugins. By setting this section, WordPress's caching logic can be extended directly to Cloudflare edge nodes, achieving site-wide dynamic page acceleration.

Here, users need to configure Cloudflare's authentication information. They can choose the traditional Global API Key, you can also use the more recommended API TokenThe latter provides targeted permission control, is more secure, and is more in line with Cloudflare's official best practices. Once connected, the plugin automatically interacts with Cloudflare to push and clean caches without requiring manual backend operations:

After clicking the "Connect to Cloudflare" button below:

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

Then SPC will automatically create a cache rule in the cloudflare background:

The cache rules are as follows (too long to display in full, so I’ll take a screenshot to illustrate):

The complete expression for SPC to generate matching conditions 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 seem much different from the default "Accept Origin Server TTL". After all, it is mainly limited by the refresh time of Cloudflare's edge cache:

3.2.4 Other additional optimization functions

In addition to its core caching and Cloudflare edge node integration features, Super Page Cache also includes some common local optimization options. These features aren't the plugin's unique selling points, but their integration saves webmasters the trouble of installing additional plugins.

exist Files In terms of font size, the plugin provides optimization options for Google Fonts, which can merge multiple font requests into one file, or even directly download Google Fonts to a local server for loading, avoiding delays and potential compliance issues caused by external requests:

exist Media In terms of image lazy loading, the plugin supports lazy loading. Webmasters can either enable the browser's native lazy loading mechanism or switch to the plugin's built-in solution for more refined loading control. This can effectively reduce bandwidth consumption on the first screen, making the page "faster" in the user's perception:

exist Database The plugin provides tools for cleaning and optimizing your database. This includes regularly clearing out old article revisions, drafts, spam comments, and invalid transient data, as well as defragmenting database tables. For sites with a long history and a high volume of redundant data in their databases, these tools can help reduce workload and increase speed:

These additional features are not really important, they are just icing on the cake. If your site is already using WP Rocket,LiteSpeed Cache or Autoptimize Such comprehensive optimization plug-ins may overlap with SPC. In this case, you can choose to enable or disable the corresponding functions as needed to avoid duplicate optimization or potential conflicts.

4 Key points for linking SPC with Cloudflare accounts

In Section 2.2, I mentioned: "When you publish, update an article, or adjust the site content in the background, SPC will automatically call the API to notify Cloudflare to clean or refresh the cache of the relevant page. In other words,Whether the cache can enter the edge depends on Cloudflare's own caching rules; and the responsibility of SPC is to clear and refresh the content when the content changes, so that the edge copy is synchronized with the site content."The real meaning of this sentence is to “Who will cache?” and “Who manages the cache lifecycle?” Clarify the division of labor.

Cloudflare's default policy is very restrained: the edge will only cache static resources (such as CSS, JS, images),HTML is not cached by defaultTherefore, even if SPC staticizes the page locally and performs "linked cleanup" well, without additional policies, the edge node will still treat HTML as dynamic content and return it to the source, and the "cf-cache-status" you see will always be DYNAMIC.

To change this, the SPC plugin has a built-in solution: “Cloudflare: CDN & Edge Caching” Enable in options Enable Cloudflare CDN & Caching and click Update settings, SPC will automatically call the Cloudflare API and 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 background, login state, interface, shopping process, etc. to avoid incorrect caching. In other words,SPC is not only responsible for linkage cleaning, but also configures the "Cache Everything" rules for you, so you don't need to manually go to CF to write them again..

Compare it with APO to make it clearer:APO This is equivalent to "making HTML into edge cache by default + linking with WordPress". SPC The combination logic is: the plug-in automatically creates a Cache Rule to solve the problem of "caching HTML"; then uses the API to accurately clean up and solve the problem of "linked refresh". The mechanism is different, but the experience is relatively similar; the difference is,SPC itself does not "push" the page to the edge, it just ensures that the edge copy is refreshed or deleted in time after you change the content.

In the case of a free Cloudflare subscription account (paid subscriptions come with APO and don't require SPC), there are three key points to making SPC truly effective:

First,Qualification first: Make sure Cloudflare CDN & Caching is enabled in the SPC settings and generate cache rules on Cloudflare simultaneously so that the HTML is eligible for caching.

second,Let’s talk about linkage again: SPC will call the Cloudflare API to perform targeted cleanup when you publish, update, delete, or comment on changes to avoid the "local update but edge lag" asynchrony.

third,Retain exceptions: Backend, login, shopping processes, interfaces, and previews must bypass caching to prevent them from being cached. SPC automatically generates rules to cover these common exclusions, but users can further fine-tune them in the Cloudflare dashboard.

In practice, the idea can be simplified into one sentence:"Let Cloudflare be responsible for storage and clearly state what is stored; let SPC be responsible for management and clearly state when it will expire." For free users, this involves two steps: enabling Cloudflare CDN & Caching in the SPC plugin (which automatically generates cache rules), and letting SPC automatically clean up the rest. Cloudflare's official "Default Cache Behavior" and "Cache Rules" documents clarify the justification and boundaries of this approach. Combined with SPC's "per-URL cleanup" logic, you can consistently replicate results close to APO.

Here I would also like to correct a common misunderstanding. When the cache policy of "Cache Everything" is not configured on Cloudflare by default, you will see the response header cf-cache-status: DYNAMIC Does not mean SPC is invalid:

Note: To prevent the local cache function from interfering with the observed SPC plug-in and Cloudflare cache linkage results, I turned off this function in subsequent tests. It does not need to be turned off in actual use.

It just means "The HTML requested this time was not considered cacheable by Cloudflare." When SPC's automatic rules are enabled, the first visit is usually MISS(Back to source and write to edge):

You will see it later HIT:

When you update content in WordPress, SPC will clear the edge copy of the relevant URL, and the next request will write back to the source and continue to hit it. “Rules + Linkage” The rhythm of collaboration.

Finally, the different routes are explained clearly to facilitate your judgment: If you are using Pro / Business / Enterprise Package, install the official cloudflare plug-in directly in WordPress and enable it according to the processAPOCloudflare will automatically put the HTML into the edge cache without any additional operation; if you are Free Users need to rely on SPC plug-in automatically generates cache rules, which also allows HTML to be cached on edge nodes. Although the two paths have different methods, they have the same goal:Make WordPress HTML "fast" at the global edge and "keep up" as you modify your content.

---

This chapter describes how SPC works with Cloudflare accounts (primarily free subscription accounts) to implement a linkage mechanism for HTML page caching. It should be noted that for readers who have no basic understanding of APO or edge caching, even if I write this chapter clearly, it may be difficult to fully understand the true advantages of SPC. In other words, the core essence here depends on the Edge caching, HTML caching strategy and API refresh mechanism cognition.

For users who are new to WordPress or CDN caching principles, you can first understand SPC as a "Local Cache Plugin + Tools that automatically configure caching rules in Cloudflare and refresh the cache when content changes"This way, you don't have to worry about how to write rules or when to refresh the cache. First, establish the core idea, and then combine the knowledge in the previous chapter to gradually understand the overall picture of the linkage mechanism.

---

5. SPC actual effect verification

5.1 Access Accelerated Verification

Logically, this chapter should have included a section specifically testing the access speed acceleration effect of SPC's "local caching" feature. However, in practice, this section of the test is not easy to "purely verify SPC" for the reasons discussed in Chapter 4 when describing the SPC and CloudFlare interaction mechanism:

• Cloudflare does not cache HTML pages by default:Even if SPC is working properly, the cf-cache-status you see in the developer tools is still DYNAMIC. This is not because SPC is invalid, but because of 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 we see a clear switch between hits and misses. However, this already introduces additional rule configuration, and the test results can no longer be attributed solely to SPC.

In addition, for various local cache plug-ins for WordPress, the acceleration effect achieved (i.e. improving access speed by generating static copies of pages locally) is actually similar (this is why the SPC and CloudFlare cache linkage mechanisms are particularly outstanding and stand out from the crowd), so I don’t think there is much need for testing. The focus of this article is still on verifying the linkage effect.

5.2 Verifying the effectiveness of SPC and Cloudflare cache linkage

to test the URL"https://blog.tangwudi.cc/game/trinitycore1/“For example.

1. First, make sure that "cf-cache-status" is "HIT":

2. Add a new paragraph in the article editing interface:

3. Wait a few minutes and refresh the page. Theoretically, SPC should have notified CF to clear the content corresponding to the URL in the cache, so the "cf-cache-status" should be "MISS" (note that the article content has not been updated at this time):

After waiting for a while and refreshing the page again, the article content was added successfully, and the "cf-cache-status" changed to "HIT":

Note: SPC will automatically notify Cloudflare through the API to refresh the corresponding page cache after the article is updated, but the speed of refreshing the cache is affected by the Cloudflare package - free accounts are usually slower, while accounts using APO are almost instantaneous. In addition, the visitor's network environment (operator, region, network type, etc.) and the browser's own caching policy will also affect the update display: even if Browser Cache-Control is set to 60 seconds or less, refreshing the page in the same browser window may still display old content because the browser gives priority to the local cache. On the contrary, when a newly opened browser window or incognito mode is accessed, the browser has no cache history and will directly obtain the latest HTML from the Cloudflare edge node, which may be updated faster. In short, SPC can ensure that the content is eventually synchronized, but refresh delays are normal.

---

From the test results in this section, it can be seen that SPC can Automatically call the API to refresh Cloudflare edge cache after the article content is changed, but it is difficult to predict when edge cached content will take effect. In addition, it also provides the function of manually triggering updates, such as clearing the cache of the current article only, as follows.

1. Delete the previously added content in the article editing interface and click Update:

Then find the SPC Cache icon in the top bar of the WP backend and click "Purge cache for this page only" at the bottom:


Of course, you can also do the same thing here:

---

6. Afterword

Compared to APO, SPC's overall experience is quite good. While there are still some gaps in cache refresh speed, browser cache handling, and compatibility with certain dynamic pages, it's still an outstanding option among free WordPress plans. Especially with the basic APO plan no longer recommended, SPC offers a relatively clear and controllable caching solution for individual webmasters or small and medium-sized sites using Cloudflare's free plan.

From an operational perspective, SPC's automatic refresh feature synchronizes updated article content to the Cloudflare cache via the API, reducing the need for manual cleanup. Furthermore, it offers the option to manually purge the cache for the current page or the entire site, providing a safety net for webmasters. Even with some delays, this semi-automated mechanism is significantly more convenient than relying solely on local caching or frequently logging into the Cloudflare dashboard to purge the cache.

Compared to other CDN or caching solutions, SPC is unique in that it is one of the few plugins that can directly connect to Cloudflare in a normal WordPress environment. Most mainstream CDNs - whether it is Akamai, Fastly, AWS CloudFront or KeyCDN - although they provide a refresh API, usually require webmasters to write their own scripts or use third-party tools to implement the "article update → automatic refresh cache" function. A few hosted WordPress services will automatically manage the cache in the background, but this is exclusive to the service provider and cannot be used directly in any environment. SPC, in a free and open source form, allows webmasters to enjoy the convenience of automatic refresh, manual control, cache strategy visualization, etc. under the Cloudflare free package. It is an extremely rare and practical choice among the current free WordPress caching solutions.

Of course, caching isn't just for the sake of fuss; its goal is to reduce the hassle of website owners and ensure a smooth visitor experience. Understanding the underlying principles and mastering the tools can make even the simplest plugins incredibly valuable. Both SPC and APO essentially help you optimize site performance within limited resources. Mastering caching logic is like holding a key to making your WordPress site more stable and efficient across the globe.

Returning to the "WordPress caching dilemma" mentioned at the beginning of this article, many webmasters have been deterred by the complexity of dynamic pages and the tedious configuration of CDNs. This article's analysis shows that even with free plans, there is a viable path: understanding the cache hierarchy, properly configuring local and edge caches, and combining automatic and manual cleanup mechanisms can ultimately ensure content synchronization while providing visitors with a smooth browsing experience.