In a recent article, I spoke at length about the free WPX Hosting Plan Resource Update of last September. From the viewpoint of the end-user, it was just a simple increase to some limits. When looking at it from an operations perspective, it was a complex procedure with many moving parts that needed careful evaluation before the adjustments were actually made to bring the largest possible benefit to all users, given the capabilities of the platform.
The topic of today’s column: a feature that was launched silently in the middle of this year, has been working ever since, and is getting support from 3rd parties. It goes by the decidedly uninspired name of “Remote Cache Invalidation” and there is a good chance your WPX-hosted websites are probably using it at all times without you even knowing it.
Ultimately, this article will be about three topics: (1) how caching works when combined with a CDN service such as the one that is available for free to all WPX customers; (2) what are the unique challenges of making a distributed system like that always serve the most up-to-date version of the site content, and (3) how WPX have implemented a solution that allows their customers to reset the WPX CDN cache programmatically.
Some History and Context
One of the first complete full-page caching solutions for WordPress was a plugin called W3 Total Cache (W3TC). It was created by a guy called Frederick Townes all the way back in 2013. It is quite an ambitious project, and for a very long time, it held an uncontested No. 1 place in the toolbox of those who wanted to make their websites run faster through local caching and resource minification.
W3TC gives website owners the ability to control every aspect of local speed optimization: from minification and compression through integration with opcache (memcached, redis) and many others. Among its many features is the built-in support for Varnish — a very high-performing full-cache solution that sits in front of the actual hosting server and serves pre-built copies of all pages at an immense speed.
The downside of W3TC is the sheer complexity of its configuration. It is not a ‘set all toggles to on’ solution; it requires lots of knowledge and experience to wade through the tons of settings and select the right combinations. As a matter of fact, the developer’s main source of revenue is selling support packages for their own caching plugin — after that business was almost crushed by the amount of support tickets caused by its complexity.
WPX and W3TC
At the time WPX were launching their hosting business, and for a long time thereafter, essentially all efforts at site loading speed were targeted towards achieving on-site speed gains. CDN (Content Delivery Network) solutions were still rare and expensive to set up and operate. Also, they were predominantly used to serve static resources like images and multimedia files. The hosting industry still needed several more years and significant advances in technology to make full-page caching solutions affordable.
Very early on, the WPX performance team realized the speed advantages W3TC provided. They spent possibly more than a thousand man-hours studying the behavior of the caching plugin and the overall effect of its myriad of settings on page loading speed.
WPX did another very smart thing: they removed the difficulty of configuration for their customers by offering everybody a one-time FREE tune-up per website that included configuring W3TC the best way to work with their servers (sidenote: they still do; click here for full details).
Those WPX customers who prefer to take care of things themselves can take advantage of several ready-made configuration sets for W3TC that the WPX team has made available to everyone free of charge.
The Need for CDN
The thing about full local caching is that, while it is absolutely required for top performance, it is not always sufficient. Unless your website is located close to your customers, there will always be some network latency. So, naturally, one would want to have their website located close to their customers, and that is why WPX offer a choice between 3 locations — Chicago, London, and Sydney.
But while this works wonderfully for customers whose audience is mainly located in North America, Europe, Australia, and Southeast Asia, it would be impossible to serve all three regions from the same origin location and retain that coveted celerity.
Using a CDN is the way to go when one wants to maintain quick loading speeds but do away with the complexity of maintaining multiple servers in different geographic locations and making sure they all serve the same content.
Modern CDN networks operate from multiple data centers situated strategically in various locations around the globe where the majority of traffic comes from. These super-fast servers maintain local copies of the fully cached website and periodically contact the origin server to make sure they still serve fresh content.
When the hosting operator has done their job well, all of this happens transparently for the visitors and requires no effort on the part of the user. But what happens when one needs to update the content they are serving to their visitors before the next scheduled round of updates?
How to Bust Local and CDN Cache Simultaneously and Reliably
When we only need to take care of the local cache, things are simple: W3TC rebuilds the outdated content, and subsequent visitors begin to see the refreshed version immediately. But when the CDN network gets between our content and our readers, suddenly it becomes a challenge to guarantee everybody will be seeing the refreshed content at the same time.
Every CDN service needs a mechanism to ‘flush the pipes’ whenever the content on the origin server changes. This procedure is called ‘Remote Cache Invalidation’.
When WPX built their CDN service, they needed to do two things: (1) figure out a way to know when page cache was invalidated locally (on the origin server) and (2) invent a procedure to instruct their CDN server network to refresh their cache out of the scheduled sequence.
This job would be relatively simple if WPX decided to support only one type of caching plugin and only their own CDN. However, the company would not want to restrict their customers like this, especially because the choice of local caching solutions had become much more varied than back in the days when W3TC had no practical alternatives.
WPX smartly concede that users should be free to choose a local caching plugin that best suits their individual preferences; the same applies to their preference for a CDN. However, this meant that WPX had to come up with a cache-busting solution that could be made compatible with potentially all combinations of caching plugins and 3rd party CDN.
So this is what they ended up doing.
Busting CDN Cache via Varnish-compatible HTTP Requests
Technically speaking, Varnish is the precursor to the modern caching server that runs as part of the CDN. I cannot describe this any better than its creators:
Varnish Cache is a web application accelerator also known as a caching HTTP reverse proxy. You install it in front of any server that speaks HTTP and configure it to cache the contents. Varnish Cache is really, really fast. It typically speeds up delivery with a factor of 300 – 1000x, depending on your architecture.
Source: Varnish-Cache.org
Before going for a distributed content delivery network, many users would run a Varnish proxy in front of their web server. As a matter of fact, you could easily think of a CDN as a network of Varnish proxy servers linked to the same origin server.
Just like W3TC, Varnish is tremendously popular in the community, and the way it operates is well-understood and supported by many caching plugins. Because the WPX team was intimately familiar with W3TC, they also knew about Varnish.
Although the WPX dev team researched different solutions, in the end, it was a simple decision to make their CDN compatible with the method Varnish used to handle cache purging requests. This would allow immediate compatibility with many caching plugins that already supported Varnish.
What Varnish does is listen to HTTP requests on port 6081 for special requests that use the HTTP PURGE method. The PURGE request supplies the local path towards the resources that need to be invalidated.
WPX hosting servers are configured to emulate this behavior. On each machine there is a small daemon that listens to 127.0.0.1:6081 (localhost:6081) and accepts the following kinds of requests:
PURGE / # Purges the home page
PURGE /some_specific_url/ # Purge a single page
PURGE /specific_url/.* # Another way to purge a page
PURGE .* # Purge the complete cacheWhen somebody sends a valid PURGE request, the daemon immediately propagates it across the WPX CDN network. As simple as that.
OK But…
You are probably asking yourself, what does that mean for you, as a regular user of WPX hosting services?
It gives you options.
Before this feature was enabled, if you needed to clear the WPX CDN cache, you had to open the Client Area of your WPX hosting account, click on ‘Manage Service’, then select ‘WPX Cloud’ and click on the ‘Empty Cache’ button for your domain:
This method has two major inconveniences: (1) you need to open a separate website, log into your account, and then navigate several layers deep into the settings panel to reach the cache invalidation button, and (2) the ‘Empty Cache’ request purges all cache for the entire website.
Even if the first inconvenience is acceptable, the second one is quite significant, and might not be necessarily acceptable.
While it is sometimes necessary, full cache busting is not without its drawbacks. When the cached copy of a web page is destroyed, the web server needs to create a new copy. For reasons beyond the scope of this article, caching plugins cannot be configured to generate new copies of all site pages; a URL that has had its cache invalidated will only get a new cached copy created when that URL is hit for the first time.
In general, full cache invalidation is usually unnecessary and should be avoided if possible. WPX have provided users with the ability to bust parts of the cache selectively and programmatically, which allows a better solution than nuking the whole site cache.
How to Perform Cache Purging
There are a couple of ways to take advantage of this new capability.
If you are using an existing caching solution such as W3 Total Cache, WP-Rocket, Nitropack (and possibly, a few others — I will update this list), this is handled automatically for you. All of these plugins hook into the WordPress events that necessitate selective cache purging, like publishing a new post, editing an existing post, or deleting a post (or a page; or a product page; etc.).
You can also take advantage of a cache nuking plugin, which does not perform on-site caching and optimization but is only intended to send cache-clearing commands at the appropriate events.
Two such standalone solutions are Varnish/Nginx Proxy Caching by Razvan Stanga and Proxy Cache Purge by Mika Epstein.
For Varnish/Nginx Proxy Caching, you need to configure only two fields: IPs and Dynamic Host, then press ‘Save Changes’ at the bottom of the page.
It is really simple to use: it installs an admin bar menu entry called ‘Purge ALL Varnish Cache’.
In Proxy Cache Purge the situation is pretty much the same: you need to install the plugin, go to the Proxy Cache entry into the Settings and then type 127.0.0.1:6081 then store the settings using the ‘Save IP Settings’ button.
3rd Party Optimization/Caching Solutions
Although having a good caching solution goes a long way, there is additional speed gain to be had by optimizing resources: images, CSS rules, JavaScript files, and so on. Where once W3TC was a one-stop shop, we now have dozens of services that compete for that lucrative market.
Today you will find at least a couple of dozen different speed optimization services that rely on both local caching (via plugin) and remote optimizations like lossless compression of images, creation of different image sizes for desktop and mobile devices, conversion into next-gen image formats like WebP, and so on.
One such solution is the WP-Rocket plugin, which offers a rich arsenal of image and script optimization tools. Another one is Nitropack. The common link between these two is that they rely on a CDN of their own as part of the optimization process. To work with a fully-cached website, they are facing the same issues WPX themselves had to solve for their own XDN network.
Since the summer of 2022, both companies have implemented into their WordPress plugins the cache-busting mechanism provided by WPX, and have adapted their infrastructure to detect local cache purge requests and to propagate them. Nitropack were the first to announce official support; WP Rocket however attracted more publicity, as the work on this integration was publicly visible on GitHub.
About a month ago, the changes were merged and initially were enforced for 25% of all WP Rocket customers at WPX. After extensive testing, since late November 2022, the update has been propagated to all users.
How The Puzzle Pieces Click Together
It might not be apparent, but whether to use the WPX CDN and a 3rd party optimization tool is actually not an either/or decision. In fact, the two can complement each other wonderfully. Here are the why and how.
Most modern WordPress optimization tools improve on their predecessors in two aspects: how they process resources and how they distribute them to site visitors. I can offer as an example one of the first kinds of speed optimization that we had: the compression & conversion of image files.
Compressing images is one thing hosting companies hate *a lot*. It is a very CPU and I/O-heavy process, customers usually trigger it during the daytime, when there are more site visitors, and everybody on the same server gets unhappy when performance degrades.
More than a decade ago, the makers of tools like EWWW I.O. and ShortPixel had the bright idea to offload the compression task from the hosting server, and to use dedicated compression servers for that task, then simply re-upload the optimized files.
Over time, this idea was extended onto CSS stylesheets and JavaScript files. It became relatively easy to figure out the ‘above the fold’ CSS that the browser required to render a page quickly to the visitor. Some smart optimization services began to pull website pages and render them at different resolutions while taking note of which CSS rules were used, and which JS events fired. They generated different sets of files that the origin website could then serve to actual visitors who happened to use devices with the same screen sizes and resolutions as the ones used by the optimization service itself. At the expense of some more storage space, the problem of tailoring the view of every webpage to the specific visitor began to solve itself.
Ultimately, somebody else had another bright idea. He or she astutely observed that the source files (images, CSS, JS…) traveled from the origin servers to the processing servers run by the optimization service, and then the output traveled back. Wouldn’t it be smarter, that somebody asked if the optimized resources were instead propagated across the CDN network and were served to visitors from data centers that were closer to them?
Today, most WordPress optimization services offer some kind of CDN that caches locally the very same resources those services pulled from the origin server and squashed. So you might be asking yourself, why do I need another CDN service from WPX when I already use the CDN provided by my optimization service?
These optimization plugins, by necessity, operate on separate website components — images, scripts, stylesheets — and store their optimized versions.
The WPX CDN works quite differently than that.
Because it is owned and operated by the same company, it basically allows servers to talk to each other directly. The WPX CDN does not operate on the website level; it works on the server level.
Whenever your optimization plugin compresses an image or minifies a JS/CSS file, it gets cached by the origin server. Future visitors will receive the latest cached version of each page. When the WPX CDN is activated, pages that get loaded into the origin server’s cache are quickly replicated across the CDN into the other POPs.
So, as you can see, the 3rd party optimization tools can actually synergize and complement the WPX CDN service. And, incidentally, this was another reason why the WPX dev team pushed with the universal solution for purging cache both locally and across the CDN itself.
Conclusion
WPX earned their place among the very best performers in the hosting industry by making careful choices about the technologies they should use, and by adopting the best available 3rd party solutions to build on top of them. This forward-thinking is the reason why they were the first hosting provider to equip their servers entirely with SSD storage on launch. Or why they were among the very early adopters of Litespeed Enterprise server at scale, or why they created their own full-page caching CDN solution.
However, the hosting business never stands in one place for too long. Now that the consumer market for full-sized personal computers has begun to stagnate, the hardware manufacturers have directed all of their efforts to compete in the server market. This means faster, better, and more affordable tech than at any time.
On the software front, we witness something similar. Where once there were a few optimization plugins for WordPress, today there is a whole new optimization industry growing out of our need to have ever faster-loading websites.
WPX are aware that sticking with the old solutions can only take them so far, and that change is inevitable. That is why they develop their technology stack in such ways that it is compatible with a growing number of site optimization services.
These efforts have started to bear fruits. Every developer of a WordPress optimization plugin that includes a CDN component can now effortlessly provide support for WPX and their cache-purging solution, and attract thousands of new customers.
If you are a WordPress developer working on the next best speed optimization plugin and you read this, give WPX a call — their technical team will be happy to chat with you and discuss how you can make your tools compatible with theirs, and earn the attention of the full WPX customer base, always eager and committed to go faster 🙂
And if you are a WPX customer, now you know that you will be entering the new year with even more choices and even more speed for your websites than ever before.
