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.
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.
In fact, a third party library is included in WordPress by default, known as jQuery.
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.
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.
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.
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.
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 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 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!