Reference guide · performance · Published 2026-08-16 · 3 min read
Third-party script performance impact
Third-party script performance: how to measure byte and main-thread impact, and how to defer or sandbox the scripts.
- ·The cost model
- ·Measure the impact
- ·Sandbox the scripts
What third-party scripts cost
Third-party scripts are the code other companies load into your page: analytics, chat widgets, A/B testing, tag managers, advertising, social embeds, and heatmaps. Each one means the browser places another network request, downloads more JavaScript, and runs code on your main thread during the same render that decides your Core Web Vitals.
The hidden cost is that most of them do not just download. They execute on every page, on the main thread that also renders your content, they block load while their network requests complete, and they often load more code and trackers after they run. A single page with a chat widget, a remarketing pixel, and analytics can spend dozens of requests and hundreds of kilobytes on software your business never visibly uses.
Measure the impact
Do not guess. The performance audit script has a third-party stage, and this drill goes one step further:
- Open the page in an empty profile with DevTools Network open.
- Exclude the first-party origin from the list, and sum everything else by domain.
- Note the total bytes and the count of requests per third-party domain.
- Open DevTools Performance, reload, and look at the task breakdown to see which providers own the long main-thread blocks (a "sources" or "activity" view lists the script files at fault).
Then compute the two numbers that matter: third-party byte share (third-party bytes divided by page bytes), and third-party main-thread share. A 10% JavaScript bill from a tag manager is a bill you can control; a 60% share is the score.
Deploy on your own schedule
The blunt fix is you own the trigger, not the vendor. A script that loads at page start with async still competes with your own load schedule; the same script loaded after the first render, or on interaction, costs far less. In order of decreasing aggression:
| Method | What it does | Risk |
|---|---|---|
Load after window.load | Moved off the critical path | Feature fires late |
defer / async | Does not block the render | Still runs during render |
| Load on idle or first interaction | Runs when the browser has free capacity | Feature appears late |
IntersectionObserver-gated | Runs when the widget is near the viewport | Complex to write |
A tag manager single tag is usually the unification; remove it from the head and load it under your own scheduler, and re-run the same audit after each change.
The qualification budget
Almost every third-party features a cost that another provider can fill. Run the audit, then ask per vendor: is this script on every page, does it implement one feature, and does a lighter or self-hosted variant exist? The honest outcome is usually a short list: keep the two you use, defer the rest, and delete the ones that survive on pageviews alone.
Prevention
Never add a third-party script without recording its name, why it is needed, and the expected page-visit weight; re-run the third-party audit after each vendor change; and keep the tag manager list under review, because a tag added for a campaign has a way of staying on the site after the campaign dies.