How Much Does a Chat Widget Slow Down Your Site? 10 Widgets Measured

Whether a chat widget slows down a website is usually argued with vendor claims and single PageSpeed screenshots. This post answers it with measurements: each vendor's official snippet on an otherwise empty page, and what it costs before anyone clicks.

The post is for site owners, marketers and developers choosing a chat widget or trying to fix a slow page. Everything below was measured on 19 October 2026 with Lighthouse 13.5.0 and Chrome 155, three runs per page, median reported. We tested 13 widgets. Ten loaded on our test page; Intercom, LiveChat and Smartsupp refused to start on a domain their own accounts do not list, so they get their own section.

PepoChat is our product. It was measured exactly like everyone else, its default configuration is not the lightest in the table, and the numbers are published as they came out.

How much does each chat widget add to a page?

Between 3.8 KB and 649 KB of downloads, 1 to 32 extra requests and 0 to 36 ms of Total Blocking Time, measured on a blank page on 19 October 2026. None of the 10 widgets changed the Lighthouse performance score, which stayed at 100, because none of them delayed the page's own first paint.

Method in brief: a plain HTML page with a heading and two paragraphs, and one copy per vendor with its official snippet before the closing body tag. Lighthouse loaded each page three times with its default mobile profile, which simulates a slow 4G connection and a CPU four times slower than the test machine. "Added" figures subtract the blank page, and nobody clicked a launcher.

Measured 19 October 2026: medians of three Lighthouse 13.5.0 runs per page, mobile profile, Chrome 155. KB means 1,024 bytes as Lighthouse reports it; transfer is compressed size over the network. Every page in this table scored 100 for performance. "Third-party script execution" is Lighthouse's bootup-time audit, which lists only scripts that ran for 50 ms or more, so light scripts count as zero; "added main-thread work" has no such cut-off. Some widgets in the Yes group still fetch extra pieces on first open, such as tawk.to's full-size chat window.

PepoChat's two rows are the same loader with one attribute changed. By default it fetches the chat frame in browser idle time after the page has loaded, so the first click opens instantly: 21 requests and 523 KB over the network, about 1,680 KB once uncompressed. The frame is a cross-origin iframe, and desktop Chrome runs its scripts in a separate process, which is why its main-thread columns stay low here; the Android section below shows what changes when that frame shares your page's main thread.

Tidio downloads its full widget before a click, including two fonts (99 KB) and two notification sounds (35 KB); its launcher never appeared on our test page, so its main-thread figures may understate a visible widget. Gorgias also prefetches about 222 KB of script chunks that Lighthouse files as "Other" rather than JavaScript. HubSpot's row is its tracking code as HubSpot's own portal configures it: a cookie banner (149 KB), a Facebook pixel (117 KB), analytics (52 KB) and the conversations script (30 KB). The chat window itself was never requested, most likely because HubSpot's own chatflows are set to appear on hubspot.com pages; on your site the tracking code loads whatever your portal has switched on.

How we measured, and what we did not

The test ran on a 12-core Apple M6 Mac under macOS 27.0.1, with Google Chrome 155.0.8059.84 driven headless by Lighthouse 13.5.0 through its chrome-launcher, which starts every run with a fresh temporary profile. The flags were the defaults plus --only-categories=performance --output=json --quiet --chrome-flags="--headless=new". Pages were served from http://127.0.0.1:8731 by Python's built-in web server, and each page was run three times in rotation so a slow minute could not hit one vendor only.

We created no accounts. Each snippet carries the public ID the vendor runs on its own website, read from its page source or from one Lighthouse run against that page; PepoChat used the demo workspace on pepochat.com. Where the install documentation showed the snippet only as a screenshot, inside the dashboard or behind a bot check (tawk.to, Tidio, Crisp, Chatbase, Gorgias and Help Scout), we used the snippet the vendor runs on its own site and checked it against the documented format.

Sources checked 19 October 2026. Protocol-relative URLs (starting with two slashes) were written as https because the test page itself was served over http.

Two adjustments keep the comparison fair. Every page, the blank one included, starts with one line of script that deletes four helper variables Lighthouse injects, because Crisp's loader checks for two of them and skips its chat client when it finds them: with them in place, Lighthouse saw only Crisp's 3.2 KB loader; without them, the 110 KB a real visitor's browser downloads. And every "added" figure subtracts the blank page's own 1.1 KB and one request. Two vendors are missing on purpose. Drift is being retired, on 31 January 2027 according to Salesloft's Drift Sunset FAQ as recorded on our Drift alternative page on 3 October 2026, and the only Freshchat token we found on Freshworks' sites belongs to a hidden messenger whose start-up code is commented out.

The limits are real. This is lab data from one machine with simulated throttling, on an empty page where nothing else competes for the network or the CPU. Each vendor's own account settings shape what loads, as HubSpot's chat targeting shows. And we measured page load only: no launcher was clicked, no chat opened and no message sent, except for PepoChat's own chat frame, measured separately below.

Which chat widgets refused to load on a test page?

