Performance
Third-party script
Third-party script is JavaScript loaded from a host you do not control, such as an ad network, chat widget, or font loader. It runs with your page's privileges but on someone else's schedule.
How it is measured
In the Network panel, filter out your own domain. Lighthouse's third-party summary lists transfer size and main-thread blocking time per vendor, and the Performance panel's bottom-up view grouped by domain shows CPU cost.
Check each script for four things: bytes, blocking time, request chain length (scripts that load more scripts), and what happens when it fails. A synchronous script on a slow or down host can hold up your whole page.
Worked example
A SaaS pricing page loads a live-chat widget from a vendor CDN. It is 340 KB, pulls in 11 more files, and takes 780 ms of main-thread time on a throttled phone. When the vendor has an incident, the synchronous tag in the head stalls for 30 s before timing out, and the pricing table does not appear.
Switching to `async` and loading it only when a visitor clicks 'Chat with us' removes it from the initial load. TBT falls by 700 ms and the vendor outage no longer touches the page.
How it differs
A third-party script is one external file or vendor. Tag weight is the aggregate cost when a tag manager brings many of them. The distinction is the host: scripts served from your origin are first-party even if you copied the vendor's code.
Common errors
Loading scripts synchronously in the head. Trusting a vendor's claim that its snippet is async. Adding a script and forgetting it. Self-hosting a copy and never updating it. Ignoring what the script loads next. Having no fallback if it fails.
In practice
List every external domain in your top page's Network panel. Give each an owner and a business reason. Make the non-essential ones `async` or load them on interaction, and use `defer` for the rest. Test with the vendor's host blocked to see if the page still works.