Inside the widget speed program: cutting our embed JS by two thirds

The ledger: what we cut

Two items deserve a word. The icon change sounds trivial and is not: 87 icons pulled in a 40 KB vendor bundle where the actual path data was about 3 KB, so we generated our own components once and deleted the dependency. The modal change is about fairness across devices. A desktop shopper was downloading the mobile bottom-sheet, a Shopify store was downloading the WooCommerce panel, and everyone was downloading one customer’s demo dataset. Each variant now loads only where it can actually render.

The bigger win: loading nothing

Bundle size is the second-order problem. The first-order problem is loading code on pages that will never show content. A product page whose product has no tagged posts used to download the entire widget, mount it, discover the empty response, and hide. The loader now remembers which galleries came back empty, races first visits against the data response, and skips the bundle when there is nothing to paint. Galleries embedded deep below the fold wait for an intersection observer instead of taxing initial page load.

For merchants who want to go further, an experimental lite mode paints the grid from the data response alone, with the interactive app arriving lazily afterwards. It is a flag on the embed div, it fails open in every path we could think of, and it exists because the honest end state of a widget speed program is first pixels that cost almost nothing.

Mobile apps: a supported path, not a shrug

Customers kept asking whether the widget works inside their native apps. The truthful answer was “usually, with sharp edges”: WebViews silently drop window.open, so product taps did nothing, and some ship with storage disabled. Both edges are now handled. Every outbound tap goes through a single exit point that can deliver a structured event to React Native, WKWebView or Android instead of opening a popup, storage degrades gracefully, and a diagnostic panel (add idk_appcheck=1 to any URL inside the app) tells support exactly what that WebView allows. None of this changes anything for regular web embeds; the bridge is strictly opt-in.

Proof over promises: the Performance page

Lab benchmarks flatter everyone. The number that matters is what your shoppers’ browsers measured on your pages, so the widget now reports a small sampled beacon (time to first tile, data latency, LCP, layout shift) to a new Performance page in the dashboard. You see your own percentiles, the trend over time, mobile against desktop, and how you compare with the fleet-wide benchmark across all Idukki widgets. When we say the widget got faster, you should be able to check.