Fixing Main-Thread Blocking From Chat Widgets

Support chat widgets are among the heaviest third-party scripts a static site carries: a loader, a full messaging application, fonts, an iframe or two, a WebSocket and often analytics of their own. They usually load on every page, immediately, because that is what the vendor's snippet does. On a static page that otherwise ships almost no JavaScript, a chat widget can be the entire main-thread cost — and since it runs during and just after load, it lands exactly when readers first try to scroll, tap a menu or open search.

This guide measures the cost of a commercial chat widget on a SaaS documentation and marketing site built with Eleventy, then reduces it in three steps: deciding where chat is needed, delaying the vendor until the page is idle, and replacing the eager widget with a static launcher that loads it on click. It belongs to Third-Party Script Performance on Static Sites; the general facade pattern is in Facades for Chat Widgets and Maps.

Step 1: Measure the Widget's Cost

A Performance panel recording of a docs page on a 4× throttled CPU, grouped by domain, attributed the main-thread time:

Lighthouse's "Reduce the impact of third-party code" audit agreed within 10%. To confirm the effect in the field, a 10% sample of sessions had the chat script blocked through a feature flag for a week, and INP and Total Blocking Time were compared, as in Measuring Third-Party Cost with Request Blocking.

The field comparison: sessions without the widget had INP p75 of 110 ms on mobile; sessions with it, 230 ms. One widget doubled INP for the whole site.

Step 2: Load Chat Only Where Support Is Offered

The support team was asked where chat mattered. Analytics answered more precisely: 84% of conversations started on pricing, account, billing and three troubleshooting sections of the docs — about 9% of page views. Reference documentation, the blog and the changelog produced almost none. The widget now loads only on templates and sections flagged in front matter:

# docs/troubleshooting/troubleshooting.11tydata.json
{ "chat": true }

{% if chat %}<div id="chat-launcher-slot"></div>{% endif %}

On every other page, the widget simply does not exist. A "Contact support" link in the footer goes to the support page, which has chat.

Step 3: Never Load the Vendor During Page Load

On pages that do offer chat, the vendor script still ran its 690 ms during load. Two changes moved that work out of the window when readers first interact.

First, a static launcher, rendered at build time, that looks like the vendor's button:

<button class="chat-launcher" type="button" aria-label="Open support chat" hidden>
  <span class="icon" aria-hidden="true"></span>
</button>

Second, the vendor loads on the first of: a click on the launcher, or the page being idle for a few seconds after load and the reader having scrolled — a sign they are reading rather than bouncing. A click shows "Connecting…" in the launcher immediately, loads the vendor, and opens the conversation when it is ready:

const btn = document.querySelector('.chat-launcher');
btn.hidden = false;
let loading;
function loadChat(open) {
  loading ??= new Promise((res) => {
    const s = Object.assign(document.createElement('script'), { src: 'https://widget.chat-vendor.example/v3/loader.js', async: true });
    s.onload = () => window.ChatVendor.init({ appId: 'acme', hideDefaultLauncher: true }).then(res);
    document.head.append(s);
  });
  if (open) { btn.dataset.state = 'loading'; loading.then(() => { window.ChatVendor.open(); btn.dataset.state = ''; }); }
}
btn.addEventListener('click', () => loadChat(true));
addEventListener('scroll', () => requestIdleCallback(() => loadChat(false), { timeout: 8000 }), { once: true, passive: true });

hideDefaultLauncher keeps the vendor from adding its own button, so the static one stays in control. The idle preload means that for most readers who do click, the widget is already loaded and opens instantly.

Step 4: Keep the Widget Accessible

The vendor's default launcher had been a <div> with a click handler. The static launcher is a real button with an accessible name, reachable by keyboard, and it moves focus into the chat panel when it opens. The vendor's panel, once loaded, handled focus within itself. An axe scan of the open state showed no new violations, while the old launcher had produced two.

Step 5: Check the Business Metric

Performance changes to support tools need sign-off from the team that owns them. Over four weeks, before and after:

Conversations held steady. The cold-click case — a reader clicking before the idle load — took about a second, with the "Connecting…" state making the wait clear.

Why Not Partytown or a Worker?

Moving third-party scripts into a web worker with Partytown is often suggested for heavy vendors, and it was tried here. It did not suit a chat widget. The widget manipulates the DOM constantly — rendering messages, animating the panel, handling input — and in Partytown every DOM access from the worker becomes a synchronous round trip through the main thread. Opening the panel took 2.3 seconds in a test, and typing lagged visibly. Workers suit scripts that mostly compute and send data, such as some analytics; widgets that are themselves user interfaces belong on the main thread, loaded only when they are needed. Running Third-Party Scripts in a Web Worker with Partytown covers where it does help.

Keeping New Vendors in Check

The chat widget was not the last vendor the site will add. A short policy now applies to any third-party script: it must name the pages it needs, load no earlier than idle time unless it affects the first paint, and come with a before-and-after Lighthouse run on one affected page in the pull request. The Lighthouse CI budget for JavaScript per template enforces the first rule mechanically, since a vendor loaded site-wide pushes every template over its budget.

Measured Impact

Pitfalls & Rollback

• Assuming async solves it. The work still runs during load.
• Loading chat everywhere. Ask where conversations start; most pages never need it.
• A launcher that does nothing visible on click. Show a loading state immediately.
• Changing support tooling without the support team. Track conversation rates before and after.
• Rollback: the front matter flag and the loader are separate; setting chat: true site-wide restores coverage while keeping the deferred loading.

Conclusion

A chat widget can be the largest main-thread cost on a static site. Measuring it, limiting it to the 9% of page views where support conversations actually start, and replacing the eager vendor snippet with a static launcher that loads the widget during idle time or on click halved site-wide INP and cut Total Blocking Time on docs pages from 620 to 80 ms, with no change in how often readers started a conversation.

FAQ

How much does a chat widget slow a page?

On the site in this guide, the vendor's widget added 410 kilobytes of JavaScript and 690 milliseconds of main-thread work on a mid-range phone during load, split into long tasks of up to 280 milliseconds. That raised Total Blocking Time from 80 to 620 milliseconds and field INP by about 120 milliseconds on pages where it loaded.

How do I measure a third-party widget's main-thread cost?

Record a Performance panel trace with CPU throttling and group activity by domain or by third party, or use Lighthouse's third-party summary, which attributes main-thread time to each vendor. For field impact, compare INP attribution with and without the widget by blocking its domain for a small share of sessions.

Does loading the chat script with async or defer fix the problem?

Only partly. async and defer stop the script from blocking HTML parsing, but the script still runs during or right after load, producing long tasks that delay the first interactions. The main-thread cost has to be moved later, to idle time or the first user interaction, or avoided on pages that do not need chat.

Will readers notice if the chat widget loads on click?

In the test in this guide, chat conversations started per thousand page views were unchanged when the real widget loaded on the first click of a static launcher. The launcher looks the same and shows a loading state for under a second while the widget initialises.

Related

• Parent: Third-Party Script Performance on Static Sites — third-party costs and controls.
• Facades for Chat Widgets and Maps — the facade pattern in general.
• Auditing Third-Party Scripts With Lighthouse — attributing main-thread time.
• Fixing Poor INP on Static Pages With Heavy Widgets — the chat launcher among other widgets.
• Running Third-Party Scripts in a Web Worker with Partytown — why that does not suit chat widgets.