Third-party scripts are JavaScript files a page loads from services its owner does not operate: analytics, tag managers, advertising, consent banners, chat, reviews and social embeds. The owner chooses to install them but does not control their size, their code or their release schedule. Once loaded they run on the same main thread as the site’s own scripts, so the time they spend parsing and executing is time the page cannot respond to the visitor.
Owned by someone else, not served from somewhere else
“Third-party” is easy to confuse with “served from another host”, and the two give very different numbers. Hosted site builders deliver almost the whole page from their own CDN domain, which is a different host from the site’s address but is not a third party in any useful sense.
Counted by host, the median site in our audit base gets 79% of its bytes from hosts other than the one that served the page (2,059 sites, snapshot 8 October 2026). On Webflow that share is 98% and on Squarespace 97%, against 32% on WordPress, which mostly reflects where the platform keeps its files.
Counted by owner, using the service directory Lighthouse ships with and leaving out CDNs and hosting, the picture shrinks. The median site gets 9% of its bytes from third-party services and spends 223 ms of main-thread time running them (1,242 sites measured on mobile between 24 September and 8 October 2026; the middle half of the sample sits between 1% and 25% of bytes). 209 of the 1,242 loaded no recognised third-party service at all. Across eight platforms the byte share stays between 3% and 13%.
The most widespread single script is the tag manager. In our study of the hosts a page talks
to, googletagmanager.com appeared on 286 of 457 sites, 63%; the full count and its
connection to the score are in
The median site we audited loads from 12 hosts it doesn’t own.
Why a small share of bytes still costs time
Weight is the wrong way to judge these scripts. A tag manager container of a few dozen kilobytes can pull in several more scripts, each of which parses, executes and often sets timers that keep the main thread busy after the page looks finished. That time shows up as TBT in a lab run and as slow responses to taps, measured by INP, in the field.
Three patterns make it worse:
- Loaded in the
<head>withoutasyncordefer. The parser stops until the vendor’s server answers, so a slow third party delays the whole first paint. - Containers that grow unreviewed. A tag manager lets marketing add tags without a deploy, and tags are rarely removed once the campaign that needed them is over.
- Widgets that load on every page for a feature used on one. A chat bubble or a review carousel costs the same on the blog post that never shows it.
Keeping a vendor’s script out of the first paint
The owner’s options are to remove a script, load it later, or load it only where it is used. Loading later is the one that rarely breaks anything:
- <script src="https://widget.example-chat.com/loader.js"></script>
+ <script src="https://widget.example-chat.com/loader.js" defer></script>Analytics is the exception worth thinking about. Delaying it until after the first interaction improves the lab score but drops visits that end before that interaction, so the analytics undercount exactly the visitors a slow page loses.
What our proxy does with them
Our proxy recognises common third-party widgets and holds them back until the page is usable, without editing the site. In the August 2026 snapshot it found something to defer on 211 of 440 audited sites; the table is in What Lighthouse tells you to fix. It does not remove any service and does not change what the scripts do once they run, so a heavy tag still costs main-thread time, only later.