My thinking: if I'm going to build websites that are fast and reliable, I need to really understand the mechanics of each step a browser goes throu...
For further actions, you may consider blocking this person and/or reporting abuse
Great post.loved the images. Thank you.
Thanks, really appreciate it!
Nice article, but I've long argued that the information in the diagram in section 3 cannot possibly be right. In the absence of a DOM document, (remember, that's not applied until section 5) there's no way to turn
body { font-size: 16px } div { font-size: 14px }into a tree structure in which a div rule is a child of a body rule. You could possibly turnbody { font-size: 16px } body div { font-size: 14px }into such a tree structure, though personally I have my doubts that browsers actually do this, since I really can't see how doing so would significantly help evaluate the cascade.The CSSOM is real and is indeed tree structured, but it's a very different sort of tree, where stylesheets are towards the top of the tree and each has rule children, which have selector and declaration-block children. Each declaration block has declaration children which have name and value children.
Thanks for the feedback, yes I see what you're saying. It's a great point. I'm happy to admit I'm no expert on the inner workings of the CSSOM. I'll do some more investigation and see if I can update the diagram to better reflect what's happening 👍
From what I've read on Firefox source code, James is right.
You can actually make the CSS tree at #3. Both trees are constructed at the same time. Rules are just rules, they are attached in reverse order from what you expect, you can actually build the entire rule tree without having the DOM, its the DOM that does the lookup on the CSSOM when its time to render.
Its more like the body rule is the child of the div rule, CSS is inverted. The lookup is the inverse of what common sense says it is. Its a literal inverted tree, it actually is.
What do you mean by both trees? The DOM tree and the CSSOM tree, or the CSSOM tree and the render tree? Have you got a link to the relevant bit of the Firefox source code?
Thanks for putting this together so succinctly!
Over on A List Apart, we have a series that goes into great depth on this as well as how assistive technologies play into it. The roll-up is here: alistapart.com/article/from-url-to...
Awesome, thanks, I'll check it out!
How did you created this diagrams ? The style of them looks SICK as hell :+)
Thanks! 😀 I draw them in Photoshop. The typeface is one I made, intending to open source it soon.
awesome work !
The interviewer asked me this question and I'm failed to answer it and exactly define the process of browser rendering when the user visited any URL. After reading your article I'm pretty much sure that I'll explain it to someone in a better way. I really like your article and started following you to read similar kind of articles in the future.
Thank you, @james Starkie.
Very kind, thank you, glad I could help 😊
Hi @jstarmx , thanks for writing this great post.
Could you please fix the link for "Check out this fantastic post for a deeper dive into how the JavaScript engine works" it takes me to this same page. Thank you!
Ah whoops!! Thanks for the heads up, sorted now 😊
So if css only render blocking, and not parser blocking, does it makes sense to preload the css file according to this article web.dev/articles/defer-non-critica...? Normally we put link:css in the head anyway, so it will be downloaded really soon without blocking the html parsing process, so preloading it makes no sense?
Hello, may I translate your article into Chinese?I would like to share it with more developers in China. I will give the original author and original source.
Yes absolutely, please go ahead, that would be great :)
thank you very mush!
Great post, have one question - In case of Ajax or SPA, all of these steps executed or is there any difference?
Thanks! These steps would still be executed, the differences would come afterwards really. In the case of a SPA, most would only happen once (on initial load), the trade-off being that those steps will likely take longer because there are more assets to load up-front. But the last couple of steps will execute every time the DOM is updated (e.g. navigating to a new 'page') as the layout will need to be recalculated and repainted each time.
Make sense, thanks.
Thank you. Your post is interesting
What a great, concise and informative article! Loved it! <3
Very nice chronological summary of how browsers render pages. The topics covered (parse order, blocking vs non-blocking loading and load events) were exactly what I was looking for!
Fantastic, glad I could help!
Hi, James, fantastic post, and thank you for sharing.
Great information!
Thanks!
Insightful, thanks!
Great article, I also find this resource useful for knowing what causes a reflow/layout
Thank Adam! Looks like very interesting and useful link too, cheers.
Another detailed resource is Chrome University
That looks really interesting, thanks!
I love the visuals. A fantastic approach to sharing your knowledge!
Brilliant explanation. Thanks.
Much thanks for writing this article. Very helpful ✨
Awesome work 👏
Cool, now I know basically how websites painted. Thanks
Sorry, but when the browser exactly fetch resources when it parse raw html to tokens or when parse tokens to DOM
gooooooooooooood!