CartBuddy AI Start free

Five grams, zero scripts: the case for a tiny chat widget

Every chat widget we tested added more JavaScript than our entire storefront. Why we built one that loads after your page has painted, and what that discipline buys.

The CartBuddy dashboard showing conversation volume, recovered carts and revenue next to the merchant's own speed score.
The dashboard is where the smallness shows up as numbers rather than opinions.

Before writing a line of the widget, we installed the popular chat tools on a test store and weighed them. The lightest added about two hundred kilobytes to every page view. The heaviest came in near four hundred. For scale: our storefront’s own JavaScript, theme included, weighed less than most of them.

A tool that exists to help you sell was costing more bytes than the shop it sits on. That gap is the whole of this post.

What a widget owes the page it lands on

A chat bubble is not the reason a shopper came. It is a late-arriving guest, and the page’s job — the product photos, the buy button, the Core Web Vitals — outranks it in every way that matters. So the widget’s design rule was written before the code: the storefront pays nothing for chat until the shopper asks for chat.

What the page pays Chat closed Chat open
JavaScript executed none one small gzipped file, loaded on open
Network connections 0 one socket, on the open action
Blocking time added 0 ms 0 ms
Tracking or polling none none

In practice that means the bundle is one small file, gzipped to under six kilobytes, requested only when the browser is idle. The bubble appears after the page has painted, and until it is opened it opens no sockets, runs no polling and sends no tracking pings — a shopper who never chats costs the page exactly zero.

Why the discipline holds

Small is easy on launch day and hard by the third quarter, which is why the limit is enforced rather than intended: the build fails if the gzipped bundle grows past its budget. Features have to argue their way in against the byte cost, and most lose. The ones that win tend to be the ones that move work off the browser entirely — the order lookups and inventory checks live on the server, where they are free to the page.

The honest caveat: a six-kilobyte widget cannot carry a rich in-page experience, so the conversation’s polish lives server-side, streamed in. That is a trade we would make again. Your product images should never have queued behind someone else’s framework.

The number that matters

Merchants do not buy a small widget; they buy what the smallness protects. On stores where speed scores were green before install, they stay green after — because almost nothing arrived.

← All posts