Title: BaseCloud Boost
Author: BaseCloud
Published: 3. Juni 2026
Last modified: 18. Juni 2026
---
Plugins suchen
# BaseCloud Boost
Von [BaseCloud](https://profiles.wordpress.org/basecloud/)
[Herunterladen](https://downloads.wordpress.org/plugin/basecloud-boost.1.2.1.zip)
* [Details](https://de.wordpress.org/plugins/basecloud-boost/#description)
* [Rezensionen](https://de.wordpress.org/plugins/basecloud-boost/#reviews)
* [Installation](https://de.wordpress.org/plugins/basecloud-boost/#installation)
* [Entwicklung](https://de.wordpress.org/plugins/basecloud-boost/#developers)
[Support](https://wordpress.org/support/plugin/basecloud-boost/)
## Beschreibung
**BaseCloud Boost** is a professional-grade WordPress performance plugin that dramatically
speeds up your website through intelligent full-page caching, asset optimization,
and smart cache management.
#### Core Features
**Page Cache**
* Full-page HTML caching that bypasses WordPress and PHP entirely for maximum throughput
* GZIP and Brotli compression variants stored alongside each cached page
* Smart cache invalidation on post updates, comment submissions, and taxonomy changes
* Configurable cache lifetime (default: 24 hours)
* Separate mobile device cache for responsive-aware caching
* Cache exclusion by URL pattern or cookie name
**Asset Optimization**
* HTML, CSS, and JavaScript minification
* CSS and JS file combining to reduce HTTP requests
* JavaScript deferral for faster first paint
* Critical CSS extraction and inline injection
* Remove query strings from static asset URLs for better CDN hit rates
* Async-load non-critical Google Fonts with font-display=swap
**Media Optimization**
* Reliable native lazy loading for images, iframes, and videos — defers off-screen
media without ever hiding it, so images always appear
* 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
* Quality-preserving compression — originals are never altered; WebP copies are
created alongside them at a tunable visually-lossless quality
* WebP and AVIF serving — automatically serves the next-gen format when available
* Video facade for YouTube and Vimeo — replaces iframes with click-to-play thumbnails
* preload=“none“ applied to video tags for faster page loads
**Cache Preloader**
* Automatic sitemap-based URL discovery
* Background batch processing to keep the cache warm
* Real-time progress tracking in the admin dashboard
**CDN Integration**
* Generic CDN hostname rewriting for any CDN provider
* Cloudflare API cache purging — automatically clears Cloudflare edge cache on
purge
* BunnyCDN API cache purging — mirrors local purge events to your Pull Zone
**Database Optimization**
* Post revision cleanup
* Auto-draft and trashed post/comment removal
* Expired transient removal
* Orphaned postmeta cleanup
* Table optimization (OPTIMIZE TABLE)
**Security Headers**
* X-Content-Type-Options, X-Frame-Options, Referrer-Policy
* Permissions-Policy (FLoC/Topics API opt-out)
* Strict-Transport-Security (HSTS) for HTTPS sites
**Developer-Friendly**
* Full hook API: filter cache behaviour, modify HTML before write, extend CDN purge
logic
* WP-CLI commands for cache management
* PSR-4 autoloaded class architecture
### External Services
BaseCloud Boost connects to the following external services **only when you explicitly
configure them** in the plugin settings. No data is sent to any third-party service
by default.
#### Cloudflare Cache Purge API (Optional)
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.
* Service: Cloudflare, Inc.
* What it is used for: Purging edge-cached pages so visitors see fresh content
after a cache clear.
* When data is sent: Only when you trigger a cache purge (manually, on post save,
or via plugin action).
* Data sent: List of URLs to purge and your Cloudflare Zone ID (via your API token).
* API endpoint: https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache
* Terms of Service: https://www.cloudflare.com/terms/
* Privacy Policy: https://www.cloudflare.com/privacypolicy/
#### BunnyCDN Cache Purge API (Optional)
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.
* Service: BunnyWay d.o.o. (BunnyCDN)
* What it is used for: Purging Pull Zone edge cache so visitors receive fresh content.
* When data is sent: Only when you trigger a cache purge.
* Data sent: URLs to purge and your API key.
* API endpoints: https://api.bunny.net/purge and https://api.bunny.net/pullzone/{
id}/purgeCache
* Terms of Service: https://bunny.net/tos/
* Privacy Policy: https://bunny.net/privacy/
#### Performance Metrics Webhook (Optional)
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.
* Service: Custom endpoint configured by you.
* What it is used for: Sending performance data to an external monitoring or reporting
system.
* When data is sent: Once per day via a scheduled cron event, and when you manually
send a test from the admin panel.
* 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.
* Endpoint: Your custom URL — you are responsible for its security and privacy
compliance.
#### Google PageSpeed Insights API (Optional)
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.
* Service: Google LLC (PageSpeed Insights)
* What it is used for: Running automated Lighthouse performance audits (Performance,
Accessibility, Best Practices, SEO scores).
* When data is sent: When you manually trigger an audit from the Lighthouse settings
page, or on the scheduled Lighthouse cron (if enabled).
* Data sent: Your site URL and your API key.
* API endpoint: https://www.googleapis.com/pagespeedonline/v5/runPagespeed
* Terms of Service: https://developers.google.com/terms
* Privacy Policy: https://policies.google.com/privacy
#### Vimeo oEmbed API (Conditional)
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.
* Service: Vimeo, Inc.
* What it is used for: Retrieving the video thumbnail image to display in the click-
to-play facade.
* When data is sent: When a page containing a Vimeo video facade is viewed by a
visitor.
* Data sent: The Vimeo video ID (no user data or authentication is required).
* API endpoint: https://vimeo.com/api/v2/video/{id}.json
* Terms of Service: https://vimeo.com/terms
* Privacy Policy: https://vimeo.com/privacy
#### Google Tag Manager / Google Fonts Preconnect Hints (Conditional)
When the Resource Hints module is enabled, the plugin outputs `` and `` 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 — no data is sent by the
plugin itself.
* Service: Various (Google LLC, Cloudflare, Inc.)
* What it is used for: Reducing connection latency for third-party resources already
loaded by your theme or other plugins.
* When data is sent: The browser (not the plugin) initiates the connection. No
plugin data is transmitted.
* Terms of Service / Privacy: Governed by the respective third-party services.
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.
## Installation
1. Upload the `basecloud-boost` folder to the `/wp-content/plugins/` directory.
2. Activate the plugin through the ‚Plugins‘ menu in WordPress.
3. Navigate to **BaseCloud Boost > Dashboard** to configure.
4. Enable Page Cache and click **Boost Cache** to start caching immediately.
## FAQ
### Does BaseCloud Boost work with WooCommerce?
Yes. Cart, checkout, and My Account pages are automatically excluded from caching.
Active WooCommerce cart session cookies bypass the cache transparently.
### Is it compatible with WordPress Multisite?
Yes. BaseCloud Boost supports WordPress Multisite with per-site cache directories.
### Can I use it with Cloudflare or BunnyCDN?
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.
### Will it conflict with other caching plugins?
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.
### What if my site breaks after activating the plugin?
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.
### Does BaseCloud Boost modify wp-config.php?
Yes. On activation it sets `define( 'WP_CACHE', true )` in `wp-config.php` so WordPress
loads the `advanced-cache.php` drop-in. On deactivation this line is removed. The
change is minimal and clearly labelled so it is easy to identify.
## Rezensionen
Zu diesem Plugin liegen noch keine Rezensionen vor.
## Mitwirkende und Entwickler
„BaseCloud Boost“ ist Open-Source-Software. Folgende Menschen haben an diesem Plugin
mitgewirkt:
Mitwirkende
* [ BaseCloud ](https://profiles.wordpress.org/basecloud/)
[Übersetze „BaseCloud Boost“ in deine Sprache.](https://translate.wordpress.org/projects/wp-plugins/basecloud-boost)
### Interessiert an der Entwicklung?
[Durchstöbere den Code](https://plugins.trac.wordpress.org/browser/basecloud-boost/),
sieh dir das [SVN-Repository](https://plugins.svn.wordpress.org/basecloud-boost/)
an oder abonniere das [Entwicklungsprotokoll](https://plugins.trac.wordpress.org/log/basecloud-boost/)
per [RSS](https://plugins.trac.wordpress.org/log/basecloud-boost/?limit=100&mode=stop_on_copy&format=rss).
## Änderungsprotokoll
#### 1.2.1
**Defer/Delay JS: keep the whole Elementor chain together so headers and menus work**
* **Fixed Elementor navigation/headers breaking under Defer or Delay JS.** The
1.2.0 default exclusions kept Elementor’s script files but not the inline config
they depend on (`elementorFrontendConfig`, `ElementorProFrontendConfig`), the`
js-cookie` (`Cookies`) dependency, or the bundled libraries under `assets/lib/`(
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 `lib/` helpers) plus `js-cookie`, so they load together and initialise correctly—
while analytics, tag managers, chat, forms and WooCommerce scripts are still
deferred/delayed. Still overridable via `BCBOOST_default_js_excludes`.
#### 1.2.0
**More robust CSS minification + safer Async CSS and JS optimization on page-builder
sites**
* **Fixed a CSS minification bug that could delete large blocks of CSS and break
styling (e.g. Gravity Forms).** When a CSS comment contained an apostrophe or
quote — for example `/* inherit Elementor's font */` — 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.
* **Async CSS now activates only when Critical CSS is present.** Loading CSS asynchronously
without inlined Critical CSS defers every stylesheet — including each page-builder
template’s per-element rules — 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.
* **JavaScript Defer/Delay no longer breaks page-builder menus out of the box.**
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 `BCBOOST_default_js_excludes`.
#### 1.1.9
**Dashboard: honest cache status when a reverse proxy is in front**
* **The dashboard now explains the hit rate when a reverse proxy (Varnish) is active.**
On stacks like Cloudways, a reverse proxy caches Boost’s optimized pages and
serves most visits without ever reaching PHP — 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.
#### 1.1.8
**Combine CSS now also folds stylesheets printed in the `` (Elementor/Astra/
Gravity Forms)**
* **Page-builder stylesheets printed late in the `` are now combined too.**
Combine CSS only folded stylesheets in the ``, but Elementor, Astra and
Gravity Forms print widget/form CSS in the body, where it stayed as many separate
render-blocking requests — 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 — so the menu and form are
styled before first paint instead of flashing/reflowing. Fewer requests and steadier
layout (CLS) on page-builder sites.
#### 1.1.7
**Cloudways (managed Varnish) support + reverse-proxy bypass cookie**
* **New Varnish „Reverse Proxy Type“ setting.** 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 **Cloudways** 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 **Cloudways** under _Advanced Purge Varnish_
and Boost now purges the way Cloudways expects: `URLPURGE` for a single URL and
a `PURGE` to `/?purgeall` for the whole zone, sent to the proxy front-end (defaults
to `127.0.0.1:8080`). Purge requests to internal proxy ports are correctly sent
over HTTP.
* **New `bcboost-nocache` bypass cookie.** 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 — emitting the cookie only on that
transition so normal anonymous pages stay cacheable. Add `bcboost-nocache` to
your reverse proxy’s excluded-cookies list (on Cloudways: _Application Varnish
Settings Excluded Cookies_) so the proxy bypasses its cache for those visitors.
Boost’s own page cache honours the same cookie.
#### 1.1.6
**Fixed: Delay/Defer JS broke Elementor menus & widgets even after scripts loaded(
no more excluding the whole Elementor stack)**
* **The order-safe loader now holds jQuery’s `ready` until every delayed script
has run.** 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 _before_ later scripts (Elementor Pro’s element handlers,
SmartMenus, etc.) had registered — 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 — keeping the full Total-Blocking-Time benefit on Elementor
sites.
#### 1.1.5
**Fixed: Delay JS made the first click on menus/buttons do nothing (dropdowns appeared
broken)**
* **The first click after a page loads now works with Delay JS enabled.** Delay
JS holds scripts until the first user interaction, but that very interaction —
usually a click on a navigation dropdown, accordion or button — 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—
so a single click behaves exactly as it would without Delay JS. Normal links
still navigate as expected.
#### 1.1.4
**Fixed: Critical CSS was corrupted on save (broke hero/background images)**
* **Saving settings no longer escapes quotes in your Critical CSS.** WordPress
adds slashes to submitted form data, and the settings handler stored the Critical
CSS without removing them, so `background-image: url("…")` was saved as `url(\"…\")`.
That is invalid CSS, so any rule relying on a quoted value — most visibly above-
the-fold section/hero background images — 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.
#### 1.1.3
**Faster LCP on page-builder sites: CSS background images now go through WebP +
CDN, and the hero image is preloaded**
* **CSS `background-image` files are now served as WebP/AVIF and from your CDN.**
Boost already rewrote `` 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 — they stayed as full-size origin JPG/PNGs baked into the
combined stylesheet. Boost now rewrites those `url()` 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.)
* **The hero / LCP background image is now preloaded with `fetchpriority="high"`.**
A section background lives inside the CSS, so the browser cannot discover it
until the stylesheet has downloaded and parsed — 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 `` for it in the ``, 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 _Preload LCP image_ option.
#### 1.1.2
**Font display + safer Critical CSS**
* **`font-display: swap` is now applied to fonts inside your stylesheets.** Boost
already added swap to Google Fonts links and inline `@font-face` blocks, but
icon-font packs (Themify, Linearicons, ElementsKit, Font Awesome, …) declare
their `@font-face` inside external stylesheets, where it was untouched. Boost
now injects `font-display: swap` into those `@font-face` rules while minifying/
combining CSS, so text and icons stay visible during font load (the „Font display“
PageSpeed item). Governed by the existing _Optimize Google Fonts_ toggle.
* **Critical CSS is no longer corrupted on save.** The Critical CSS field was sanitised
with a text filter that strips every `%xx` URL-encoded sequence, which silently
broke `url()` 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.
#### 1.1.1
**Combine CSS & Async CSS now work when a CDN is enabled (major mobile fix)**
* **Fixed: Combine CSS and Async CSS did nothing when BunnyCDN URL rewriting was
on.** The CDN rewriter swaps every asset URL to your pull-zone hostname (e.g.`
yourzone.b-cdn.net`) before Boost folds the page’s stylesheets. Boost only recognised
origin URLs, so it treated every CDN-hosted stylesheet as „external“ and skipped
it — leaving the whole page’s CSS render-blocking even with Combine CSS + Async
CSS (or the _Optimize for PageSpeed_ 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 — 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.
**WooCommerce: fixed „ghost products“ added to the cart + safer real-time cart on
cached pages**
* **Fixed: products silently appearing in the cart („ghost products“).** Boost’s
link prefetch (on hover/tap) and the Speculation Rules engine were speculatively
loading WooCommerce „Add to cart“ links — which are ordinary `?add-to-cart=ID`
URLs marked `rel="nofollow"`. 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 `rel="nofollow"` link and any URL carrying a cart/AJAX/nonce action
parameter (`add-to-cart`, `remove_item`, `undo_item`, `wc-ajax`, `add_to_wishlist`,`
_wpnonce`), as well as the cart/checkout/my-account pages. Add-to-cart, remove
and quantity changes now only happen when the shopper actually clicks.
* **Real-time cart keeps working with Delay JS.** The cart-fragments / add-to-cart
scripts were already kept out of Defer/Delay so the mini-cart updates on cached
pages, but jQuery — which they depend on — 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.)
#### 1.1.0
**Order-safe JavaScript engine — fixes broken sliders/menus and unlocks a big PageSpeed
gain**
* **Defer & Delay JS no longer break themes (major fix).** Previously Boost only
added `defer` (or the delay marker) to _enqueued_ script files, but left the
inline initializers a theme or page-builder hard-codes in the page running during
parsing — before the libraries they call had loaded. On sliders, popups and many
WPBakery/ThemeForest themes that meant `… is not a function` 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.
* **Delay JS is now safe and on by default.** Because order is preserved, holding
all JavaScript (including jQuery) until the first interaction — with a 5-second
fallback for passive visitors — 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 `DOMContentLoaded` and`
load` events so everything still initializes. Use _Delay JS Exclusions_ to keep
specific scripts (analytics, chat, etc.) running immediately, or add `data-no-
delay` / `data-cfasync="false"` to a tag to opt it out.
* **„Optimize for PageSpeed“ now includes Async CSS.** The one-click preset (Tools
_Optimize for PageSpeed_) now also enables Async CSS alongside Combine CSS so
the combined stylesheet stops blocking first paint. Test your homepage after
applying — themes that don’t inline their above-the-fold CSS may briefly flash
unstyled.
* **Async CSS now covers single-stylesheet sites too.** When Combine CSS has only
one local stylesheet to work with, that sheet is now loaded asynchronously (with
a `