|
|
|
|
|
by thanasisp
4901 days ago
|
|
...so why don't you try it? You can fork and perform tests... You are right about what the spec sais and what happens in reality as far as "loading" is concerned. Modern browsers can open multiple requests to a webserver. However "Painting" and "Rendering" is another area which most developers miss its significance. Script parsing is blocking to rendering. Especially when scripts are included in the HEAD the delay becomes pretty apparent. Check those slides out: https://perf-metrics-velocity2012.appspot.com/#16 (move left/right with cursor keys). The point of the article was to illustrate how DOM Ready is not needed when loading and executing scripts synchronously. I am not convinced that loading scripts asynchronously will result in a faster, absolute time of when the page is ready to be used by the user (events binded, complex ui that need JS are rendered. And i am definitely not sold on the concept of polling every 5ms for the existence of elements in the DOM. Which is required for async loaded scripts if they want to be as fast as possible (and hoping that they were loaded before the elements are rendered). If I had that much a burden of manipulating an element right there and then when it was rendered, i'd plainly add a SCRIPT tag right beneath it. |
|