Minified once, served from cache thereafter.
Varnish stores the already-minified page; each fill costs 3–160 ms (median ~36 ms) against the seconds your application takes to render the same page.
Platform add-on
Automatic HTML Minification
Every page your store serves is shrunk before it enters the Varnish cache.
It's the same Rust-based @swc/html engine behind the Hyvä minifier, delivered inside the hosting stack. Works on Hyvä, Luma, custom Magento themes and WordPress. No module, no theme change, no deploy, nothing for your developers to do.
- ~25%
- more pages fit in the same Varnish cache memory
- 9–29%
- smaller HTML on the wire (gzipped) on Magento stores — typically 15–20%
- 15–50%
- less HTML for the browser to parse — helps most on mid-range mobiles
- 0 ms
- added to cache hits — minified once per page, served millions of times
How it works
Between the cache and your application — so it only runs on a cache fill.
Shopper browser
Edge WAF / TLS
Varnish page cache
Minifier add-on
Your store Magento / WP
The minifier sits between Varnish and your application, so it only runs when Varnish fills its cache. Cache hits — the vast majority of traffic — never touch it.
Whole-page coverage.
Sees the delivered page — comments, CMS and page-builder content, third-party tags — not just templates. Stores already using Magento’s built-in “Minify Html” measured a further ~10%.
Varnish-native.
ESI-aware (hole-punched menus and dynamic blocks survive), gzip storage preserved.
Why your Varnish cache works harder
Smaller pages, more of them in memory, fewer visitors waiting on PHP.
−20%
bytes per cached page
(typical custom theme)
(typical custom theme)
+25%
pages held in the
same cache memory
same cache memory
Higher hit ratio when it matters.
During sales and campaigns, layered-navigation and filter pages flood the cache. Smaller objects mean fewer evictions, so more visitors get an instant cached response instead of waiting on PHP.
Every hit is lighter.
The cached object is smaller, so each hit costs less bandwidth and less transfer time — the hit path itself is unchanged.
Less egress.
Every HTML byte leaving the cache shrinks ~20–26% on typical custom themes; roughly a fifth to a quarter of HTML bandwidth and CDN egress disappears.
Measured results
Nine real production stores, thirty pages.
Across nine real production stores, Magento sites saved 9–29% of every HTML page on the wire — typically 15–20% — with no code changes.
| Storefront type | On the wire (gzipped) | Raw HTML |
|---|---|---|
| Hyvä theme store (jewelry) | 25–29% | 39–51% |
| Classic / custom Magento themes (5 stores) | 14–26% | 15–46% |
| Alpine-based store, data-heavy pages | 17–23% | 29–35% |
| Stock Magento Luma | 10–12% | 19–28% |
| Magento with built-in minify already on | 9–11% | 9–13% |
| WordPress news / media site | 5.5–7% | 15–17% |
Measured July 2026. "On the wire" is what crosses the network after gzip; "raw" is what the browser parses. Stores on Brotli (Varnish Enterprise) measured 15–19% on the wire — minification removes structure that no compressor can squeeze away. Hyvä's published 38–50% reproduces here because it is the same engine. On news and media sites the wire saving is modest because gzip already handles unique text well; the win there is the 15–17% less HTML the browser has to parse, which matters most to mobile-heavy audiences.
Safe by design
There is no failure mode where minification takes a page down.
Fail-open.
If a page can’t be minified for any reason, the original is served unchanged and automatically. Worst case is an unminified page — never a broken or blank one.
Cart, checkout and account pages untouched.
Only cacheable pages are minified; your most sensitive flows follow exactly the same path as before. Logged-in shoppers browsing the catalog still get the minified cached pages, with their details filled in dynamically as always.
Verified on every store tested.
Alpine.js interactivity, Magento inline configuration, JSON-LD structured data and ESI blocks all intact.
Instant on / off.
Enabled or disabled from the luroConnect dashboard — no deploy, no downtime; off restores previous behaviour exactly.
See it yourself.
Every page carries a Server-Timing header in browser dev tools showing the saving on that very page. Cumulative bytes saved are tracked for reporting.
Where you are today
Same proven engine, broader reach.
On Hyvä already?
The Hyvä minifier, managed at the platform level.
Same engine, same output quality — with no module to install, update or debug. It simply comes with the hosting.
On Luma or a custom theme?
Hyvä-grade results without re-theming.
The benefit Hyvä stores get from their minifier, available to any theme you already run. Hyvä migration remains a great choice we support; this works either way.
Using Magento’s built-in “Minify Html”?
You’re leaving ~10% on the table.
Magento’s setting only minifies templates and is a known source of inline-JavaScript breakage with no safety net. Ours sees the whole delivered page, uses a real HTML parser, and falls back automatically. Keep it simple: turn Magento’s setting off and let the platform do it.
Optional tuning levels
Beyond the safe default, two opt-in levels — validated on your staging store first.
The default settings are the ones measured above and are safe for every store we host. Two further levels exist. Neither is switched on by default; each is enabled per store only after we have validated it on that store's staging environment.
Deeper whitespace optimization
A more aggressive whitespace mode for stores whose theme has been validated for it on staging.
Inline script consolidation
Folds dozens of inline scripts into one — the same idea as Hyvä’s “Merge Inline JavaScript”. Page-structure hygiene rather than byte savings; critical scripts such as tag managers and loader configuration are automatically left in place.
A paid add-on for luroConnect-hosted stores
Enabled per store from the luroConnect dashboard, on your own AWS or GCP account. Enable on staging first, verify in your browser, then switch on production — seconds, not a project.