In this article we are going to discuss how to reduce the impact of 3rd party code on the loading of your website. If you have a ton of 3rd party code loading when a visitor enters your URL into their browser, your page will load slower leading to penalties on Google search engine ranking and a poor user experience.
Many speed testing and optimization tools such as PageSpeed Insights, GTmetrix, and lighthouse have an audit called "reduce the impact of 3rd party code". If third party code has a serious negative effect on the loading time of your website, this notice will display, leaving you to try and figure out exactly how to do that. We wrote this article to teach you how to reduce the impact of 3rd party code on the loading time of your website. This article is specifically created for the WordPress CMS, but can be adapted to most website frameworks and CMSs out there.
When trying to reduce the impact of 3rd party code on a website, there are a few steps that you need to take. First, you need to identify what exactly is loading on your website, and what code you should actually take a look at. There are some chunks of code that are essential to the well being of your website such as analytics trackers, JavaScript frameworks and libraries, and more. There are some that aren't mandatory and can be removed. And there are some that can be optimized to have less of an impact on the loading time of a website.
First, let's take a look at some real world data, as well as common third party code. many news websites have tons of trackers that help them understand where their visitors are coming from, allowing them to serve targeted ads which leads to more revenue.
This is great from a financial standpoint, but from a page speed standpoint, these additional tags have a serious impact on the loading time of a website. According to a Pingdom study of the world's top 50 news websites, the average load time of sites with tags was 9.46 seconds, and just 2.69 seconds when tags were disabled. (wp-rocket.me).
You may be thinking, "I don't run a news website, so these trackers shouldn't have much of an impact on the user experience for my visitors". However, that's also probably false. On average, sites have 43 trackers, and 42% of sites loaded with 30 to 49 trackers. (wp-rocket.me). Now, you may be wondering why any website may need 43 trackers. First, let's take a look at some common trackers out there to give you a better understanding of why they may be mandatory for your website.
Some of the most common trackers out there are Google Analytics, Facebook pixel, and additional retargeting tools that help you run better advertising campaigns. Many websites use Google tag manager as a platform that helps you manage all of these additional third party code snippets.
And those are just the trackers. If you're looking for complex functionality on a website, chances are this is enabled by third party JavaScript libraries which can be called from a CDN or enqueued directly into your WordPress files. There are JavaScript libraries for virtually everything out there, from sliders to complex animations to popups. Many WordPress plugins are built on top of JavaScript libraries, and make third party code requests.
In fact, a third party library is included in WordPress by default, known as jQuery.
For pretty much any modern website in 2020, third party code is a mandatory obligation. with that being said, it almost always negatively impacts the page speed of a website. Website developers and users alike should understand this trade off, and seek to find a balance between functionality and usability. As we said before, there's mandatory third party JavaScript, there may be third party JavaScript that you can get rid of altogether, and there's also third party code that you can load in a different way, giving it less of an impact on your page speed.
Now that we've covered what third party code usually is on a WordPress website, let's discuss how to identify and efficiently load this third party JavaScript (or other code). The remainder of this article is going to cover some basic things and plugins that you can install in your WordPress website to increase the page speed loading time, while also diving into some advanced methods of reducing the impact of 3rd party code . Feel free to use the table of contents at the beginning of this post to skip around.
When optimizing your website for speed, you first need to identify what third party code is impacting your page speed drastically. Once you know what the issue is, you can determine the best way to remove or efficiently load it. Let's get right into how to identify these aspects of your website.
We highly recommend taking a two pronged approach to this challenge. First, generate a lighthouse performance audit, which will let you know the third party usage of your website. This is incredibly helpful because it not only links you directly to the location of your third party code, but it also displays this size and main thread time taken up by these libraries.
Let's take a look at a website that is notoriously slow to load, and gets terrible lighthouse scores: CNN.com. this is one of those news websites that loads dozens of trackers at once, and has a ton of 3rd party code impacting the performance of it. We're not even going to begin to try to figure out how to speed it up, but this is just to show you howdy lighthouse tool found at web.dev can help you identify third party code that has a negative impact on the loading time of your website.
The transfer size is how much data is actually downloaded on the user's browser. The larger the transfer size, the more of a negative impact that it will have on your visitors loading experience. The main thread blocking time refers to how long The main thread of your server is blocked by this individual chunk of code. Main thread blocking time is directly related to total blocking time period a blocking task refers to a piece of code that runs on the main thread for more than 50 milliseconds.
During this time, the browser must wait for the specific task to finish before it can respond, making it likely that the User will notice this delay, and be negatively impacted by it. As you can see, on the CNN website, the integral ad science has a large transfer size, but a massive main thread blocking time, which directly impacts the users experience when the website loads. This is something that definitely needs to be addressed, by either removing this third party code, or loading it in a different manner, which we will discuss below.
Lighthouse is a great starting point when it comes to analyzing the impact of 3rd party code on your website's loading time, but we also like double checking and getting another perspective by using a waterfall chart. A waterfall chart is essentially a horizontal bar chart that shows the total loading time of each individual asset that loads on a website. We really like using the website called webpagetest.org to generate these type of reports. Below is a waterfall chart generated for CNN.
This is not the entire screenshot of the waterfall chart, due to the fact that the CNN website loads hundreds of different assets, leading to an incredibly long chart. Instead, here is a collection of screenshots displaying some problematic third party code assets that need to be looked at.
With the waterfall chart, you can visually identify any outliers that are negatively impacting your speed, click on that individual entry, and get more information about the asset.
Here is the full waterfall chart for a smaller website, one of our clients (before we made a new one for them). This gives you a better idea of what a typical waterfall chart looks like, and how you can easily identify several outliers.
Here, there are two decently long scripts in the form of jQuery and jQuery Migrate. we can't really get rid of jQuery, because most WordPress plugins require it, but we can get rid of migrate, and it's removed by default in newer versions of WordPress. The waterfall chart also shows that we definitely need to focus on our image optimization , as these are render blocking for some reason and definitely destroy the page speed numbers.
We also get a nice little content breakdown, which is helpful if you're trying to understand what you should focus your optimization efforts on. For example, if your images take up 90% of the data transfer, that's definitely an issue, and you'll need to compress them. However, that doesn't relate to reducing the impact of 3rd party code, which is almost always shown as JavaScript. In this example, JavaScript makes up a good portion of the data transfer, so reducing this impact will have a beneficial effect on the end user.
With the content breakdown, we can also visually compare the requests and bytes. For example, if you only have a few requests for JavaScript, but a ton of JavaScript bytes transferred, that means that there are only a few chunks of code causing a major performance impact on your website. If you have a ton of JavaScript requests, and a ton of bytes, this is also helpful information because you are loading many libraries, meaning you can either consolidate, load differently, or disable many of them.
Now that we have a list of the third party code that is loading on our website, and the actual impact that it has , we can begin to gameplan how to reduce the bloat.
If you have identified a third party chunk of code that you yourself have inserted into your website, and know that you can remove it without breaking anything (this could include an analytics platform, retargeting tracker, advertising inserter, or something else) you can simply get rid of it. this can be done by editing the header, your functions.PHP file, or wherever else you have inserted this script into. You can easily figure out where it is located on your website by going to your development tools inspector console, and searching for its name or SRC.
More often than not, including this third party code in your website is mandatory. if this is the case, you have two options. Leave it as is, or attempt to load it differently which should hopefully result in less of an impact on the page speed loading time.
If you opt for the latter route, this would be called efficiently loading third party JavaScript. There are four major ways to go about doing this. First, you can use the async or defer attribute on <script> tags. This can be done with a plugin, which we will discuss in a later section of this article, or manually if you are able to access an edit the script tag (this makes sense if you manually added it via a code snippet manager like Advanced Scripts).
Additional ways to efficiently load third party JavaScript include establishing early connections to the required origins, lazy loading your code, and optimizing how you serve them. Lazy loading your code can be incredibly beneficial to the perceived loading time of a website, unluckily there is a plugin that allows you to do this fairly easily.
Let's cover how to lazy load third party code, which reduces this overall impact on the loading time of your website, and then run through how to defer or asynchronously load JavaScript by using a plugin called asset cleanup. When discussing asset cleanup, we will also show you how to disable or remove scripts from the page altogether.
By following a number or any one of these optimization tips and techniques, you will definitely be able to make your page load quicker, score higher and page speed insights, and offer a better user experience to your visitors.
First, lazy loading scripts is easy in WordPress. All you need to do is install a free plugin, available on the WordPress repository, called Flying Scripts. This delays the downloading and execution of JavaScript until the user interacts with the website. What this does is allowed the page to load without the impact of much of the third party code, and then load it in as the visitor needs it.
It's quite simple to use. all you need to do is install the plugin, and then add the keywords of the scripts that you want to lazy load. For example, if you are trying to lazy load Google Analytics, the name of the script would be analytics.JS, meaning that the keyword analytics entered into the keyword input would be enough to delay the execution of this JavaScript.
We recommend delaying the execution of all JavaScript until absolutely necessary as it is very resource heavy and prioritizes critical JavaScript files like jQuery and animation libraries. By lazy loading these scripts, you will also reduce the initial payload to browsers by reducing the number of requests, which directly benefits your render time, time to interactive, first CPU idle, and maximum potential input delay.
Basically, using this plugin ensures that your pages will load quicker than before, and 3rd party code will have much less of an impact. You would be surprised at how many chunks of 3rd party code can be delayed until user interaction without impacting the overall structure and look of your website.
For critical JavaScript, we recommend loading it asynchronously or deferring it. This is done by using a plugin called Asset CleanUp Pro. Once you install this plugin, it generates a list of all assets and files that load on this specific web page or template that WordPress is using. This is neat because it also loads CSS files, in addition to your JavaScript code.
You have the option to remove the code from the web page entirely, or loaded asynchronously / deferred. This is done by toggling a checkbox, which in turn injects the loading rule directly into the script tag before serving it to the browser and downloading the asset. If you do this correctly, you can eliminate most render blocking resources, and load a webpage much quicker.
It is important that you choose the correct method of loading for the specific script. The difference between the two is when they start executing the actual script. Scripts with the asynchronous attribute execute as soon as they finish downloading , and right before the windows load event. Typically, this means that they are not executed in the order that they appear in the HTML, which Is sometimes necessary for the library to function. It interrupts the parsing process and Dom building while executing, which is displayed in the image below:
You should asynchronously load assets that are necessary to the immediate function of the page. That's because they execute as soon as they are fetched, but block the Dom building process. If you're unsure of which one to choose, simply test both methods of loading using asset cleanup on the front end.
If you defer the loading of a script, it fetches during the parsing process of HTML, but executes after the dom is built and the web page is visually rendered to a visitor. This is nice because there is no render blocking, but can lead to a page not functioning correctly for a matter of seconds as it needs to wait until the whole page is done to execute the script.
Essentially, you should load asynchronously if the script is mission critical to the formation of a page, but defer the scripts if at all possible. A good example would be a library that enables tabs below the fold. You don't need this immediately, so there is no point to block the parsing process by executing the script. Load that deferred.
According to Google, “Using these attributes can significantly speed up page load. For example, Telegraph recently deferred all of their scripts, including ads and analytics, and improved the ad loading time by an average of four seconds.”
We would recommend using the lazy loading for analytics scripts and other trackers (also ad scripts are good here too). We would recommend using deferred loading or asynchronous loading for mission critical libraries that pertain to the functionality of your website.
There are a couple of other things that you can do to minimize the impact of 3rd party code on your website. Specifically, if you establish early connections to the required origins of 3rd party scripts by using pre connect or DNS fetch in the link element, this can shave off 100 to 500 milliseconds of loading time.
Pre connect tells your browser to start the loading process to the specified origin as soon as possible.
Pre connect should be used sparingly, and only two critical domains that you will use as soon as possible, because your browser will close any connection that isn't used within 10 seconds. This can delay other important resources, and negatively impact your loading time. This should be used for only the most critical of connections.
DNS prefetch is like pre connect’s little brother. This instructs the browser to only resolve the DNS of the specific domain before it is called. This is only a portion of the actual connection, which includes handshakes and TLS negotiations, which isn't covered by DNS prefetch.
Additional things that you can do to minimize the impact of 3rd party code on your website is self hosting third party scripts by downloading them and enqueing them directly into your website via a custom plugin. This can be very helpful and shave off a ton of load time by improving your caching headers, taking advantage of HTTP 2 push, and reducing your DNS look ups , as you make less browser requests to third party services, but also comes with some downsides.
Your scripts will not get automatic updates , and could lead to an insecure website. That is why we typically don't do this on our client websites, as security is much more important then speed. A hacked website that loads quickly makes no sense.
If you are not using a CDN, there are tons of free options out there that can speed things up due to geographically closer nodes. We always recommend using a free CDN like cdnjs.org for all of your JavaScript libraries that are not self hosted.
If you are an advanced user, you can use service workers and Cloudflare workers to cache scripts from third party servers for a period of time period this gives you a similar benefit to self hosting, but also refreshes the script every so often ensuring that you have the most up-to-date version, plugging up any security issues. However, specific to the Cloudflare worker caching, that server can only catch offsite or third party resources if those third parties sign up with Cloudflare and configure their cache security policies.
If you are looking to reduce the impact of 3rd party code on your website, you have several options, ranging from simple plugins to complex server worker setups. Luckily for you, regardless of your technical know how, you have many solutions at your disposal. We definitely recommend taking a look at the plugin that allows you to lazy load third party JavaScript assets, Flying Scripts. If you can't manually add defer or async to your script tags, take a look at Asset Cleanup Pro, which makes this process quick, simple, and painless.
If you have any additional questions about how to reduce the impact of third party code on your WordPress website, don't hesitate to reach out to us in the comments section below. We hope that this article was beneficial, if it was feel free to share it with your audience!
Wonderful read
Thanks Lanardo!