{"id":295388,"date":"2026-06-03T20:39:50","date_gmt":"2026-06-03T20:39:50","guid":{"rendered":"https:\/\/en-za.wordpress.org\/plugins\/basecloud-boost\/"},"modified":"2026-06-18T19:32:24","modified_gmt":"2026-06-18T19:32:24","slug":"basecloud-boost","status":"publish","type":"plugin","link":"https:\/\/de.wordpress.org\/plugins\/basecloud-boost\/","author":23342161,"comment_status":"closed","ping_status":"closed","template":"","meta":{"version":"1.2.1","stable_tag":"1.2.1","tested":"6.9.4","requires":"5.5","requires_php":"7.4","requires_plugins":null,"header_name":"BaseCloud Boost","header_author":"BaseCloud","header_description":"World-class page caching, asset optimization, and performance acceleration for WordPress \u2014 by BaseCloud.","assets_banners_color":"afbec6","last_updated":"2026-06-18 19:32:24","external_support_url":"","external_repository_url":"","donate_link":"","header_plugin_uri":"https:\/\/basecloud.co\/boost","header_author_uri":"https:\/\/basecloud.co","rating":0,"author_block_rating":0,"active_installs":10,"downloads":510,"num_ratings":0,"support_threads":0,"support_threads_resolved":0,"author_block_count":0,"sections":["description","installation","faq","changelog"],"tags":{"1.0.0":{"tag":"1.0.0","author":"basecloud","date":"2026-06-03 20:39:32"},"1.0.1":{"tag":"1.0.1","author":"basecloud","date":"2026-06-04 09:42:14"},"1.0.2":{"tag":"1.0.2","author":"basecloud","date":"2026-06-04 10:53:50"},"1.0.3":{"tag":"1.0.3","author":"basecloud","date":"2026-06-04 12:59:26"},"1.0.4":{"tag":"1.0.4","author":"basecloud","date":"2026-06-08 21:28:02"},"1.0.5":{"tag":"1.0.5","author":"basecloud","date":"2026-06-10 16:02:03"},"1.0.6":{"tag":"1.0.6","author":"basecloud","date":"2026-06-10 16:17:41"},"1.0.7":{"tag":"1.0.7","author":"basecloud","date":"2026-06-10 18:25:28"},"1.0.8":{"tag":"1.0.8","author":"basecloud","date":"2026-06-10 20:36:47"},"1.0.9":{"tag":"1.0.9","author":"basecloud","date":"2026-06-10 21:21:50"},"1.1.0":{"tag":"1.1.0","author":"basecloud","date":"2026-06-15 15:03:24"},"1.1.1":{"tag":"1.1.1","author":"basecloud","date":"2026-06-16 16:24:11"},"1.1.3":{"tag":"1.1.3","author":"basecloud","date":"2026-06-17 12:20:00"},"1.1.4":{"tag":"1.1.4","author":"basecloud","date":"2026-06-17 13:30:56"},"1.1.5":{"tag":"1.1.5","author":"basecloud","date":"2026-06-17 13:55:01"},"1.1.7":{"tag":"1.1.7","author":"basecloud","date":"2026-06-17 18:16:37"},"1.1.8":{"tag":"1.1.8","author":"basecloud","date":"2026-06-17 18:48:22"},"1.1.9":{"tag":"1.1.9","author":"basecloud","date":"2026-06-17 19:14:48"},"1.2.0":{"tag":"1.2.0","author":"basecloud","date":"2026-06-18 19:12:27"},"1.2.1":{"tag":"1.2.1","author":"basecloud","date":"2026-06-18 19:32:24"}},"upgrade_notice":{"1.0.3":"<p>Combine CSS is now safe for Elementor\/page-builder sites (relative font and image paths are rewritten correctly). Recommended if you want to cut the number of CSS requests.<\/p>","1.0.2":"<p>Important fix: JavaScript minification could break theme scripts and leave a loading\/preloader screen spinning so the page never rendered. Update strongly recommended.<\/p>","1.0.1":"<p>Fixes &quot;cleared cache but still see the old page&quot; (HTML is no longer over-cached by browsers) and lazy loading that could hide images\/videos. Adds automatic image compression with a bulk tool, makes pages faster, encrypts your API keys, and turns the toolbar Boost Cache button into an instant in-place clear. Recommended for all users.<\/p>","1.0.0":"<p>Initial public release. No upgrade steps required.<\/p>"},"ratings":[],"assets_icons":{"icon-128x128.png":{"filename":"icon-128x128.png","revision":3559990,"resolution":"128x128","location":"assets","locale":"","width":128,"height":128},"icon-256x256.png":{"filename":"icon-256x256.png","revision":3559990,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256}},"assets_banners":{"banner-1544x500.png":{"filename":"banner-1544x500.png","revision":3559990,"resolution":"1544x500","location":"assets","locale":"","width":1544,"height":500},"banner-772x250.png":{"filename":"banner-772x250.png","revision":3559990,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.0.0","1.0.1","1.0.2","1.0.3","1.0.4","1.0.5","1.0.6","1.0.7","1.0.8","1.0.9","1.1.0","1.1.1","1.1.3","1.1.4","1.1.5","1.1.7","1.1.8","1.1.9","1.2.0","1.2.1"],"block_files":[],"assets_screenshots":[],"screenshots":{"1":"Dashboard -- live cache statistics, feature status overview, and one-click cache clear.","2":"Page Cache settings -- configure cache lifetime, exclusions, and mobile cache separation.","3":"File Optimization -- HTML, CSS, and JS minification and combining controls.","4":"Media settings -- lazy loading, WebP\/AVIF serving, and video facade options.","5":"CDN settings -- Cloudflare and BunnyCDN API integration configuration.","6":"Database Optimizer -- one-click cleanup for revisions, transients, and orphaned data."}},"plugin_section":[],"plugin_tags":[146,144,187,247,794],"plugin_category":[52,54],"plugin_contributors":[246295],"plugin_business_model":[],"class_list":["post-295388","plugin","type-plugin","status-publish","hentry","plugin_tags-cache","plugin_tags-caching","plugin_tags-optimization","plugin_tags-performance","plugin_tags-speed","plugin_category-performance","plugin_category-security-and-spam-protection","plugin_contributors-basecloud","plugin_committers-basecloud"],"banners":{"banner":"https:\/\/ps.w.org\/basecloud-boost\/assets\/banner-772x250.png?rev=3559990","banner_2x":"https:\/\/ps.w.org\/basecloud-boost\/assets\/banner-1544x500.png?rev=3559990","banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/basecloud-boost\/assets\/icon-128x128.png?rev=3559990","icon_2x":"https:\/\/ps.w.org\/basecloud-boost\/assets\/icon-256x256.png?rev=3559990","generated":false},"screenshots":[],"raw_content":"<!--section=description-->\n<p><strong>BaseCloud Boost<\/strong> is a professional-grade WordPress performance plugin that dramatically speeds up your website through intelligent full-page caching, asset optimization, and smart cache management.<\/p>\n\n<h4>Core Features<\/h4>\n\n<p><strong>Page Cache<\/strong><\/p>\n\n<ul>\n<li>Full-page HTML caching that bypasses WordPress and PHP entirely for maximum throughput<\/li>\n<li>GZIP and Brotli compression variants stored alongside each cached page<\/li>\n<li>Smart cache invalidation on post updates, comment submissions, and taxonomy changes<\/li>\n<li>Configurable cache lifetime (default: 24 hours)<\/li>\n<li>Separate mobile device cache for responsive-aware caching<\/li>\n<li>Cache exclusion by URL pattern or cookie name<\/li>\n<\/ul>\n\n<p><strong>Asset Optimization<\/strong><\/p>\n\n<ul>\n<li>HTML, CSS, and JavaScript minification<\/li>\n<li>CSS and JS file combining to reduce HTTP requests<\/li>\n<li>JavaScript deferral for faster first paint<\/li>\n<li>Critical CSS extraction and inline injection<\/li>\n<li>Remove query strings from static asset URLs for better CDN hit rates<\/li>\n<li>Async-load non-critical Google Fonts with font-display=swap<\/li>\n<\/ul>\n\n<p><strong>Media Optimization<\/strong><\/p>\n\n<ul>\n<li>Reliable native lazy loading for images, iframes, and videos -- defers off-screen media without ever hiding it, so images always appear<\/li>\n<li>On-the-fly image compression -- generates high-quality WebP copies of your images on upload, plus a one-click Bulk Compress tool for your existing media library<\/li>\n<li>Quality-preserving compression -- originals are never altered; WebP copies are created alongside them at a tunable visually-lossless quality<\/li>\n<li>WebP and AVIF serving -- automatically serves the next-gen format when available<\/li>\n<li>Video facade for YouTube and Vimeo -- replaces iframes with click-to-play thumbnails<\/li>\n<li>preload=\"none\" applied to video tags for faster page loads<\/li>\n<\/ul>\n\n<p><strong>Cache Preloader<\/strong><\/p>\n\n<ul>\n<li>Automatic sitemap-based URL discovery<\/li>\n<li>Background batch processing to keep the cache warm<\/li>\n<li>Real-time progress tracking in the admin dashboard<\/li>\n<\/ul>\n\n<p><strong>CDN Integration<\/strong><\/p>\n\n<ul>\n<li>Generic CDN hostname rewriting for any CDN provider<\/li>\n<li>Cloudflare API cache purging -- automatically clears Cloudflare edge cache on purge<\/li>\n<li>BunnyCDN API cache purging -- mirrors local purge events to your Pull Zone<\/li>\n<\/ul>\n\n<p><strong>Database Optimization<\/strong><\/p>\n\n<ul>\n<li>Post revision cleanup<\/li>\n<li>Auto-draft and trashed post\/comment removal<\/li>\n<li>Expired transient removal<\/li>\n<li>Orphaned postmeta cleanup<\/li>\n<li>Table optimization (OPTIMIZE TABLE)<\/li>\n<\/ul>\n\n<p><strong>Security Headers<\/strong><\/p>\n\n<ul>\n<li>X-Content-Type-Options, X-Frame-Options, Referrer-Policy<\/li>\n<li>Permissions-Policy (FLoC\/Topics API opt-out)<\/li>\n<li>Strict-Transport-Security (HSTS) for HTTPS sites<\/li>\n<\/ul>\n\n<p><strong>Developer-Friendly<\/strong><\/p>\n\n<ul>\n<li>Full hook API: filter cache behaviour, modify HTML before write, extend CDN purge logic<\/li>\n<li>WP-CLI commands for cache management<\/li>\n<li>PSR-4 autoloaded class architecture<\/li>\n<\/ul>\n\n<h3>External Services<\/h3>\n\n<p>BaseCloud Boost connects to the following external services <strong>only when you explicitly configure them<\/strong> in the plugin settings. No data is sent to any third-party service by default.<\/p>\n\n<h4>Cloudflare Cache Purge API (Optional)<\/h4>\n\n<p>If you enable Cloudflare CDN integration and provide a Zone ID and API Token, the plugin calls the Cloudflare API to purge cached content whenever your local cache is cleared.<\/p>\n\n<ul>\n<li>Service: Cloudflare, Inc.<\/li>\n<li>What it is used for: Purging edge-cached pages so visitors see fresh content after a cache clear.<\/li>\n<li>When data is sent: Only when you trigger a cache purge (manually, on post save, or via plugin action).<\/li>\n<li>Data sent: List of URLs to purge and your Cloudflare Zone ID (via your API token).<\/li>\n<li>API endpoint: https:\/\/api.cloudflare.com\/client\/v4\/zones\/{zone_id}\/purge_cache<\/li>\n<li>Terms of Service: https:\/\/www.cloudflare.com\/terms\/<\/li>\n<li>Privacy Policy: https:\/\/www.cloudflare.com\/privacypolicy\/<\/li>\n<\/ul>\n\n<h4>BunnyCDN Cache Purge API (Optional)<\/h4>\n\n<p>If you enable BunnyCDN integration and provide an API Key and Pull Zone ID, the plugin calls the BunnyCDN API to purge cached content whenever your local cache is cleared.<\/p>\n\n<ul>\n<li>Service: BunnyWay d.o.o. (BunnyCDN)<\/li>\n<li>What it is used for: Purging Pull Zone edge cache so visitors receive fresh content.<\/li>\n<li>When data is sent: Only when you trigger a cache purge.<\/li>\n<li>Data sent: URLs to purge and your API key.<\/li>\n<li>API endpoints: https:\/\/api.bunny.net\/purge and https:\/\/api.bunny.net\/pullzone\/{id}\/purgeCache<\/li>\n<li>Terms of Service: https:\/\/bunny.net\/tos\/<\/li>\n<li>Privacy Policy: https:\/\/bunny.net\/privacy\/<\/li>\n<\/ul>\n\n<h4>Performance Metrics Webhook (Optional)<\/h4>\n\n<p>If you configure a webhook URL in the plugin settings, BaseCloud Boost will POST a JSON payload containing anonymous performance metrics to that URL on a daily cron schedule.<\/p>\n\n<ul>\n<li>Service: Custom endpoint configured by you.<\/li>\n<li>What it is used for: Sending performance data to an external monitoring or reporting system.<\/li>\n<li>When data is sent: Once per day via a scheduled cron event, and when you manually send a test from the admin panel.<\/li>\n<li>Data sent: Cache hit rate, cache size, bytes saved (HTML\/CSS\/JS), last purge time, plugin version, site URL, and site name. No user data or passwords are included.<\/li>\n<li>Endpoint: Your custom URL -- you are responsible for its security and privacy compliance.<\/li>\n<\/ul>\n\n<h4>Google PageSpeed Insights API (Optional)<\/h4>\n\n<p>If you enter a PageSpeed Insights API key in the Lighthouse settings, the plugin calls Google's PageSpeed Insights API to run automated Lighthouse audits for your site.<\/p>\n\n<ul>\n<li>Service: Google LLC (PageSpeed Insights)<\/li>\n<li>What it is used for: Running automated Lighthouse performance audits (Performance, Accessibility, Best Practices, SEO scores).<\/li>\n<li>When data is sent: When you manually trigger an audit from the Lighthouse settings page, or on the scheduled Lighthouse cron (if enabled).<\/li>\n<li>Data sent: Your site URL and your API key.<\/li>\n<li>API endpoint: https:\/\/www.googleapis.com\/pagespeedonline\/v5\/runPagespeed<\/li>\n<li>Terms of Service: https:\/\/developers.google.com\/terms<\/li>\n<li>Privacy Policy: https:\/\/policies.google.com\/privacy<\/li>\n<\/ul>\n\n<h4>Vimeo oEmbed API (Conditional)<\/h4>\n\n<p>If a page contains a Vimeo video facade, the plugin's frontend JavaScript fetches the video thumbnail from the Vimeo public oEmbed API. This happens in the visitor's browser, not on the server.<\/p>\n\n<ul>\n<li>Service: Vimeo, Inc.<\/li>\n<li>What it is used for: Retrieving the video thumbnail image to display in the click-to-play facade.<\/li>\n<li>When data is sent: When a page containing a Vimeo video facade is viewed by a visitor.<\/li>\n<li>Data sent: The Vimeo video ID (no user data or authentication is required).<\/li>\n<li>API endpoint: https:\/\/vimeo.com\/api\/v2\/video\/{id}.json<\/li>\n<li>Terms of Service: https:\/\/vimeo.com\/terms<\/li>\n<li>Privacy Policy: https:\/\/vimeo.com\/privacy<\/li>\n<\/ul>\n\n<h4>Google Tag Manager \/ Google Fonts Preconnect Hints (Conditional)<\/h4>\n\n<p>When the Resource Hints module is enabled, the plugin outputs <code>&lt;link rel=\"preconnect\"&gt;<\/code> and <code>&lt;link rel=\"dns-prefetch\"&gt;<\/code> hints for common third-party origins (Google Tag Manager, Google Analytics, Google Fonts, jsDelivr\/cdnjs). These are passive hints that tell the browser to pre-establish connections \u2014 no data is sent by the plugin itself.<\/p>\n\n<ul>\n<li>Service: Various (Google LLC, Cloudflare, Inc.)<\/li>\n<li>What it is used for: Reducing connection latency for third-party resources already loaded by your theme or other plugins.<\/li>\n<li>When data is sent: The browser (not the plugin) initiates the connection. No plugin data is transmitted.<\/li>\n<li>Terms of Service \/ Privacy: Governed by the respective third-party services.<\/li>\n<\/ul>\n\n<p>All remote requests originating from the plugin server-side use WordPress's built-in wp_remote_post() \/ wp_remote_get() functions and respect your server's SSL configuration.<\/p>\n\n<!--section=installation-->\n<ol>\n<li>Upload the <code>basecloud-boost<\/code> folder to the <code>\/wp-content\/plugins\/<\/code> directory.<\/li>\n<li>Activate the plugin through the 'Plugins' menu in WordPress.<\/li>\n<li>Navigate to <strong>BaseCloud Boost &gt; Dashboard<\/strong> to configure.<\/li>\n<li>Enable Page Cache and click <strong>Boost Cache<\/strong> to start caching immediately.<\/li>\n<\/ol>\n\n<!--section=faq-->\n<dl>\n<dt id=\"does%20basecloud%20boost%20work%20with%20woocommerce%3F\"><h3>Does BaseCloud Boost work with WooCommerce?<\/h3><\/dt>\n<dd><p>Yes. Cart, checkout, and My Account pages are automatically excluded from caching. Active WooCommerce cart session cookies bypass the cache transparently.<\/p><\/dd>\n<dt id=\"is%20it%20compatible%20with%20wordpress%20multisite%3F\"><h3>Is it compatible with WordPress Multisite?<\/h3><\/dt>\n<dd><p>Yes. BaseCloud Boost supports WordPress Multisite with per-site cache directories.<\/p><\/dd>\n<dt id=\"can%20i%20use%20it%20with%20cloudflare%20or%20bunnycdn%3F\"><h3>Can I use it with Cloudflare or BunnyCDN?<\/h3><\/dt>\n<dd><p>Yes. BaseCloud Boost includes Cloudflare and BunnyCDN API integrations. When you purge the local page cache, the plugin automatically purges the corresponding edge cache too.<\/p><\/dd>\n<dt id=\"will%20it%20conflict%20with%20other%20caching%20plugins%3F\"><h3>Will it conflict with other caching plugins?<\/h3><\/dt>\n<dd><p>Running multiple full-page caching plugins simultaneously is not recommended and can produce unexpected results. BaseCloud Boost detects and warns you about other active caching plugins on the Dashboard.<\/p><\/dd>\n<dt id=\"what%20if%20my%20site%20breaks%20after%20activating%20the%20plugin%3F\"><h3>What if my site breaks after activating the plugin?<\/h3><\/dt>\n<dd><p>Deactivate the plugin from the Plugins screen. This automatically removes the advanced-cache.php drop-in and disables WP_CACHE, restoring your site to its previous state.<\/p><\/dd>\n<dt id=\"does%20basecloud%20boost%20modify%20wp-config.php%3F\"><h3>Does BaseCloud Boost modify wp-config.php?<\/h3><\/dt>\n<dd><p>Yes. On activation it sets <code>define( 'WP_CACHE', true )<\/code> in <code>wp-config.php<\/code> so WordPress loads the <code>advanced-cache.php<\/code> drop-in. On deactivation this line is removed. The change is minimal and clearly labelled so it is easy to identify.<\/p><\/dd>\n\n<\/dl>\n\n<!--section=changelog-->\n<h4>1.2.1<\/h4>\n\n<p><strong>Defer\/Delay JS: keep the whole Elementor chain together so headers and menus work<\/strong><\/p>\n\n<ul>\n<li><strong>Fixed Elementor navigation\/headers breaking under Defer or Delay JS.<\/strong> The 1.2.0 default exclusions kept Elementor's script files but not the inline config they depend on (<code>elementorFrontendConfig<\/code>, <code>ElementorProFrontendConfig<\/code>), the <code>js-cookie<\/code> (<code>Cookies<\/code>) dependency, or the bundled libraries under <code>assets\/lib\/<\/code> (SmartMenus, sticky header, Swiper). With those delayed, the Elementor scripts ran before their config\/libraries existed and threw \"not defined\" errors, so menus, sticky headers and sliders never initialised. The built-in exclusion list now covers the entire Elementor + Elementor Pro footprint (scripts, inline configs, and <code>lib\/<\/code> helpers) plus <code>js-cookie<\/code>, so they load together and initialise correctly \u2014 while analytics, tag managers, chat, forms and WooCommerce scripts are still deferred\/delayed. Still overridable via <code>BCBOOST_default_js_excludes<\/code>.<\/li>\n<\/ul>\n\n<h4>1.2.0<\/h4>\n\n<p><strong>More robust CSS minification + safer Async CSS and JS optimization on page-builder sites<\/strong><\/p>\n\n<ul>\n<li><strong>Fixed a CSS minification bug that could delete large blocks of CSS and break styling (e.g. Gravity Forms).<\/strong> When a CSS comment contained an apostrophe or quote \u2014 for example <code>\/* inherit Elementor's font *\/<\/code> \u2014 the minifier mistook that quote for the start of a CSS string and swallowed everything up to the next quote, often hundreds of lines away. The affected CSS (including custom form styling) was then dropped, making elements fall back to their default appearance. Comments and strings are now parsed together in a single pass, so a quote inside a comment can never start a string, and a comment sequence inside a string is never stripped. This also replaces an older comment-stripping pattern that could be slow on very large stylesheets.<\/li>\n<li><strong>Async CSS now activates only when Critical CSS is present.<\/strong> Loading CSS asynchronously without inlined Critical CSS defers every stylesheet \u2014 including each page-builder template's per-element rules \u2014 past the first paint, so builder pages (Elementor, etc.) could render with default styling until the stylesheet arrived: unstyled headings, missing section background overlays, mis-sized widgets. Async CSS is now a safe no-op until Critical CSS is filled in, and the setting explains this. CSS stays render-blocking (correct layout) in the meantime.<\/li>\n<li><strong>JavaScript Defer\/Delay no longer breaks page-builder menus out of the box.<\/strong> Boost now ships a built-in exclusion list for the jQuery + Elementor + Elementor Pro + SmartMenus initialization chain, so navigation menus and dropdowns bind correctly while everything else (analytics, tag managers, chat, forms) is still deferred\/delayed for a lower main-thread cost. The list is filterable via <code>BCBOOST_default_js_excludes<\/code>.<\/li>\n<\/ul>\n\n<h4>1.1.9<\/h4>\n\n<p><strong>Dashboard: honest cache status when a reverse proxy is in front<\/strong><\/p>\n\n<ul>\n<li><strong>The dashboard now explains the hit rate when a reverse proxy (Varnish) is active.<\/strong> On stacks like Cloudways, a reverse proxy caches Boost's optimized pages and serves most visits without ever reaching PHP \u2014 so Boost's hit counter (which only sees PHP requests) reads 0% even though every page is cached and served fast. When Varnish purging is enabled (or a proxy is detected), the dashboard now shows a short note clarifying that pages are cached at the proxy and the hit rate reflects only direct PHP requests, so the 0% is no longer mistaken for a caching failure.<\/li>\n<\/ul>\n\n<h4>1.1.8<\/h4>\n\n<p><strong>Combine CSS now also folds stylesheets printed in the <code>&lt;body&gt;<\/code> (Elementor\/Astra\/Gravity Forms)<\/strong><\/p>\n\n<ul>\n<li><strong>Page-builder stylesheets printed late in the <code>&lt;body&gt;<\/code> are now combined too.<\/strong> Combine CSS only folded stylesheets in the <code>&lt;head&gt;<\/code>, but Elementor, Astra and Gravity Forms print widget\/form CSS in the body, where it stayed as many separate render-blocking requests \u2014 adding network latency and, because that CSS styles above-the-fold elements (the nav menu, a contact form), causing layout shifts when it loaded after the content had already painted. Boost now folds those same-origin body stylesheets into a single bundle placed ahead of the content they style. It is intentionally kept render-blocking (not async, unlike the head bundle) precisely because it styles above-the-fold elements \u2014 so the menu and form are styled before first paint instead of flashing\/reflowing. Fewer requests and steadier layout (CLS) on page-builder sites.<\/li>\n<\/ul>\n\n<h4>1.1.7<\/h4>\n\n<p><strong>Cloudways (managed Varnish) support + reverse-proxy bypass cookie<\/strong><\/p>\n\n<ul>\n<li><strong>New Varnish \"Reverse Proxy Type\" setting.<\/strong> The existing Varnish integration assumed a self-managed Varnish whose VCL you control (PURGE for a URL, BAN for the whole site). Managed hosts like <strong>Cloudways<\/strong> don't let you edit the VCL and use a different purge protocol, so those purges silently failed and the reverse proxy kept serving stale HTML. Choose <strong>Cloudways<\/strong> under <em>Advanced \u2192 Purge Varnish<\/em> and Boost now purges the way Cloudways expects: <code>URLPURGE<\/code> for a single URL and a <code>PURGE<\/code> to <code>\/?purgeall<\/code> for the whole zone, sent to the proxy front-end (defaults to <code>127.0.0.1:8080<\/code>). Purge requests to internal proxy ports are correctly sent over HTTP.<\/li>\n<li><strong>New <code>bcboost-nocache<\/code> bypass cookie.<\/strong> Boost now sets this cookie for visitors who must always get a fresh page (logged in, or with an active WooCommerce cart) and clears it once they're anonymous again \u2014 emitting the cookie only on that transition so normal anonymous pages stay cacheable. Add <code>bcboost-nocache<\/code> to your reverse proxy's excluded-cookies list (on Cloudways: <em>Application \u2192 Varnish Settings \u2192 Excluded Cookies<\/em>) so the proxy bypasses its cache for those visitors. Boost's own page cache honours the same cookie.<\/li>\n<\/ul>\n\n<h4>1.1.6<\/h4>\n\n<p><strong>Fixed: Delay\/Defer JS broke Elementor menus &amp; widgets even after scripts loaded (no more excluding the whole Elementor stack)<\/strong><\/p>\n\n<ul>\n<li><strong>The order-safe loader now holds jQuery's <code>ready<\/code> until every delayed script has run.<\/strong> Libraries like Elementor self-initialise on jQuery ready the instant their script executes. Because the loader runs delayed scripts one at a time, Elementor would initialise <em>before<\/em> later scripts (Elementor Pro's element handlers, SmartMenus, etc.) had registered \u2014 so dropdown menus and some widgets never bound their behaviour and appeared dead, even once everything had loaded. Boost now pauses jQuery ready the moment jQuery is defined and releases it only after the whole queue drains, so all components initialise together exactly as on a normal page load. This removes the need to exclude jQuery\/Elementor from Delay JS to keep menus working \u2014 keeping the full Total-Blocking-Time benefit on Elementor sites.<\/li>\n<\/ul>\n\n<h4>1.1.5<\/h4>\n\n<p><strong>Fixed: Delay JS made the first click on menus\/buttons do nothing (dropdowns appeared broken)<\/strong><\/p>\n\n<ul>\n<li><strong>The first click after a page loads now works with Delay JS enabled.<\/strong> Delay JS holds scripts until the first user interaction, but that very interaction \u2014 usually a click on a navigation dropdown, accordion or button \u2014 was being \"spent\" loading the scripts and never reached the handler that had just loaded, so the element looked dead until you clicked a second time (most visibly: Elementor\/SmartMenus dropdown menus wouldn't open). The loader now captures that first click, suppresses its default action so nothing navigates prematurely, and replays it on the original element once the scripts have loaded and bound their handlers \u2014 so a single click behaves exactly as it would without Delay JS. Normal links still navigate as expected.<\/li>\n<\/ul>\n\n<h4>1.1.4<\/h4>\n\n<p><strong>Fixed: Critical CSS was corrupted on save (broke hero\/background images)<\/strong><\/p>\n\n<ul>\n<li><strong>Saving settings no longer escapes quotes in your Critical CSS.<\/strong> WordPress adds slashes to submitted form data, and the settings handler stored the Critical CSS without removing them, so <code>background-image: url(\"\u2026\")<\/code> was saved as <code>url(\\\"\u2026\\\")<\/code>. That is invalid CSS, so any rule relying on a quoted value \u2014 most visibly above-the-fold section\/hero background images \u2014 silently failed to render once Critical CSS was enabled. Boost now unslashes the submitted settings before saving (the standard WordPress behaviour), preserving quotes and valid CSS escape sequences. If you enabled Critical CSS on 1.1.3 and a background went missing, re-save your settings on 1.1.4 and clear the cache.<\/li>\n<\/ul>\n\n<h4>1.1.3<\/h4>\n\n<p><strong>Faster LCP on page-builder sites: CSS background images now go through WebP + CDN, and the hero image is preloaded<\/strong><\/p>\n\n<ul>\n<li><strong>CSS <code>background-image<\/code> files are now served as WebP\/AVIF and from your CDN.<\/strong> Boost already rewrote <code>&lt;img&gt;<\/code> tags to modern formats and to the CDN host, but section\/hero backgrounds set in CSS (the bulk of Elementor, Divi, Bricks, etc. layouts) were missed \u2014 they stayed as full-size origin JPG\/PNGs baked into the combined stylesheet. Boost now rewrites those <code>url()<\/code> targets to the WebP\/AVIF copy when one exists and to your CDN hostname, exactly as it does for images in the markup. On hero-heavy pages this can cut hundreds of KB off the single most important image. (Requires Combine CSS; clear the Boost cache after updating so the bundle is rebuilt.)<\/li>\n<li><strong>The hero \/ LCP background image is now preloaded with <code>fetchpriority=\"high\"<\/code>.<\/strong> A section background lives inside the CSS, so the browser cannot discover it until the stylesheet has downloaded and parsed \u2014 a major Largest-Contentful-Paint delay on page-builder sites. Boost now detects the first full-width section that carries a background image and adds a high-priority <code>&lt;link rel=\"preload\" as=\"image\"&gt;<\/code> for it in the <code>&lt;head&gt;<\/code>, so it loads in parallel with the CSS instead of after it. Fully automatic, falls back to no preload when no hero is found, and can be turned off with the <em>Preload LCP image<\/em> option.<\/li>\n<\/ul>\n\n<h4>1.1.2<\/h4>\n\n<p><strong>Font display + safer Critical CSS<\/strong><\/p>\n\n<ul>\n<li><strong><code>font-display: swap<\/code> is now applied to fonts inside your stylesheets.<\/strong> Boost already added swap to Google Fonts links and inline <code>@font-face<\/code> blocks, but icon-font packs (Themify, Linearicons, ElementsKit, Font Awesome, \u2026) declare their <code>@font-face<\/code> inside external stylesheets, where it was untouched. Boost now injects <code>font-display: swap<\/code> into those <code>@font-face<\/code> rules while minifying\/combining CSS, so text and icons stay visible during font load (the \"Font display\" PageSpeed item). Governed by the existing <em>Optimize Google Fonts<\/em> toggle.<\/li>\n<li><strong>Critical CSS is no longer corrupted on save.<\/strong> The Critical CSS field was sanitised with a text filter that strips every <code>%xx<\/code> URL-encoded sequence, which silently broke <code>url()<\/code> values (such as inline SVG data URIs) in pasted critical CSS. It now uses CSS-safe sanitisation that removes HTML tags but preserves valid CSS.<\/li>\n<\/ul>\n\n<h4>1.1.1<\/h4>\n\n<p><strong>Combine CSS &amp; Async CSS now work when a CDN is enabled (major mobile fix)<\/strong><\/p>\n\n<ul>\n<li><strong>Fixed: Combine CSS and Async CSS did nothing when BunnyCDN URL rewriting was on.<\/strong> The CDN rewriter swaps every asset URL to your pull-zone hostname (e.g. <code>yourzone.b-cdn.net<\/code>) before Boost folds the page's stylesheets. Boost only recognised origin URLs, so it treated every CDN-hosted stylesheet as \"external\" and skipped it \u2014 leaving the whole page's CSS render-blocking even with Combine CSS + Async CSS (or the <em>Optimize for PageSpeed<\/em> preset) enabled. On a CSS-heavy Elementor site that left dozens of stylesheets blocking first paint and capped the mobile PageSpeed score. Boost now maps CDN asset URLs back to their local files, so all same-origin stylesheets are combined into one bundle and that bundle is delivered asynchronously \u2014 and the bundle itself is served from the CDN. This is the single biggest mobile First-Contentful-Paint \/ Largest-Contentful-Paint fix for sites running BunnyCDN. After updating, clear the Boost cache (and purge your BunnyCDN pull zone) so pages are rebuilt.<\/li>\n<\/ul>\n\n<p><strong>WooCommerce: fixed \"ghost products\" added to the cart + safer real-time cart on cached pages<\/strong><\/p>\n\n<ul>\n<li><strong>Fixed: products silently appearing in the cart (\"ghost products\").<\/strong> Boost's link prefetch (on hover\/tap) and the Speculation Rules engine were speculatively loading WooCommerce \"Add to cart\" links \u2014 which are ordinary <code>?add-to-cart=ID<\/code> URLs marked <code>rel=\"nofollow\"<\/code>. Loading one actually runs the action, so simply hovering or tapping near a product button could add it to the cart. Both engines now skip every <code>rel=\"nofollow\"<\/code> link and any URL carrying a cart\/AJAX\/nonce action parameter (<code>add-to-cart<\/code>, <code>remove_item<\/code>, <code>undo_item<\/code>, <code>wc-ajax<\/code>, <code>add_to_wishlist<\/code>, <code>_wpnonce<\/code>), as well as the cart\/checkout\/my-account pages. Add-to-cart, remove and quantity changes now only happen when the shopper actually clicks.<\/li>\n<li><strong>Real-time cart keeps working with Delay JS.<\/strong> The cart-fragments \/ add-to-cart scripts were already kept out of Defer\/Delay so the mini-cart updates on cached pages, but jQuery \u2014 which they depend on \u2014 was still being delayed, so on a WooCommerce store those scripts could run before jQuery was ready. When WooCommerce is active Boost now also keeps jQuery running immediately, so the mini-cart, add-to-cart and quantity updates stay live. (On non-WooCommerce sites jQuery is still delayed for the Total-Blocking-Time win.)<\/li>\n<\/ul>\n\n<h4>1.1.0<\/h4>\n\n<p><strong>Order-safe JavaScript engine \u2014 fixes broken sliders\/menus and unlocks a big PageSpeed gain<\/strong><\/p>\n\n<ul>\n<li><strong>Defer &amp; Delay JS no longer break themes (major fix).<\/strong> Previously Boost only added <code>defer<\/code> (or the delay marker) to <em>enqueued<\/em> script files, but left the inline initializers a theme or page-builder hard-codes in the page running during parsing \u2014 before the libraries they call had loaded. On sliders, popups and many WPBakery\/ThemeForest themes that meant <code>\u2026 is not a function<\/code> errors and broken layouts. Boost now treats inline and external scripts as one ordered unit: every eligible script is run through a single loader that executes them strictly in their original order, waiting for each external file to finish before the next. Inline initializers (RevSlider, WPBakery, theme setup) and a script's localized config keep working exactly as the theme intended.<\/li>\n<li><strong>Delay JS is now safe and on by default.<\/strong> Because order is preserved, holding all JavaScript (including jQuery) until the first interaction \u2014 with a 5-second fallback for passive visitors \u2014 no longer breaks pages. This is the single biggest Total-Blocking-Time \/ PageSpeed lever and is now part of the recommended setup. After the delayed scripts run, Boost re-fires the page's <code>DOMContentLoaded<\/code> and <code>load<\/code> events so everything still initializes. Use <em>Delay JS Exclusions<\/em> to keep specific scripts (analytics, chat, etc.) running immediately, or add <code>data-no-delay<\/code> \/ <code>data-cfasync=\"false\"<\/code> to a tag to opt it out.<\/li>\n<li><strong>\"Optimize for PageSpeed\" now includes Async CSS.<\/strong> The one-click preset (Tools \u2192 <em>Optimize for PageSpeed<\/em>) now also enables Async CSS alongside Combine CSS so the combined stylesheet stops blocking first paint. Test your homepage after applying \u2014 themes that don't inline their above-the-fold CSS may briefly flash unstyled.<\/li>\n<li><strong>Async CSS now covers single-stylesheet sites too.<\/strong> When Combine CSS has only one local stylesheet to work with, that sheet is now loaded asynchronously (with a <code>&lt;noscript&gt;<\/code> fallback) instead of staying render-blocking.<\/li>\n<\/ul>\n\n<h4>1.0.9<\/h4>\n\n<p><strong>Asynchronous CSS delivery \u2014 the mobile First Contentful Paint fix<\/strong><\/p>\n\n<ul>\n<li><strong>Combine CSS can now load asynchronously.<\/strong> Combining stylesheets reduces the number of requests, but the single bundle was still render-blocking \u2014 on a CSS-heavy page-builder site that one large file can hold up first paint on a slow mobile connection. With <em>Async CSS (Lazy CSS)<\/em> enabled alongside <em>Combine CSS<\/em>, the combined bundle now loads without blocking the first paint (<code>media=\"print\"<\/code> + onload swap, with a <code>&lt;noscript&gt;<\/code> fallback). The theme's inline above-the-fold CSS paints immediately and the bundle applies as soon as it arrives \u2014 and because the stylesheet is no longer hogging the connection, the LCP image can start downloading sooner too. This is the single biggest lever for mobile First Contentful Paint \/ Largest Contentful Paint on heavy Elementor\/Divi sites. Enable both under File Optimization. (When Combine CSS is off, Async CSS continues to load each stylesheet asynchronously as before.)<\/li>\n<\/ul>\n\n<h4>1.0.8<\/h4>\n\n<p><strong>Faster Largest Contentful Paint + one-click PageSpeed setup<\/strong><\/p>\n\n<ul>\n<li><strong>Your hero image no longer waits for JavaScript (big LCP win).<\/strong> Many themes and plugins ship their own JavaScript \"lazy loader\" that replaces every image \u2014 including your above-the-fold hero \u2014 with a tiny placeholder and only loads the real picture once scripts run. On a slow mobile connection that can push your Largest Contentful Paint many seconds later, and the browser's <code>fetchpriority=\"high\"<\/code> hint is wasted on the placeholder. Boost now detects the LCP\/above-the-fold image, restores its real source immediately (from the usual <code>data-src<\/code> \/ <code>data-orig-src<\/code> \/ <code>data-srcset<\/code> attributes), removes the lazy-load hooks so it can't be hidden again, and preloads it \u2014 using the responsive <code>imagesrcset<\/code>\/<code>imagesizes<\/code> set when one is present so the browser fetches the exact size it will display. The hero starts downloading right away instead of after the page's JavaScript has executed.<\/li>\n<li><strong>Combine CSS now catches page-builder stylesheets (major fix).<\/strong> Combine CSS previously merged files at the point WordPress builds the page, which runs <em>before<\/em> Elementor, Divi and similar builders register most of their stylesheets \u2014 so on those sites it folded only a handful of files and left dozens of render-blocking requests behind (and, worse, served the rest un-minified). Combine now runs on the finished HTML, so it reliably collapses <em>every<\/em> eligible same-origin stylesheet \u2014 including the late builder\/plugin ones \u2014 into a single minified bundle, preserving cascade order. External stylesheets (Google Fonts, CDNs) and print\/media-query sheets are left alone. This is the difference between \"combine did almost nothing\" and \"70 requests become 1\" on a typical Elementor site.<\/li>\n<li><strong>\"Optimize for PageSpeed\" one-click setup (new).<\/strong> Tools \u2192 <em>Optimize for PageSpeed<\/em> applies our recommended high-impact configuration in a single click \u2014 page cache, CSS &amp; JS minify and combine, JavaScript defer plus delay-until-interaction, image lazy-load and WebP, GZIP and browser caching \u2014 then clears the cache so pages rebuild optimised. It's the fastest way to get a strong Core Web Vitals baseline without learning every individual toggle. Your CDN, Cloudflare, webhook and other credentials are left untouched, and you can fine-tune anything afterwards.<\/li>\n<\/ul>\n\n<h4>1.0.7<\/h4>\n\n<p><strong>Two features that silently didn't work now do<\/strong><\/p>\n\n<ul>\n<li><strong>Cache preloading now actually runs.<\/strong> The preloader queued URLs and showed progress, but its background worker was never registered, so the crawl never started and progress sat at 0%. The batch-processing cron and its schedule are now booted on every request (including WP-Cron), so \"Preload Cache\" properly warms the site in the background.<\/li>\n<li><strong>Multisite: deleting a network site now clears its cache.<\/strong> Cache is stored by URL, but deletion looked for a non-existent per-blog-ID folder, so a removed site's cached pages were left behind. Deletion now purges the cached pages for the site's actual domain and path.<\/li>\n<\/ul>\n\n<h4>1.0.6<\/h4>\n\n<p><strong>Critical CSS fix + automatic database cleanup<\/strong><\/p>\n\n<ul>\n<li><strong>Critical CSS toggle now works.<\/strong> Pasting CSS into the Critical CSS box had no effect unless you also knew it was applied regardless of the on\/off switch, while a second (per-URL) code path read a store that was never populated and did nothing. Now the <em>Enable Critical CSS<\/em> toggle properly controls whether your above-the-fold CSS is inlined, and the dead per-URL path has been removed.<\/li>\n<li><strong>Scheduled database cleanup (new).<\/strong> Database \u2192 Automatic Cleanup can now run a safe, unattended cleanup on a daily or weekly schedule \u2014 post revisions, auto-drafts, spam comments, expired transients and orphaned post meta. Destructive\/heavy operations (emptying trash, OPTIMIZE TABLE) are deliberately left to the manual buttons. Off by default.<\/li>\n<\/ul>\n\n<h4>1.0.5<\/h4>\n\n<p><strong>PageSpeed \/ Core Web Vitals improvements<\/strong><\/p>\n\n<ul>\n<li><strong>Self-host Google Fonts (new).<\/strong> Boost can now download the Google Fonts stylesheet and its woff2 files to your server once and inline the localised <code>@font-face<\/code> CSS directly in the page. This removes the render-blocking request to <code>fonts.googleapis.com<\/code> and the extra DNS\/TLS handshake to <code>fonts.gstatic.com<\/code> \u2014 both common PageSpeed Insights flags \u2014 and serves fonts from your own origin with <code>font-display: swap<\/code>. The download happens on a single cache-priming request and is reused for every visitor; the now-redundant Google Fonts preconnect hints are dropped automatically. Enable under Media \u2192 Google Fonts \u2192 <em>Self-Host Google Fonts<\/em>.<\/li>\n<li><strong>LCP image control (new).<\/strong> A new \u201cNever Lazy-Load These Images\u201d list (Media \u2192 LCP \/ Above-the-Fold Images) lets you protect your hero\/banner from lazy loading by URL fragment or CSS class, for the cases the automatic detection can\u2019t infer.<\/li>\n<li><strong>Safer Delay JavaScript.<\/strong> Delayed scripts now honour the <code>data-no-delay<\/code> attribute and the widely-used <code>data-cfasync=\"false\"<\/code> opt-out, so scripts that must run immediately keep working.<\/li>\n<\/ul>\n\n<h4>1.0.4<\/h4>\n\n<p><strong>Geolocation \/ currency pricing now survives caching, plus WooCommerce and stability fixes<\/strong><\/p>\n\n<ul>\n<li><strong>Per-country &amp; per-cookie cache variants.<\/strong> The page cache used to store one frozen HTML file per URL, so a geolocation\/currency switcher would \"stick\" on whichever currency the first visitor saw \u2014 e.g. a South African visitor being shown USD. Boost now stores a separate cached copy per visitor country and per currency cookie, so geo pricing keeps working while pages are still served from cache. Enable <em>Page Cache \u2192 Geolocation &amp; Currency \u2192 Separate Cache per Country<\/em>; common currency-switcher cookies (Aelia, WOOCS, WPML, etc.) are handled automatically, and a new <code>BCBOOST_resolve_country<\/code> filter lets a theme supply the country when there's no GeoIP header. Variant responses are marked <code>private<\/code> so a CDN can't collapse them back into one.<\/li>\n<li><strong>WooCommerce cache exclusions now actually apply.<\/strong> The <code>BCBOOST_cache_reject_uri<\/code> \/ <code>BCBOOST_cache_reject_cookies<\/code> \/ <code>BCBOOST_do_generate_cache<\/code> developer filters were documented but never executed, so WooCommerce's own cart\/checkout\/account exclusions silently did nothing. They are now enforced on the cache-write path.<\/li>\n<li><strong>WooCommerce mini-cart fix.<\/strong> Cart-fragments and add-to-cart scripts are no longer deferred\/delayed, so the mini-cart and cart count keep updating on cached pages.<\/li>\n<li><strong>Mobile cache actually works now.<\/strong> The separate-mobile-cache option served mobile visitors but never wrote a mobile cache file, so mobile pages were re-rendered on every request. Mobile variants are now written and served correctly. Because most themes are responsive (identical HTML for both), separate mobile cache now defaults to <strong>off<\/strong> on new installs for a higher cache hit rate \u2014 turn it on only if you run a separate mobile theme or AMP. Existing sites keep their current setting.<\/li>\n<li><strong>Targeted purges now clear every variant.<\/strong> Purging a URL removes all of its cached variants (desktop\/mobile\/country\/cookie, plus their GZIP\/Brotli copies) instead of a fixed handful of filenames.<\/li>\n<li><strong>HTML minifier can no longer blank a page.<\/strong> On very large pages a single regex hitting PHP's <code>pcre.backtrack_limit<\/code> could return null and wipe the whole document. Every step now falls back to the original HTML, so a failed optimisation simply skips itself instead of breaking the page.<\/li>\n<li><strong>LCP fix \u2014 stop lazy-loading the hero image.<\/strong> The lazy loader treated the first <code>&lt;img&gt;<\/code> in the DOM (usually the header logo) as the LCP, gave it <code>fetchpriority=\"high\"<\/code>, and then lazy-loaded the <em>real<\/em> hero image even when the theme had already marked it <code>fetchpriority=\"high\"<\/code> and preloaded it. It now respects an existing priority\/eager image as the LCP, never lazy-loads it, doesn't steal priority for the logo, and won't emit a duplicate preload. Also fixed malformed <code>&lt;img \u2026 \/ fetchpriority&gt;<\/code> output from appending attributes after a self-closing slash.<\/li>\n<li><strong>Google Fonts hints no longer corrupted.<\/strong> The optimizer was appending <code>?display=swap<\/code> to <code>preconnect<\/code>\/<code>dns-prefetch<\/code> hints (e.g. <code>href=\"https:\/\/fonts.googleapis.com?display=swap\"<\/code>). It now only rewrites the actual font stylesheet link.<\/li>\n<li><strong>Corrected nginx serving rules.<\/strong> The recommended nginx snippet omitted the scheme directory (so it never matched the real cache files) and mishandled pre-compressed files (raw Brotli\/GZIP served without <code>Content-Encoding<\/code>). The new snippet is variant-aware (mobile, currency\/geo cookies, per-country), skips the cache safely for logged-in\/cart\/query-string requests, and uses <code>gzip_static<\/code>\/<code>brotli_static<\/code> for correct compressed serving.<\/li>\n<\/ul>\n\n<p><strong>Server cache &amp; object cache compatibility (no clashes)<\/strong><\/p>\n\n<ul>\n<li><strong>Varnish \/ reverse-proxy support.<\/strong> When enabled (Advanced \u2192 Server Cache &amp; Compatibility), every BaseCloud Boost purge now also clears Varnish over HTTP \u2014 a <code>PURGE<\/code> for single URLs and a <code>BAN<\/code> for site-wide clears \u2014 so the proxy never serves stale HTML. Supports separate Varnish server addresses (preserving the site host in the <code>Host<\/code> header) and ships a ready-to-paste, ACL-restricted VCL snippet.<\/li>\n<li><strong>Object Cache Pro \/ Redis \/ Memcached: guaranteed coexistence.<\/strong> BaseCloud Boost is a page cache and runs alongside a persistent object cache. It never installs a competing <code>object-cache.php<\/code> drop-in and never calls <code>wp_cache_flush()<\/code> (which would wipe the object cache on every page purge), and it registers its own group as non-persistent. The Advanced screen now detects and reports the active object cache backend.<\/li>\n<li><strong>Hosting auto-detection now actually runs.<\/strong> The host detector (WP Engine, Kinsta, SiteGround, LiteSpeed, Cloudways, Pantheon, and more) was defined but never booted, so its host-specific tweaks did nothing. It now runs: on hosts that provide their own full-page cache (WP Engine, Kinsta, Pagely, Pantheon, WP.com VIP) BaseCloud Boost\u2019s file cache disables itself to avoid double-caching, and host\/LiteSpeed\/SiteGround caches are purged alongside ours.<\/li>\n<\/ul>\n\n<h4>1.0.3<\/h4>\n\n<p><strong>Combine CSS is now safe \u2014 big win for Elementor and other builder sites<\/strong><\/p>\n\n<ul>\n<li>Combining CSS now rewrites relative <code>url()<\/code> and <code>@import<\/code> paths to absolute URLs. Previously, combining stylesheets into a single bundle could break web fonts (e.g. Font Awesome icons turning into boxes) and CSS background images, because their relative paths resolved against the bundle's location. This made Combine CSS unsafe on page-builder sites with many stylesheets \u2014 exactly where it helps most. It now works correctly, letting heavy Elementor\/ElementsKit pages collapse dozens of render-blocking CSS requests into a handful.<\/li>\n<li>Per-file CSS minification also rewrites relative paths now, so individually minified stylesheets never lose their fonts or images either.<\/li>\n<li>Combining no longer folds <code>media=\"print\"<\/code> (or other non-screen) stylesheets into the main bundle, so print styles can't leak onto the screen.<\/li>\n<\/ul>\n\n<h4>1.0.2<\/h4>\n\n<p><strong>Critical Bug Fix<\/strong><\/p>\n\n<ul>\n<li>Fixed a JavaScript minification bug that could break a site's scripts \u2014 most visibly leaving a theme \"preloader\"\/loading screen spinning forever so the page never appeared. The minifier preserved quoted strings before stripping comments, so an apostrophe inside a code comment (e.g. \"don't\", \"we're\") was mistaken for the start of a string and swallowed real code, producing invalid JavaScript. The minifier is now a proper single-pass lexer that correctly understands strings, template literals, regular expressions, and comments, and never breaks Automatic Semicolon Insertion. Minify JavaScript is safe to leave enabled again.<\/li>\n<\/ul>\n\n<h4>1.0.1<\/h4>\n\n<p><strong>Performance<\/strong><\/p>\n\n<ul>\n<li>Major front-end speed improvements: cached the modern-image (WebP\/AVIF) format lookups so pages no longer hit the disk for every image on every request.<\/li>\n<li>Removed a redundant full-page processing pass in the lazy loader \u2014 less PHP work per uncached request and faster Time to First Byte.<\/li>\n<\/ul>\n\n<p><strong>Bug Fixes<\/strong><\/p>\n\n<ul>\n<li>Fixed \"I cleared the cache but still see the old page.\" HTML pages were being sent to browsers with a long cache lifetime, so browsers (and shared caches) kept serving their own copy for hours and a server-side purge could not reach them. HTML is now always revalidated by the browser (a cheap 304 when unchanged), while static assets keep their long-term caching \u2014 so content edits appear immediately after a purge. Logged-in admins\/editors now always see live, uncached content.<\/li>\n<li>The drop-in and .htaccess rules now self-heal on update: updating the plugin no longer leaves a stale <code>advanced-cache.php<\/code> behind, so fixes take effect without a manual deactivate\/reactivate.<\/li>\n<li>Fixed lazy loading hiding images, iframes, and videos. The previous JavaScript placeholder approach could leave media permanently invisible if a script failed to run. Lazy loading now uses the browser's reliable native <code>loading=\"lazy\"<\/code> and never hides content.<\/li>\n<li>The \"Boost Cache\" button in the admin toolbar no longer reloads you back to the dashboard. It now clears the cache instantly via AJAX with a rocket animation and keeps you on the current page.<\/li>\n<\/ul>\n\n<p><strong>New Features<\/strong><\/p>\n\n<ul>\n<li>Image compression: BaseCloud Boost now generates high-quality WebP copies of JPEG\/PNG uploads automatically. A new Bulk Compress tool on the Media screen compresses your entire existing media library in the background, with live progress. Originals are kept untouched, so quality and your media library are never broken.<\/li>\n<\/ul>\n\n<p><strong>Security<\/strong><\/p>\n\n<ul>\n<li>API keys and secrets (Cloudflare API token, BunnyCDN API key, webhook secrets, PageSpeed Insights API key) are now encrypted at rest in the database using authenticated encryption.<\/li>\n<li>Secret fields are now masked in the admin UI and are never printed into page source.<\/li>\n<li>PageSpeed Insights audits now run through a secure server-side proxy, so your API key is no longer exposed to the browser.<\/li>\n<\/ul>\n\n<h4>1.0.0<\/h4>\n\n<ul>\n<li>Initial public release.<\/li>\n<li>Full-page HTML caching with GZIP and Brotli compression variants.<\/li>\n<li>HTML, CSS, and JavaScript minification and combining.<\/li>\n<li>JavaScript defer and delay strategies.<\/li>\n<li>Critical CSS extraction and inline injection.<\/li>\n<li>Native lazy loading for images, iframes, and videos.<\/li>\n<li>WebP and AVIF next-gen image serving.<\/li>\n<li>YouTube and Vimeo video facade (click-to-play thumbnails).<\/li>\n<li>Sitemap-based cache preloader with real-time progress tracking.<\/li>\n<li>Cloudflare API cache purge integration.<\/li>\n<li>BunnyCDN API cache purge integration and URL rewriting.<\/li>\n<li>Generic CDN hostname rewriting.<\/li>\n<li>Database optimizer (revisions, transients, orphaned postmeta).<\/li>\n<li>Security headers module (HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy).<\/li>\n<li>Heartbeat API throttle to reduce admin-area server load.<\/li>\n<li>Performance metrics webhook for external monitoring.<\/li>\n<li>WP-CLI commands for cache management.<\/li>\n<li>WordPress Multisite support.<\/li>\n<li>WooCommerce cart and checkout cache exclusion.<\/li>\n<li>Google Fonts optimization with font-display=swap.<\/li>\n<\/ul>","raw_excerpt":"World-class page caching, asset optimization, and performance acceleration for WordPress \u2014 by BaseCloud.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/de.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/295388","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/de.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/de.wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/de.wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=295388"}],"author":[{"embeddable":true,"href":"https:\/\/de.wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/basecloud"}],"wp:attachment":[{"href":"https:\/\/de.wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=295388"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/de.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=295388"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/de.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=295388"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/de.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=295388"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/de.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=295388"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/de.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=295388"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}