Third-party scripts are JavaScript files that a website loads from domains it does not control. Typical examples are analytics, advertising, social buttons, video embeds, chat widgets and A/B testing tools.
What effect do they have on performance?
web.dev lists several risks. Each script adds network requests to other servers. Parsing and running the code occupies the main thread, which delays rendering and reactions to input. A slow vendor server can hold up the page, and some scripts use outdated practices such as document.write(). Lighthouse reports this under audits like “Reduce JavaScript execution time”. Total Blocking Time (TBT) reflects it in lab tests, and Interaction to Next Paint (INP) in field data.
How can they be controlled?
- Governance: web.dev recommends checking each tag for compliance, necessity, ownership, purpose and regular review, and setting a budget such as a maximum number of tags per page type.
- Loading behavior:
asyncruns a script as soon as it is downloaded,deferafter HTML parsing. Non-critical scripts can be loaded later, for example on interaction. - Connections:
preconnectanddns-prefetchshorten connection setup to important vendors. - Hosting: web.dev mentions self-hosting critical scripts for better cache control, at the cost of manual updates.
Example
In Chrome DevTools, a script can be blocked in the Network panel. Comparing a run with and without it shows what it costs.
Sources
Last updated: