A fair question about third-party code
Anyone who has watched a site get slowly buried under tag managers, heatmaps, ad pixels and
support widgets is right to be suspicious of one more script. Third-party code is the most common
cause of a page that tests well in a lab and feels slow to real people, and a chat widget is
third-party code on every single page.
The honest answer is that a chat widget does have a cost, that the cost is small when it is loaded
correctly, and that almost all of the horror stories come from a handful of avoidable mistakes
rather than from chat itself. What matters is not whether the widget adds bytes — it does
— but whether it adds them on the path that blocks your page from rendering.
Async and defer are the whole story
A normal script tag stops the browser mid-parse: it fetches the file, runs it, and only then
continues building the page. Put a third-party script in that position and your page waits on
somebody else's server before it shows anything. That is the pattern behind most third-party
performance disasters.
The install snippet MyLiveChat generates carries both async and defer
and is placed immediately before the closing body tag, which takes it off the critical path
entirely. The browser keeps parsing and painting your page while the widget is fetched in the
background, and the widget assembles itself once the page is already usable. It also sets
referrerpolicy to send only the origin rather than the full URL of the page the visitor
is on, and marks itself so that CDN script-rewriting features leave it alone.
The practical consequence: the widget's cost lands after your content is visible, not before. Your
largest content element, the point at which the page becomes readable, and the moment it becomes
interactive are all reached without waiting for chat. That is the property to check on any vendor
you evaluate — look at the actual snippet they hand you, and if it is a plain synchronous
script tag in the head, that is a real problem regardless of how small the file is.
The mistakes that do cause slowdowns
When a chat widget genuinely hurts a site, it is usually one of these rather than the widget
itself.
- Loading it through a tag manager that is itself blocking. The widget inherits
whatever loading behaviour the container has. Installing the snippet directly is faster and easier
to reason about.
- Installing it twice. Once in the template and once on a specific page, or once
directly and once via a plugin. Everything is fetched and initialised twice, and the symptoms are
strange rather than obviously slow.
- Putting it in the head to make it appear faster. It does not appear meaningfully
faster and it moves the cost in front of your content.
- Stacking it with eight other third-party scripts. Any single script is
defensible; the aggregate is what makes a phone on a poor connection struggle. Audit the whole set,
not just the newest addition.
- Blocking it in your content security policy and then retrying. A widget that
cannot load is not fast, it is broken.
Two things to check that are not speed
If you run a content security policy, the widget's runtime loads from the chat host rather than
from your own domain, so that host has to be permitted on both the script and style
directives. Allowing scripts but not styles is a specific trap: the widget mounts and then renders
unstyled, which looks like a broken widget rather than a policy problem. And the snippet must be
requested over HTTPS on an HTTPS page — an old copy of an install snippet using HTTP will be
blocked as mixed content, and the widget simply never appears.
The second thing is CSS. The widget renders inline in your page rather than inside an iframe,
which is what allows it to be styled and to behave well on mobile, but it also means aggressive
site-wide CSS rules can reach it. A global rule that restyles every button or input on the page can
change how the chat controls look. If the widget looks subtly wrong rather than slow, this is
usually why, and the fix is a more specific selector on your side rather than a widget setting.
Measure your own site rather than trusting anyone's number
Benchmarks quoted by vendors, including in articles like this one, are close to meaningless
because they depend on your pages, your other scripts and your visitors' devices. Fortunately
measuring it yourself takes about ten minutes.
Take a page that matters — your busiest landing page, not the homepage, if they differ
— and record its performance metrics with the widget installed and again with the snippet
commented out. Do it three times each way, because single runs are noisy, and do it on a throttled
mobile profile as well as on your desktop, since that is where third-party cost actually shows up.
Then look at the numbers your visitors feel: when the main content appears, and how long the page
takes to respond to a tap. Total bytes transferred is the least interesting figure on the page.
If the difference is small, you have your answer and you can stop worrying about it. If it is
large, the cause is nearly always one of the installation mistakes above rather than the widget, and
it is worth finding out which before removing a channel that was working.
Performance work exists to make a site convert and serve people better, so a purely technical
verdict is incomplete. A widget that adds a small, deferred cost to page load and answers a
pre-purchase question in thirty seconds is very likely a net gain, and the same widget on a
documentation page nobody chats from is pure cost. That framing also gives you a cheaper lever than
optimisation: show the widget where conversations actually happen, and leave it off the pages where
they do not.