Cooee is built so that adding it to your store has near-zero effect on how fast your pages load. This article explains the specific engineering choices behind that, and what we measure.
How Cooee is built for performance
1. Non-blocking script loading
Cooee's SDK is added to the page as a module script with the browser's async flag. Module scripts never block HTML parsing — the browser continues building and painting your page while Cooee is fetched in the background.
In practice this means Cooee cannot delay your content appearing. It is not in the critical path for rendering, and nothing about your page waits on it.
2. Code is added only when it is needed
Cooee does not ship one fixed payload to every page. Most of what it can inject sits behind a condition, so a page that does not need a feature never downloads the code for it.
Experiments are the clearest example. The experiment runtime is only added when your store actually has a live experiment:
{%- assign activeExperiments = app.metafields.letscooee.activeExperiments -%}
{%- if activeExperiments and activeExperiments.value.size > 0 -%}
<script id="cooee-experiments">...</script>
{%- render 'experiment-runtime' -%}
{%- endif -%}
With no experiment running, that block renders nothing at all — not a deferred script, not an empty tag. Zero bytes reach the browser. The same pattern governs page context: the product snippet renders only on product templates, the cart snippet only on cart templates, and so on.
3. Small, chunked files — you load only your features
Rather than one large JavaScript file, the SDK is split into small chunks along feature boundaries. A chunk is fetched the first time a page actually needs it, and never fetched otherwise. Two stores running Cooee can therefore download quite different amounts of code, depending only on what each has switched on.
No progress bar configured? The progress bar code is never downloaded, on any page.
Shoppable video only on your product pages? Your homepage and collection pages never fetch the video player.
Not using swatches? That code is absent from every page load.
The practical effect is that the cost of Cooee scales with what you use, rather than with everything Cooee is capable of.
4. Lazy loading within a page
The same principle applies again inside a single page. The widget rendering engine is only downloaded when there are active widgets to display. If a page has no widgets running, that code is never fetched — saving both bandwidth and JavaScript execution time.
5. Minified and mangled JavaScript
Everything Cooee ships is compiled and minified before it reaches your store. Comments and whitespace are stripped, and every internal name is shortened to a character or two. Our source is written to be readable by our engineers; what your visitors download is optimised purely for size.
Here is a real example. This is how we write it:
export function showAntiFlicker(): void {
if (document.getElementById(STYLE_ID)) return;
const style = document.createElement('style');
style.id = STYLE_ID;
style.textContent = 'body{opacity:0!important;pointer-events:none!important}';
document.head.appendChild(style);
_timeout = setTimeout(removeAntiFlicker, TIMEOUT_MS);
}
And this is the same function as it actually ships — one line, every name shortened:
var b="lc_anti_flicker",J=1500,x=null;function W(){if(document.getElementById(b))return;const e=document.createElement("style");e.id=b,e.textContent="body{opacity:0!important;pointer-events:none!important}",document.head.appendChild(e),x=setTimeout(T,J)}
The function name becomes W, the constants become b and J, comments are gone, and separate statements are merged. Across the theme runtime, roughly 39 KB of source compiles down to about 12 KB of JavaScript.
6. CDN delivery
Nothing Cooee serves comes from a single origin server. Two separate CDNs are involved:
SDK JavaScript and CSS are published to jsDelivr, which is itself backed by Cloudflare's global network — one of the fastest and most widely distributed in the world. Your visitors get the SDK from a Cloudflare edge node near them.
Widget configuration and campaign data are served via Amazon CloudFront. API responses are delivered from the edge location nearest each visitor, keeping latency low regardless of where your customers are.
7. Viewport-aware video playback
Videos inside Cooee widgets only begin playing once they scroll into the visitor's viewport, so off-screen video never consumes bandwidth or competes with your page for resources while it is loading.
8. No media hosted by Cooee
Cooee does not host product images, collection images, videos or GIFs on its own servers. Those assets are served from your store's files or Shopify's CDN — the approach Shopify recommends — so they benefit from the same caching as the rest of your storefront.
Redirect experiments: a deliberate exception
Theme, split-URL and template experiments decide a visitor's variant in the page <head> before anything renders, then redirect if needed. To stop visitors seeing a flash of the original page first, Cooee briefly masks the page while that decision is made and clears the mask the moment the variant is settled, with a short safety timeout as a backstop.
This is a deliberate trade-off: a brief, controlled pause in exchange for a clean experience with no content flicker. It applies only to stores running a redirect experiment, and only to pages within that experiment's scope. Stores with no live redirect experiment are unaffected.
What we measure
We validate real-world impact with Google PageSpeed Insights, comparing a store before and after the SDK is enabled. Across the core metrics we see near-zero impact:
First Contentful Paint — near zero impact
Largest Contentful Paint — near zero impact
Time to Interactive — near zero impact
Total Blocking Time — near zero impact
Speed Index — near zero impact