Does a live chat widget slow down your website? We measured.

Does live chat slow down a website? Every widget we tested downloads code and runs scripts, so in that narrow sense yes. Whether it hurts your site in a way visitors would notice varies a lot by vendor. We measured ten widgets, including our own, and the honest answer has three parts. Before anyone clicks anything, a chat widget downloads somewhere between 49 KB and about 1 MB. On a throttled phone, the CPU time varies far more than the bytes do. And Talvo lands in the middle of the pack, not at the light end.

Here is the short version. Help Scout's Beacon was the lightest at 49.4 KB before a click, and Intercom the heaviest at 1,003.8 KB. Talvo came in at 280.1 KB before a click and 443.3 KB once opened: lighter than six of the other widgets, heavier than three (Tawk.to, Crisp and Help Scout). On widget CPU, Talvo was on the low side, at 187 ms on a simulated mid-range phone.

On Total Blocking Time (TBT), only LiveChat, HubSpot and Zendesk showed a clear increase on mobile, and Intercom was borderline. For everyone else, the effect was smaller than the noise. That does not mean the rest are free. It means this kind of test cannot see small costs on busy pages.

The rest of this post explains how we got those numbers, what they can and cannot tell you, where Talvo's own widget is wasteful, and how to run the same test on your own site in an afternoon.

How we measured, in plain words

We are one of the ten vendors in this test, so the method matters more than usual. Here it is without the jargon.

Two tools, two jobs. We used Lighthouse 12.8.2 driving Google Chrome 155.0.8059.40 to measure CPU and Total Blocking Time. We used Playwright 1.49.1 with Chromium 131 to count bytes before and after opening the chat.

Blocked-URL deltas. For each vendor, we ran Lighthouse on the page normally, then again with the widget's URLs blocked using Lighthouse's --blocked-url-patterns option. The difference between the two is the widget's effect on that page. Each arm ran five times, alternating normal and blocked, and we report the median. In total that was 220 Lighthouse runs, plus 10 runs of Talvo's no-snippet control page, run strictly one after another.

Mobile and desktop. The mobile profile is Lighthouse's Moto G Power emulation with simulated 4x CPU slowdown on a slow 4G connection (150 ms round trip, 1.6 Mbps). Mobile figures are simulated from a real load, not measured on a phone. The desktop profile has no CPU throttling.

