BaseCloud Boost

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.