Google’s 3rd Parties Insight Explained: Fix Slow Third-Party Code

Most websites today run at least some third-party code and scripts. It’s a great way to add functionality and features to your site. At the same time, however, it can negatively impact performance. 

That’s why Google has added the 3rd Parties Insight audit to their suite of speed testing tools. It helps check the effect of third-party code and take corrective action. 

If you are unfamiliar with this topic, in this post you’ll learn what third-party code is, how Google’s insight tracks it, and how you can identify it and its impact on performance on your own website. After that, we cover the steps for reducing third-party code — both manually and with the help of a WordPress plugin. 

What is the 3rd Parties Insight?

First, let’s define Google’s 3rd Parties Insight audit. In order to do that, we have to cover some basics. 

What is Third-Party Code? 

What do we mean by third-party code, and how does it get on your website? 

A standard website visit usually involves two parties: the website and the visitor. When people come to your site, your server sends them all the data needed to display it. 

However, the way websites work today, that’s often not all they receive. Most times, web pages also include code or references to markup from other, external sources — aka third parties. Common examples are analytics scripts, dynamic ads, social media feeds, or even custom fonts, embedded videos, and A/B testing software. 

This often makes sense. For example, it’s usually smarter to embed videos from YouTube or Vimeo on your website than to host them yourself. These services are highly specialized in making video content load and play as fast as possible. If you tried to host the videos on your own server instead, depending on your traffic, it could easily be overwhelmed. 

The Problematic Side of Third-Party Code 

At the same time, external assets can also negatively impact your website. For one, they add more HTTP requests, can compete with essential files for bandwidth, and block the main browser thread. 

In addition, they may be unoptimized, for example, they may be uncached or uncompressed, create excessive DOM elements, use expensive CSS selectors, or duplicate code by loading existing libraries.  

This can negatively impact all Core Web Vitals of your website, making it not just a performance issue but also an SEO concern. 

Finally, it’s also possible for third-party code to become a security and privacy issue by unknowingly adding unsafe scripts to your website or using outdated APIs. 

What Does the 3rd Parties Insight Measure? 

To address the performance side of external assets, Google has introduced the 3rd Parties Insight. It shows up, for example, when you run a test through PageSpeed Insights. 

3rd Parties have replaced an older audit named “Reduce the impact of third-party code.” It shows what external markup is present on your site, where it comes from, its transfer size (meaning file size), plus main thread time (how long it blocks the main browser data pipeline). 

What’s important is that, unlike other metrics, the 3rd Parties Insight doesn’t offer a pass/fail assessment. It’s mostly informational and helps you easily find the external scripts and other code that have the most impact on your website’s performance. 

How to Identify Third-Party Data and Content on Your Website 

So, one way you can find third-party code on your site is through PageSpeed Insights. You’ll find it listed under Insights or Passed Audits. 

Besides that, you can also view third-party assets in the Chrome Developer Tools Performance panel when you record a trace. The 3rd Party Insight will show up in the left sidebar. When you click on it, the third-party data is also displayed in the loading timeline.

For best results, be sure to test more than just your homepage as third-party code and its impact can differ across different pages. In addition, run several tests and aggregate results to get a more complete picture. 

How to Reduce the Impact of Third-Party Code Manually

Now that we understand the matter of external markup and how to measure its impact, let’s discuss what to do about it. 

In the following, we will go through the steps you can take to mitigate the effect of third-party scripts and code on your site — first manually and later via plugin. Please note that doing this is not a matter of making one big change but rather of granular improvements that accumulate. 

1. Identify the Biggest Culprits 

Knowing how to measure the impact of third-party code is crucial, because it gives you a clear idea of where to start. If a particular script or external file is causing the most delay or takes the longest to transfer, optimizing it will give you the most benefit. 

After testing your important pages, you should end up with a hit list of files that cause the most performance issues on your site. Start working on them from the top down. 

To test changes beforehand, Chrome allows you to stop individual scripts and files from loading. In the Network tab, just right-click on any network request and choose Block request URL or even Block request domain. 

When you now re-run a speed test in the browser developer tools, you can see the site’s performance without that third-party code. 

2. Limit the Number of Third-Party Resources 

The single most effective step you can take to reduce the impact of third-party code on your site is to eliminate it outright. Even the most optimized script will still load slower than one that’s not even there. 

So, the first step is to see if you actually need the code that’s loading. Does the script, functionality, or feature add value to your site that outweighs the loss in performance? If not, get rid of it. 

That doesn’t have to mean not loading it on your site at all — it can also mean only including it on pages where it makes sense. For example, it isn’t necessary to load a web form script on a page that doesn’t contain a form. Conditional logic is very helpful to achieve this. 

3. Use preconnect and dns-prefetch 

Another way to reduce the performance impact of third-party code is by establishing connections to its sources early. You can achieve that with preconnect and dns-prefetch. 

<link rel="preconnect" href="https://www.google-analytics.com"> 

<link rel="dns-prefetch" href="//www.googletagmanager.com"> 

Both are resource hints that tell the browser to prepare for receiving data from specific domains. That way, when the time comes, the download can start more quickly. This can shave off up to 800 milliseconds of loading time per third-party resource — the time it takes to establish a full connection, including DNS lookup, TCP handshake, and TLS negotiations. 

Of the two resource hints, only preconnect completes the full process. dns-prefetch merely performs a DNS lookup —meaning it queries the Domain Name System for the IP address of a domain. That’s why the latter is best suited for important but non-critical third-party code, while you should reserve preconnect for crucial resources that need to load early. 

This distinction also matters because browsers automatically close unused connections established via preconnect after about ten seconds, which can otherwise introduce additional delay. 

4. Load Scripts After Main Page Content 

A way to lessen the effect of third-party scripts is to delay them from loading until after the main content. This helps the page appear quickly for visitors, improving perceived performance. 

You can use the async and defer attributes for that. They tell browsers to continue parsing the page code, load scripts in the background, and execute them when they are finished. This keeps them from blocking the browser’s main thread. 

<script async src="/js/main.js"></script> 

<script defer src="/js/secondary.js"></script> 

The difference between the attributes is that async will execute scripts as soon as they are done loading, pausing the HTML parsing in the meanwhile. It also ignores the order of scripts on the page and is therefore good for assets that should load as soon as possible. 

Scripts with defer, on the other hand, will wait to execute until HTML parsing is finished and do so in the order on the page. It’s good for less critical resources, for example those that appear below the fold. 

You can also move your script calls to the footer — that way, they will automatically start loading after the main content. In WordPress, for example, you can do this by adding the in_footer argument to wp_enqueue_script(). All techniques mentioned here can also be combined. 

5. Self-Host Third-Party Scripts and Resources 

Many third-party resources allow you to load them from a CDN — a Content Delivery Network. That means a system of computers around the world that has copies of the file and delivers it to visitors from the closest location, reducing delay through distance. 

While CDNs are usually great for performance, they also come with a cost. Loading from external sources, no matter how close, adds an additional HTTP request. The browser needs to establish a connection, do an SSL handshake, and download the file — all of which takes time. You also have no control over the caching of these resources or other performance improvements. 

For that reason, it can be a better idea to self-host third-party code (making it technically no longer third-party, but you know what I mean). Self-hosting allows you to decide how it loads and eliminates some third-party issues. 

The downside is that you miss out on automatic updates such as security fixes. It also adds extra work because maintaining the code is up to you now, so weigh the pros and cons. It can make a lot of sense to self-host resources that are unlikely to update very often, such as font files. 

6. Lazy Load External Resources 

Lazy loading is a simple concept: It means instructing browsers to refrain from loading page elements that aren’t visible on the user’s screen at the initial page load. 

After all, these elements don’t contribute to the early user experience but can still block more important content from loading. Lazy loading prevents this by delaying them until visitors scroll close to them. 

This method is most commonly used for images (along with other optimization tactics), but can also be applied to other elements. In those cases, it’s sometimes referred to as “lazy rendering.” 

This technique is perfect for third-party code that displays objects on the page, such as ads, embedded videos, and similar elements. Depending on their number and type, potential performance savings can be significant. 

How you implement it depends on what you are trying to lazy load. For images and iframes, you can use the loading attribute. 

<img src="images/hero-banner.jpg" alt="Hero banner" width="1200" height="600" loading="lazy"> 

The Intersection Observer API is a method that’s available for implementations with JavaScript. 

