React Chat Widget: How to Add One Without Wrecking Your Core Web Vitals

Zendesk's chat widget downloads over 500KB of JavaScript — 2.3MB after unzipping — to render a button with a speech-bubble icon. That's the finding from DebugBear's benchmark of 21 live chat widgets, and it's worth sitting with for a second. Half a megabyte of code. For a button. Before anyone has typed a single word.

If you're adding a React chat widget to your app, that benchmark is the thing to internalize first. The widget itself is easy — every provider hands you a two-line snippet. The hard part is loading it so your Lighthouse score, your INP, and your actual users don't pay for a feature that most visitors will never click. In DebugBear's tests, the leanest widgets (LiveAgent, Zoho Desk) stayed under 100KB precisely because they delay loading most of their code until someone opens the chat. The heaviest fetched up to 749KB up front.

We build ChatterMate, an open-source AI support agent with an embeddable widget, so we think about this constantly — both as widget authors and as developers who have to live with the result. Here's how we'd wire a chat widget into a React or Next.js app today, from the naive version to the one we'd actually ship.

What a chat widget really costs

Chat widgets are third-party scripts, and third-party scripts have a habit of being the heaviest thing on the page. Google's web.dev guidance on third-party embeds notes that many popular embeds ship over 100KB of JavaScript, with some reaching 2MB. Every one of those bytes competes with your own bundle for bandwidth, then competes with your own code for main-thread time.

The DebugBear numbers make the spread concrete. Across the 21 widgets tested, download weight ranged from 67KB (Zoho Desk, MyLiveChat) to 749KB (Tawk.to at the time of testing). JavaScript execution time ranged from roughly 260ms to nearly a full second of CPU. And the time until the chat bubble actually appeared ranged from 2.5 seconds to 9.4 seconds.

Two lessons hide in that data.

First, the good news: almost none of the tested widgets blocked the initial render, because they're injected at the end of the body. Your hero image will still paint. The damage lands later — in main-thread work that inflates INP, in bandwidth stolen from images, in mobile CPUs grinding through a megabyte of decompressed widget code.

Second, the design that separates the light widgets from the heavy ones is lazy loading. The sub-100KB widgets load a tiny launcher and defer the real chat app until the user clicks. That's the pattern to copy — and if your provider doesn't do it for you, you can approximate it yourself. More on that below.

The wrong way: pasting the snippet into index.html

Every widget provider gives you something like this:

<script>window.chattermateId='YOUR_WIDGET_ID';</script>
<script src="https://app.chattermate.chat/webclient/chattermate.min.js"></script>

(That one is ours. Two lines: set the widget ID, load the script.)

The path of least resistance in a React app is to paste it straight into public/index.html. It works. But you've now given up all control. The script loads on every page, for every visitor, as early as the browser can manage it — including the large majority of sessions where nobody opens the chat. (DebugBear's blunt estimate: 99% of the time, users don't touch the chat feature.) You can't gate it by route, by consent, or by whether the user has scrolled past the fold. And in an SPA, "every page" really means "once, at the most expensive moment": initial load, exactly when your bundle, your fonts, and your LCP image are all fighting for the same connection.

One more trap for React specifically: dropping the <script> tag into JSX is unreliable. Depending on how the markup is rendered — hydration after SSR, or anything routed through dangerouslySetInnerHTML — the script may never execute, and you'll spend twenty minutes wondering why the bubble never shows up. You need one of the patterns below.

Plain React: inject the script in a useEffect

For a Vite, CRA, or plain React app, the standard approach is a small component that injects the script after mount:

import { useEffect } from "react";

export default function ChatWidget() {
  useEffect(() => {
    // Guard: never inject twice (StrictMode runs effects twice in dev)
    if (document.getElementById("chattermate-script")) return;

    window.chattermateId = "YOUR_WIDGET_ID";

    const script = document.createElement("script");
    script.id = "chattermate-script";
    script.src = "https://app.chattermate.chat/webclient/chattermate.min.js";
    script.async = true;
    document.body.appendChild(script);
  }, []);

  return null; // the widget renders its own UI
}

Drop <ChatWidget /> into your root layout and you're done. Three details matter here.

The guard clause is not optional. React 18's StrictMode mounts, unmounts, and remounts components in development, which means your effect runs twice. Without the ID check you'll inject two copies of the widget and get two chat bubbles, or worse, two socket connections.

Don't clean up by removing the script. Your instinct might be to return a cleanup function that deletes the script tag on unmount. Resist it. Most chat widgets attach global state, sockets, and DOM nodes outside your React tree; yanking the script tag doesn't undo any of that, and re-injecting on remount can double-initialize. Inject once, globally, and let it live for the session.

Mount it above your routes. If the component sits inside a route that unmounts on navigation, you'll trigger the remount problem on every page change. Put it in the layout that wraps everything.

This is already better than index.html — the widget now waits for your app to mount. But it still loads eagerly. We can do better.

Next.js: use the Script component, and get the order right

Next.js ships a purpose-built solution: the next/script component, which takes a strategy prop. The docs are direct about which one fits here: lazyOnload — which defers the script to browser idle time, after everything else has loaded — is the recommended strategy for chat support plugins. The Chrome team's write-up on the Script component gives the same advice: a chat widget is never critical to first paint, so it should never compete with things that are.

There's a subtlety, though. Our snippet is two scripts: an inline one that sets window.chattermateId, and the external widget file. Two separate lazyOnload scripts aren't guaranteed to execute in order — and if the widget script runs first, it won't find its ID. The clean fix is to do both in one script:

// app/layout.tsx
import Script from "next/script";

export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>
        {children}
        <Script id="chattermate-widget" strategy="lazyOnload">
          {`
            window.chattermateId = 'YOUR_WIDGET_ID';
            var s = document.createElement('script');
            s.src = 'https://app.chattermate.chat/webclient/chattermate.min.js';
            s.async = true;
            document.body.appendChild(s);
          `}
        </Script>
      </body>
    </html>
  );
}

One inline script, executed at idle, that sets the config and then loads the widget. Order guaranteed. This works in both the App Router and the Pages Router, and because it lives in the root layout, Next.js won't re-run it on client-side navigation.

Does the strategy choice actually move numbers? CoreWebVitals.io's analysis of Next.js third-party scripts reports a median INP improvement of 27ms across monitored sites that moved analytics-style scripts from afterInteractive to lazyOnload — small on paper, but INP thresholds are tight enough that 27ms can be the difference between passing and failing. For a widget pulling in hundreds of KB, keeping it off the critical path matters more, not less.

The pattern we'd actually ship: load on intent

lazyOnload still loads the widget for everyone. The sharper question is: why load 300KB of chat code for the many visitors who will never open the chat at all?

web.dev's answer is the facade pattern: render a lightweight fake — a button that looks like the chat launcher — and only load the real widget when the user shows intent. Click-to-load. Libraries like react-live-chat-loader implement exactly this for Intercom, Help Scout, and Messenger, and web.dev cites Postmark's success with it.

You can get most of the benefit with a few lines and no library. Load the widget on the first meaningful interaction — scroll, pointer move, or touch — with a timeout as a safety net:

import { useEffect } from "react";

const EVENTS = ["scroll", "pointermove", "touchstart", "keydown"];

export default function ChatWidget() {
  useEffect(() => {
    let loaded = false;

    const load = () => {
      if (loaded || document.getElementById("chattermate-script")) return;
      loaded = true;
      EVENTS.forEach((e) => window.removeEventListener(e, load));

      window.chattermateId = "YOUR_WIDGET_ID";
      const script = document.createElement("script");
      script.id = "chattermate-script";
      script.src = "https://app.chattermate.chat/webclient/chattermate.min.js";
      script.async = true;
      document.body.appendChild(script);
    };

    EVENTS.forEach((e) => window.addEventListener(e, load, { passive: true }));
    const fallback = setTimeout(load, 8000); // bots and idle readers still get chat

    return () => {
      clearTimeout(fallback);
      EVENTS.forEach((e) => window.removeEventListener(e, load));
    };
  }, []);

  return null;
}

Now the widget costs nothing at load time. A user who scrolls gets the chat bubble a moment later — long before they'd ever look for it. A user who bounces in three seconds never downloads it at all. Your Lighthouse run, which doesn't scroll or move a mouse, sees a page without a chat widget. (DebugBear caught one vendor gaming this by detecting Lighthouse's user agent and serving an empty file. Loading on real interaction gets you the same score honestly.)

The trade-off is a delay between page load and bubble appearance. For a support widget, we think that's the right trade almost every time. The exception: if chat is your primary conversion path — say, a sales-led landing page where "talk to us" is the whole point — load it at idle instead, and eat the cost knowingly.

Two gotchas that bite React apps specifically

Layout shift from the launcher. Most chat bubbles are position: fixed in a corner, which means they don't push content and can't cause CLS. But some widgets inject inline banners, proactive message previews, or "we're online" bars that do shift layout. web.dev's fix applies here: reserve the space with explicit dimensions, or configure the widget to stay in its corner. Test with DevTools' layout shift regions on, not just your eyes.

Consent and conditional loading. Because you now control when the script loads, you also control whether it loads. If your widget sets cookies or tracks visitors, gate the load() call behind your consent manager's callback rather than bolting consent on afterwards. The interaction-based loader above makes this trivial — one more condition in the guard.

If you self-host your support stack, the calculus shifts again: the widget script comes off your own domain (no third-party DNS/TLS round trip) and no visitor data touches an external vendor, which can simplify the consent question. We've written more about that trade-off in our guide to self-hosted customer support software.

Where the widget's own weight comes from

Loading strategy is half the story. The other half is what you're loading — and here you're at the mercy of your vendor, so it's worth checking before you commit. Run your candidate widget through a Lighthouse audit or DebugBear's free speed test on a blank page and look at transferred bytes and main-thread time. The spread is enormous: 79KB versus 533KB is not a rounding error, and you'll be shipping that difference to every visitor on every page, forever.

For what it's worth, this shaped how we built ChatterMate's widget: a single script tag boots the chat interface, and everything heavy — the model, the retrieval, the knowledge base that grounds answers in your docs (we covered how that works in RAG for customer support) — runs server-side and never enters your bundle. If you're evaluating options, our rundown of the best open-source customer support chatbots compares several widgets you can self-host and inspect, code and all.

The checklist

Before you ship a chat widget in React or Next.js: never paste the snippet into JSX (it won't execute); inject via useEffect with a double-mount guard in plain React, or one combined lazyOnload script in Next.js; prefer loading on first interaction with a timeout fallback; mount above your routes so navigation never re-initializes it; skip cleanup-on-unmount; gate behind consent if the widget tracks; and audit the widget's actual weight before you marry it.

None of this is exotic. It's maybe forty lines of code. But it's the difference between a support channel your users appreciate and a 500KB tax every visitor pays for a button they never press.

Written by the ChatterMate team — we build an open-source, AI-first support agent with a widget you can embed in one script tag and self-host if you'd rather keep everything on your own infrastructure.

Want a chat widget that answers from your docs instead of guessing? ChatterMate is open source and free to start — your first 300 chats are on us, and you can self-host the whole stack.