4 Ways to Optimize 3rd Party Libraries
Tags: javascript, webdev, performance
Published: 2021-10-07 18:11:50

Web performance is an often overlooked metric of a company's website. It’s pushed to the back of the queue in preference of a site's look, layout and theme. While these areas of a site are important aspects of your visitors' experience, a poor loading and performing website will cause them to leave your site before it’s loaded. This means all the time and effort spent on crafting a great and compelling user experience was for naught.

According to a [study conducted by Google in 2017](https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/page-load-time-statistics/), as page load time goes from 1 second to 3 seconds the probability of a user navigating away increases 32%. The performance of your site ensures visitors get to go through the finely crafted experience teams have spent many hours creating.

If you’re a 3rd party SaaS provider, performance is more important. Businesses want to use your service, but if it’s the cause of performance issues on their site, they will be looking to replace your service as soon as they can. 

At [Ketch](https://www.ketch.com/), one of our top priorities is to ensure our libraries are as optimized as they can be for performance. 

Here are 4 ways we use, and so can you, to optimize our libraries to ensure they don’t hinder the loading and performance of our customers' websites and applications.

##Use async/defer
If at all possible you should design your library to be loaded asynchronously, rather than synchronously. This is to allow page rendering to occur while the library is being downloaded, unlike synchronous scripts which stop page rendering until the script is downloaded, parsed, and executed. 

![Synchronous loading of javascript](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z8fl1dz6i02a7hddmuwo.png)

You can utilize the `async` or `defer` attributes to instruct the browser to continue parsing the HTML while the scripts are downloaded.

While both the `async` and `defer` attributes tell the browser to download while the page is being rendered, the point at which the downloaded script is executed is where they differ.

The `async` attribute tells the browser to execute the script the first chance it gets after it has been downloaded, but before the `load` event is fired.

![Asynchronous loading of javascript](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u7mdnl4f73r2uchlstj1.png)

The ‘defer’ attribute tells the browser to execute the script after the HTML has finished parsing, but before the `DOMContentLoaded` event is fired.

![Defer loading of javascript](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8csnu9fuaf39psshjkve.png)

##Remove unused code
![Room with many stacked arm chairs on one side](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/002vitg0g3hsvhfdvzzh.png)<figcaption align = "center">Photo by [v2osk](https://unsplash.com/@v2osk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/remove-unused?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyTex)</figcaption>   

To optimize the loading of your library you will probably run it through a bundling process to reduce the number of round trips to the server. Bundling combines your code files and their dependencies into a single file. 

What we tend to forget is that we rarely use all of the functions available within our dependencies, which come along for the ride during the bundling process. This can lead to an unnecessarily large file to download. 

To reduce this file size, implement a [tree shaking](https://webpack.js.org/guides/tree-shaking/) process to remove all the code not being used.

Tree shaking looks at the bundled file and attempts to determine which code paths are not called and remove them from the final output.

Note: Tree shaking can have unintended side effects if it is too aggressive in removing what it thinks is unused code. This can cause unintended side-effects or broken logic on your page. You need to thoroughly test your page with the tree shaken file.

 

##Break larger JavaScript files into multiple, smaller logical files
![Lego Star Wars Stormtrooper being pulled apart by Darth Vader](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/blyrx9h67z0y21iz34nk.jpg)<figcaption align = "center">Photo by [Daniel Cheung](https://unsplash.com/@danielkcheung?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/construct-lego?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)</figcaption>


Above we talked about the bundling process, which combines your code and its dependencies into a single file to reduce the need for multiples to the server. Sometimes we don’t need all the functionality immediately upon page load. 

For instance, there may be function calls that require a user to press a button before it’s activated. This code can be separated into another file to be downloaded, or deferred, after the page’s HTML has been parsed. 

##Use a Content Delivery Network
![World globe with several destinations marked](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/regx6cddbn4rjx3por07.png)<figcaption align = "center">[People illustrations by Storyset](https://storyset.com/people)</figcaption>

With all the previous optimizations implemented, you may think you’ve done all you can to increase your page’s performance, but visitors to your customers site are not created equal, at least in the case of location.

The further the visitor is away from your web server's physical location, and the speed of the network they’re connected to, affect how long it will take for their device to download your library.

While the previous optimizations will help tremendously with how long a library takes to download, this will move the files closer to the visitor. This can be accomplished by utilizing a content delivery network (CDN), like [Fastly](https://www.fastly.com/), [Akamai](https://www.akamai.com/us/en/cdn/), or [Cloudflare](https://www.cloudflare.com/cdn/).

The CDN does not replace the need for a web server, but allows caching of a site’s content at strategic locations around the world. This caching closes the distance between your library and the visitor viewing your customers page, decreasing the download time.

##Conclusion
As a library creator, your responsibility doesn’t stop at getting the code working as expected. How it loads and affects the page on which it's executed is just as important. 

At Ketch we are continually monitoring and improving the performance of our libraries utilizing the tips above, ensuring we are never a hindrance to a customer’s site. 

Optimizing your library will show customers you care just as much about their site’s performance as they do.