Table of contents of the article:
Third party scripts add a wide range of useful functions to your website, making it more interactive, dynamic and interconnected. Features like analytics, ads, social media share buttons, video embeds - all are possible thanks to third-party scripts. Some of these features may be essential to the functionality or monetization of your website.
However, third party scripts are also a major cause of slow performance on websites. They are usually the most expensive resource when loading the page. Some of these scripts can also pose security and privacy risks.
This article will provide you with the basics of third-party scripts, how they affect website performance, and what you can do to mitigate their negative effects.
Sound interesting? Let's begin!
What are third party scripts?
“Third Party Script” means any script that can be incorporated directly into a third party vendor's website. They are not created by the user, nor explicitly controlled by the user, and are served by an external URL. Normally to be clear, all the Javascript scripts for example that are loaded from domains external to ours, precisely from third parties.
Where are third party scripts used?
Almost every website uses third party scripts to add some functionality. Some of their more common uses are:
- Embedding videos (e.g. YouTube, Vimeo)
- Adding social sharing buttons
- Adding chat widgets
- Embedding comment systems (e.g. Disqus)
- Enabling web analysis (eg. Google Analytics)
- Embedding ads
- Serving resources via content delivery networks (CDNs)
- Experimenting with A / B test scripts
- Adding helper libraries (e.g. animation, functional libraries, and so on)
Developers can add powerful functionality to websites with just a few lines of code using third-party scripts. For instance:
- Marketing teams can use A / B test and analysis script reports to manage their business decisions about valid data.
- Users can share an article they love on their favorite social network with just the click of a button.
- Potential customers can contact support or sales staff via the chat widget and get their questions answered right away.
Third-party scripting applications are endless, but it just doesn't end there.
If used without caution, third-party scripts can be problematic for page privacy, security, and performance.
The cost of third party Javascript.
Third-party scripts are everywhere. According to HTTPArchive's State of JavaScript report , the median number of external scripts requested by websites is 20 , and their total size is approximately 449 KB.
A whopping 93,59% of web pages include at least one third-party resource. Digging deeper into the same data shows that 76% of websites track users with analytics scripts.
The worst impact of third-party scripts is the delay in the critical rendering path. This is the set of actions a browser takes to assemble HTML, CSS, and JavaScript into a live, usable website. Naturally, the payload size of third-party scripts plays a major role here, but there's another important factor to consider.
In 2019, the dominant script processing costs are now download and CPU runtime.
JavaScript takes up a lot of CPU resources to run. Even if you optimize third-party scripts to reduce the impact on render times, they can still affect the “Time to Interactive” metric. It measures how quickly users can interact with a web page. The slower it is, the more frustrated your users will be and the more likely they are to leave your website.
You can summarize the cost of using JavaScript with two main metrics.
Increase the page size
Byte for byte, JavaScript is the most expensive third-party resource served by web pages. Since a browser needs to download all linked third-party scripts when loading the page, adding them to your website can significantly slow it down.
The larger the script size, the harder it will be for your website to drop performance. After all, the larger the size of a web page, the slower it will load.
Reducing the size of external scripts is an impressive way to speed up your website.
Additional network requests
Whenever a user requests any of the pages on your site, the browser has to retrieve all embedded third-party scripts. To do this, the browser will reach all external URLs where these scripts are hosted to download them.
Typically, each third-party script alone doesn't amount to much. However, loading each third-party script is an additional HTTP request that the browser must make to fully render the page. These requests accumulate and slow down the page's performance.
Also, the more requests your web page has, the longer the “Time to Interactive” metric will be.
In the above example, you can see that the page takes more than 9 seconds to fully load. The main culprit here is the embedding of a lot of third party scripts that drag down page load speed.
Scripts aren't the only third-party resources used by websites, but they make up a mass of third-party requests across all categories and content types. So, optimizing them should be your top priority.
Measuring the impact of loading third-party scripts
There are many webpage speed testing tools that you can use to diagnose third party scripts and find out which of them are the most expensive resources on your website. These tools show you the number of third-party scripts loaded from your site and the time they take to run.
Here are some free tools you can use to evaluate third-party scripts:
- WebPageTest.org
- Chrome tools
- PageSpeed insights (Lighthouse audit)
WebPageTest.org
WebPageTest is a free open source speed test tool that you can use to evaluate website performance. It includes many advanced features such as waterfall charts, content breakdown by type and domain, web page rendering and video clips and comparison of test.
WebPageTest provides many advanced tools to test your site's performance
I tested my portfolio website on WebPageTest. Below is the cascading view of the requests made by my site while the page is loading. That's a lot of requests, but not all of them come from third-party sources.
The waterfall chart breaks down requests by domain and size along with a timeline representing the page load.
You can also check the breakdown of content by type by clicking on the "Content Breakdown" tab. As you can see, JS makes up a lot of requests and bytes transferred.
Clicking on the 'Domains' tab will give you a complete list of all domains reached by the browser during the page load.
In this case, most of the requests come from the primary domain itself. You can also click on the 'Map Requests' link to view all these requests.
If you recognize a problematic script that takes a long time to load or run, check if the script is needed. Remove such scripts if they do not represent any perceptible damage to the functionality of your website or user experience.
WebPageTest also provides a way to test your website speed by blocking requests from specific domains . This is useful for measuring the performance impact of problematic third-party scripts by specifically targeting them.
blockDomainsExcept www.domain.com cdn.domain.com cdnjs.cloudflare.com
navigate https://www.domain.comFor example, you can block requests from all external domains (except important CDNs) and then direct WebPageTest to go to the site to test it.
Note:< You can also use the 'Block' tab in the 'Advanced Settings' section of WebPageTest to do the same.
Here's a typical workflow to use WebPageTest to identify slow scripts:
- Test the original web page.
- Test the same webpage again, but this time with some blocked third party scripts.
- Compare the two results using the 'Compare' feature of WebPageTest from the 'Test History' panel.
Chrome tools
Chrome DevTools supports highlighting third-party network requests in the Network panel. This feature allows you to get detailed information about third-party script requests on a page.
To use this feature, press Ctrl/CMD, Shift, and P in one of Chrome's DiSCi panels to display the "Command Menu." Then, type "Show third-party badges" and enable this feature.
Note: Google Chrome version 80 removed this feature, announcing no replacement . It's most likely a bug. For now, you'll need to manually sort external scripts until Google fixes this issue.
You can also use the “Performance” panel in Chrome DevTools to identify any performance issues on your website.
For more information on testing page load performance with Chrome DevTools, see Google's tutorial on this topic.
Lighthouse audit
Google's Lighthouse speed test tool has two specific checks to evaluate your site's performance.
Lighthouse's JavaScript startup time audit classifies scripts based on parse, compile, and evaluation time. These metrics help you identify third-party scripts that have accumulated significant server resources.
Lighthouse's network payload audit lists all scripts by total size and transfer time. You can use these metrics to identify third-party scripts that may be slowing down your site's page load time.
Chrome's built-in Lighthouse tool also shows you expensive third-party resources on a page sorted by size and transfer time.
Now that you've learned how to test the performance of third-party scripts, it's time to learn how to reduce or undo their damage.
How to minimize the negative effects of third-party scripts.
1. Delay the loading of third party scripts
If you find third-party scripts slowing down your website, you can load them using async attributes or defer HTML to avoid their negative impact on page loading.
The async attribute forces the browser to continue parsing the rest of the HTML document until the script is downloaded. Once the script is downloaded, parsing of the HTML document is suspended to execute the script.
The defer attribute does the same thing, except that the browser doesn't execute the script until it has parsed the entire HTML document.
It is recommended that you load all third-party scripts with asynchronous or deferral attributes (unless they are critical to the critical rendering path of your web page).
2. Host self-hosted third-party JavaScript files
Hosting third-party scripts on the server can give you more control over how they are loaded. It helps reduce DNS lookup and round-trip times, improve HTTP caching headers, and use advanced features such as HTTP / 2 server push.
Self-hosting hosting is recommended for any third-party script critical to the functioning of your website (e.g. jQuery, Modernizr, Underscore.js).
Warning: Self-hosted scripts may not be updated and may not function as expected. For example, if you're self-hosting an ad serving script and the ad publisher changes the way their script works, your website will not serve any ads until you manually update the self-hosted script.
3. Remove the third party script completely
If a third-party script doesn't add any clear value to your site or users, consider removing it. Many WordPress themes and plugins load a lot of unnecessary scripts that you can never use.
WordPress also forces every site to load the jQuery Migrate script ( wp-includes/js/jquery/jquery-migrate.min.js ). This helps older plugins and themes maintain compatibility with older versions of jQuery. While this isn't a third-party script as it's self-hosted, it still adds an unnecessary HTTP request.
Ask yourself whether your website really needs a date slider or formatting script. If in doubt, you can run A/B testing to see if removing a script will impact your website's performance or usability.
4. Implement browser resource suggestions
Connecting to external domains to download third-party scripts can take an inordinate amount of time, especially if users are on slow networks. DNS lookups, redirects, and any round trips to load each third-party script can cause significant delays.
You can use browser resource hints to establish a connection with the external domain hosting the third-party script at the start of the page load.
There are many resource suggestions, but the ones that are useful here are dns-prefetch or preconnect.
<link rel="dns-prefetch" href="http://domain.com">If the final destination of your third-party script's external domain uses https:// , you can use this to avoid TCP round trips and handle any TLS negotiations ahead of time.
<link rel="preconnect" href="https://cdn.domain.com">5. Third party JS lazy loading
Embedded third-party elements like ads and videos add a lot of stress to your website, especially if they're served via poorly optimized sources. You can defer these built-in resources to speed up page loading.
For example, if you are running ads in the footer of your website, you can load them deferred so that they are only loaded when the user scrolls down the page.
If you're embedding ads on your website, check out this article from Mediavine where they discuss how they improved page speed by 200% after implementing lazy loading.
Use a tag manager to organize third-party JS
Tag managers allow you to group multiple third-party scripts (or tags) together and manage them all from a single source. Using a tag manager wisely allows you to minimize the performance results of loading third-party scripts.
While it is possible to load third-party scripts asynchronously, the browser must still parse and execute them individually. This could mean requesting additional data while the page is loading. Tag handlers solve this problem by reducing the number of requests to one.
Google Tag Manager (GTM) is the most popular solution for managing tags. It loads itself and all related tags asynchronously, so the browser renders a page without pausing. Even a lazy-loading third-party script won't block the loading of any other script.
The Google Tag Manager for WordPress plugin is an easy way to integrate GTM into WordPress sites.
Other tag handlers that you can look at are Adobe Experience Platform Launch, Ensight, and Qubit.
Warning: Use tag managers like GTM with caution. While it reduces the cost of loading third-party scripts, its simplicity also leaves it open to abuse by anyone with the credentials to add tags. Some tags can also introduce a request chain that can result in your site being crawled.
Have a performance budget
After you've optimized your site's performance, you should use a performance budget to ensure your site's performance doesn't degrade over time.
A performance budget is a self-imposed limit for counting the total number of requests and the sizes of scripts, images, and so on. It can also include setting a limit for performance metrics such as Time to Interactive and First Meaningful Paint.
For more information, see the list of all supported resource types and metrics.
You can use the Lighthouse Keep Request Counts Low and Small File Size controls to set your performance budget. Discussing the exact method for setting performance budgets is beyond the scope of this article, but you can learn more about how to do so in the Lighthouse docs.
Conclusions
Third party scripts have become a crucial part of most websites today. Even if you've optimized all the other code on your website, you can't control how third-party scripts play. You can't avoid them because some of them may be critical to your site's functionality, user experience, or revenue stream.
Some topics discussed in this article may not be easy to understand right away. I suggest you review them one more time. Understanding the performance impact of third-party scripts and how to manage them will help you regain control over page load performance.
If you have any questions about any of the points discussed in this article, please feel free to contact us.
