Widget speed: how much does a chat widget cost your PageSpeed score?

The like-for-like methodology

Widget-weight claims are easy to game, so any honest comparison has to fix four rules up front:

• 1. Gzipped transfer size, same basis for everyone. Compare what actually travels over the network. Mixing one vendor's gzipped number with another's parsed number is the most common trick - the parsed figure is several times larger.

• 2. Count everything the widget loads. The visible<script> tag is often a tiny loader that pulls in the real bundle, vendor chunks, fonts, and analytics afterwards. Sum every request the widget initiates, not the stub.

• 3. Cold cache. First visits are where PageSpeed and real visitors hurt. Disable the cache when you measure.

• 4. Default configuration. Measure the widget as a real customer ships it - default theme, default features - not a stripped demo build.

On that basis, our internal April 2026 sweep of popular chat widgets landed in the200–400 KB gzipped range (we re-check quarterly). Toran's bundle comes in at about 100 KB gzipped on the same basis.

A claim enforced in CI - not a marketing measurement

The number we publish is deliberately an enforced claim, not a snapshot. Every Toran release runs a size check that gzips the built widget bundle and compares it against an append-only size ledger: every kilobyte of growth has to be justified on the record, and the build fails outright if the bundle drifts past the point where "about 100 KB" stops being an honest description. A point-in-time measurement flatters the vendor and rots quietly as features pile up; an enforced claim means the number on this page is re-tested on every single deploy. When the bundle genuinely outgrows the wording - it happened once, by a fraction of a kilobyte - we change the public wording, not the measurement.

Don't take our word for it - vendors admit the cost

The clearest evidence that widget weight hurts PageSpeed comes from widget vendors themselves. Elfsight's own help center opens an article by asking, "Have you noticed that your page with the Elfsight widget has low PageSpeed scores?" - and then walks customers through lazy-loading the widget to soften the hit (their article). When the vendor's own documentation teaches mitigation, the performance cost isn't a competitor's smear - it's the product working as built. Lazy-loading is a real mitigation, but it defers the cost rather than removing it: the bytes still arrive, just later. The structural fix is a widget that's small in the first place.

See the full Toran vs Elfsight comparison or the compare hub for the feature-by-feature view.

How to verify it yourself

Ten minutes, no tooling to install. Run the same test on Toran and on whatever widget you use today:

DevTools Network tab (exact bytes)

1. Open a page that embeds the widget; open DevTools (F12) → Network tab.
2. Tick Disable cache, filter by JS, and reload the page.
3. Sort by domain and sum the "Size" (transferred) column for every request the widget's domains initiate - loader, chunks, vendor files.
4. That transferred total is the gzipped, like-for-like number. (The "Resource size" column shows the parsed weight the browser must execute - compare it for the same widget and you'll see the unpacking multiplier.)

PageSpeed Insights (the SEO view)

1. Run your page through pagespeed.web.dev.
2. In the diagnostics, open "Reduce the impact of third-party code" - it lists each third party's transfer size and main-thread blocking time.
3. For a controlled A/B: run a staging page with the widget snippet, remove the snippet, and run it again. The delta is the widget's true PageSpeed price.

Frequently asked questions