Proxy Cache Purge vs DietPress

This plugin does not install nor configure a cache proxy. It acts as an interface with such services. One common method of caching content for websites is via the use of reverse proxy caching. Common examples of this are Varnish and NGINX. These systems allow a website to update content and have the visitor’s experience cached without the need for complex plugins storing the files locally and using up a user’s disk space. A reverse proxy cache is installed in front of a server and reviews requests. If the page being requested is already cached, it delivers the cached content. Otherwise it generates the page and the cache on demand. The Proxy Cache Purge plugin sends a request to delete (aka flush) the cached data of a page or post every time it’s modified. How It Works When content on a site is updated by WordPress, the plugin reaches out to the proxy cache service with the URL of the page, requesting the cache be deleted. Not all pages are deleted from the cache on every change. For example, when a post, page, or custom post type is edited, or a new comment is added, only the following pages will purge: The front page The post/page edited Any categories, tags, and/or custom taxonomies associated with the page Related feeds Associated JSON API pages In addition, your entire cache will be deleted on the following actions: Changing themes Pressing the Empty Cache button on the toolbar Plugins can hook into the purge actions as well, to filter their own events to trigger a purge. On a multisite network using subfolders, only network admins can purge the main site. Keep Your Cache Warm Purging is only half the story. Once Proxy Cache Purge empties a page, the cache for that URL is gone, so the next visitor triggers a full uncached render and waits for it. On busy sites this “cache stampede” shows up as slow pages right after every update. Cacheability Pro is a companion plugin that closes that gap: it automatically re-warms purged URLs in the background so visitors keep hitting fast, cached responses, and it tunes your cache headers so more of your pages stay cacheable in the first place. Proxy Cache Purge handles invalidation; Cacheability Pro handles everything around it. Monitor Your Cache Proxy Cache Purge keeps your cache fresh, but how often is it actually being hit? If you run your own Varnish or NGINX server, GetPageSpeed Amplify shows your cache hit rate, request volume, and backend health over time, with a free tier. Proxy Cache Purge handles invalidation; Amplify shows you whether the cache is doing its job. Development Mode If you’re working on a site and need to turn off caching in one of two ways: Add define( 'VHP_DEVMODE', true ); to your wp-config.php file Go to Proxy Cache -> Settings and enable Debug Mode for 24 hours at a time That will break cache on page loads. It is not recommended for production! Cache Tags (BETA) As of version 5.4.0, Proxy Cache Purge includes an optional Cache Tags / Surrogate Keys purge mode. This feature is marked as BETA and is disabled by default. When enabled, the plugin: Adds cache-tag headers to WordPress responses (for example, tagging pages by post ID, post type, taxonomy terms, author, and archives). Uses tag-based purges instead of individual URL purges when content is updated, which can reduce purge traffic and improve consistency on complex sites. Requirements: A proxy cache that supports Cache Tags / Surrogate Keys and advertises this via standard Surrogate-Capability headers (for example, Surrogate-Capability: vhp="Surrogate/1.0 tags/1"). How to enable: Go to Proxy Cache → Settings → Purge Method and check “Use Cache Tags (Surrogate Keys)”. The checkbox is only enabled when your cache tells WordPress it supports tags (or when you explicitly enable it via a define). Alternatively, you can force-enable or force-disable detection via wp-config.php: define( ‘VHP_VARNISH_TAGS’, true ); // Force treat cache as tag-capable define( ‘VHP_VARNISH_TAGS’, false ); // Force treat cache as not tag-capable Because this feature depends on your cache configuration, it is recommended that you test it carefully in staging before enabling it on production. Background Purging with WP-Cron On busy sites, sending many PURGE requests directly from admin requests can slow things down. When you define DISABLE_WP_CRON as true in wp-config.php (because you are running a real system cron that calls wp-cron.php), Proxy Cache Purge automatically switches to an asynchronous mode: Purge requests (both URL-based and tag-based, when Cache Tags are enabled) are collected into a small per-site queue. The queue is processed by WP-Cron in the background, keeping your admin and content-editing actions responsive even when many URLs or tags must be invalidated. Object-cache purges (the “Purge Database Cache” option) remain synchronous and are not affected by this behaviour. The Proxy Cache settings page and Site Health integration expose basic queue status so you can verify that background purging is healthy; if the queue appears large or very old, check that your system cron is correctly invoking WordPress cron. Important: Cron Frequency and Cache Freshness When using background purging, the frequency of your system cron determines how quickly cache invalidations are processed. The longer the interval between cron runs, the longer visitors may see stale content after updates. For minimal stale content, run your system cron every minute: * * * * * /usr/bin/php /var/www/html/wp-cron.php If you can tolerate slightly longer delays, every 2-5 minutes is also acceptable. However, running cron less frequently (e.g., every 15 minutes) means cache purges may be delayed by that amount after content changes. Note: Scheduled posts are handled specially. When a scheduled post is published via WP-Cron, the cache is purged synchronously within the same cron run, ensuring immediate cache invalidation without waiting for the next cron execution. For detailed instructions on setting up a proper Linux-based WordPress cron, see: WordPress Cron Optimization. Disabling Background Purging If you have DISABLE_WP_CRON defined but do not want background purging (for example, on low-traffic sites where immediate purges are preferred), you can force-disable cron-based purging by adding this to your wp-config.php: define( 'VHP_DISABLE_CRON_PURGING', true ); With this constant set, all cache purges will execute immediately during the request, regardless of the DISABLE_WP_CRON setting. WP-CLI Purge Purge commands let you empty the cache. wp varnish purge – Flush the entire site cache (equivalent to clicking “Empty Cache” in admin) wp varnish purge --all – Explicitly flush the entire site cache wp varnish purge – Flush cache for a specific URL and all content below it (wildcard) wp varnish purge --url-only – Flush cache for only the exact URL specified (no wildcard) wp varnish purge --tag= – Flush cache by tag (requires Cache Tags mode to be enabled) Examples: wp varnish purge – Purge entire site wp varnish purge --all – Same as above, more explicit wp varnish purge https://example.com/hello-world/ – Purge this URL and everything below it wp varnish purge https://example.com/hello-world/ --url-only – Purge only this exact URL wp varnish purge https://example.com/wp-content/themes/ --wildcard – Purge all theme files wp varnish purge --tag=p-123 – Purge all pages tagged with post ID 123 wp varnish purge --tag=pt-post – Purge all cached pages of post type “post” Debug Debugging can help you figure out why your cache isn’t working as well as it could. The default is for your home page, but you can pass any URL on your domain. wp varnish debug [ ] Available parameters: [--include-headers] — Include headers in debug check output [--include-grep] — Grep active theme and plugin directories for common issues DevMode Development mode allows you to disable the cache, temporarily. wp varnish devmode [ ] – Change development mode state Async purge queue (cron-mode) When you define DISABLE_WP_CRON as true and run a real system cron for WordPress, Proxy Cache Purge can move heavy purge work into a small background queue that is processed by WP‑Cron. You can inspect and manage that queue via WP‑CLI: wp varnish queue status – show whether cron-mode is active, if a full purge is queued, counts of queued URLs/tags, and the last queue run time. wp varnish queue process – process any items currently in the queue (useful to run after deploys or cache‑sensitive operations). wp varnish queue clear – clear the queue without sending any PURGE requests. These commands do not replace your normal WordPress cron (you still need a cron entry that calls wp cron event run --due-now or hits wp-cron.php), but they give you a simple operational handle when using cron‑mode. Understanding Purge Behavior There are different types of cache purges, and they behave differently: Manual Purges (Admin Bar) “Purge Cache (All Pages)” – Sends a single regex purge request to invalidate the entire cache. Always executes immediately. “Purge Cache (this page)” – Purges only the exact URL you’re viewing. Always executes immediately. Manual purges are always immediate, even when background cron-mode is enabled. This is intentional: when you click a button, you expect immediate results. Automatic Purges (Post Save/Update) When you save or update a post, the plugin automatically purges: The post’s URL The homepage Category archive pages Tag archive pages Author archive page Date-based archives RSS feeds Related REST API endpoints This can be 20-50+ URLs depending on your site structure. When cron-mode is enabled, these automatic purges are queued and processed in the background to avoid slowing down the post editor. Key Difference Action URLs Purged Uses Cron Queue? “Purge Cache (All Pages)” 1 (regex) No – always immediate “Purge Cache (this page)” 1 No – always immediate Post save/update 20-50+ Yes (if cron-mode enabled) If you need to immediately purge all URLs related to a specific post (not just the post URL), save the post – the automatic purge will handle all related URLs.

