Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: