Analytics, a chat widget, a cookie banner, two social embeds, a review badge, a font from Google and a comment system. Each was added for a reason, each seemed small, and together they are usually the largest performance problem on the site — and the one nobody owns, because none of it is your code.
Advertisement. We earn a commission if you sign up through this link, at no extra cost to you.
This is also where Interaction to Next Paint goes wrong. Third-party JavaScript competes for the same main thread your interface needs to respond on, and no amount of image optimization touches it.
Measure the real cost first
Run a Lighthouse report and open Reduce the impact of third-party code. It lists every third-party origin with transfer size and main-thread blocking time attributed to each. That table ends most arguments, because the numbers are usually worse than anyone expects.
Then in DevTools, the Performance panel with CPU throttled to 4x slowdown shows you the long tasks and who owns them. And the Coverage panel shows how much of each downloaded script was actually executed — third-party libraries routinely report 90 percent unused.
The number to focus on is blocking time, not file size. A 30 KB script that runs for 400 milliseconds is worse for responsiveness than a 200 KB one that runs for 20.
The categories, roughly in order of damage
Chat widgets
Usually the single heaviest item on a site. A live chat widget commonly loads several hundred kilobytes, opens a persistent connection, and runs continuously — for a feature most visitors never touch.
The fix is a facade: render a lightweight button that looks like the widget, and load the real thing on click. First interaction costs a second; every visitor who does not click pays nothing.
Comment systems
Hosted comment platforms are heavy — commonly over a megabyte with their own tracking attached. WordPress has a comment system built in, and it is a fraction of the weight.
Two things worth doing regardless of platform: load comments on demand rather than with the page, and ask whether the section is earning its place at all. A comment form that has collected nothing in a year is weight plus an invitation to spam plus a visible signal that nobody is here.
Social embeds and share widgets
An embedded post from a social platform pulls in that platform’s entire framework to render what is visually a box with some text in it. Share buttons load each network’s SDK to draw an icon.
Replace share widgets with plain links — https://twitter.com/intent/tweet?url=… and equivalents — styled however you like, with no third-party code at all. For embedded posts, a screenshot with a link is usually both faster and more durable, since embeds break when the original is deleted.
Video embeds
A standard YouTube embed loads several hundred kilobytes before anyone presses play. The facade pattern applies again: show the thumbnail, load the player on click. The lite-youtube-embed component does exactly this, and most performance plugins have the option built in.
Analytics and tag managers
Individually modest, and the failure mode is accumulation: GA4, plus a tag manager, plus a heat-mapping tool, plus two advertising pixels, plus a session recorder — each added by someone who did not know about the others.
A tag manager concentrates the loading, which is useful, but it does not reduce it. Audit what is in your container. There is almost always something firing that was for a campaign that ended.
Server-side tagging is the structural answer for sites where this is a real cost, at the price of running infrastructure.
Web fonts
Fonts deserve their own treatment because they are both a performance and a privacy question.
Self-host them. Loading fonts from Google’s CDN sends every visitor’s IP address to Google, and a German court ruled in 2022 that doing so without consent violated GDPR. That decision was one court and it changed the calculation for European sites — self-hosting removes the question entirely.
Self-hosting is also faster now than it used to be. Browser cache partitioning means a font fetched on another site is no longer reused on yours, so the old shared-cache argument for a public CDN no longer holds.
Use WOFF2 only. Every current browser supports it, and it is substantially smaller than the older formats. Serving WOFF and TTF fallbacks doubles your font weight for browsers nobody has.
Cut the weights you do not use. A family loaded in nine weights and their italics, to use three, is the most common font mistake. Look at what your CSS actually references.
Subset. If you write in English, you do not need Cyrillic, Greek and Vietnamese glyphs. Subsetting typically removes half the file.
Set font-display and preload:
@font-face {
font-family: 'Inter';
src: url('/fonts/inter.woff2') format('woff2');
font-display: swap;
}<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>font-display: swap renders fallback text immediately and swaps when the font arrives — text is never invisible. The cost is a layout shift at the swap, which you reduce by choosing a fallback with similar metrics, or by matching them explicitly with size-adjust.
Consider a variable font. One file covering a whole weight range is often smaller than three static weights.
When someone else’s server goes down
Every third-party script is a dependency on infrastructure you do not control. A script loaded synchronously from a host that stops responding does not fail gracefully — it blocks page rendering until the browser gives up, which can be tens of seconds.
Reducing that exposure:
Load everything async or deferred. A blocking third-party script is a single point of failure for your whole page. Nothing external should be synchronous in the head.
Self-host what you can. A library from a CDN is a dependency; the same library on your server is not. The shared-cache benefit that once justified public CDNs is gone.
Use Subresource Integrity for anything you must load externally, so a compromised CDN cannot serve modified code:
<script src="https://cdn.example.com/lib.js"
integrity="sha384-..." crossorigin="anonymous"></script>Design for absence. If the chat widget never loads, is there still a contact route? If the font never arrives, does the fallback look acceptable? If the review badge fails, is there a hole in the layout? Non-critical features should degrade quietly.
The audit worth running once a year
List every third party your site loads. For each one, three questions:
- What is it for, and who asked for it? A surprising number have no current owner.
- What does it cost? Transfer size and blocking time from the Lighthouse table.
- What would we lose without it? Sometimes the honest answer is nothing.
Then: delete what nobody owns, put a facade in front of what is heavy and rarely used, self-host what can be self-hosted, and defer everything that remains.
This is usually the largest single performance improvement available on an established site, and unlike most of the work here, most of it is decisions rather than engineering.
The short version
Third-party scripts are usually your worst performance problem and always your worst responsiveness problem. Measure blocking time, not file size. Put facades in front of chat widgets and video embeds so they load on click. Replace share widgets with plain links. Self-host fonts in WOFF2, only the weights you use, subset, with swap and a preload. Load everything external asynchronously, and make sure the page still works when someone else’s server does not.
Working through this list on your own site and would rather not? That is what an Expert Web Audit is for.
Advertisement. We earn a commission if you sign up through this link, at no extra cost to you.
