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 JavaScript status report from HTTPArchive, the median number of external scripts requested by websites is 20 and their total size is approx 449 KB.
A big 93,59% of web pages includes at least one resource of third parties. Digging deeper into the same data shows that the 76% of websites tracks users with analytics scripts.
The worst impact of third-party scripts is the critical rendering. It is the set of actions a browser does to assemble HTML, CSS, and JavaScript into a live, usable website. Of course, the payload size of third-party scripts plays a big role here, but there is still 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 by byte, JavaScript is the resource of more expensive third party served by web pages. Since a browser needs to download all linked third-party scripts while the page is loading, adding them to your website can slow it down considerably.
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. But loading each third party script is one additional HTTP request that the browser must perform to render the page full. These requests accumulate to slow page 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.
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 the speed of your website blocking requests from specific domains. This is useful for measuring the performance impact of problematic third-party scripts by targeting them specifically.
blockDomainsExcept www.domain.com cdn.domain.com cdnjs.cloudflare.com
navigate https://www.domain.com
For 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 of requests network from third parties in the "Network" panel. This feature allows you to get detailed information about third-party script requests on a page.
To use this function, press CTRL / CMD, Shift and P in one of the Chrome DiSCi panels to display the "Command Menu". Next, type “Show third party badges” and activate this function.
Note: Google Chrome version 80 has removed this feature by announcing no replacement. Most likely it is an insect. For now, you need to manually sort the external scripts until Google fixes this problem.
You can also use the "Performance" panel in Chrome DevTools to identify any performance issues on your website.
For more information on how to test 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.
The time audit of start JavaScript Lighthouse classifies scripts based on parsing, compiling, and evaluating time. These metrics help identify third-party scripts that have accumulated a lot of server resources.
The audit of network payload Lighthouse lists all scripts based on total size and transfer time. You can use these metrics to identify third-party scripts that may slow 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 that slow down your website, you can load them using attributes async o postpone HTML to avoid their negative impact on page loading.
The attribute async forces the browser to continue parsing the rest of the HTML document until the script is downloaded. After the script is downloaded, parsing of the HTML document is suspended to run the script.
The attribute defer it 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 attributes asynchronous o of referral (unless they are critical to the web page's critical rendering path).
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 can be out of date and not perform as expected. For example, if you're self-hosting an ad serving script and if the ad publisher changes how their script works, your website won't 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 is not a third party script as it is self-hosted, it still adds an extra HTTP request unnecessarily.
Ask yourself if your website really needs a slider or date formatting script. If in doubt, you can run the test A / B to see if removing a script affects website performance with respect to 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 helpful here are dns-prefetch o preconnect.
<link rel="dns-prefetch" href="http://domain.com">
If the third-party script's final destination of the external domain uses https://, you can use it to avoid TCP round trips and handle any TLS negotiations in advance.
<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 its tags asynchronously so that the browser renders a page without pausing. Even a slow-loading third-party script will not block the loading of any other script.
Il Google Tag Manager for WordPress plugin is an easy way to integrate GTM on 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 opens up to abuse by anyone with the credentials to add tags. Some tags may also introduce a chain of requests that can lead your site to a crawl.
Have a performance budget
Once you've optimized your site's performance, you need to use a budget for performance to make sure your site's performance does not decline over time.
Un performance budget is a self-imposed limit to count the total number of requests and the size 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 control. Keep Farhouse Request Counts low and small file size to set the performance budget. Discussing the exact method for setting performance budgets is beyond the scope of this article, but you can read more information on how to do it in the Lighthouse documents.
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.