DietPress

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. The next visitor gets that file, skipping the database, the theme and most of the loading time. It is normally the single biggest speed gain a WordPress site can get, and it is also what keeps a small hosting plan standing up when a post does well on social media. You need one unless your hosting already provides it. DietPress detects the usual managed hosts and tells you when that is the case.

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 was taken; the parallel figures are 100 requests with ten in flight at a time. The only thing that changed between the two columns was the page cache switch, on the same content, in the same session. You can repeat it on your own site with any tool that reports time to first byte. From a terminal, curl -o /dev/null -w "%{time_starttransfer}\n" https://yoursite.com/ a dozen times with the cache off, then a dozen with it on, and compare the medians rather than any single reading. Do it while logged out, because your own visits are never cached. Two honest caveats. A local install has no network latency, so the absolute milliseconds are lower than you will see in production, where the saving is usually larger rather than smaller. And these numbers say nothing about a Lighthouse score: that measures mostly what the browser does with your theme and your scripts after the page arrives, which is a different problem from how fast your server answers.

A browser will not paint anything until it has downloaded every stylesheet in the page. Those files are render-blocking: your visitor stares at a blank screen while they arrive. Critical CSS is the small subset of rules needed to draw what fits on the screen at first sight. DietPress writes it straight into the page, so the browser can paint immediately and load the rest of the styles afterwards. It is the usual fix for the "eliminate render-blocking resources" warning in PageSpeed Insights, and it improves Largest Contentful Paint, one of the Core Web Vitals Google measures.

By default a script tag stops the browser: it downloads the file, runs it, and only then carries on reading your page. A theme with half a dozen scripts in the head can hold the first paint for a second or more. Deferring tells the browser to keep building the page and run the scripts once it has finished. Nothing is removed and nothing loads later than it should, it just stops blocking. DietPress handles the dependency order for you and lets you exclude any script that misbehaves, from the settings or with a filter.

Two reasons. Speed: a font from fonts.gstatic.com needs a fresh DNS lookup, TCP connection and TLS handshake to a domain the browser has never contacted, and browser cache partitioning means the visitor gets no benefit from having downloaded that font on another site. Privacy: serving them from Google transfers your visitor's IP address to Google, which German and other European courts have ruled a GDPR violation. DietPress downloads the fonts your theme uses to your own uploads folder and rewrites the stylesheets to point there. If anything fails it quietly falls back to Google, so a font never goes missing.

Plugins tend to load their CSS and JavaScript on every page of your site, whether or not the page uses them. A contact form plugin loads its scripts on every blog post; a slider plugin loads its libraries on pages with no slider; WooCommerce loads its cart on your About page. DietPress detects which pages actually use each one and removes the rest, for WooCommerce, Contact Form 7, the block library, Slider Revolution, TablePress, Smash Balloon, Formidable Forms and Everest Forms. Pages built with a builder such as Elementor keep everything, because their content is not readable from the database and guessing there is how things break.

They cache different things for different people. The page cache stores your HTML on your server, so the next visitor is served it without rebuilding the page. Browser caching tells each visitor's own browser to keep your images, styles, scripts and fonts on their machine, so their second visit downloads almost nothing. You want both, and they do not overlap. DietPress lets you set how long each family of files is kept: media, styles and scripts, and fonts, each on its own, because the right answer is different for each.

It decides how long a visitor's browser may reuse the page itself, as opposed to its images and styles. Zero, "Always revalidate", is not the same as sending nothing at all. With no answer at all the browser invents a lifetime of its own, normally about a tenth of the age of the document, which on an old page can be hours and is entirely out of your hands. With "Always revalidate" the browser asks every time, and the usual answer is a 304 Not Modified of a few hundred bytes, so the page is not downloaded again either: you get almost all of the saving and none of the staleness. Raise it only for a site that genuinely almost never changes, and be aware of the trade: an edit then takes that long to reach anyone who has already visited, because their browser will not even ask. This one is sent as an HTTP header rather than an .htaccess rule, so it works on nginx too.

Risk, not importance. Light is safe on any site: things nobody misses, like the emoji script or the Windows Live Writer tag. Moderate deserves a look first, because a plugin or theme might use it, oEmbed or jQuery Migrate for example. Strict depends on what your site actually does: disabling comments, feeds or a whole content type is only right if you really do not use them. Every option says what it does and what might break, and the Scale tab analyses your site and recommends only what applies to you, so you never have to guess.

They are the three measurements Google uses to judge how a page feels: how quickly the main content appears (LCP), how quickly the page responds to a click (INP) and how much things jump around while loading (CLS). DietPress works on all three. The page cache and preloading cut the time to the first byte and to the largest element; deferring JavaScript and trimming what loads leaves the main thread free to answer clicks; and adding width and height to images that lack them stops the layout from shifting as they arrive.

Yes, if you want it to be. The performance optimizations are on by default, so you can just activate and go. The difference is that now you can fine-tune everything and, optionally, put WordPress on a diet by disabling features you do not use.

The performance optimizations are designed to be safe and are tested across many sites. The diet options only change something when you explicitly enable each toggle, and every option has a description of what might break. If something fails, turn the toggle off; deactivating the plugin restores default WordPress behavior.

