News

The critical rendering path: Why you need to know about it

Discover how the 'critical rendering path' can improve performance and ultimately keeps visitors happy

CriticalPath

Discover how the ‘critical rendering path’ can improve performance and ultimately keeps visitors happy

CriticalPath

The critical rendering path is an idea pioneered by engineers from Google but has been embraced as a good idea by the wider web community.

The crux of it is to ensure the path to render a useable portion of the page to the user is as short as possible. This should ensure a quick first render of the page and a happy person using your website. Although it doesn’t affect CSS directly, it affects how CSS is included on a page and understanding how the browser interprets CSS is one method of achieving faster sites.

The ‘path’ describes the series of events which absolutely must occur for the page to render. The reason for targeting this area as an optimisation hotspot is that it’s often not considered. In the past, we’ve concentrated on page weight rather than time and performance after the initial render. From this perspective there are some low-hanging fruit to make some quick and significant performance savings.


You have to weigh up the benefits and drawbacks on visitors not having JS enabled and the experience they’ll have


First, we want to minimise the amount of files loaded by concatenating and minifying CSS and JS. This decreases the amount of HTTP requests made. You could also use techniques to lazy load images so only the initial ones are shown. Note that you have to weigh up the benefits and drawbacks on visitors not having JS enabled and the experience they’ll have.

One of the practices that aids this is minimising ‘render blocking CSS’. This can mean inlining styles pertinent to the top of the viewport (what is shown on the person’s device). The rest of the styles can then be downloaded in the background and be ready when the person needs them. This technique adds a bit of complexity to the site as it needs to know roughly how much of the page will be shown above the fold per device and which styles need to be included to cover the markup shown. Thankfully there are tools that take the pain out of doing this yourself.

Tools to help you

CriticalCSS by Filament Group finds the above-the-fold-CSS per page and outputs it into a separate file. If you already have a build process, Addy Osmani’s Critical module can be used directly with gulp to extract and inline styles in one fell swoop, but it relies on basic HTML pages. Penthouse by pocketjoso doesn’t detect styles automatically but might be useful if you have many styles injected by JavaScript or use pages that are more complex than vanilla HTML. Historically, mixing styles and scripts with markup has been frowned upon but as the technologies evolve we’re realising that they are all tightly coupled. Some advocate adding inline styles for the critical rendering path injected dynamically just before the page is served: the performance benefits are proven but there’s still resistance as others feel inline styles blur the separation between structure, semantics and presentation.

These are all techniques that aim to solve the same issue, namely that writing CSS in large projects is hard to maintain. Often this is because names conflict or styles are either too specific or too abstracted for what you want to achieve. They’re also techniques that don’t shy away from tying the markup, styles and functionality together in a single file. This breaks down the philosophical statement that they should be distinct from one another. They come with their own challenges and increased complexity.


GET THE LATEST ISSUE OF WEB DESIGNER NOW


×