Timeline for Is JavaScript added and executed in parsing or in rendering?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 25, 2019 at 16:56 | comment | added | amon |
@gaurav5430 I never bothered sourcing that because it seemed obvious, and can be easily reproduced by inserting some JavaScript code in a page in order to interrupt parsing (JS can modify the page source thus delays parsing). E.g. consider the URL data:text/html,content before pause<script>alert("close to continue")</script> and more content.. The Mozilla blog also contains some overviews of their Quantum engine, e.g. a post about speculative parsing.
|
|
| Dec 24, 2019 at 17:56 | comment | added | gaurav5430 | What is your source for "The browser will immediately try to render the DOM, even if the HTML code has not yet been fully parsed, for example if the full code hasn't yet been received. The browser will update the rendering if the DOM changes or as style information becomes available, for example when the correct font is loaded." Doesn't rendering happen after parsing is completed? any pointers on this? | |
| Apr 17, 2019 at 10:57 | comment | added | amon | @JohnDoea The async attribute is only available for script tags that link to an external script. If the script is inline it should be moved to the bottom of the HTML document, or just register a callback to run once the DOM has been fully loaded. | |
| Apr 17, 2019 at 10:55 | comment | added | amon | @JohnDvorak You do have some valid points: JS execution is not the problem, the problem is delayed discovery of resources that must be loaded. I don't quite buy the CPU resource argument though: if server resources were so precious we'd write backends in Rust not Ruby. Templates are generally not the problem. | |
| Apr 17, 2019 at 10:07 | comment | added | John Dvorak | Also, if you do server-side rendering on a server that's low on CPU resources (CPU hours cost hosting money), the time to do the rendering will become even more significant than the network time. And of course, all of that is moot if the main bottleneck is that it takes the database five seconds to answer the simplest of queries. I'm looking at you, Azure. | |
| Apr 17, 2019 at 10:04 | comment | added | John Dvorak | Not sure about the "don't modify DOM client-side" bit. The main bottleneck, as per my guess, is the network response time. GZip is really good at compressing HTML, but there may still be some savings. How much time is lost by having to render CSS after Javascript runs I'm not sure, but CPUs are getting fast these days... | |
| Apr 17, 2019 at 9:58 | comment | added | John Dvorak |
"its execution blocks further parsing" - usually the browser will keep parsing the data (and even recomputing CSS) in parallel with Javascript execution. It can't update the DOM from under Javascript's nose, but it can prepare the DOM resultant from the parsing and put it in place once Javascript is done running. It only has to discard that data if the Javascript pulls off some document.write type of nonsense. Best case, the Javascript merely sets up a ready handler and stops, in which case the rendering only pauses for the time it takes to retrieve the script from cache.
|
|
| Apr 17, 2019 at 8:40 | comment | added | user216836 |
Thanks amon. Please avoid this comment if you think it's unrelated (I think it will help me to make sure I understand but if you think I should ask a new question I will do so): If Async JS redunds the need to move sync JS to <footer> to prevent "blocking" (waiting for each JS resource in parsing) AND actually takes JS out of parsing to load it only in Rendering in a "First In First Out" way, why not Always use async and be done with it?
|
|
| Apr 17, 2019 at 8:24 | vote | accept | CommunityBot | ||
| Apr 17, 2019 at 7:29 | history | answered | amon | CC BY-SA 4.0 |