Instead, consider exploring how that library solved your problem. Perhaps you can extract the relevant bits of code and tests into your own project, focusing on just the bits you need.
The total size of the library. Not just the initial script, but all the assets that might get loaded asynchronous. A 5kb script could load 100kb of other files later.
Is the total size appropriate for what you get? If your logging library is more than 10kb, you can find a better client-side logger that doesn’t bloat your page.
When does the library change? If you are loading a generic endpoint, like
example.com/library.js, you’ve given an external team the ability to break your page on their schedule. Check if you can load a versioned URL, or better yet, host the library yourself.
Load What You Need, When You Need It.
This can be as simple as defining multiple entry point scripts. For example, a
main.js is loaded everywhere, while
blog.js is only loaded on blog post pages.
main.js would contain generic behavior like analytics and
blog.js could contain the speciality things like comments and sharing.
If you are using a script bundler like Webpack, there are options to break your scripts into separate bundles and load them asynchronously when they are needed.