Intercom, LiveChat and Smartsupp each refused to start on our test page, because their own accounts only accept their own domains. That is a sensible security setting, and PepoChat has the same idea in its allowed domains list, but it means these three cannot be measured on a neutral page without an account.

Intercom's API answered the messenger's start-up request with a 403 saying the domain "has not been trusted" for that app. The launcher never appeared, yet the browser still downloaded and ran the full messenger code: 914.6 KB in 12 requests, 121 ms of Total Blocking Time and 343 ms of third-party script execution, with a score of 99. LiveChat's configuration lists the domains its license accepts (livechat.com, text.com and a few others); on our page the loader fetched that configuration and never requested the chat window, 39.7 KB in all. Smartsupp's bootstrap request came back with a 403 and the code domain_not_allowed, after 6.5 KB.

To show what these three load where they are allowed, we ran Lighthouse three times on each vendor's own home page and counted only the requests to the widget's domains.

Measured 19 October 2026, medians of three runs. Home-page figures are not comparable row for row with the blank-page table: those pages carry their own scripts, fonts and images, and vendors may configure their own widgets differently from a customer's.

Intercom's messenger downloaded the same 911 KB of JavaScript on intercom.com as on our page, so its refused-page figure is a fair guide to its size. One caution: with Lighthouse's helper variables left in place, the refused Intercom page stopped at about 229 KB in all three runs, so a stock Lighthouse test can understate it. LiveChat runs its chat window in a cross-origin iframe, which keeps that window's scripts off the page's main thread in desktop Chrome, as with PepoChat's preloaded frame.

Why do some chat widgets cost over 100 times more than others?

Because of one design choice: whether the widget downloads its whole chat application when the page loads, or only a small launcher until someone opens the chat. Everything else (fonts, sounds, analytics) adds tens of kilobytes; that choice adds hundreds.

Eager widgets fetch the complete chat app with the page: Gorgias, Tidio, PepoChat in its default mode, Zendesk, tawk.to and Crisp, plus Intercom, which downloaded its full messenger even where it was refused. The benefit is a chat that opens instantly and can show proactive messages, unread badges and online status the moment the page appears. On-demand widgets load a launcher and wait for the click: Chatbase, Zoho SalesIQ, Help Scout Beacon and PepoChat with data-preload="false". They cost a fraction at page load and make the visitor wait a moment on first open. HubSpot sits between the two: its tracking code loads up front, and the chat window only where a chatflow is set to appear.

Inside the eager group, extras explain the spread: 134 KB of fonts and notification sounds in Tidio's case, prefetched chunks and 48 KB of fonts from a separate font host in Gorgias's, and a full web app with its own fonts and styles in PepoChat's preloaded frame. None of this is wrong in itself, but on a phone each kilobyte competes with your own page.

Does a chat widget hurt Core Web Vitals or Google rankings?

Not much in the lab, and only through real-user data in rankings. In our tests no widget moved Largest Contentful Paint (607 to 610 ms) or Cumulative Layout Shift (0 on every page), because the widgets loaded after the content and their launchers are fixed in a corner where they shift nothing.

The real risk is responsiveness. Interaction to Next Paint (INP) is the Core Web Vital that measures how long a page takes to respond to clicks, taps and key presses; web.dev's INP guide rates 200 ms or less as good, measured at the 75th percentile of real page loads. A widget that runs hundreds of milliseconds of script on the main thread can delay the response to a tap that lands during its start-up. Total Blocking Time is the lab stand-in: the time after first paint during which long tasks block input, and web.dev's TBT article sets the target under 200 ms on average mobile hardware. The worst TBT among the 10 measured widgets was HubSpot's 36 ms, and the largest added main-thread work was HubSpot's 510 ms, followed by Gorgias at 401 ms.

On rankings, be careful with claims in either direction. Google's Core Web Vitals page sets the targets at LCP within 2.5 seconds, INP under 200 ms and CLS under 0.1, and says Core Web Vitals align with "what our core ranking systems seek to reward". Search Console's Core Web Vitals report is built from real-world usage data in the Chrome UX Report, not from Lighthouse. A widget therefore matters for search only if it pushes your real visitors' 75th-percentile numbers past those thresholds. A lab score, ours included, is a diagnostic, not a ranking input.

What changes on Android phones?

On many Android phones, a chat frame's scripts can share your page's main thread, which our main table does not show. Desktop Chrome isolates every site in its own process, so a cross-origin chat iframe runs its code elsewhere; Chromium's site isolation documentation says Chrome on Android isolates only a subset of sites, mainly ones users log into, and only on devices with at least 2 GB of RAM.

To approximate that, we ran every page three more times with site isolation switched off (--disable-features=IsolateOrigins,site-per-process).

Measured 19 October 2026, medians of three runs, same pages and profile as the main table.

PepoChat's default row changes for a structural reason: its preloaded chat frame is the kind of cross-origin iframe desktop Chrome keeps off the page's main thread. With isolation off, the frame's scripts added 37 ms of Total Blocking Time and 98 ms of script execution (141 ms of main-thread time in all), with one long task of about 87 ms after the page had loaded. The other rows moved by up to about 70 ms either way between passes; those widgets run in your page in both cases, so that is ordinary run-to-run variation.

What does PepoChat load when a visitor opens the chat?

With preload off, the first click loads the chat frame; with preload on, that same frame has already been fetched during idle time. To show the cost either way, we loaded the frame's own address directly with Lighthouse, three runs each: the preload address and the address the loader opens on a click, which also starts a visitor session.

Measured 19 October 2026, medians of three runs, Lighthouse mobile profile.

Either way the chat app is about 530 to 550 KB, of which 449 KB is JavaScript, and when loaded on its own its largest element painted after about 3.7 seconds on Lighthouse's simulated slow 4G connection. That is a rough guide to the first-open wait with preload off. With preload on, the same cost is paid in idle time after your page has loaded, and the window opens instantly. Gorgias, Tidio, Zendesk, tawk.to and Crisp pay their equivalent cost at page load for every visitor, and the main table already includes it. Chatbase, Zoho SalesIQ and Help Scout Beacon, like PepoChat with preload off, pay it on the first open instead; we did not open their chats, so that cost is not in this post.

The behavior and API docs describe both modes. A preloaded PepoChat frame only reads your workspace settings, and a visitor session is created only when someone opens the window, so preloading costs bandwidth, not conversations.

How do you keep any chat widget from slowing your site?

Choose the loading mode on purpose, load the widget after the page and not before it, and keep it off pages that do not need it.

1. Check your widget's loading mode. Some vendors offer one. In PepoChat it is one attribute: data-preload="false" on the script tag, or the Preload the chat in the background switch in the WordPress plugin settings. The install docs list every attribute.
2. Never block rendering. The snippet belongs just before the closing body tag or carries async or defer. The script tag guide explains placement for each site builder.
3. Skip pages where chat does not help. Checkout steps and landing pages built for speed rarely need a launcher. PepoChat's WordPress plugin, for example, hides the widget by path; check whether your vendor offers the same.
4. Wait for consent where you need it anyway. If your cookie banner already gates analytics, loading the widget after consent removes it from the first page view; our guide to loading the widget after consent has a pattern that also offers a click-to-load button.
5. Delay the load until the visitor interacts. The pattern below works with any vendor whose snippet you can paste.

<!-- Load a chat widget on the first interaction, or 5 seconds after page load -->
<script>
  (function () {
    var started = false;

    function loadChatWidget() {
      if (started) return;
      started = true;
      // Replace with your vendor's loader. Example: PepoChat.
      var s = document.createElement("script");
      s.src = "https://widget.pepochat.com/widget.js";
      s.async = true;
      s.setAttribute("data-organization-id", "YOUR_ORGANIZATION_ID");
      document.body.appendChild(s);
    }

    ["pointerdown", "keydown", "touchstart", "scroll"].forEach(function (type) {
      window.addEventListener(type, loadChatWidget, { once: true, passive: true });
    });

    window.addEventListener("load", function () {
      setTimeout(function () {
        if ("requestIdleCallback" in window) {
          requestIdleCallback(loadChatWidget, { timeout: 2000 });
        } else {
          loadChatWidget();
        }
      }, 5000);
    });
  })();
</script>

For vendors whose snippet sets a configuration variable first (Crisp's website ID, Intercom's settings object, LiveChat's license number), keep that line outside the function and move only the part that inserts the loader script inside it. Tidio's developer documentation shows its own variant that simply waits five seconds.

The same reasoning sits behind web.dev's advice to load third-party JavaScript efficiently: asynchronous scripts, early connections to the origins you use, and lazy loading for the rest. How the widget should behave once it is loaded is covered in our website chatbot best practices.

What does HTTP Archive data say about chat widget performance?

Both sources put Zendesk's main-thread cost above tawk.to's, but HTTP Archive's numbers are several times larger, because it measures real home pages instead of an empty one. The open-source third-party-web dataset behind thirdpartyweb.today attributes main-thread script time to each vendor across about 4 million sites that HTTP Archive crawls with Lighthouse on mobile. Version 0.30.0, published 14 September 2026, uses the crawl of 1 March 2026.

Source: third-party-web 0.30.0 (HTTP Archive crawl of 1 March 2026), read 19 October 2026; average impact is total execution time divided by pages. PepoChat, Chatbase, Gorgias and Zoho SalesIQ are not in the dataset.

Three cautions before you quote these figures. Each entity covers every script on the vendor's domains, so Zendesk's and HubSpot's numbers can include help centers and sites hosted on their platforms, not only chat. Tidio's entity maps only one of its domains, which is why it appears on just 79 pages. And Crisp's 33 ms average most likely reflects the same Lighthouse detection we hit: Crisp averages about one script per page there (1,584 scripts on 1,577 pages), consistent with only its loader running.

What to do next

Measure your own pages with and without the widget: three Lighthouse runs each way, the Network panel in an ordinary Chrome window to catch widgets that behave differently under Lighthouse, then a month of field data in Search Console. If you are choosing a widget, Tidio vs Crisp vs PepoChat compares features and prices next to these costs. To try the lightest configuration in this test, start a free PepoChat workspace, add the script tag with data-preload="false" and run the same measurement on your own site; every feature is on the free plan.