25x Smaller Bootstrap: Lazy-Loading Campaign Data for Faster UX and Greener Footprint
In this blog post, we will cover:
- Why we changed how campaign data loads
- Real numbers
- What this means for end users
- How we implemented it
- How this align with Fluentos’ sustainable practices
- Final thoughts
Why we changed how campaign data loads
With ongoing improvements and customers expanding to new markets, our main configuration file grew over time. We tackled it in two steps:
- Step 1: Enable modern compression (zstd). This gave an immediate ~50% reduction.
- Step 2: Refactor the architecture to lazy-load campaign data on demand. Only the essential bootstrap ships at startup; campaigns are fetched as needed.
The Step 2 change is so significant, it deserved its own write-up.
Real numbers from one of our customers
Before vs. after for the same customer:
- Before: 73kB (compressed) and 3.4 MB (uncompressed)
- After: 2.9kB (compressed) and 13kB (uncompressed)
Reductions:
- Compressed: 73kB -> 2.9kB ≈ 96% reduction (≈ 25x smaller)
- Uncompressed: 3.4MB -> 13kB ≈ 99.6% reduction (≈ 260–270x smaller)
Per-request compressed data saved:
- 73kB − 2.9kB = 70.1kB
Network transfer time examples (initial bootstrap only):
- On 4G (10 Mbps): 73kB ≈ 58ms -> 2.9kB ≈ 2.3ms (≈ 56ms saved)
- On 3G (2 Mbps): 73kB ≈ 292ms -> 2.9kB ≈ 11.6ms (≈ 280ms saved)
Parsing impact on devices:
- Parsing ~3.4 MB JSON can cost ~70–170ms on mid/low hardware.
- 13kB is effectively instantaneous, reducing main-thread work and GC pressure.
What this means for the end users
From Core SEO metric perspective.
- Faster first interaction: smaller bootstrap means less waiting on slow networks.
- Smoother UI: less parsing/GC work during cold start improves responsiveness.
- Better Core Web Vitals: reduced bootstrap work helps FCP/LCP and lowers layout/parse jitter.
- Lower data and battery usage: less radio “on-time” and CPU burn, especially impactful on mobile.
How we implemented it
Nerdy stuff.
- Slim bootstrap: moved campaign payloads out of the initial config; only critical identifiers and capabilities ship up front.
- Compression and minification: ensure modern compression and tight JSON minification.
- Content-addressed assets: hashed URLs so repeat visitors and CDNs see long-lived cache hits.
- Caching strategy: strong Cache-Control and ETags to minimize re-downloads; on-demand campaign fetches are cached and segmented by the environment.
- Lazy hydration: fetch campaigns when they are likely to be needed (triggers), not at TTFB.
Quick math
For the curious.
Percent reduction:
- Compressed: (73 − 2.9) / 73 = 0.9603 -> 96.0%
- Uncompressed: (3400 − 13) / 3400 = 0.9962 -> 99.6%
Order-of-magnitude difference:
- Compressed factor: 73 / 2.9 = 25.2x
- Uncompressed factor: 3400 / 13 = 261.5x
How does this align with Fluentos’ sustainable practices
Fluentos stands for privacy and sustainable practices at its core:
- Minimal impact on end-user devices and networks through aggressive payload reduction and caching.
- Privacy-first by design: we don’t store user data. Any failed-to-process parts are encrypted and removed once integrations are healthy.
If you’re exploring vendors, also check out our original comparison in Performance & Privacy for Sustainable Growth.
We regularly ship changes that reduce bytes over the wire and CPU cycles. See our release notes.
Final thoughts
In a world of "fast by default", the reality is that bloat still accumulates. This change trims the very first bytes your users see, and it does so in a way that’s both measurably faster and meaningfully greener. I couldn’t be prouder of this one.
About The Author:
Hi, I’m Ricardas Risys, the CEO and Founder of Fluentos. I care deeply about web performance, simplicity, and sustainable web practices. I write these posts myself to share what I'm learning — and to make marketing more human again.
