Tips on loading third-party scripts efficiently
As we discussed in "How third-party scripts performance pitfalls are related with the Critical Rendering Path", third-party scripts can be costly to loading performance, significantly slowing it down. Now, let's identify some available options to improve the so-called browsing performance.
Load the script using the async or defer attribute
You might want to use
defer for third-party scripts excepting that the ones that do something crucial for the critical rendering path, like jQuery that makes things dynamic and/or interactive for the user.
async attribute makes the script run earlier in the loading process. Consider this option if the script plays a critical role like analytics tracking. Click here to read about the differences between
defer [ * ].
defer attribute is a good choice for less critical resources like something that is hidden to the user at the time when the page first loads or something that only works or is displayed after some user interactions. So, the browser doesn't wait for the script and continues to process the HTML, building the DOM.
Self-host the script if the third-party server is slow
Sometimes the third-party server may not be so reliable. In this case, you may consider self-hosting the script. Here we have some reasons to choose this option:
Reduce DNS lookup and round-trip times: DNS lookup happens to be background work responsible for addressing a request to its IP address, only after that the resource you wanted will be called. So, you now can imagine that this work may become a bottleneck in the browsing experience as the referenced resources from numerous domains grow larger in your website.
For this specific amount of time to reach a destination and come back we give the name DNS Latency. So, when you reduce DNS lookups for your website you shave off time from page loading performance which can eventually result in SEO bonuses. Click here to read more details about it [ * ].
Improve HTTP caching headers: is known to fast retrieve resources as it gets required the next time storing local copies in the browser. Self-hosting allows you to attach those headers to the response and control the cache behavior.
Take advantage of HTTP/2 server push: the common behavior of a website relies basically on the website sending requests to web servers. This way, the user needs to wait for the webserver to retrieve those assets delaying rendering and increasing load times. Server pushes can be used to send those assets just before they've been requested. It is known as a performance technique capable of load resources preemptively. Click here to read more about it and learn with practical examples [ * ].
Self-hosting scripts come with a considerable number of issues that you must check out reading this article [ * ].
Remove the script if it does not add value to the site
Simple like that.
Perform DNS lookup for hosting domains
This hint anticipates a DNS lookup improving performance and so when the browser requests a resource, the lookup has already occurred. Those are known as Resource Hints and you can click here to learn more about it [ * ].
<link rel=preconnect> to tell the user agent that it should preemptively connect to the target resource’s origin.
<link rel=dns-prefetch> to tell the browser to preemptively perform DNS resolution for the target resource’s origin.
Performance Benefits — https://developers.google.com/speed/public-dns/docs/performance
Increasing Application Performance with HTTP Cache Headers — https://devcenter.heroku.com/articles/increasing-application-performance-with-http-cache-headers
A Comprehensive Guide To HTTP/2 Server Push (2017) — https://www.smashingmagazine.com/2017/04/guide-http2-server-push/
Techniques for improving site performance — https://web.dev/fast/#prioritize-resources
HTML attribute: rel — https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel