critical-rendering-path
Every time the browser processes HTML markup, it goes through all of the steps above: convert bytes to characters, identify tokens, convert tokens to nodes, and build the DOM tree. This entire process can take some time, especially if we have a large amount of HTML to process.
The graph above shows how long it takes HTML to parse into the DOM, which is sometimes an optimization point.
Why does the CSSOM have a tree structure? When computing the final set of styles for any object on the page, the browser starts with the most general rule applicable to that node (for example, if it is a child of a body element, then all body styles apply) and then recursively refines the computed styles by applying more specific rules; that is, the rules “cascade down.”
Cascading Style Sheets (CSS) Cascading Style Sheets (Cascading Style Sheets) Cascading Style Sheets (Cascading Style Sheets) CSS is converted by Chrome, or rather the browser, to CSSOM, which is a tree data form. So the child rule inherits the style of the parent rule and is therefore layered.
The article gives an example
https://googlesamples.github.io/web-fundamentals/fundamentals/performance/critical-rendering-path/basic_dom.html
Open the example and view it on Performance Reload to see that style.css was requested when the HTML was parse.
By default, CSS is treated as a render blocking resource, which means that the browser won’t render any processed content until the CSSOM is constructed. Make sure to keep your CSS lean, deliver it as quickly as possible, and use media types and queries to unblock rendering.
In other words, during the first screen rendering, both HTML and CSS are needed, and the first screen rendering starts after dom and CSSOM are built, so CSS will also block the first screen rendering.
First, notice that in the above example our inline script is near the bottom of the page. Why? Well, you should try it yourself, but if we move the script above the span element, you’ll notice that the script fails and complains that it cannot find a reference to any span elements in the document; GetElementsByTagName (‘ SPAN ‘) returns null. This demonstrates an important property: our script is executed at the exact point where it is inserted in the document. When the HTML parser encounters a script tag, it pauses its process of constructing the DOM and yields control to the JavaScript engine; after the JavaScript engine finishes running, the browser then picks up where it left off and resumes DOM construction.
In other words, our script block can’t find any elements later in the page because they haven’t been processed yet! Or, put slightly differently: executing our inline script blocks DOM construction, which also delays the initial render.
The DOM is built sequentially, and inline script blocks this build. When a script tag is encountered, the browser gives execution permission to the JS engine and waits for the JS engine to execute the inline script before building the dom.
Another subtle property of introducing scripts into our page is that they can read and modify not just the DOM, but also the CSSOM properties. In fact, that’s exactly what we’re doing in our example when we change the display property of the span element from none to inline. The end result? We now have a race condition.
What if the browser hasn’t finished downloading and building the CSSOM when we want to run our script? The answer is simple and not very good for performance: the browser delays script execution and DOM construction until it has finished downloading and constructing the CSSOM.
Inline scripts are blocked by the CSSOM build process, meaning that the JS engine will not continue executing until csSOM is also built.
Whether we use a
Either inline script or SCRIPT tag JS blocks the first screen rendering.
By default all JavaScript is parser blocking. Because the browser does not know what the script is planning to do on the page, it assumes the worst case scenario and blocks the parser. A signal to the browser that the script does not need to be executed at the exact point where it’s referenced allows the browser to continue to construct the DOM and let the script execute when it is ready; for example, after the file is fetched from cache or a remote server.
To achieve this, we mark our script as async:
Blocking can be cancelled by adding async to script tags.
Notice that our “awesome photo” did not block the domContentLoaded event. Turns out, we can construct the render tree and even paint the page without waiting for each asset on the page: not all resources are critical to deliver the fast first paint. In fact, when we talk about the critical rendering path we are typically talking about the HTML markup, CSS, Images do not block the initial render of the page — although we should also try to get the Images painted as soon as possible.
Image requests do not block DOM parsing and first screen rendering.
Check out this article for information on the role of async and defer in script tags. Read the original here
This article has done experimental JS and CSS blocking DOM rendering parsing in detail
For fonts that block the first screen rendering, see optimize-webfont-loading
A good tool for testing site performance
www.webpagetest.org/