More weight doesn’t mean more wait — @scottjehl

When building for the web we all have this sense of how careful we should be about not shipping too much JavaScript and CSS to our users. That the more we send, the slower our web app might get.

So the mindset usually is “always send as few code as possible”. And that’s fine, the less code the better. Less time to download, less time to process, less time to paint, less time to have content on the screen!

But, more important than trying to squeeze our web apps as a whole as much as we can, is to understand the journey in our browsers from consuming HTML, CSS and JavaScript and transforming these into pixels on the screen — the Critical Rendering Path (CRP).

Render vs Progressive render

Optimising the CRP has everything to do with reducing critical resources and download non-critical in a non-blocking way, in order to achieve better page load times.

And as load is not a single moment in time, there are multiple stages during the load experience that should be tracked in order for us to measure how “fast” or how “slow” our web app is. These are:

When does the user first sees something on the screen? — FCP

on the screen? — FCP When does the user first sees something meaningful on the screen? — FMP

on the screen? — FMP When is the user able to interact? — TTI

There are several different strategies to improve these timeline metrics, but as there’s no “one size fits all solution”, it is fundamental to understand CRP in order to define the strategy that better suits our problem.

Critical Rendering Path

This following diagram captures all the essentials of CRP. From the moment the request is performed and we receive the first byte (TTFB):

Critical Rendering Path

First, grab the HTML and start building the DOM, containing all the information about what content to present; Next, once CSS is fetched, build the CSSOM, holding all that is related to how to present content on the screen; Then, combine these two and build the Render Tree, containing both the content and style information. And then, there’s Layout. At this stage we know the content and styles but there’s one thing missing, calculate the exact position and size of each element within the viewport of the device — that’s Layout responsibility. Finally, when layout is complete, Paint event is triggered converting the render tree into pixels on the screen.

Notice that we didn’t cover JavaScript. Before we do, let’s exercise this considering only HTML and CSS.

CSS and the CRP

In the following snippet we have an HTML document with some markup with the page skeleton, a CSS resource and some text.