Can someone explain to me why third party JS has such a big impact on load time? I thought browsers deprioritize third party JS and load it after all first party assests have been downloaded and the site has been rendered. If that's the case why does third party JS still have such a big impact on page performance?
You can (usually accidentally) end up with a render blocking script tag. In this article example it was client-side optimizely.
This makes sense for a tool like Optimizely which has to block rendering.
The parsing and execution of third-party javascript is definitely non-trivial if you profile it, especially on lower end devices.
Given that this is supposed to happen after the page has already loaded, does this matter? If the thing you are optimizing for is page load time, and it takes a few 100ms after the page has already loaded to run the JS, does that actually negatively impact the user experience?
Finally, browser download priority requires async and defer attributes on scripts (usually), or other clever ways of deferring loading.
When you add third party JS, shouldn't this be taken care of for you? Scripts for adding third party JS should already make use of async and defer as needed. What's a case where you would need to actually think about async and defer when making use of third party JS?
This type of thing usually ends up being “death by a thousand cuts”. async + defer help out, but they do still incur parsing and evaluation (iirc, before document onload event) overhead. If you delay loading until you’re sure the page is interactice, you’ll end up loading third-party pretty late (which impacts metrics, and usually isn’t out of the box supported).
On a standard product-ey site with retargeting ads, user tracking, etc. this third-party slowdown is significant.
All of this is exacerbated on lower-end devices, and non-WiFi Internet.
One thing important to note is for certain use cases of Optimizely like A/B testing, it's actually desirable to block rendering until it's initialized as otherwise you end up with a flash of the default variation that then gets switched to the appropriate one afterwards.
Though after working with a few of these A/B testing vendors, I'm firmly convinced that you'd be better off long term implementing your own A/B testing service on top of some internal admin UI builder like Retool.
I don’t know how standard this is but to prevent our third party JavaScript from impacting page load times, we defer our tag manager (Tealium) from being loaded until after the page has successfully loaded.
Comments
Can someone explain to me why third party JS has such a big impact on load time? I thought browsers deprioritize third party JS and load it after all first party assests have been downloaded and the site has been rendered. If that's the case why does third party JS still have such a big impact on page performance?
You can (usually accidentally) end up with a render blocking script tag. In this article example it was client-side optimizely.
The parsing and execution of third-party javascript is definitely non-trivial if you profile it, especially on lower end devices.
Finally, browser download priority requires async and defer attributes on scripts (usually), or other clever ways of deferring loading.
This makes sense for a tool like Optimizely which has to block rendering.
Given that this is supposed to happen after the page has already loaded, does this matter? If the thing you are optimizing for is page load time, and it takes a few 100ms after the page has already loaded to run the JS, does that actually negatively impact the user experience?
When you add third party JS, shouldn't this be taken care of for you? Scripts for adding third party JS should already make use of async and defer as needed. What's a case where you would need to actually think about async and defer when making use of third party JS?
This type of thing usually ends up being “death by a thousand cuts”. async + defer help out, but they do still incur parsing and evaluation (iirc, before document onload event) overhead. If you delay loading until you’re sure the page is interactice, you’ll end up loading third-party pretty late (which impacts metrics, and usually isn’t out of the box supported).
On a standard product-ey site with retargeting ads, user tracking, etc. this third-party slowdown is significant.
All of this is exacerbated on lower-end devices, and non-WiFi Internet.
One thing important to note is for certain use cases of Optimizely like A/B testing, it's actually desirable to block rendering until it's initialized as otherwise you end up with a flash of the default variation that then gets switched to the appropriate one afterwards.
Though after working with a few of these A/B testing vendors, I'm firmly convinced that you'd be better off long term implementing your own A/B testing service on top of some internal admin UI builder like Retool.
I don’t know how standard this is but to prevent our third party JavaScript from impacting page load times, we defer our tag manager (Tealium) from being loaded until after the page has successfully loaded.