Learn Measure Blog About

Third-party JavaScript performance

Find out how third-party JavaScript can affect performance and what you can do to keep it from slowing down your sites.

Milica Mihajlija
Milica Mihajlija

Third-party JavaScript generally refers to scripts embedded in your website that are:

  • Not authored by you
  • Served from third-party servers

Sites use these scripts for various purposes, including:

  • Social sharing buttons
  • Video player embeds
  • Chat services
  • Advertising iframes
  • Analytics and metrics scripts
  • A/B testing scripts for experiments
  • Helper libraries (like date formatting, animation, and functional libraries)

Third-party scripts can provide powerful functionality, but that's not the whole story. They also affect privacy, security, and page behavior⁠—and they can be particularly problematic for performance.

Performance

Any significant amount of JavaScript can slow down performance. But because third-party JavaScript is usually outside your control, it can bring additional issues.

Network

Setting up connections takes time, and sending too many requests to multiple servers causes slowdowns. That time is even longer for secure connections, which may involve DNS lookups, redirects, and several round trips to the final server that handles the user's request.

Third-party scripts often add to network overhead with things such as:

  • Firing additional network requests
  • Pulling in unoptimized images and videos
  • Insufficient HTTP caching, which forces frequent fetching of network resources
  • Insufficient server compression of resources
  • Multiple instances of frameworks and libraries pulled in by different third-party embeds

Rendering

The way third-party JavaScript is loaded matters a lot. If it's done synchronously in the critical rendering path it delays parsing of the rest of the document.

Key Term: The critical rendering path includes all resources that the browser needs to display the first screen's worth of content.

If a third party has server issues and fails to deliver a resource, rendering is blocked until the request times out, which can be anywhere from 10 to 80 seconds. You can test and simulate this problem with WebPageTest Single-Point-of-Failure tests.

A/B testing scripts can also often delay rendering. Most of them block content display until they complete processing—which can be true even for asynchronous A/B testing scripts.

What to do about it

Using third-party JavaScript is often unavoidable, but there are things you can do to minimize adverse effects:

  • When choosing third-party resources, favor those that send the least amount of code while still giving you the functionality you need.
  • Use performance budgets for third-party content to keep their cost in check.
  • Don't use the same functionality from two different vendors. You probably don't need two tag managers or two analytics platforms.
  • Routinely audit and clean out redundant third-party scripts.

To learn how to audit third-party content and load it efficiently for better performance and user experience, check out the other posts in the Optimize your third-party resources section.

Last updated: Improve article