7. Configure Your Scripts Correctly 

Sometimes, poor performance is not due to the third-party code itself but because of the way you have set it up. For example, if you load six different tracking and advertising pixels, each with its own <script> tag, it’s bound to have an impact on page performance. If you find that a third-party integration significantly interferes with your site’s loading process, be sure to check if your setup could be the issue. 

In the example above, you could likely improve performance by using a tag manager instead. Likewise, you may reduce the performance impact of an A/B testing tool by applying the test to a smaller sample size. 

8. Offload Scripts to Web Workers 

A web worker is a JavaScript construct that allows you to offload code processing to a background thread. It keeps the browser’s main thread available for more essential files and tasks. 

Web workers are an alternative to self-hosting — you are still using a third-party resource but with the ability to cache it and manage it differently. 

9. Track Performance Over Time 

Performance isn’t static. New third-party scripts and other code find their way onto websites all the time or may change how they work after an update. Over time, it’s easy for your hard-won optimizations to erode. 

That’s why it’s important to regularly check up on site performance. Keep an eye on indicators such as Largest Contentful Paint (LCP), Total Blocking Time (TBT), and Cumulative Layout Shift (CLS). Track values over time to spot trends and changes. It will help you take corrective action before performance degrades. 

How to Optimize Third-Party Scripts With a Plugin 

Besides taking manual action, you can also tackle the 3rd Parties Insight using a performance plugin like WP Rocket.  It is chock full of powerful features to reduce the impact of external code on your site, like: 

• Preloading for important files and fonts 
• Combining, deferring, or asynchronously loading JavaScript to prevent it from blocking the loading process 
• Lazy loading for images, CSS backgrounds, videos, and iframes 
• Delaying non-critical JavaScript until after a user interaction 
• Self-hosting Google Fonts to reduce external requests 

The neat thing is, you can easily enable most of these options by simply ticking a box in the plugin settings. 

Besides optional features above, WP Rocket automatically implements a host of other optimizations: 

• Automatic lazy rendering 
• Caching (with a separate mobile cache) 
• Critical image optimization (that means, images above the fold aren’t lazy loaded) 
• GZIP compression 
• Minification for CSS and JavaScript files 

That means your site instantly benefits from most performance best practices when you switch on the plugin. Finally, Rocket Insights helps you automatically monitor your website’s performance over time. 

It’s the hands-on performance monitoring tool included in WP Rocket. Powered by GTmetrix, it allows you to track your top pages with in-depth insights. That way, you can measure WP Rocket’s impact instantly, quickly spot and troubleshoot performance issues, and optimize what slows your site down, all in one place. 

Curious to see how much faster WP Rocket can make your site? Let’s look at a case study. 

Case Study: Improve Third-Party Code Performance with WP Rocket

To test WP Rocket’s impact on external resources, we created a demo website with a default WordPress theme, a few standard WordPress plugins, custom fonts, and a homepage with text, images, and an embedded video. 

We ran the site through PageSpeed Insights to get a performance baseline. The results were as follows: 

In short, the performance of the site wasn’t too great. The Insights section also included the 3rd Parties warning with a long list of external resources. 

With that in hand, we installed and activated WP Rocket. Besides the automatic enhancements, we enabled the following plugin features: 

• Remove unused CSS 
• Defer JavaScript and delay execution 
• LazyLoad for images, videos, and iframes 
• Preload fonts 

After that, the results improved a lot. 

In addition, the 3rd Parties insight had a lot fewer entries. 

Of course, there’s more that could be done. For one, the font files still showing up under 3rd Parties would be off better self-hosted. But, because they were added by a plugin, this would take a few additional steps. 

What’s more, some images on the homepage are larger than they should be — something easily remedied with a image optimization plugin like Imagify. But, considering it took all but five minutes and a few clicks, the improvements are already quite satisfying. 

Show the 3rd Parties Insight the Door

Third-party code and scripts help enhance websites, but they can also have a substantial impact on performance. Google’s 3rd Parties Insight helps you spot the resources that slow your site down, and you can use the tips above to take corrective action. 

If you find it challenging to make improve your site by hand, the plugin route offers an easier and more accessible alternative. Get WP Rocket today and test its impact on your website’s performance risk-free for 15 days!