I have one example in mind that really annoyed me.

One of our clients needed some features really quick and I wasn’t around at that time to help with it. They got someone from UpWork to do the job and they did it, it worked as expected.

All good until the client mentioned that the loading time is quite high now. We started to look at the code and how it was created to find out that all the libraries were embedded from 3rd party CDNs/servers. Not even the minified versions, the full ones.

We ended up with OwlCarousel twice on the site (and now loaded everywhere), we ended up with Bootstrap twice and some other JS library being delivered from 3rd parties.

Keep libraries locally

My main focus here is the CDN libraries.

This is something that I noticed a lot in WordPress development projects. Mostly when it comes to someone working on an existing project.

Clients will come in and ask for improvement, or some feature to be added on their existing website. This means you need to deal with the code that someone else created, the folder/file structure, re-use some functions/scripts, etc.

This is tedious and it takes time, you just want to have that thing done and ship it. It’s totally understandable, but you also need to make your adjustment robust.

Linking the libraries in the <head> directly from a CDN or server is not a good practice.

It’s perfect for the development environment where you want to quickly test and see if it does the job and you don’t have to worry about adding the library into the compile process or enqueue it on a specific component.
But for the real-world, when you ship that solution, you should store that library locally in the folder of your project. If the project will use a CDN and that asset will be delivered from there, then perfect.

Do not rely on a 3rd party CDN or server to deliver your library.

Reasons

  • It might get an update and break your production site (in most cases they are version controlled, but it can happen)
  • It can get deleted at some point
  • The CDN/server link my go down
  • Multiple requests on page load
  • Slowing the loading time
  • Offers details on what libraries you’re using. Might be easy to target some exploits.

Build things that are durable, robust, and don’t need any external help to run.