Title: BaseCloud Boost Author: BaseCloud Published: 2026(e)ko ekainaren 3(a) Last modified: 2026(e)ko irailaren 29(a) --- Bilatu pluginak ![](https://ps.w.org/basecloud-boost/assets/banner-772x250.png?rev=3559990) ![](https://ps.w.org/basecloud-boost/assets/icon-256x256.png?rev=3559990) # BaseCloud Boost [BaseCloud](https://profiles.wordpress.org/basecloud/)-(r)en eskutik [Deskargatu](https://downloads.wordpress.org/plugin/basecloud-boost.1.5.0.zip) * [Xehetasunak](https://eu.wordpress.org/plugins/basecloud-boost/#description) * [Berrikuspenak](https://eu.wordpress.org/plugins/basecloud-boost/#reviews) * [Instalazioa](https://eu.wordpress.org/plugins/basecloud-boost/#installation) * [Garapena](https://eu.wordpress.org/plugins/basecloud-boost/#developers) [Laguntza](https://wordpress.org/support/plugin/basecloud-boost/) ## Deskripzioa **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: 7 days) * 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 between 05:00 and 06:00 site time (retried up to 3 times, 15 minutes apart, if your endpoint fails), and when you send it manually 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. ## Instalazioa 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. ## MEG ### 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. ## Berrikuspenak Ez dago berrikuspenik plugin honentzat. ## Laguntzaileak eta Garatzaileak “BaseCloud Boost” software librea da. Ondoko pertsonek egin dizkiote ekarpenak plugin honi. Laguntzaileak * [ BaseCloud ](https://profiles.wordpress.org/basecloud/) [Itzul zaitez BaseCloud Boost zure hizkuntzara.](https://translate.wordpress.org/projects/wp-plugins/basecloud-boost) ### Garapena interesatzen zaizu? [Araka kodea](https://plugins.trac.wordpress.org/browser/basecloud-boost/), begiratu [SVN biltegia](https://plugins.svn.wordpress.org/basecloud-boost/) edo harpidetu [garapen erregistrora](https://plugins.trac.wordpress.org/log/basecloud-boost/) [RSS](https://plugins.trac.wordpress.org/log/basecloud-boost/?limit=100&mode=stop_on_copy&format=rss) bidez. ## Aldaketen loga #### 1.5.0 **Boost was changing Elementor Global Colours and Global Fonts, and “Bundle Elementor” broke sites. Both fixed — plus a Headers tab, a Cloudways setup, scheduled cache boosts and a full security review.** **Elementor and theme styling** * **Fixed: the CSS minifier changed which elements a rule applies to.** A space before `:where(` / `::before` was removed, so `.entry-content :where(...)` became`. entry-content:where(...)` and matched nothing. On live sites this turned Elementor headings and body text grey and changed font sizes. The minifier is rewritten as a single-pass tokenizer; custom-property values (`--e-global-*`, `--border- top-width:0px`) are now kept byte-for-byte — shortening `0px` to `0` there collapsed Elementor container overlays. * **Fixed: Critical CSS overrode your theme’s colours and fonts.** It was printed after the theme’s inline styles, so its generic `body` rules won. It is now always placed first in ``, so your real CSS always has the last word. * **Fixed: Google Fonts `@font-face` rules were corrupted** (`font-style:normalfont- display:block`). * **Fixed: Global colour/font changes could stay stale.** A Site Settings save now clears every cached page once Elementor has finished regenerating its CSS, not before. * **“Bundle Elementor stylesheets” is now off by default and switched off once on update.** It re-minified Elementor’s files, folded across inline styles and removed stylesheets Elementor’s own scripts look up. It now concatenates Elementor’s shipped files untouched, never crosses an inline style, never bundles runtime sheets, and aborts on any unreadable file. Re-enabling it yourself sticks. **Speed (mobile and desktop)** * **Layout shift:** stylesheets printed in the footer for above-the-fold markup( Elementor header/nav, popups, form themes) are copied into ``. Measured on a live site: desktop CLS 0.93 0.02. * **Largest Contentful Paint:** hero detection now understands Elementor slideshow backgrounds, Elementor 4 containers, Boost’s minified post CSS and multiple CSS bundles; only the hero keeps high priority. On 6 of 8 audited sites the preload was on the wrong image or missing. * **Blocking time:** more third-party tags are delayed (async gtag.js, reCAPTCHA on pages without a form, PixelYourSite, Podium) with a safe `gtag`/`dataLayer` stub. The fallback timer now starts at page load. New opt-in “wait for interaction only”. * **Fixed: with Delay/Defer JavaScript on (the default), the site’s own page-ready code could run twice.** When the delayed third-party tags were released, Boost re-announced “page loaded” to the whole page. Contact Form 7 then sent every enquiry twice and the Hello Elementor mobile menu would not open. Only the delayed tags now receive those events, exactly once. This was present in earlier versions too. * **Font fallbacks** now apply to every stylesheet Boost serves, including Elementor’s kit CSS, and work with Used CSS off. Bold text uses a real bold fallback font, so headings no longer re-wrap while the web font loads. * **Used CSS** (still opt-in) is now built by Boost’s own warm-up requests before a page is cached, so the first cached copy is already optimised. Warm-up requests are signed. * Minified files are named after their contents, so new bytes always get a new URL; files still linked by cached pages are kept for 48 hours after a purge instead of being deleted at once. **Cloudways** * **Boost now asks whether the site is hosted on Cloudways** (pre-answered from detection) and offers Cloudways-optimal settings that mirror Breeze, Cloudways’ own plugin — with a preview of every change, the Breeze setting it mirrors, a daily off-peak cache refresh, and one-click Undo. * **Fixed: Varnish purges on Cloudways were likely being refused.** Boost now sends exactly the requests Breeze sends, through Cloudways’ nginx. * Running Breeze’s page cache alongside Boost is detected and explained. **Cache** * **New: Scheduled Cache Boost.** Choose weekdays, times and calendar dates when the cache is cleared on every layer and re-warmed. Runs are logged, with “Run now” and a WP-Cron health panel. * **Fixed: sites that show prices per visitor country served the first visitor’s country to everyone.** If your theme or geolocation plugin marks the page with a country class (`geo-country-southafrica`, `geoip-country-ZA`, `geot-…`), Boost now spots it on its own and keeps a separate cached copy per country — South African visitors keep seeing Rands, US visitors Dollars. Nothing to set up; the Page Cache screen shows which countries are cached. A visitor’s first page view is built fresh for their country, then served from their country’s copy; CDNs and proxies are told never to share these pages between visitors. * HTML pages now always send `Cache-Control` (the fix from 1.3.7 was never switched on). * Fixed: HTTPS pages behind a proxy could never be served from cache; a page being rendered during a purge could re-cache old HTML; Cache Lifetime 0 now means “ never expire”. * Fixed on Apache: cached pages could be gzipped twice and arrive as garbage. The`. htaccess` rules now update whenever settings change, and plugin updates finish on their own without an admin visit. * The “Cache for Logged-In Users” and “Cache Pages with Query Strings” switches are retired: logged-in visits are personal and were never cached, and caching`? orderby=`-style addresses could overwrite the normal page. Visits that only add marketing parameters (`utm_*`, `gclid`, `fbclid`) are now actually served from cache. **Security** * **New Headers tab** (BaseCloud Security Manager, built in): X-Frame-Options, nosniff, Referrer-Policy, Permissions-Policy, Content-Security-Policy (with Report- Only), HSTS, COOP/COEP/CORP and safe HTTPS redirect. Headers are sent on cached pages too, with a live test button and one-click import from the standalone plugin. Warnings flag policies that would break styling, fonts or scripts. The deprecated` interest-cohort` directive is no longer sent. * Full security review: password-protected, commenter and cart pages are no longer shared from cache; forged Host headers can no longer write into another URL’s cache; outbound requests refuse internal addresses; exports no longer contain secrets; settings are validated on save; combining can never republish a non- CSS file. **Fleet Ops (BaseCloud CRM)** * **New: BaseCloud can look after this site from its central dashboard.** Fleet Ops lets the BaseCloud CRM check the site’s health, clear its cache and warm it up again. It cannot change your settings, read your content or users, or touch anything else. * **Off by default, and nothing is exposed by this update.** It needs three things, all set by you: a line in `wp-config.php` (`define( 'BCBOOST_FLEET_OPS_READY', true );`), the Fleet Ops switch under BaseCloud Boost > Advanced, and a pairing key. Without the wp-config line the API does not exist at all. * **How to turn it on:** add the line to `wp-config.php` above “That’s all, stop editing!”. Then go to BaseCloud Boost > Advanced > Fleet Ops, switch it on, click** Generate pairing key** and copy the key into the CRM. The key is shown once and stored encrypted. **Regenerate** or **Revoke** it at any time; the old key stops working immediately. The card shows the exact Site URL to give the CRM, and warns if your permalinks are set to Plain (the API needs pretty permalinks). * **Built to stay safe:** at most 10 requests a minute, clear cache one purge at a time, and warm-ups queued (never run during the request, never twice). Every answer is marked “do not cache”, and bad keys are throttled without ever locking BaseCloud out. The last 50 requests are listed on the card. Security plugins that block the WordPress REST API are allowed through for these requests only; each request still needs the key. * **Daily Site Report:** the performance webhook now sends the BaseCloud CRM report format. It goes out once a day between 05:00 and 06:00 site time and is retried up to 3 times, 15 minutes apart, if the receiver is down. “Send now” still works. The cache hit rate is now a whole number, and the old field names are still included. **Admin** * Dropdowns and fields are readable in light and dark mode; Boost’s own notices are no longer hidden. #### 1.4.2 **Enquiries sent from a cached page were being marked as spam by Gravity Forms. Fixed.** Gravity Forms 3.0 and newer stamps every form with a hidden anti-spam token at the moment the page is generated, and rejects any submission whose token is more than two days old — the entry lands in the Spam folder with the note “Hidden input (name: state_1) does not contain the expected value.” A cached page is a snapshot, so that token kept ageing for as long as the copy was served. Boost keeps pages for seven days by default, and its fastest serving route (the .htaccess rules on Apache) never looked at a page’s age itself, so on any contact page nothing had edited, genuine enquiries were quietly filed as spam for five days out of every seven, and sometimes longer. A check of live sites before this release found cached form pages being served with tokens 62, 118 and 376 hours old. * **Pages with a Gravity Forms form now expire on their own schedule.** When Boost caches a page it reads the form’s own token and allows the copy to be served for only the first half of the token’s life: 18 hours to a day after the form was generated, depending on which tokens the page carries. The other half is deliberately left as headroom for a proxy or CDN holding its own copy, and for the visitor who opens the page and only presses Send hours later. The deadline is enforced on every route a cached page can take: Boost’s serving script refuses a copy past its deadline, and on Apache the .htaccess fast path now hands form pages to that script, which checks the deadline on every request while still serving from cache without loading WordPress. On nginx, Boost never installs a static fast path, so cached pages there were already served by the script. If a form’s token is so old that the deadline is only minutes away, the page is served fresh and not cached at all. * **Expired form pages are removed from every layer, not just from disk.** A reverse proxy or CDN in front of your site keeps its own copy and never asks Boost, so deleting our file alone would not stop an expired form reaching visitors. The hourly clean-up now also purges expired form pages from Varnish and any CDN integration you have enabled, and re-fetches form pages that are about to expire so the next visitor still finds a warm copy. Both are capped per run (25 purges, 10 re-warms) so a large site never floods a purge API. Re-warming follows your existing “Re- warm after purge” setting. When a CDN is enabled, edge copies of form pages are given a matching lifetime and are never served stale while revalidating. * **Fixed: a stale compressed copy could outlive the page it belonged to.** When a page was re-cached but its compressed (.gz / .br) copy could not be rewritten, the old compressed copy stayed behind — and because compressed copies are preferred, it kept being served under the new page’s timestamp. Such a copy is now removed instead. * **Pages without a form are untouched.** They are cached and served exactly as before, and the HTML, CSS and JavaScript Boost sends to the browser is identical to 1.4.1 on every page, form or not: this release changes how long a copy may be served, never what is in it. **What it costs.** A form page is regenerated roughly once a day instead of once a week, so about one visitor per form page per day gets the page built fresh rather than from cache — a normal uncached page load, measured at around a second on typical hosting. Field Core Web Vitals do not move. **Nothing to configure.** On update the drop-in and .htaccess rules are refreshed and the cache is cleared once, so every form page is re-cached with its deadline. Cache Lifetime keeps its value and still governs every other page. For developers:` BCBOOST_cache_expires_at` lets another plugin’s expiring token impose its own deadline on a page, `BCBOOST_token_purge_limit` and `BCBOOST_token_refresh_limit` adjust the hourly caps, and `BCBOOST_cache_own_hosts` widens the hosts whose pages Boost may purge and re-warm (by default only this site’s own). #### 1.4.1 **Used CSS is now opt-in. If you updated to 1.4.0, this switches it back off for you.** 1.4.0 introduced the Used CSS engine and switched it on for everybody. That was the wrong call and this release corrects it. The engine’s analysis was checked thoroughly, but only offline — against copies of real client pages, never inside a running WordPress site. The parts that touch a live request (finding the stylesheets in the page, swapping in the shortened version, building it after the page is sent) had no testing at all, and there was no library of theme and plugin combinations to justify turning something that rewrites every page’s CSS on for everyone by default. * **Used CSS is off unless you switch it on.** Updating from 1.4.0 turns it off for you and clears the cache, once. If you deliberately switch it back on afterwards, it stays on. Nothing about how it works has changed — it is the same engine, now behind a switch. * **Dropping unused font alphabets is off too.** It reads the characters on the page to decide which alphabets a font needs, and it cannot see text that arrives afterwards — comments, product names loaded as you scroll, translations inserted by a script. Those would show as empty boxes. A version that decides from your site’s language instead of from one page is the correct approach and is not built yet. * **Everything else from 1.4.0 is unaffected** and stays as it was: the page cache, image conversion, the third-party script delay, Elementor Speed, and Lazy Render( which was already off by default). Note that the font-swap layout fix introduced in 1.4.0 is delivered as part of the Used CSS bundle, so it is inactive while Used CSS is off. Separating the two is on the list. **What happens next:** a compatibility test suite across common themes and plugins, with screenshot comparison and scripted interaction, so that switching this on by default is backed by evidence rather than judgement. Until then it stays opt-in. #### 1.4.0 **The CSS release: your pages stop waiting for stylesheets they cannot use** A page cannot show anything until the browser has downloaded and read every stylesheet in its head. Measured across ten live client sites, each one was making phones read between 0.8 MB and 1.9 MB of CSS before a single word could appear — and between a third and three quarters of it belonged to widgets, icon sets, forms and languages that were nowhere on the page. Not one byte of it was being loaded in the background. That, rather than JavaScript, is why mobile scores stayed low on sites where the cache, the image conversion and the third-party script delay were all working correctly. * **New: Used CSS (switched on).** Boost now works out which style rules a page can actually reach, and serves only those — as one stylesheet per group instead of dozens of separate requests. On the sites it was built against this removed between 24% and 73% of the CSS blocking the first paint; on one page 1,316 KB fell to 355 KB, and a stylesheet that appeared four separate times went from 57 KB to 2 KB. Stylesheets are only ever merged in the order they already appear and never across an inline style block, so nothing changes position and your styling order is exactly what it was. **The first visitor to a page never waits for this** — the page is served exactly as before while Boost works it out in the background, and the shorter version starts serving once it is ready. * **New: a safety net that repairs its own mistakes (switched on).** Everything Used CSS removes is still loaded, as a second stylesheet that does not hold up the page. Those rules match nothing, so normally they do nothing at all — but if a rule was removed in error, or only becomes needed once a menu opens or a form reports an error, it is already there. The worst case becomes a style that arrives a moment late rather than a broken layout. You can switch it off for a little more speed once you have tested a site, and the setting explains the trade. * **New: unused font alphabets are dropped (switched on).** A font stylesheet declares every alphabet a typeface supports — Latin, Cyrillic, Greek, Vietnamese and a large block of symbols — for every single weight. On an English site almost none of it can ever be used, yet the browser reads all of it before painting. One family measured 102 KB on a client site; 61 KB of that was alphabets the page never writes in. Boost reads the characters actually on the page and keeps every alphabet they need. This does not change which font files are downloaded — browsers already fetch only what they need — it removes the reading work before the first paint. * **New: text stops jumping when your fonts load (switched on).** Text is drawn first in a standard font and redrawn in your real font once it arrives. The two are different heights, so at that moment every line changes size and everything below it shifts down the page. Google measures that shifting directly and it is a quarter of the performance score. Boost now gives the stand-in font the exact height of your real font so the swap moves nothing. The measurements come from the font files themselves rather than being estimated, and fonts Boost has no measurements for are left alone. * **New (optional, off by default): Lazy Render.** Lets the browser postpone drawing sections far down a long page until the visitor scrolls near them. The content is still fully present and still found by search engines and by Ctrl+F. It is off by default deliberately: to skip that work the browser has to seal each section off permanently, which clips anything designed to overhang its edges and re-anchors anything pinned to the screen. Overlapping sections and overhanging decoration are common in Elementor and Divi and Boost cannot tell from the page whether your design relies on them. Sticky, popup, overlay and parallax sections are skipped automatically. Switch it on, scroll the whole page on a phone and a desktop, and check nothing has been clipped or moved. **If something looks wrong** This is the first release of a new CSS engine. It was built and checked against real client pages, but every site is different. If anything looks off, switch ** Used CSS** off under File Optimization and clear the cache — the page returns to exactly its previous behaviour immediately. Individual stylesheets can also be excluded there without giving up the benefit elsewhere. #### 1.3.9 **Mobile release: Combine CSS actually combines now, self-hosted fonts stop bloating every page, and Boost tells you which optimizations you have left switched off** * **Fixed: “Combine CSS” was silently doing almost nothing.** WordPress adds a version tag to nearly every stylesheet address (`style.css?ver=4.2.1`). Boost looked for a file with that version tag _in its name_, never found one, and quietly skipped the stylesheet — so on a normal site the combiner merged only the rare stylesheet that happened to carry no version, and everything else still loaded as its own render-blocking request. Measured on a live client site: Combine CSS switched on, and 44 of the page’s 47 stylesheets were still arriving individually. Combining now works as described. **Please re-test any site where you have Combine CSS enabled** — for the first time it will genuinely merge your stylesheets, which is a large mobile win but also the change most likely to disturb a slider, form or menu. Check the site after updating and clear the cache; if anything looks wrong, switch Combine CSS off. (Minification was never affected — only combining.) * **Fixed: self-hosted Google Fonts were being embedded into every single page.** With “Self-Host Google Fonts” enabled, Boost pasted the entire localised font stylesheet directly into the page. On a real site that meant 138 KB of font CSS inside every HTML response — re-sent on every page view, stored in every cached page, and parsed before the page could paint. Localised font CSS is now written once to a cached, permanently-cacheable stylesheet and linked, so the browser downloads it a single time for the whole site. Small font stylesheets (under 8 KB) are still embedded, where doing so genuinely saves a request. **Also in this release** * **New: the Mobile Score Advisor (Dashboard).** Boost’s biggest optimizations ship switched off on purpose, because switching them on for you could break a site. The unintended result was that most installs quietly ran only the safest fraction of what the plugin can do — a fleet audit found every site slow on mobile for that reason alone, not because of any defect. The dashboard now reads this site’s own settings and states plainly which mobile levers are off and what each one costs, with a one-click button that switches on **only the safe-by-default ones** and clears the cache. File combining is deliberately never applied for you: it is the optimization most likely to disturb a slider, form or menu, so the advisor explains it and leaves the decision — and the testing — with you. * **New: Elementor stylesheet bundling (part of Elementor Speed).** Since Elementor 3.24 each widget loads its own small stylesheet; a real page was measured carrying 22 of them among 34 render-blocking stylesheets. Boost now merges neighbouring Elementor stylesheets into one fingerprinted file. Only Elementor’s own shipped files are merged — never your page CSS, your theme, or anything a builder generated— and any other stylesheet sitting between two of them ends the merge, so the styling order is bit-for-bit what it was. The bundle stays render-blocking (content is still styled before it paints), and the whole pass stands down automatically if you enable the site-wide Combine CSS. * **New (opt-in): non-blocking Elementor fonts.** When Elementor hosts Google Fonts locally it writes every weight and style of a family into a single stylesheet— over 100 KB for one family is common — and the page cannot paint until it arrives. This option loads those stylesheets in the background instead. Elementor already displays text in a fallback font while webfonts load, so the final rendering is unchanged; the page simply appears sooner. Off by default because the switch to the real font becomes more noticeable on slow connections. * **Improved: more Elementor page CSS is now inlined.** The per-file size limit for embedding Elementor’s per-page stylesheets was raised from 15 KB to 50 KB after measuring real sites, where the largest page stylesheets (25–40 KB) were exactly the ones being skipped — and therefore left as render-blocking requests. CSS compresses roughly six-to-one, so the added page weight is a few kilobytes in exchange for removing a round-trip. #### 1.3.8 **Hotfix: video and iframe embeds render reliably again** * **Fixed YouTube/Vimeo embeds erroring in the editor and rendering empty on the site.** The “Disable Embeds” optimization (on by default) removed not just WordPress’s embed _assets_ but its embed _rendering_ machinery — the editor’s embed preview returned “Sorry, this content could not be embedded”, and a URL-based embed could resolve to nothing and then be frozen empty by the page cache. The toggle now does only its real job: stop serving wp-embed.min.js and this site’s embed-discovery links. Embed rendering can no longer be affected by it. If a page cached an empty embed, one Clear Cache repairs it. * **Changed: the click-to-play video facade is now opt-in (was on by default).** Replacing YouTube/Vimeo players with thumbnail facades is an aggressive optimization: it changes playback to two clicks, conflicts with builder video widgets, and errors outright on sites whose security headers deny autoplay/encrypted-media. Sites that want it can enable “Video Facade” deliberately; its play-button icon( previously invisible due to a rendering bug) is also fixed. * **Fixed autoplaying hero/background videos being demoted to `preload="none"`.** An autoplay video must start buffering immediately — its poster is usually the page’s LCP. Only passive click-to-play videos are now demoted. #### 1.3.7 **Elementor Speed (opt-in), a redesigned Light/Dark admin, the Fleet Ops read-only API, and an HTML-freshness correctness fix** * **New: Elementor Speed — Boost finally optimizes Elementor instead of only protecting it (opt-in).** Most Elementor sites carry the same invisible weight: 4–27 tiny render-blocking `post-*.css` requests per page, an always-loaded `eicons` icon stylesheet, and Font Awesome shims. The new module (File Optimization Elementor Speed, master toggle **off** until you enable it) inlines each page’s own Elementor CSS straight into the HTML (identical rules, same position, minus every one of those blocking requests), drops the eicons/Font Awesome stylesheets only on pages that provably use no icons, lightboxes, popups or carousels (any doubt = the sheet stays), and adds a read-only advisor that flags Elementor settings worth changing (font-display swap, Inline Font Icons, Element Caching alongside a page cache). Elementor’s own JavaScript and init order are never touched — that is exactly what historically breaks sliders and forms — and the advisor also warns on oversized DOM (Boost will never restructure your markup; the fix belongs in the builder). * **New: the Boost admin now has true Light and Dark modes.** Appearance Interface Mode switches the whole panel — every card, dropdown, text field and toggle re- themes with full contrast in both modes, previewing instantly. Typography is refreshed with a premium display face (Space Grotesk) over Inter. The bright Goop WebGL backdrop is retired (existing installs migrate to Dark automatically); the Classic particles and all six ambient video backdrops remain as optional dark-mode extras. Your four accent colours now adapt automatically so text stays readable on light surfaces whatever colours you pick. * **Preview: Fleet Ops (BaseCloud CRM) — visible on the Advanced screen, marked“ Unavailable Right Now”.** The plugin side of BaseCloud’s central monitoring ( a read-only `bcboost/v1` REST API with a revocable, encrypted pairing key and optional signed requests) ships in this release but stays fully dormant — the API does not register and there is nothing to configure — until the BaseCloud service goes live in a future update. * **Fixed stale HTML on hosts with an edge cache when “Browser Cache Headers” was off.** That toggle previously gated _all_ Cache-Control output — with it off, HTML went out with no Cache-Control at all, so browsers heuristic-cached pages that no server-side purge could ever reach (found live on an Oxygen/Varnish site). HTML freshness headers (`max-age=0, must-revalidate`, plus logged-in no-store protection) are now sent unconditionally — the toggle only gates the static-asset caching rules, as it always should have. * **Improved: async-CSS protection patterns can now be precise.** Exclusion entries accept `regex:` patterns alongside substrings, so Oxygen’s numeric per-page stylesheets are protected exactly — while its site-wide sheets stay eligible for minify/combine/ async. An invalid pattern fails closed (the stylesheet stays render-blocking) and is logged: a typo can slow a page, never break one. * **Improved: cross-origin video-background heroes get a preconnect.** Hero videos streamed from a different origin (Azure blob, S3, video CDN) now have their connection warmed before the first byte is requested, the same treatment image heroes already get. * **Improved: GZIP compression rules are always written to .htaccess** — compression is a correctness-neutral win and no longer depends on the browser-cache toggle. #### 1.3.6 **New: a built-in Critical CSS generator (Beta, opt-in) — the key that unlocks async CSS** * **Boost can now create critical CSS itself — no Node, no headless Chrome, no external service.** The number-one thing holding back mobile scores on most sites is a wall of render-blocking stylesheets, and the cure (inlining the above-the- fold “critical” CSS, then loading the rest asynchronously) previously required generating that CSS with external tooling. The new built-in generator does it in pure PHP on your own server: it reads each template’s page, determines which stylesheet rules the above-the-fold content actually uses, and fills the Per- Template Critical CSS store at the press of a button. * **You choose — nothing turns itself on.** The generator ships **off**; enable it under Advanced Critical CSS (“Built-In Critical CSS Generator (Beta)”), press _Generate for all templates_, and review the results per template. Inlining ( Enable Critical CSS) and Async CSS (File Optimization) remain separate switches you flip yourself, and the long-standing safety gate is unchanged: any page without critical-CSS coverage automatically keeps safe render-blocking CSS — a page can never paint unstyled because coverage was missing. * **New: six ambient video backdrops for the Boost admin.** The Appearance screen now offers looping video themes — Boost Rocket, Goop Motion, Lava Lamp, Colours, Fish Tank, and Zombies — behind the glass UI, alongside the Goop, Classic, and Minimal engines. Hover a card to preview its motion before choosing. Heavily compressed (all six together add ~4 MB to the plugin, sources were 140 MB), admin- only (never loaded on your website), paused in hidden tabs, and reduced-motion users get a still frame. * **Improved: smarter preconnects.** Boost no longer preconnects to a fixed list of third-party origins on every page — it now checks which origins the page actually references (Tag Manager, Analytics, Google Fonts…) and hints only those, capped at the browser’s useful budget of four. Unused preconnects were burning TLS handshakes inside the critical first-paint window and drawing Lighthouse’s “preconnect not used” warning. * **Improved: one hero per page — competing image priorities are demoted.** When the detected hero is a background, slider, or video-poster image, WordPress core( or the theme) may still have marked a different content image `fetchpriority=" high"` — two “highest priority” images then fight for the same critical bandwidth and both paint later. Boost now removes the competing marker (returning those images to normal browser priority, never forcing them low) so the real hero … ## Meta * Version **1.5.0** * Azken eguneraketa **duela 3 ordu** * Instalazio aktiboak **50+** * WordPress bertsioa ** 5.5 edo handiagoa ** * **7.1.2** (e)raino probatuta. * PHP bertsioa ** 7.4 edo handiagoa ** * Language * [English (US)](https://wordpress.org/plugins/basecloud-boost/) * Etiketak * [cache](https://eu.wordpress.org/plugins/tags/cache/)[caching](https://eu.wordpress.org/plugins/tags/caching/) [optimization](https://eu.wordpress.org/plugins/tags/optimization/)[performance](https://eu.wordpress.org/plugins/tags/performance/) [speed](https://eu.wordpress.org/plugins/tags/speed/) * [Ikuspegi aurreratua](https://eu.wordpress.org/plugins/basecloud-boost/advanced/) ## Balorazioak No reviews have been submitted yet. [Your review](https://wordpress.org/support/plugin/basecloud-boost/reviews/#new-post) [See all reviews](https://wordpress.org/support/plugin/basecloud-boost/reviews/) ## Laguntzaileak * [ BaseCloud ](https://profiles.wordpress.org/basecloud/) ## Laguntza Zerbait duzu esateko? Laguntza behar? [Ikusi laguntza foroa](https://wordpress.org/support/plugin/basecloud-boost/)