> 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 worked with Alexey on this project. It’s pretty straightforward to filter out bots (either before send, or in analysis later). For our traffic, it was mostly commonly known bot user-agents.
I’m also pretty sure malicious bots get blocked by Cloudflare before hitting the Cloudflare workers.
When dealing with ads, most "bots" are actually clicks coming from click farms, which are from real devices. I'm not sure what's the best way to filter those though.
reply