When you enable it (Light tab, Performance section), DietPress detects the Google Fonts stylesheets your theme enqueues, downloads the stylesheet and its font files once, stores them in your uploads folder, and serves everything from your own server. Visitors no longer connect to Google (faster fonts and GDPR-friendly, since no visitor data is sent to a third party). If any download fails, the fonts silently keep loading from the Google CDN. The local copies are refreshed when you switch themes and removed when you disable the option or deactivate the plugin. Fonts hardcoded by a theme outside the standard WordPress enqueue system are left untouched.

Each selective loading module only removes assets where its target content is not detected, but unusual setups exist: a hand-coded header mini-cart, a form injected via AJAX, a slider printed by the theme, or a classic theme that reuses block styles everywhere. Turn the specific toggle off, or use the escape filters (dietpress_selective_{module}_has_content, dietpress_selective_page_hides_content, dietpress_selective_wc_keep_cart_fragments, dietpress_selective_cf7_has_form, dietpress_selective_blocks_dequeue) to keep exactly what your site needs. Pages built with Elementor, and any request an Elementor Theme Builder template applies to, are left alone on purpose: their content lives in the database, out of reach of the content scan.

No. Both plugins already have a conditional loading mode of their own, off by default in the case they cover, and those two modules simply turn it on for visitors. The plugin itself then loads its stylesheet when a table or a feed is rendered, so nothing can end up unstyled. The Formidable Forms module does dequeue, but it puts the plugin own footer fallback back in play for the same reason.

It turns the "Include libraries globally" setting of Slider Revolution off for each visit, without saving anything and without touching your configuration. From there Slider Revolution decides on its own, exactly as if you had turned that setting off in its Global Settings: it loads its libraries in preview mode, when one of its shortcodes is in the content, when its widget is active, and on any page you listed in its own "List of pages to include RevSlider libraries". DietPress only adds the cases its check misses, such as a shortcode inside a text widget or an archive page. If you already turned that setting off yourself, the module does nothing at all and your page list stays in charge. One thing to know: with the global loading off, the add_revslider() PHP function that some themes use to print a slider from a template refuses to render and shows a notice instead. That is how Slider Revolution behaves on its own, and the remedy is the one it documents: add those pages to its list.

Because it cannot do what it says right now, and saying so is better than letting you switch on something inert. Two things can happen. An option is unavailable when it would contradict another one or break another plugin: "Disable WordPress XML sitemap" while a plugin builds its own sitemap on top of the native one, or "Disable native lazy loading" and "Disable fetchpriority attribute" while "Enhance image loading attributes" is on and already sets those attributes itself. And an option simply says it has no effect when another option already covers it: the granular RSS feed toggles while "Disable ALL RSS feeds" is on, or the .htaccess sub-options while the master switch is off. Those ones stay usable, so you can set them up before turning the master switch on. Whatever you had saved is kept. An option that cannot apply is not switched off behind your back: it stays stored and starts working again as soon as the thing blocking it changes.

Yes. DietPress works alongside caching plugins and includes CORS and Vary headers for full CDN compatibility.

If a plugin or theme does not enqueue scripts correctly, the JavaScript defer may affect it; you can turn that option off or use the dietpress_skip_defer_script_handles filter. If you get a 500 error, edit your .htaccess and remove the block that starts with # BEGIN DietPress (or # BEGIN Zero Config Performance if you updated from 2.x and the rules have not been rewritten yet), or disable the ".htaccess server rules" option.

Open DietPress and go to the Cache tab, then 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 entirely. If you need the exact reason for one particular page, turn WP_DEBUG on and read the last line of that page's HTML source: DietPress writes the reason there, for example that the response set a cookie or that a plugin declared the page uncacheable. 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 (cart, checkout, my account, a password protected post), and a cache directory the server cannot write to. The status panel reports the third one on its own.

Publishing, editing, deleting or renaming a post purges it and everything that lists it, and approving a comment purges the post it belongs to. Changing the theme, the menus, the widgets, the permalinks or the front page settings empties the whole cache, and so does activating or updating any plugin. If a change made outside WordPress (straight in the database, or by an importer) is not showing, use the purge button on the Page Cache screen. And check with a private window first: DietPress asks browsers not to keep the HTML, but an aggressive browser cache, a CDN or a hosting cache in front of the site are outside its reach.

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 WooCommerce cart or session cookie is served the live site everywhere, so a mini cart in the header never shows somebody else's basket. A store in "coming soon" mode is not cached at all.

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 or any of about thirty similar plugins is active, the toggle stays disabled and says which one. Object cache plugins such as Redis Object Cache are a different thing and are fine. With a hosting cache (Kinsta, WP Engine, SpinupWP, Cloudways and others) it is possible but rarely a good idea, because purging one does not purge the other. DietPress detects the usual ones and asks for an explicit confirmation before letting you enable it. On LiteSpeed servers we recommend the LiteSpeed Cache plugin instead: caching at server level is faster than anything PHP can do.

Never, and there is no option to change that. The same goes for anyone with a cart, an unlocked password protected post or a comment awaiting moderation.

Yes. See the filters listed in the description (the dietpress_* hooks). The page cache adds dietpress_cache_bypass, dietpress_cache_bypass_cookies, dietpress_cache_ignored_params, dietpress_cache_exclude_urls and dietpress_cache_post_urls, the dietpress_cache_purge_all action and the dietpress_purge_page_cache( $url ) function. Defining DIETPRESS_DISABLE_CACHE as true switches the engine off without deactivating anything.