Identify and Solve Third Party Script Blocks
In Qoala, we recently came across a web performance setback, the biggest cause was from third party scripts blocking, which is when third party scripts significantly block the main thread and impact the web’s load performance.
Third party script itself refers to any script that you can directly embed into your website from a third-party vendor, as they are served from an external URL. The implementation of third party scripts is for a wide range of useful functionalities such as advertising, social media and analytics service purposes.
To audit and help us know which scripts are considered blocking time, we choose Lighthouse because of its many abilities to give scores for performance, accessibility, progressive web apps, SEO, and more, and it’s easy to use. There are also other alternatives.
How to Identify Which Redundant Third Party Scripts in Our Web
Install the Lighthouse extension to your local and start generating report.
You can also identify manually on your web page by opening Inspect Element > Network tab and then empty cache and hard reload and see the log requests. Notice that the loading time takes about 3.17s roughly.
Then, try to block a certain script’s request URL. In this case, we will try to block the script name pixel which is provided by analytics.tiktok.com (note that this blocking only occurs on your local). Right-click the request in the Network panel log request and select block request URL.
Empty cache and hard reload again, then the new result can be seen. Loading time takes 2.57s with one network being blocked. Therefore, we take this script as the use case for us to solve later.
How to Solve Blocking Third Party Scripts
If a third-party script is slowing down your page load and it is needed to be there, there are options to improve performance:
async/defer
Using async/defer is important when the <script> element is not located at the very end of the document.
With async, the browser downloads the script asynchronously and when the script finishes downloading, the script executes as it blocks HTML parsing until it’s done. For script files that are not dependent on other files and/or do not have any dependencies themselves, use async. For example, external tools like google analytics that are independent and other scripts wouldn’t wait for, can use async.
With defer, the file gets downloaded asynchronously and it doesn’t run until the HTML document parsing is complete. For script files that require interaction with the fully parsed DOM and dependent with other files included on the page, use defer. For example, if you’re using jQuery and you have other scripts that depend on it, you’d use defer to make sure to call jQuery before the dependent scripts.
Implementing async/defer in HTML <head>:
<script async src=”script.js”></script>
<script defer src=”script.js”></script>Resource Hints; preload, prefetch, dns-prefetch, and pre-connect
preload focuses on fetching a resource for the current navigation without blocking the document’s onload event. Use this for resources that are considered to have a high priority and needed on early establishment (such as web fonts, images, or other stylesheets).
prefetch focuses on fetching a resource for the next navigation that might be needed later. For example, while waiting for a user’s authentication process, using prefetch can store the resources on the next page they will see once authenticated and make it ready to be rendered.
dns-prefetch indicates to the browser that it should perform DNS lookup before that domain is used to download resources. Use this for handling many critical third parties like Google fonts, Google Analytics, or any external JS. This has wider support on any browsers than preconnect has.
preconnect allows the browser to establish an early connection to another origin before an HTTP request is actually sent to the server. Similar to dns-prefetch but this can perform the DNS lookup, TLS negotiation, and the TCP handshake all together. Use this for most critical third-party connections and when you know the origin of the request but don’t know what the actual resource itself is, like our current case analytics.tiktok. Use it carefully as it can still take up valuable CPU time, and delay other important resources.
You can implement these resource hints via HTTP Link headers or via JavaScript
// on Javascript
<link href="resource-url" //url of the script
rel="directive" //preload, prefetch, dns-prefetch or preconnect
as="resource-type" //type of resource
crossorigin="value" //how to handle cross-origin request
/>// on HTTP Header
Link: <resource-url>; rel=directive; as=resource-type;
Implementation and Result
From the report generated by Lighthouse, it is shown that analytics.tiktok blocks more time than the other third party scripts. For this most critical connection, we’re choosing to add resource hint preconnect since it helps to reduce render blocking and improves time to paint, and dns-prefetch so it can serve as a fallback for browsers that don’t support preconnect.
Simply put in HTML head:
<head><link rel="preconnect" href="https://analytics.tiktok.com/api/v2/pixel"><link rel="dns-prefetch" href="https://analytics.tiktok.com/api/v2/pixel" >
If using nuxt, can modify in nuxt.config.js:
head: {
link: [{
rel: 'preconnect',
href: 'https://analytics.tiktok.com/api/v2/pixel',
},{
rel: 'dns-prefetch',
href: 'https://analytics.tiktok.com/api/v2/pixel',
},...Save and deploy! Check the result on Lighthouse, as the mentioned script analytics.tiktok.com is now out of the list.
That’s mostly it! No more worries for slow performance caused by dependent external scripts.