The network split. To see what loads before and after a click, Playwright loaded each page with an empty cache and recorded every widget request for a fixed 30 seconds with no interaction. Then it clicked the launcher (or called the vendor's documented open command if the click did nothing) and recorded 19 more seconds. Three runs per widget, and we report the median. Sizes are transfer size, meaning compressed bytes on the wire including headers, and 1 KB is 1,024 bytes.

Limits of the setup. One machine, one evening (October 21, 2026), one US East location. This is lab data, not field data from real visitors. We did not click any cookie banner. Nothing here is a Core Web Vitals pass or fail.

Which pages we tested

We tested each widget on the page where we could confirm it was running. For most vendors that was their homepage. Three were different, and one is ours.

On talvo.chat itself, the widget is first-party, and its iframe reuses the JavaScript the homepage already downloaded. That makes the widget look nearly free, which is misleading, because your visitors would not have that bundle cached. So we tested Talvo on a tiny HTML page with nothing but the snippet, which is the closest thing to a customer install. For Talvo, the baseline was the identical page without the snippet.

What loads before anyone clicks

This is the table that stays true however you test it. Each figure is the median of three runs, and byte counts barely moved between runs (well under 1%), except HubSpot.

Almost all of it is JavaScript. For Talvo, 259.0 KB of the 280.1 KB is script.

The spread between the lightest and heaviest is about 20 times, and the byte count tells you less than you'd expect, because the widgets split into two camps.

Help Scout loads a 49.4 KB launcher and then 243.1 KB more only when a visitor opens it. LiveChat loads 362.2 KB up front and 390.2 KB more on open. Intercom front-loads about a megabyte and then adds 449.0 KB on open. Crisp's own site waits about 8.7 seconds before it requests anything, which looks like a choice that site made rather than the default for a customer. Freshchat, HubSpot and Tidio load nearly everything up front. Talvo loads 280.1 KB up front and 163.0 KB on open, and defers nothing.

Two table cells need a warning. Tidio's page shows a modal Cookiebot dialog, so the click landed on the dialog, and its open command did not visibly open the chat either. We have no after-opening number for Tidio. For Zendesk, Box hides the launcher, so the open command sent 22 more requests but nothing visibly changed on screen. Treat 276.9 KB as unverified.

CPU varies far more than bytes

Bytes cost time and data. CPU is what makes a mid-range phone feel sticky. This table shows how much main-thread time each widget's own scripts used on the throttled mobile profile, median of five runs, with the range in brackets. It also shows the change in Total Blocking Time between the normal and blocked runs.

A few readings. The heavy-CPU group (HubSpot, LiveChat, Intercom, Freshchat) spends one to two seconds of main-thread time on a phone profile, while the light group (Help Scout, Tidio, Tawk.to) spends about a tenth of a second. Between HubSpot and Help Scout that is about a 30-fold gap in CPU, against an 18-fold gap in bytes for the same pair (and 20-fold across all ten), and the two are not tightly linked: Tidio downloads 512.6 KB yet used only 114 ms.

Lower p-values mean the with-widget and blocked runs separated more cleanly. With five runs per side, the smallest p-value possible is 0.008, which means complete separation. LiveChat and Zendesk hit that floor, and HubSpot came close at 0.016. Intercom's 339 ms at p = 0.056 is borderline.

Everyone else is "inconclusive", which is not the same as "no effect". Vendor homepages run 20 to 60 other third parties, so the page's own noise is large. On Tidio's page, main-thread time ranged from 7.2 to 22 seconds between runs in the same arm. A 100 ms effect disappears in that. Also, TBT counts only long tasks before the page becomes interactive, and a lot of widget work happens after that.

On desktop with no CPU throttling, nothing stood out except Intercom at +69 ms (p = 0.032, weak evidence). One caution on desktop CPU columns: a widget that runs in a cross-site iframe does its work in a separate process that Lighthouse does not attribute to the page, so a 0 there means "not on the page's main thread", not "free". That is why we ran the mobile profile with Chrome's site isolation off, which is closer to how Chrome on a typical Android phone behaves.

Why Talvo's TBT is not in the comparison

Talvo's measured TBT change was +6 ms on mobile. Please do not line that up against the +1,080 ms or +492 ms above. We tested Talvo on a nearly empty page, and on an empty page a widget's work only counts toward TBT if one single task runs longer than 50 ms. On a busy marketing page, the same work stretches tasks that are already running and counts for much more. The vendors were measured on busy pages, so the two sets of TBT numbers are not the same kind of number.

The comparable columns are bytes and widget script CPU, and on those, Talvo is mid-pack on bytes and low on CPU. We would rather you know the whole picture: across all main-thread work on the plain test page, the page took 428 ms with the Talvo widget against about 70 ms without it, a difference of about 360 ms.

The one LCP result we will quote

We are not quoting Largest Contentful Paint numbers, because Lighthouse's simulated LCP swung by 10 to 30 seconds between runs on several of these pages. One result held up, because the simulated and observed figures agreed. On Intercom's homepage, in 4 of 5 mobile runs with the widget, the text of the OneTrust cookie banner became the LCP element at about 31 seconds in the simulation. It never did that with the widget blocked. The observed, unthrottled LCP also rose from 470 ms to 2,790 ms (p = 0.008). The widget indirectly changed what the browser counted as the page's biggest element. That is a reminder that a widget can affect Core Web Vitals through side effects, not just by being heavy.

What the numbers do not say

Please do not turn this into "LiveChat slows your site by 1,080 ms" in a slide deck. That is the difference on LiveChat's own marketing page, under a simulated phone, on one evening. On your page, the number will be different.

Some other limits worth keeping in view:

• Crisp's CPU is missing. Its widget requests start about 8.7 seconds after navigation, after Lighthouse stopped recording. Only its 3 KB loader was captured, so its CPU and TBT figures leave out the widget. Bytes come from the separate 30-second window.
• Tidio and Zendesk after-open figures are missing and unverified, as above.
• Widget configuration differs. Proactive messages, AI greetings, sounds and attention grabbers are all configured per site. A vendor's homepage shows one setup, not the minimum.
• Region matters. On the pages we tested, cookie banners did not stop the widgets from loading in this US-located test. Visitors in the EU may get a consent-gated load that behaves differently. We did not click any banner.
• Five runs per arm is a small sample. At these noise levels, a 50 to 150 ms effect on a busy page can't be resolved.
• Talvo shipped a new build mid-test. The bundle hashes changed, but transfer sizes stayed within 1 KB.

The test also registered roughly 40 synthetic visitor sessions in Talvo's own workspace. No forms were submitted and no chat messages were sent.

Where Talvo's widget is wasteful

You are reading a post on a vendor's blog, so here are the weak spots in our own widget, as the data shows them today.

That is why a plain page pays 280.1 KB before anyone clicks. The chat iframe loads a vendor bundle of about 211 KB compressed, an app script of about 36 KB and a stylesheet of about 13 KB. The loader itself is served uncompressed (12.0 KB) with cache-control: no-cache, so the browser revalidates it on every page view.

Opening the chat was also heavier than it should have been. In our October 21 runs it fetched the full help-article list (about 100 KB) and roughly 60 KB of code written for Talvo's marketing pages that a visitor in the chat panel never sees. Since then, Talvo changed the widget so opening it fetches only a few starter article titles, under 1 KB, and the full list loads when a visitor opens the Help tab. The 163.0 KB "after opening" figure in the table was measured before that change; we'll re-run the test and update it.

The widget also kept talking after it loaded. In our runs it checked for matching proactive campaigns about every 3 seconds and sent a heartbeat about every 20 seconds, roughly 20 small requests per minute for an open tab. Each one was around 390 bytes, so the bandwidth was trivial, but on a phone the requests keep the radio busy. Talvo has since changed the campaign check: the widget asks once, a few seconds after the page loads, and asks again only at the time a campaign for that page could next match, or stops if none can. The heartbeat is unchanged.

On the credit side, the CPU is modest. 187 ms of script time on the throttled phone profile is lower than five of the competitors we could compare. The chat interface lives in its own iframe, so your page's CSS can't restyle it and its styles can't leak into your page.

Test your own site in an afternoon

Our numbers describe our test pages. The only numbers that matter for your decision are the ones from your own pages, and the method is cheap. Lighthouse's variability guide says the median Lighthouse score of five runs is twice as stable as a single run. That is why we used five runs per arm, and it is a sensible minimum for your own test.

1. 1Pick a representative pageUse a real page with your usual tags and consent banner, not an empty test page. Test your pricing or product page, since that is where chat matters.
2. 2Find the widget's URLsOpen DevTools, load the page, and list the requests from the chat vendor's domains in the Network tab. Note the host patterns, such as *widget.example.com*.
3. 3Run it normally, five timesnpx lighthouse https://yoursite.com/page --only-categories=performance --output=json --output-path=./with-1.json, then repeat for runs 2 to 5. Add --preset=desktop for the desktop profile.
4. 4Run it blocked, five timesSame command plus --blocked-url-patterns='*widget.example.com*'. Repeat the pattern flag for each host. Alternate normal and blocked runs so drift hits both.
5. 5Compare mediansTake the median TBT, total byte weight and script time for each arm. Judge whether the gap is bigger than the spread within each arm. If the ranges overlap heavily, you have your answer: the effect is smaller than your page's noise.
6. 6Open the chat and record itIn the DevTools Performance panel, record while you click the launcher and send a message. Look for long tasks attributed to the vendor's scripts. This is the cost Lighthouse's load test does not capture.

You can do the A/B by hand without the command line. In Chrome DevTools, the Request conditions drawer (formerly Network request blocking) lets you add URL patterns with * wildcards and block them, then re-run the Lighthouse panel. WebPageTest also supports blocking requests by URL substring, running multiple runs and a repeat view for the warm-cache case.

Two version notes. Lighthouse 13 removed the third-party-facades audit with no replacement, and replaced the older "Reduce the impact of third-party code" audit with a third-parties insight. If a guide tells you to look for an audit that your Lighthouse doesn't show, that is probably why. State your Lighthouse version whenever you report results.

Also, lab tests are not your Core Web Vitals. Google's field data, from the Chrome UX Report, covers a 28-day window and only sites with enough traffic, and it can't isolate one script. If you want to know whether chat moved your real-visitor numbers, you need weeks of before-and-after traffic, and a small site may not have data at all.

How to shrink any widget's cost

If your test shows a real cost, the fix rarely means dropping chat. It usually means changing when the widget loads.

Load it after the page is done. An async script tag keeps the widget from blocking HTML parsing, but it still competes for the network and the main thread during load. Starting it from a load handler, or from idle time, moves the cost behind the content your visitor came for. Our guide to adding live chat shows how to do this in Next.js, and the install help article covers the standard snippet.

Use a facade. Google's third-party facades guidance describes a static placeholder that looks like the widget, warms up the connection when the visitor hovers, and swaps in the real widget only when they click. It lists Intercom, Drift, Help Scout and Facebook Messenger as chat embeds that suit the pattern. The catch is lost behavior: a facade can't show an unread-message badge or fire a proactive message until the real widget is loaded. We have not tested a facade with Talvo's loader, so we are not claiming it works.

Load it where chat earns its keep. Chat on every page is not mandatory. Pricing, product and signup pages are where a question tips a decision, while a long blog archive may not need a widget. Remember that the cost applies whether the thing in the corner is a chatbot or live chat, so decide what you need first. Our post on chatbot vs live chat helps with that.

If you are still choosing a tool, speed is one input among several. The best live chat software for small business comparison weighs price, channels and AI against each other.

If you want to see the widget for yourself, the messenger page shows what it does, and the cheapest way to judge its weight is to run the test above against it.