Put WordPress on a diet.

Every time somebody visits your site, WordPress queries the database, runs your plugins, builds the page from your theme and sends it. For a visitor who is not logged in the result is the same every time until you change something, so doing all of that again is wasted work. A page cache does it once and stores the finished HTML on disk, and the next visitor gets that file. You need one unless your hosting already provides it, and DietPress detects the usual managed hosts and tells you when that is the case.

With another page cache plugin, no, and DietPress will not let you: two page caches on the same site serve each other's stale HTML and the result is very hard to diagnose. If W3 Total Cache, WP Super Cache, LiteSpeed Cache, WP Fastest Cache, Cache Enabler, Surge, WP Rocket, SiteGround Speed Optimizer or any of about thirty similar plugins is active, the toggle stays disabled and names the one in the way. With a hosting cache (Kinsta, WP Engine, SiteGround, SpinupWP, Cloudways and others) it is possible but rarely a good idea, because purging one does not purge the other, so DietPress asks for an explicit confirmation first. If your hosting cache is one DietPress recognises, the browser caching options also warn you when the HTML lifetime you pick would stop it from storing your pages. On LiteSpeed servers we recommend LiteSpeed Cache instead, since caching at server level is faster than anything PHP can do. Object cache plugins such as Redis Object Cache are a different thing and are fine.

The page cache normally serves its copy from PHP, once WordPress has loaded its plugins. That skips the database and the theme, but not the start of WordPress itself, and on a site with many plugins that start is most of what a cached page still costs. The accelerator removes that too: on Apache and LiteSpeed the server hands out the stored copy by itself, without starting PHP or WordPress at all, and on nginx you get the same rules to paste into your server configuration. It only stays on once a real test on your home page confirms the server is serving it correctly; if it isn't, the rules come out again and the Cache tab says why.

Partly, and it's worth knowing how. The server answers before any PHP runs, so whatever a security plugin does in PHP (blocking an IP address, rate limiting, a bot filter) never sees those visits. The rules a security plugin writes to your .htaccess still apply, so a bot blocked there still gets its 403. If your site depends on the PHP side of a security plugin for anonymous visitors, leave the accelerator off; the page cache alone still answers earlier than most security plugins run their checks.

Yes. WooCommerce marks the cart, the checkout and my account as uncacheable itself, and DietPress obeys that mark rather than guessing from the URL, so it keeps working if you move or rename those pages. On top of that, any visitor carrying a cart or session cookie is served the live site everywhere, so a mini cart in the header never shows somebody else's basket, and a store in coming soon mode is not cached at all. Logged in users are never cached either, and there is no option to change that.

Open the Cache tab and press «Test the cache now»: the site asks itself for its own home page and tells you whether it was served from disk, rebuilt or skipped. For one particular page, turn WP_DEBUG on and read the last line of its HTML source, where DietPress writes the exact reason. The three usual causes are a plugin that sets a cookie on every visit (a consent banner, some analytics scripts), a page that is genuinely personal, and a cache directory the server cannot write to, which the status panel reports on its own.

On a local WordPress 7.0 install with GeneratePress, WooCommerce and a 76 product catalogue, on PHP 8.5. Each URL was requested twice to warm up and then fifteen times, and the median is what we publish; the throughput figure is 100 requests with ten in flight at a time. The only thing that changed between the two columns was the page cache switch. You can repeat it with any tool that reports time to first byte, for example curl -o /dev/null -w "%{time_starttransfer}\n" https://yoursite.com/ a dozen times with the cache off and a dozen with it on, comparing medians rather than single readings, and doing it while logged out because your own visits are never cached.

If that's what you want, yes. The performance optimizations are on by default, so activating the plugin is enough. The settings page exists for when you want to fine-tune them or start the diet, which is entirely opt-in.

The performance optimizations are designed to be safe and have been tested across many sites for years. The diet switches only act when you turn them on, and each one describes what could be affected. If something looks off, flip the switch back and WordPress returns to its default behavior.

Left out on purpose. Security belongs in a security plugin, where those protections are properly implemented and maintained. We recommend our free Vigilant. If you migrate with any security toggle active, DietPress shows a one-time notice listing them.

Yes. Critical CSS, the JavaScript defer, the image attributes, local fonts, selective loading and every diet switch work alongside WP Rocket, LiteSpeed Cache, W3 Total Cache and the rest, exactly as they always have, and DietPress sends CORS and Vary headers for full CDN compatibility. Only its own page cache steps aside.

When you enable it (Light tab, Performance section), DietPress detects the Google Fonts stylesheets your theme loads, downloads them once to your uploads folder and serves everything from your own server, so visitors no longer connect to Google, which is faster and GDPR-friendly. If any download fails, fonts silently keep loading from the Google CDN. Local copies refresh when you switch themes and disappear when you turn the option off.

Each module only removes assets where its target content isn't detected, but unusual setups exist: a hand-coded mini-cart, a form injected via AJAX, a classic theme reusing block styles everywhere. Turn that specific toggle off, or use the dietpress_selective_* escape filters to keep exactly what your site needs.

If a theme or plugin doesn't enqueue its scripts properly, deferring JavaScript can affect it. Turn that option off or use the dietpress_skip_defer_script_handles filter. If you get a 500 error, remove the block starting with # BEGIN DietPress from your .htaccess or disable the server rules option.

Yes. There are more than twenty dietpress_* filters, plus the page cache ones (dietpress_cache_bypass, dietpress_cache_exclude_urls and three more), the dietpress_cache_purge_all action and the dietpress_purge_page_cache() function. The main ones: dietpress_critical_css, dietpress_critical_css_handles, dietpress_skip_defer_script_handles, dietpress_skip_defer_style_handles, dietpress_preconnect_hints, dietpress_dns_prefetch_domains and dietpress_critical_fonts, plus specific hooks for local font hosting (dietpress_exclude_local_fonts) and selective loading (dietpress_selective_*). The old ayudawp_wpotweaks_* filters still work through a compatibility bridge.

For the cache, look at the X-DietPress-Cache header in your browser's network tab, or at the footprint comment at the end of a stored page. For the rest, check your .htaccess for the # BEGIN DietPress block, view your page source and look for the core-diet-critical-css style and the logo preload, and test compression at giftofspeed.com/gzip-test. Then measure with PageSpeed, GTmetrix or WebPageTest, running each test at least twice to account for caching.