DietPress

01 / SOURCE DETAILS

About this tool

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. Served by your web server, not by PHP. With the accelerator on, Apache or nginx hands out the stored copy by itself, without starting PHP or WordPress, and so can LiteSpeed when the test passes there. It is tested on your home page before it stays on, and cached pages still expire on time. 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 any page you choose the way an anonymous visitor gets it, 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.1 install with Astra, WooCommerce and 29 active plugins, PHP 8.5 and Apache, 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 for the same pages without the page cache, with the page cache served by PHP, and with the accelerator: Home page – 112.3 ms without, 13.7 ms with the page cache, 3.0 ms with the accelerator A blog post – 105.5 ms without, 14.9 ms with the page cache, 3.0 ms with the accelerator WooCommerce shop – 117.2 ms without, 14.9 ms with the page cache, 3.8 ms with the accelerator The interesting part is not the percentage, it is that the cached figures barely move. 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 accelerator also takes away the start of WordPress itself, which is most of what a page served from the cache by PHP still costs. It also changes how much traffic your hosting can take at once. In the same test the home page went from about 17 visits a second without the page cache to 159 with it and 732 with the accelerator, more than forty times as many , on exactly the same machine. 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, a cleanup schedule you choose and a status panel that says whether it is working, plus an accelerator that lets Apache or nginx serve those pages without starting PHP (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_request – Keep a request away from the page cache altogether, before anything is read from disk dietpress_cache_bypass_accept – Adjust the media types that keep a request 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 (DietP

02 / SOURCE DETAILS

Getting started

Go to your WP Dashboard > Plugins > Add New and search for ‘DietPress’, or upload the wpo-tweaks folder to /wp-content/plugins/ . Activate the plugin through the ‘Plugins’ menu in WordPress. Open the DietPress menu to review the settings. Performance optimizations are already on; the diet options are off until you enable them.

03 / SOURCE DETAILS

Frequently asked questions

What does a page cache actually do, and do I need one? 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. What is the accelerator, and should I switch it on? The page cache normally serves its stored copy from PHP, as soon as WordPress has loaded the 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 start too. On Apache, DietPress writes a block of rules to your .htaccess, marked Page Cache by DietPress, and the server hands out the stored copy by itself, without starting PHP or WordPress at all. That is the fastest a page can be served. On nginx, which does not read .htaccess, the Cache tab gives you the same rules to paste into your server configuration. Phones are served by the server too. With the separate mobile cache on, each address has a copy built for a phone and one built for a desktop, and the rules hand out the right one with the same test WordPress uses, so what PageSpeed measures on mobile is the served copy. Those pages go out with a Vary header, so a CDN or proxy in front keeps the two apart. Switch it on once the page cache is working, if your site runs on Apache (with mod_rewrite and mod_headers, which nearly every hosting has) or nginx, which is where it has been measured. LiteSpeed reads the same rules as Apache, and there the test is what tells whether they work. It is tested on your home page the moment you switch it on: if the server does not serve that page by itself, with its headers and for the right scheme, the rules are taken out again and the tab says why. Everything the rules leave alone, a logged in visitor, a URL with a query string, a forced reload, is still served or rebuilt by PHP, exactly as without it. Stored pages still expire on time, even on a site so well cached that WordPress hardly runs its scheduled tasks: each copy is linked under the name of every hour it is still valid in, and the server only looks for the current one. The one exception is the night the clock of the server goes back, when a copy can be served for up to an hour longer. Those extra names are also why a backup that includes wp-content/cache can grow: exclude that folder, as most backup plugins already do, because a backup that does not keep hard links stores each name as a file. Does the accelerator bypass my security plugin? Partly, and it is worth knowing how. The server answers before any PHP runs, so whatever a security plugin does in PHP does not see those visits: blocking an IP address, rate limiting, a bot filter or an under attack challenge. The rules a security plugin writes to your .htaccess, or to the server configuration, still apply: a bot that those rules block still gets its 403 on a page the server serves, while a client that is only blocked in PHP gets the cached page. The same goes for a site closed at server level, by IP address or with a password: on Apache the stored copies are only reachable through the address of their page, which those rules protect. On nginx, see the next question. Pages are never served this way to a logged in visitor or to one with a cart. If your site relies on the PHP side of a security plugin for anonymous visitors, leave the accelerator off. Keep in mind that the page cache answers very early without it too, before many security plugins run their checks. How do I use the accelerator on nginx? nginx does not read .htaccess, so DietPress cannot write the rules for you. With the page cache on, the Cache tab shows them in four parts, each with a comment that says where it goes in the configuration of your site: two inside the server block, one at the start of the location that handles your pages, and one in the location that passes PHP files to PHP-FPM. Paste them, check the configuration with nginx -t, reload nginx and then switch the accelerator on, which tests them on your home page before it stays on. The rules also close the cache folder, which nginx would otherwise let anyone read by its address. One thing to check before pasting: access rules inside your location / block (allow, deny, auth_basic or auth_request) do not reach the pages served from the cache, because nginx sends the request on before it looks at them. Move them up to the server block, or repeat them inside the location of part 2, as its comment says. If you later change an exclusion, the cookies that keep visitors out, the separate mobile cache or how long browsers keep pages, the tab says the rules changed: paste them again and reload nginx. On a managed hosting where you cannot edit the nginx configuration, leave the accelerator off; the page cache keeps working through PHP. How do I check that the accelerator is working? Open a page in a private window and look at its response headers in the developer tools of your browser: X-DietPress-Cache: HIT-STATIC means the server served it without PHP, HIT means PHP served it from the cache, and MISS means it was built. The first visit to a page after it changes is always a MISS. “Test the cache now” in the Cache tab does the same check for you on the home page. It switches the accelerator off if the server fails that page where the accelerator serves it (with an error, with a copy missing its headers, or with something other than the page DietPress stored) while WordPress still builds it fine. When the accelerator is switched on but cannot run, the test names the reason, and if the server is still answering from the cache by itself, it takes away the names the server finds the stored pages under. How were the speed figures in the description measured, and can I repeat them? On a local WordPress 7.1 install with Astra, WooCommerce and 29 active plugins, on PHP 8.5 and Apache. Each URL was requested twice to warm up and then fifteen times straight to the web server, and the median was taken; the visits per second come from 300 requests with ten in flight at a time, with the security plugin of the site told not to rate limit them. The only things that changed between the three columns were the page cache and accelerator switches, 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. What is critical CSS and why does it matter? 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. What does deferring JavaScript do? 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. Why should I host Google Fonts on my own server? 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. What is selective loading? 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 Ever

Explore related topics