DietPress is a free WordPress speed optimization plugin with a built-in page cache. Page caching, browser caching, GZIP and Brotli compression, deferred JavaScript, critical CSS, image loading attributes, preloading, locally hosted Google Fonts and selective asset loading, all in one plugin and all free. And it goes further than a caching plugin: it also puts WordPress itself on a diet, switching off the features your site never uses. It pairs that with a clean, risk-based interface. Everything is configurable, the optimizations are already on by default, and nothing is hidden behind a paid tier. Activate it and your site is faster, or open the settings and tune every detail. By default WordPress loads functions, services and scripts that most sites do not need. They slow down loading times and consume hosting resources. DietPress lets you trim that fat and apply battle-tested performance tweaks, with a clear description of what each option does and what might break, organized by risk level so you always know what is safe. WHY CHOOSE DIETPRESS Page caching, for free. Serve anonymous visitors a copy stored on disk instead of building the page again. The feature people buy WP Rocket or a NitroPack subscription for, with no licence and no monthly fee. No drop-in, no changes to wp-config.php. Unlike WP Super Cache or W3 Total Cache, DietPress installs no advanced-cache.php and never edits wp-config.php. Switching it off leaves your site exactly as it was, with nothing orphaned behind. It tells you why. Most cache plugins leave you guessing when nothing is cached. DietPress reports its own status, tests itself against your home page, and names the exact reason a page was skipped. WooCommerce-safe by design. Carts, checkout, my account and any visitor carrying a cart cookie always get the live site, so nobody ever sees somebody else’s basket. Diet as well as speed. Where Perfmatters focuses on disabling scripts, DietPress covers that ground and adds page caching, critical CSS, local Google Fonts and a dashboard, admin and email cleanup, in one plugin. Light on your server. No account, no external service, no telemetry, no upsell nags. Everything runs on your own hosting. WHAT THE PAGE CACHE DOES TO YOUR RESPONSE TIME Measured on a WordPress 7.0 install with GeneratePress, WooCommerce and a 76 product catalogue, PHP 8.5, taking the median of 15 requests per URL. Your own hosting will give different figures, but the shape of the result will not change. Server response time, the same pages with the page cache off and on: Home page – 52.7 ms without, 15.1 ms with, 71% faster WooCommerce shop – 45.4 ms without, 14.8 ms with, 67% faster A 110 KB article – 43.0 ms without, 15.1 ms with, 65% faster A 98 KB page – 41.0 ms without, 14.9 ms with, 64% faster A product category – 41.3 ms without, 15.1 ms with, 63% faster The interesting part is not the percentage, it is that the cached figure barely moves. Serving a stored file costs the same whether the page was cheap or expensive to build, so the saving grows with the size of your site rather than with the power of your server. The heaviest page in the test is the one that gained most. It also changes how much traffic your hosting can take at once. In the same test the server went from serving about 40 visits a second to more than 210, five times as many, on exactly the same plan. That is what keeps a small site standing up when one of your posts does well. TWO THINGS IN ONE PLUGIN 1. Performance optimizations (on by default) Automatic Critical CSS inlined in the head (optional experimental deferral of non-critical CSS) JavaScript defer parsing with smart dependency handling Image loading attributes safety net: lazy loading, decoding=async and fetchpriority for images that bypass core Automatic image dimensions for better CLS scores (including picture elements) Resource hints: preconnect and DNS prefetch for common third-party origins Theme stylesheet, critical fonts and logo preloading for a faster LCP Google Fonts display=swap Google Fonts local hosting: serve the fonts your theme uses from your own server, GDPR-friendly with a silent fallback to the Google CDN (opt-in) Selective third-party loading: WooCommerce, Contact Form 7, block library, Slider Revolution, TablePress, Smash Balloon, Formidable Forms and Everest Forms assets only load where they are used (opt-in) RSS feed optimization (cache headers and item limit) Server rules in .htaccess: browser caching with a configurable lifetime for media, for styles and scripts and for fonts, GZIP and Brotli compression, immutable cache headers, CORS for fonts and keep-alive (master switch plus per-feature toggles) Database maintenance: daily expired-transient cleanup and safe query optimizations Page cache: store each page on disk and serve it to anonymous visitors without building it again, with automatic purging, gzip precompression and a status panel that says whether it is working (opt-in, in its own tab) 2. Put WordPress on a diet (risk-based, opt-in) Light (safe for any site): emojis, RSD/WLW tags, shortlinks, self-pingbacks, comment pagination, and more Moderate (evaluate first): oEmbed, jQuery Migrate, Dashicons on the frontend, Global Styles and Duotone, remote block patterns, avatars and Gravatar, comment threading, and more Strict (site-specific): granular RSS feed control, Heartbeat API mode, post revisions and autosave, disable comments, XML sitemap, native lazy loading/fetchpriority, content types, selective loading for WooCommerce, Contact Form 7, block assets, Slider Revolution, TablePress, Smash Balloon, Formidable Forms and Everest Forms, and more Widgets: dashboard widgets (including third-party ones from Yoast, WooCommerce, Elementor, Jetpack, Wordfence, Rank Math, Gravity Forms), classic sidebar widgets, block-editor widgets and the Customizer Emails: silence the automatic emails WordPress sends on its own, grouped by area: auto-update results for core, plugins and themes (plus the new-version notice), comment moderation and new-comment notices, and new user, password and email-change notices, plus toggles for the admin email verification prompt and post-by-email. Every option is off by default, and critical notices such as a failed core update are always kept SCALE, PROFILES AND ANALYZER Savings indicator: HTTP requests removed, CSS/JS saved and active optimizations at a glance Quick profiles: Personal Blog, WooCommerce Store, Landing Page and Maximum Cleanup Site analyzer: personalized recommendations based on your active plugins and content, page cache included Import and export your whole configuration as a JSON file COMPATIBILITY AND EXTENSIBILITY The plugin includes filters for developers: dietpress_critical_css – Customize the inline critical CSS dietpress_critical_css_handles – Define which CSS handles are critical dietpress_skip_defer_script_handles – Opt scripts out of the JavaScript defer dietpress_skip_defer_style_handles – Opt stylesheets out of the CSS deferral dietpress_preconnect_hints – Customize preconnect origins dietpress_dns_prefetch_domains – Customize DNS prefetch domains dietpress_critical_fonts – Define critical fonts to preload dietpress_exclude_local_fonts – Exclude Google Fonts stylesheets from local hosting dietpress_selective_{module}_has_content – Mark a page as showing the content of a selective loading module, so its assets are kept. The module is wc, cf7, formidable, everest_forms or revslider dietpress_selective_{module}_styles / dietpress_selective_{module}_scripts – Adjust the handles removed by each module dietpress_selective_page_hides_content – Mark a page as rendering content the content scan cannot reach, so no module removes anything (this is what handles Elementor) dietpress_selective_is_wc_page – Override the WooCommerce page detection of selective loading dietpress_selective_wc_keep_cart_fragments – Keep the cart fragments script when your theme has a hand-coded mini-cart dietpress_selective_cf7_has_form – Mark pages that load a Contact Form 7 form dynamically dietpress_selective_blocks_dequeue – Override the block library dequeue decision dietpress_selective_everest_forms_dequeue_dashicons – Keep Dashicons when another plugin enqueues it directly dietpress_native_sitemap_in_use – Tell DietPress your plugin builds on the native WordPress sitemap, so the option that removes it becomes unavailable dietpress_cache_bypass – Keep the current page out of the page cache dietpress_cache_bypass_cookies – Adjust the cookie name prefixes that make a visitor uncacheable dietpress_cache_ignored_params – Adjust the query parameters that do not change the page dietpress_cache_exclude_urls – Adjust the excluded URL patterns dietpress_cache_post_urls – Adjust the URLs purged along with a post Compatible with: Well-coded themes and page builders (Divi, Elementor, Beaver Builder, Bricks Gutenberg) Cache plugins (WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, etc.). The one exception is the optional page cache module, which will not run beside another page cache and says so; everything else in DietPress works alongside them as it always has Security plugins (DietPress focuses on performance and deliberately leaves security to them; we recommend our free Vigilant) CDNs (Cloudflare, StackPath, KeyCDN, etc.) thanks to CORS and Vary headers WordPress Multisite (except the optional page cache module, which does not support it yet) HOW TO VERIFY THE OPTIMIZATIONS Cache rules: check your .htaccess for a block marked # BEGIN DietPress with immutable Cache-Control headers Logo preload: view page source and look for pointing to your logo Critical CSS: view source and look for in the head Compression: test at giftofspeed.com/gzip-test Always measure with tools like Google PageSpeed, GTMetrix or WebPageTest, and run each test at least twice to account for caching. Support Need private support or custom development? Do you need one-on-one help, priority troubleshooting, or a custom feature, integration, or tweak built specifically for your site? I offer private support and custom development. Just contact me and tell me what you need. Need help or have suggestions? Official website WordPress support forum YouTube channel Documentation and tutorials Love the plugin? Please leave us a 5-star review and help spread the word! About AyudaWP We are specialists in WordPress security, SEO, AI and performance optimization plugins. We create tools that solve real problems for WordPress site owners while maintaining the highest coding standards and accessibility requirements.