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 the 200–400 KB gzipped range (we re-check quarterly). Toran's bundle stays under 100 KB gzipped on the same basis.

A ceiling enforced in CI — not a marketing measurement

The number we publish is deliberately a maximum, not a snapshot. Every Toran release runs a size check that gzips the built widget bundle and fails the build if it exceeds 100 KB. A point-in-time measurement flatters the vendor and rots quietly as features pile up; an enforced ceiling means the claim on this page is tested again on every single deploy. If we ever blow the budget, we can't ship until we've earned the bytes back.

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