Before the browser can render the page, it needs to construct the DOM and CSSOM trees. As a result, we need to ensure that we deliver both the HTML and CSS to the browser as quickly as possible.
The final output of this entire process is the Document Object Model (DOM) of our simple page, which the browser uses for all further processing of the page.
Every time the browser processes HTML markup, it goes through all of the steps following: 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 CSSOM and DOM trees are combined into a render tree, which is then used to compute the layout of each visible element and serves as an input to the paint process that renders the pixels to screen. Optimizing each of these steps is critical to achieving optimal rendering performance.
The render tree construction shows that the critical rendering path requires both the DOM and the CSSOM to construct the render tree. This creates an important performance implication: both HTML and CSS are render blocking resources. The HTML is obvious, since without the DOM we would not have anything to render, but the CSS requirement may be less obvious.
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. Get it to the client as soon and as quickly as possible to optimize the time to first render.
JavaScript allows us to modify just about every aspect of the page: content, styling, and its response to user interaction. However, JavaScript can also block DOM construction and delay when the page is rendered. Executing our inline script blocks DOM construction, which also delays the initial render.
Another property of introducing scripts into webpage is that they can read and modify not just the DOM, but also the CSSOM properties. It may change the display of all or some properties of styles. In this way the browser delays script execution and DOM construction until it has finished downloading and constructing the CSSOM.
By default, JavaScript execution is "parser blocking": when the browser encounters a script in the document it must pause DOM construction, hand over control to the JavaScript runtime, and let the script execute before proceeding with DOM construction. 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. Inline scripts are always parser blocking unless you write additional code to defer their execution.
To deliver optimal performance, make your JavaScript async and eliminate any unnecessary JavaScript from the critical rendering path.
To deliver the fastest possible time to first render, we need to minimize three variables:
The number of critical resources.
The critical path length.
The number of critical bytes.
A critical resource is a resource that could block initial rendering of the page. The fewer of these resources, the less work for the browser, the CPU, and other resources.
Similarly, the critical path length is a function of the dependency graph between the critical resources and their bytesize: some resource downloads can only be initiated after a previous resource has been processed, and the larger the resource the more roundtrips it takes to download.
Finally, the fewer critical bytes the browser has to download, the faster it can process content and render it visible on the screen. To reduce the number of bytes, we can reduce the number of resources (eliminate them or make them non-critical) and ensure that we minimize the transfer size by compressing and optimizing each resource.
The general sequence of steps to optimize the critical rendering path is:
Analyze and characterize your critical path: number of resources, bytes, length.
Minimize number of critical resources: eliminate them, defer their download, mark them as async, and so on.
Optimize the number of critical bytes to reduce the download time (number of roundtrips).
Optimize the order in which the remaining critical resources are loaded: download all critical assets as early as possible to shorten the critical path length.
Summary - approximate chain of dependence of creating visible content: Visible conten => DOM => critical resources (eg. css, javascript).
Possible solution: applying styles within an element head, but without embedding them in the code HTML and using asynchronous as async / deferred downloads for all scripts. All this is applied in AMP - Accelerated Mobile Pages.
Source: Critical Rendering Path of Google Web Fundamentals and Optimizing the critical rendering path of Google Patners Help.
