3 ms·
> making your script async … can hurt with other things I can't agree. It will likely regress window.load time, but that's a bad metric. Additionally, the ref
by paulirish 11y ago
> making your script async … can hurt with other things
I can't agree. It will likely regress window.load time, but that's a bad metric. Additionally, the reflow cost post-execute will be <100ms, but the delay to the paint caused by a sync script worth 100-5000ms. In very rare occasions would it be preferable to show a white page to a user longer to avoid the DOM change costs.
> DomContentLoaded
Agree with the above. Additionally, I believe all browsers wait for DCL handlers to finish loading before painting (for the common case). But, most pages have ALOT of code attached to DCL. If the handlers are not critical for the first paint (they shouldn't be), then the easy fix would probably be
document.on('DOMContentLoaded', e => { requestAnimationFrame(function(){ /* your doc.ready stuff */ })});
That way you get a paint to the user before your piles of DCL code runs.
- taf2 11y agoI think this is what https://github.com/wilsonpage/fastdom https://github.com/wilsonpage/fastdom was designed to help with... The issue I have with it is it's another library to load...
- bzbarsky 11y ago> Additionally, the reflow cost post-execute will be <100ms It really depends on the page. It's pretty easy to come up with pages that take a lot longer than that to reflow (tables, deeply nested flexboxes, etc). I agree that typically making the script async is a good idea, but it's really worth measuring both ways for the particular script and page in question.