Description
EDZNET Super Cache is a complete, all-in-one caching plugin for WordPress. Install it, activate it, and every optimization is turned on automatically — no settings to fiddle with, no cache to “warm up”. A few minutes after activation your pages start being served from a lightning-fast disk cache.
Everything enabled by default:
- Page caching — full-page disk cache served by a real
advanced-cache.phpdrop-in, so cached pages are delivered before WordPress even boots. Includes HTTP 304 support for returning visitors. - Mobile-aware cache — separate cache for phone and tablet visitors (optional).
- Lazy loading — images and iframes only load when they scroll into view.
- HTML minification — conservative, script/style-safe minification.
- Defer JavaScript — render-blocking scripts are deferred safely, skipping ads, analytics and recaptcha.
- Disable emoji scripts — removes the WordPress emoji bloat.
- Gzip compression — Apache
.htaccessrules written automatically. - Browser caching —
Expiresheaders for static assets. - Auto-purge — cache is cleared whenever you publish a post, approve a comment, change your theme or update a plugin. No stale content, ever.
- Admin bar — a “Purge EDZNET Cache” button right in the toolbar.
Works on every host. On Apache the plugin writes its own .htaccess rules. On Nginx and LiteSpeed the drop-in serves cached pages without a single rewrite rule — an optional snippet adds static-asset caching and gzip.
Built by a host. EDZNET Super Cache is developed by EDZNET and ships pre-configured on EDZNET hosting. It stays free forever; consider hosting your site with us or becoming a funder to support development.
Source Code
This plugin is distributed as complete, human-readable source. Every PHP, JavaScript and CSS file shipped in the plugin ZIP is the original source file — nothing is minified, compiled, obfuscated, transpiled or bundled, and there is no build step, package manager or build tool of any kind involved in producing a release. What you download is what was written.
The runtime JavaScript files are shipped as their original unminified source: js/lazy-load.js is loaded by the plugin’s HTML optimizer when lazy loading is enabled, and js/admin.js (with css/admin.css) is enqueued only on the plugin’s settings page. HTML minification, script deferral and the lazy-load script injection all operate on the cached page HTML, which is the standard behaviour for a page-caching plugin.
Third-Party Libraries
js/lazy-load.js— derived from the WP Fastest Cache plugin by Emre Vona (GPLv2). Upstream: https://wordpress.org/plugins/wp-fastest-cache/. The plugin’s main file carries the same header credit. Shipped unmodified, in full and unminified. Reuse under GPLv2 is permitted; see the plugin license.
No External Services
This plugin does not contact any external service. Page caching, lazy loading, HTML minification, Gzip and browser caching all run entirely on your own server. The “Preload cache” tool only fetches your own site’s public URLs via wp_safe_remote_get(), and no data about your site, its users or its visitors is transmitted anywhere.
Installation
- Upload the
edznet-super-cachefolder to/wp-content/plugins/. - Activate the plugin through the Plugins screen in WordPress.
- That’s it. Caching starts immediately.
Manual setup (only if your server blocks automatic setup)
The plugin tries to write advanced-cache.php into wp-content/ and enable WP_CACHE in wp-config.php. If your file permissions prevent this, you will see a notice in the admin — make wp-content and wp-config.php writable and save the settings page again.
FAQ
-
Does this work on Nginx?
-
Yes. Cached pages are served by the
advanced-cache.phpdrop-in before WordPress loads, so no rewrite rules are needed. The plugin also shows an optional Nginx snippet for static-asset caching and gzip on its settings page. -
Is my BitNinja WAF compatible?
-
Yes. The plugin serves plain HTML with standard
Last-ModifiedandX-EDZNET-Cacheheaders, which pass through WAFs and CDNs without issue. -
What about logged-in users and commenters?
-
Logged-in users and recent commenters always see fresh pages, so comments, the admin bar and WooCommerce carts are never cached stale.
-
Will cached pages go stale?
-
No. The cache is automatically purged when you publish or trash a post, approve a comment, switch themes, update a plugin or customize the site.
-
Are there settings I should change?
-
No. Everything is on by default. The settings page only exists for fine-tuning (for example turning off lazy loading for a specific layout).
-
How do I clear the cache manually?
-
Use the “Purge EDZNET Cache” button in the admin toolbar, or the Clear cache button on the plugin’s settings page.
-
Is it compatible with Elementor and Divi?
-
Yes. Elementor and Divi both render the final page as server-side HTML, which the plugin caches as-is. Builder previews are never cached: the Elementor editor (
?elementor-preview=...), Divi Visual Builder (?et_fb=1) and the customizer all carry non-tracking query strings, so those requests skip the cache entirely. Saving a post in either builder automatically purges that page’s cache. -
I changed global builder settings but the page looks stale.
-
Global settings saved outside the post editor (Elementor Site Settings, Divi Theme Options, or a “clear Elementor cache” rebuild) don’t trigger WordPress’ save hooks, so they don’t auto-purge. Click “Purge EDZNET Cache” in the admin toolbar after changing site-wide builder styles. If a Divi module shows per-visitor data (e.g. dynamic content that varies by user), add that page’s URL to the excludes list on the settings page.
Reviews
There are no reviews for this plugin.
Contributors & Developers
“EDZNET Super Cache” is open source software. The following people have contributed to this plugin.
Contributors
Translate “EDZNET Super Cache” into your language.
Interested in development?
Browse the code, check out the SVN repository, or subscribe to the development log by RSS.
Changelog
1.0.3
- Fix: saving any post emptied the entire cache — including drafts, menu items, WooCommerce orders, Contact Form 7 / Flamingo entries and oEmbed cache entries, some of which are created by ordinary visitor traffic. The cache is now cleared only when published content changes (published, updated, unpublished or trashed), for public post types plus layout types such as site-editor templates, reusable blocks, Elementor/Divi library layouts and Contact Form 7 forms. Saving a menu also clears the cache.
- Fix: the per-page purge used when a comment is approved never matched a cached page, and purging the home page deleted every cached page. Each purge now removes only that page’s cached file.
- Fix: pages with non-ASCII or percent-encoded URLs (for example
/café/) were cached under the wrong key, so they never served from cache and could overwrite another page’s cache entry. Cache keys are now decoded the same way when writing and serving. - Fix: the Nginx snippet never appeared on the settings page on Nginx servers.
- Fix: pages were written to the cache before other plugins’ output rewrites had run (for example EDZNET WP HTTPS converting
http://URLs), so returning visitors could be served the un-rewritten page. The cache now starts its output buffer first, oninit, so it always stores the final page. - Hardening: the drop-in and cache writer now refuse request paths containing control characters.
- New: refreshed settings page with a status overview (cache state, size, server, Clear cache / Preload), descriptions for every setting and clearer notices after clearing or preloading.
- Tweak: the Nginx snippet’s click-to-select moved from an inline
onclickattribute into the enqueuedjs/admin.js.
1.0.2
- Fix: after logging out, visitors could still see the admin bar — a page rendered for a logged-in user could be saved to the cache and shown to everyone. Logged-in users are now always excluded (the “Skip cache for logged-in users” setting was removed), pages containing the admin bar are never cached, and the cache is cleared once on update.
- Fix: visitors with a post password or a WooCommerce cart/session cookie are no longer served shared cached pages.
- Fix: the advanced-cache.php drop-in was being rewritten on every page load.
- Fix: “Wpfcll is not defined” errors — the lazy-load script is now placed at the top of the page head, before any lazy image can fire its onload.
- Fix: Defer JavaScript broke Elementor, jQuery UI, Contact Form 7 and other plugins (“jQuery is not defined”, “wp is not defined”). Scripts are now only deferred when no inline or blocking script follows them, so dependencies always load first.
- Fix: HTML minify / lazy load could rewrite the inside of a script when two script tags were directly adjacent.
1.0.1
- Fix: settings menu and plugin “Settings” link disappeared after disabling caching — the admin UI is now always available, so caching can be re-enabled from the settings page without deactivating the plugin.
- Fix: reactivating the plugin no longer re-enables caching (drop-in / WP_CACHE) when it was switched off from the settings page.
1.0.0
- Initial release. Full-page disk cache with drop-in, mobile-aware caching, lazy loading, HTML minification, defer JavaScript, emoji removal, gzip, browser caching and automatic purge.