Add render blocking post #12
Conversation
| <img src="/img/critical_render_path_JS_karamalegos.svg" | ||
| alt="HTML encounters a synchronous script in the head which stops the parser" | ||
| width="595" height="862"> | ||
| <figcaption>Synchronous JavaScript (no async or defer) will block the HTML parser both for download and execution (<a href="#critical-render-path-js">link</a>)</figcaption> |
There was a problem hiding this comment.
I love the diagrams but it's inaccurate because the CSS will be downloaded before the script executes. This is because of speculative parsing that will look ahead to discover resources, even if the HTML parser is blocked.
It's super tricky to represent that in a diagram though.
https://andydavies.me/blog/2013/10/22/how-the-browser-pre-loader-makes-pages-load-faster/
https://webkit.org/blog/166/optimizing-page-loading-in-web-browser/
whatwg/html#5624
There was a problem hiding this comment.
Thanks! I have an idea for that. I'm wondering if that means the CSSOM construction is not blocked? I feel like it should be though.
There was a problem hiding this comment.
I have not explored this deeply enough recently to know the answer, sorry.
There was a problem hiding this comment.
Thanks again. Just edited the diagram and pushed up all the changes.
There was a problem hiding this comment.
That's a good diagram: more accurate without going too deep into speculative parsing.
I think the <figcaption> still needs updating though.
There was a problem hiding this comment.
Seems like you've updated the other figcaption (and that's a good edit). This one still mentions that it blocks downloads.
There was a problem hiding this comment.
I presumed a non-async script would block the speculative parser as well as the HTML parser because the script might change the content?
There was a problem hiding this comment.
Nope, the speculative parser was created exactly for sync scripts and in particular document.write() (see the links I shared). It is called speculative because it could download resources that won't be needed once the real parser as done its job. Bugs aside, the idea works well in practice because we rarely use document.write to comment out a section of HTML.
There was a problem hiding this comment.
For this one I actually meant the parser is blocked during download and execution of the JavaScript. Not that it blocks other files for download. Is this more clear?
Synchronous JavaScript (no async or defer) will block the HTML parser during both download and execution of the JavaScript
There was a problem hiding this comment.
What about:
While synchronous JavaScript (no async nor defer) is being downloaded and executed, the HTML parser is blocked
No description provided.