Most websites rely on third-party scripts in some way. While they are easy to add, third-party code often has a negative impact on page performance.
In this article we explain what third-party code is, how you can identify it on your website, and what you can do to fix performance issues caused by third parties.
What are third-party scripts?
You're a website operator and a visitor comes to your website. Those are the first two parties. But then additional code is often loaded from other domains, for example analytics services, support widget providers, or ad networks. These are third-party services.
Third parties provide functionality that the website operator hasn't implemented themselves.
Simon Hearne's Request Map tool provides a nice visualization of how a website fetches resources from different domains when it loads.

How does third-party code impact website performance?
In general, loading more resources will cause pages to load and render more slowly. For example:
- Early third-party requests compete for bandwidth with first-party content
- Third-party code blocks the browser main thread when it runs
- Render-blocking third-party requests prevent all page content from being displayed
- Late-loading third-party code can cause poor performance if it's responsible for important content
Here's a DevTools performance recording that shows CPU processing caused by third-party scripts when loading a website.

Chrome recently improved their developer tools to make it easier to identify of filter out third-party scripts.
How to identify third-party code that impacts performance
Google's Lighthouse tool, which is what also powers the PageSpeed Insights diagnostic data, has an audit that identifies third-party scripts that impact page speed. You can find the audit in the Performance section of the Lighthouse report.
Next to the title the audit tells you how long third-party code blocked the main thread, in this case 390 milliseconds. While the main thread is blocked, other scripting or rendering tasks can't be processed. User interactions also can't be processed.

Third-party reported in DebugBear
If you run a test with the free DebugBear page speed test you can find third-party performance reporting at the bottom of the Requests tab.
This will show you the total CPU time for the third-party as well as the total download size. Click on the third-party entry to view all related network requests.

If you have continuous synthetic website monitoring set up you can also see third-party page weight, CPU tasks, and third-party provider count tracked over time.

When one of the metrics changes you can click on it to see what changed.
For example, in the test result below New Relic was added as a new third-party resource.

