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.
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.
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?
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.