the pros and cons of using 3rd party external scripts in websites

Most modern-day websites use several different features that are provided by third-party vendors. The use of these third-party features or plugins allow you to easily incorporate common and popular functionalities without having to develop them yourself or in-house.

Many of these are implemented using JavaScript and CSS technology. Just to give you an idea as to what these are: some of the common and popular features that are implemented using scripts are Google Fonts, Shareaholic, Google Analytics, Disqus etc. Most of the social networking features such Facebook Like, Facebook widgets and Twitter badges are implemented the same way. If you are on a CMS framework, such as WordPress then you might be using some plugins as well.

Whatever the scripts you are using, there are some inherent risks involved when using these third-party scripts. I am going to use the term scripts loosely for rest of the post. It will include the script as well as other related files such as CSS and images which are packaged alongside.

Pros or Advantages

Different Hosts or Domains: By implementing these features, you are definitely using more resources. In most cases, these scripts are served from the third-party servers, such as Google or Facebook which means the load is spread over different servers. This is more beneficial than serving all those from your own servers.

Web Caching: It is quite possible that many other websites have already implemented the same functionality as you have. It is also quite possible that the users have visited other websites that have implemented them. This means that there is a definite possibility that the browser already have the content or script cached in the browser, which allows your website to render faster.

Cons or Disadvantages

Content Control: By using third-party scripts, you are relinquishing the control over how the script functions and the content gets displayed. Most times, it is not a big deal as you have chosen to implement it because you liked it. But this does not mean the vendor cannot change and update the script to differ from how you like it at a future time.

Script Delivery: Most times, the scripts is delivered efficiently using a Content Delivery Network (CDN) or high performance servers but sometimes you will find that it is served using different HTTP header values than what you would have liked. Most users do not even notice these headers, but it is not uncommon to find that your website is slow or broken because of a delivery issue from the third-party servers.

Cross Domain Issues: It is quite possible for some users to have security settings which prohibit the websites to download and display content from other domains. Cross domain scripts and content are one of the common cause of web security breaches. If the browser disallows scripts from other domains, then it is quite possible for your website to be devoid of them when displayed to the user.

Outages: Usually, these scripts and content are delivered from highly reliable and high performance servers especially if you are using features from reputable sources. But it is not uncommon to have outages once in a while which can affect your websites. Usually this is rare but when it happens, it can be highly annoying as you don’t have control over it.

Despite some of the disadvantages, it is still prudent to use them because of the features that it provides as well as the time and effort it requires if you were to do it yourself. Having understood the advantages and disadvantages of using these features, let’s see how you can implement them so as to minimize the negative side-effects of these scripts.

Efficient Script Loading

There are several different ways to load the external scripts, some more efficient than the other. Most times, I have noticed that your return will vary depending on the size of the script and the functionality it implements.

If the external script is similar to Facebook widget or a discussion module (such as Disqus) that does not directly modify the content of the page then it is best to lazy load them at the end of the page without blocking the page rendering.

If you have large scripts which takes a while to load then you can queue them up so as to not to block the download of the rest of the content.

If the script actually does modify content, then it might be worthwhile to block the rendering so that it renders correctly as soon as the content is downloaded.

What I described above is a thirty thousand foot view of the problem, with some suggestions and tips. The problem itself is actually much messier and nasty and beyond the scope of this post. The general rule is that you load them late and you load asynchronously.

Design Website Layout for Outages

Design your website such that the failure to download a script does not affect the overall layout of the page and content. The details of how to do it is quite detailed and is dependent very much on the design/layout of your website.

For example, if the Facebook widget in the sidebar does not load…., will it collapse the content in the rest of the page? It is probably a good idea to designate a blank space where the widget should have been and keep the rest of the layout intact. Or even better make the rest of the sidebar collapse gracefully…

Design the layout and implement it such that the layout and the main content renders just the way it should even if one or more of the third-party scripts fail or executes slowly.

Make Good Use of Browser or Web Caching

You could add the code that implements (or downloads) the script in a header file that is included with every page. This allows the browser to download them and reuse it from cache everywhere else it is used. This is preferred if you have a site with lots of different landing pages, such as a blog.

If you have a website such as a business site, where most of the traffic to your website passes through the front page (or a popular landing page) then it might be worthwhile to load most scripts just on that page even the ones that is not used on that page……..yep, asynchronously without blocking. This can potentially speed up the rendering of the other pages as the user traverses the rest of the site.

This is more of an art form than anything else, and there is generally no single correct answer to how best to do it. You can always come up with a use-case where it would not be optimal.