Earlier this year we ran a controlled lab comparison of Consentmo's cookie banner against other Shopify consent apps on a clean store. We measured the same timings browsers already expose: when scripts start and finish, how many resources load, payload size, memory, layout shift, and Core Web Vitals.
On banner ready time - when banner-related resources finish loading - we were at 1,294ms median with 20 resources on the wire. That left clear room to improve. This post covers what we changed, what we kept refining afterward, and why storefront performance is part of the product for a compliance app.
Why banner performance matters
A cookie banner runs on nearly every storefront pageview. Extra delay can influence Core Web Vitals, Built for Shopify scores, and how the consent step feels on slower connections.
Our goal is straightforward: help merchants stay compliant without adding unnecessary weight to the storefront.
What we changed
We worked in waves. The first three got us roughly 3× faster on that lab metric. Later rounds kept going - including reversing a few earlier choices when a simpler approach measured better.
Round 1: Slim the bundle
We audited the main JavaScript entry and found a lot of code running up front for features most stores never use - TCF, consent-analytics integrations, cross-domain sync, custom CSS injection, bot detection, and more.
Anything off the first-paint path moved to lazy loading. TCF alone (~110 KiB raw) only loads when enabled. We also stopped transpiling to ES5 for browsers Shopify no longer needs to support, which removed a large chunk of polyfill bloat.
Result:
- bundle.js: 264 KiB → 53 KiB (−80%)
- gzipped: 69 KiB → 19 KiB (−72%)
- Total dist: 706 KiB → 523 KiB (−26%)
Round 2: Keep network work off first paint
A smaller bundle still waited on sequential API calls before render - cache/version checks and full configuration - often hundreds of milliseconds of latency.
We tried inlining config into the theme for a while. It helped in the lab, but maintaining two boot paths added more operational complexity than it was worth. We consolidated back to a single API path and kept the useful parts of the experiment:
- Returning visitors warm layout choice from a local settings cache
- Version checks, impressions, and quota tracking run after paint / at idle
- Work that can wait stays off the critical path
Round 3: Polish the network path
Smaller changes that added up:
- Critical CSS inlined into the JS entry to cut stylesheet round-trips
- Preconnect / dns-prefetch for the origins we hit at boot
- Non-critical startup deferred to idle time
We also added a CI performance suite: load the banner repeatedly on our embed harness, measure resources and timings, and fail the build if budgets regress. The ceilings evolve with the architecture; the gate stays.
Round 4: Pay only for the layout you use
Merchants were still downloading code for five layouts (bar, dialog, box, smart consent, native mobile) when each store only renders one. We split those into separate chunks and warm the right one early via theme prefetch and returning-visitor cache.
We kept trimming the default path too: custom font loading only when configured, and storefront footer features (Smart Privacy Center icon, EU Withdrawal Page geo-gating) on their own lightweight endpoint so they don't ride along on banner settings.
The result
Roughly 3× faster on the metric we were improving, without giving up the strengths we already had - a low memory footprint, near-zero layout shift, and no long main-thread blocks on the harness.
Round 4 was less about another headline number and more about cost model: a dialog store shouldn't download smart-consent or native-mobile code it never shows. CI now watches that shape so the waterfall doesn't quietly grow back.
Why we're sharing this
Performance work is easy to ship quietly. We're writing about it because it is part of the product: storefront performance can influence conversion and search ranking, so "loads fast" only counts if we keep measuring it.
When our own lab numbers showed a gap, we treated that as a backlog item - not a debate. When an approach stopped earning its keep, we simplified. As we add features, we'll keep measuring impact the same way.
What's next
These numbers will keep moving - that is intentional. The regression suite stays in the pipeline. Next we are focused on:
- Keeping optional features off the wire until a store actually uses them
- Tightening resource and byte budgets as we find more dead weight
- Pairing lab harness results with real-merchant production signals
If you care about compliance that stays out of the way of storefront speed, this is the kind of work we'll keep doing.
