Glossary
Third-party script
A third-party script is JavaScript loaded from an origin you do not control — analytics, advertising, consent management, chat widgets, tag managers. It executes with the same privileges as your own code: it can read the DOM, read cookies not marked `HttpOnly`, observe form input and make network requests. That is the security position; the performance position is that it competes for the same single main thread as everything else on the page.
What it costs in performance
A connection to a new origin: DNS, TCP and TLS before a single byte of the script arrives.
Download, parse, compile and execution time, all of it on the main thread, which directly lengthens Interaction to Next Paint.
Further requests the script makes on its own, frequently to additional origins the page never declared.
Layout shifts when it inserts content into the flow after rendering, which is the usual cause of an advertisement pushing the page down.
A tag manager compounds all of this: one script that loads an unknown number of others, decided by a configuration outside the codebase.
What it costs in risk
Full access to the page. A compromised third-party script can read form fields, including payment details, and exfiltrate them.
This is not hypothetical: the pattern of injecting a card-skimming script through a third-party dependency has been used repeatedly against large sites.
A dependency on someone else's availability. A blocking third-party script that stops responding can prevent your page rendering at all.
A privacy and compliance surface: a script setting cookies or transmitting personal data before consent is a problem regardless of who wrote it.
What containment is available
`async` or `defer` so the script does not block parsing. This is the minimum and it is frequently missing.
Subresource integrity, a hash in the `integrity` attribute, so a modified file is refused. It only works for files that do not change, which excludes most analytics scripts.
A Content Security Policy restricting which origins may serve scripts, which limits where an injected script could come from.
Loading inside a sandboxed iframe where the functionality allows it, which is real isolation rather than mitigation.
Removing the script, which is the only complete answer and is available more often than it is used.
How to audit what a page loads
The network panel, filtered by domain, lists every origin the page contacted. The count is usually higher than anyone expects.
Lighthouse reports third-party usage with the main-thread time attributed to each origin, which turns a list into a ranking.
Block a script in the browser and reload. If nothing visible changes, that is the answer about whether it is needed.
Review the tag manager's configuration directly, since scripts added there do not appear anywhere in the codebase.
Frequently asked questions
- How many third-party scripts is too many?
- There is no threshold. The useful test is per script: what it costs in main-thread time and what breaks if it is removed.
- Does async make a third-party script safe?
- It stops the script blocking parsing. It does nothing about what the script can do once it runs, which is everything your own code can do.
- Can subresource integrity protect analytics scripts?
- Rarely. It requires a fixed file whose hash is known, and most analytics scripts are updated by the provider without notice.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website