Critical Render Path Optimisation – How to Load your Page in Under 3 Seconds
In this article I will be looking at increasing your page speed. Specifically, I will be looking at how to get your page to load in under 3 seconds.
I will be focusing on how to achieve a page load time of under three seconds via optimising your critical render path. I will be looking mainly at one of the main pillars of increasing page speed:
Thou shalt eliminate render-blocking.
What this article is going to cover:
- What is page speed and why should you care?
- The ten pillars of page speed success.
- How does the browser work and what is rendering?
1. What is page speed and why should you care?
Page speed is the amount of time it takes for your page to load once a user has requested it. I first heard about reducing page load speed when I was working as a marketer. I remember hearing that:
40% of users will abandon a page that takes more than 2/3 seconds to load.*
* Source Neil Patel, growth hacking expert.
I then started to work for Compare the Market as a junior software engineer and again encountered work on getting the fastest possible page speed.
It effects how many users you have on your page, which ultimately means how many customers you have, customers who are paying into a business which pays you as a developer. Also, the more users the more people seeing your work J.
How is page speed measured?
There are a few ways to measure page speed. The measurement most important for getting the under three second page load time is the:
Critical render path
The most important from an SEO perspective, how google measures you in order to rank your page for search queries are:
Critical render path
Time to first byte (TTFB).
For the purpose of this article I will be focusing only on the critical render path.
What is the critical render path?
It is the series of events that must take place to render (display) the initial view of a webpage. So the content a user sees when first loading a page, before scrolling. This is also known as the above the fold content.
Some useful definitions:
- Critical – Above the fold content. The first bit of the page which is displayed immediately.
- Render – I will go into this in more detail later but for now let’s assume it means when the page can be seen by the user.
- Path – The chain of events that lead to our webpage being displayed in a browser.
To optimise the critical render path on your site it is important to first understanding what is critical for your webpage to display – the above the fold / initial view content.
2. The ten pillars of page speed
There are 10 key issues which effect page load time. They are known as the ten pillars of page speed and are:
- Thou shalt avoid landing page redirects
- Thou shalt eliminate render-blocking
- Thou shalt enable compression
- Thou shalt bundle & minify your CSS
- Thou shalt minify your HTML
- Thou shalt prioritise visible content
- Thou shalt optimise your images
- Thou shalt reduce server response time
- Thou shalt leverage browser caching
For the purposes of this talk/article I will be focusing on number 2, “Thou shalt eliminate render-blocking”, therefore optimising the critical rendering path.
3. How does the browser work and what is rendering
What does it take for the browser to render your website?
This diagram shows the components which make up a browser. The components most critical for the rendering path are the rendering engine and networking component.
Let us imagine a user types your website url into the address bar of their browser. The address bar is part of the User Interface component of the browser.
The browser then uses its’ networking component to open up a TCP connection, it then makes an http request to the server which hosts your website. It does this by sending the request off to a DNS server which does a lookup to find the IP address of that url then sends the request to your websites’ server. Your server sends the files which make up your website to the users’ browser.
When the files are sent over it is the rendering engine which is responsible for reading and interpreting them. The rendering engine is responsible for interpreting html documents and images which are formatted using CSS and generating the layout which is displayed by the user interface.
So, how does it parses/ interprets these files:
The stages of the rendering engine
At the parsing stage it creates the DOM from the html and the CSSOM from the CSS.
It creates the render tree from the DOM and CSSOM. The purpose of this tree is to enable painting of the contents in the correct order.
The browser computes the geometry of the layout and its elements from the render tree. The browser paints pixel by pixel the visual representation of the render tree. This is what we see on the screen.
The rendering engine always tries to display the content on the screen as soon as possible. It does not wait for the html parsing to be complete before starting to build the render tree. It parses and displays the content it has received so far from the network while it is still receiving further content.
The path this page takes before it gets displayed is:
- The browser opens up the connection to your server and downloads the html file.
- Browser realises it cannot display the webpage without the CSS. As it cannot construct the CSSOM model.
- Browser fetches the CSS file and parses it. It stops parsing the html and creating the DOM while it creates the CSSOM.
- Browser completes the render tree, layout and paint stage are then completed.
- The browser can display the page.
This means they are render blocking.
4. How to reduce render blocking
Changing the style of an element:
Altering DOM elements:
Document.write causes a total re-render so it is best to avoid it if you want to increase page speed and improve performance.
1st Improving your loading strategy.
2nd Never use document.write().
How to improve your loading strategy
Normal script tag
First let’s understand what is going on when you use a normal script tag and place it at the bottom of your page.
Async scripts tag
Think of async tags as a way of sending a signal to the browser that it does not need to execute this file at its’ exact point of reference, so it can continue creating the DOM until execution.
Examples of when you would use the async attribute is when your script file is not dependant on other files and does not have dependencies itself. For example, self-contained analytics scripts.
Defer script tag
The browser fetches and parses the file the same as for async, in parallel to html parsing. However, it waits until the completion of html parsing for execution.
This means that the rest of your content can load faster and you’re above the fold and the critical render path will be completed sooner.
You would use defer for below the fold interactivity and critically, when script tags need to be placed somewhere other than the bottom of your html file.
Async and defer are pretty widely supported through most browsers apart from old versions of IE.
You should use defer for the majority of your scripts to stop render blocking. For scripts which stop other resources render blocking such as lazy loading of images, no tag is preferred. Async can be used for some analytics scripts if they are needed very soon on in the page loading journey.
To guarantee your JS does not block rendering, you must do this with your script itself, making sure the bulk of it is not executed until after it hears the onload event.
CSS is responsible for the styling of your page.
The browser parses the CSS and transforms it into the CSSOM, the CSS Object Model.
CSS is render blocking because without it the browser would not know how to layout the render tree or display the page. CSS is critical to displaying your page.
Generally, your website will access this information in one of two ways:
- In an external file, shown in the above example.
- In-line written within your html file.
To optimise your critical render path and to delivery critical (above the fold) content to your user as fast as possible you must deliver the CSS responsible for styling this area as fast as possible.
You must also ensure that the rest of the CSS does not block the beginning of the page rendering by somehow deferring it’s loading.
Deliver above the fold CSS as fast as possible
If your CSS is all in an external style sheet, like the example above, the browser has to make additional http requests to get it. This means the browser has to stop parsing the html to go through the process of opening a network connection and asking for the resource.
The best way to deal with this is to in-line this CSS. In-lining means put it straight into your html code. Example:
It will be found by your browser sooner and it can start creating the CSSOM responsible for your above the fold content quicker.
Stop the rest of the CSS from blocking the critical rendering path
In-lining all your CSS is a bad idea for overall page speed performance. This is because the browser does not cache in-line CSS so everything must be loaded from scratch ever time the user comes back to your site.
You can do this with the rel= ”preload” attribute which looks like this:
Contrasted with the usual:
The preload value of the link element’s rel attribute allows you to write declarative fetch requests in the <head> section of your html. So before the browser starts rendering the page and parsing the html it has already fetched the resource, so the resource is not blocking it.
Preload works because it removes the stylesheet tag temporarily. The stylesheet blocks rendering as the browser assigns it high priority and stops parsing the to fetch and parse it.
It allows you to asynchronously load CSS, not blocking the rendering of the rest of the page and most critically the above the fold, critical rendering part of the page.
Not all browsers support preload tags. But in these browsers you can still load your non-critical CSS asynchronously by using Polly filler libraries such as LoadCS.js.
Optimising the critical render path can take seconds off your page load time. It is really the quickest path to faster webpages. It is what has the most impact on your customers and on your google search performance.
- CSS – In-line your critical CSS within the head of your html. Asynchronously load your main CSS with the preload value for the rel attribute of the style element.
Doing all this can significantly improve performance and your page speed scores, ensuring that time to first render achieves the under 2 second rule.
This article is the script I wrote for a talk I did on increasing your page speed at JS Monthly.