A detailed guide on critical rendering path – One of the most important concepts in all pagespeed optimization. We’ll discuss all the important aspects of Critical Rendering Path and its optimization for web performance.
What is the Critical Rendering Path?
- It is the series of events that must take place to render (display) the initial view of a webpage.
- Example: get HTML > get resources > parse > display webpage
Optimizing these events result in significantly faster webpages.
The Critical Rendering Path can do a Very Wonderful Thing…
It gives you the power to make a large webpage with many resources load faster than a small webpage with few resources. I like that.
Since most webpages have many different components, it is not always possible to just remove everything to make a page load faster. If you have ever wondered “What else can I do to make my pages fast?” or “How does Google expect pages to load in one second?” then this concept is for you.
Optimizing the Critical Rendering Path
Just to be clear, let’s define a few things:
- Critical – absolutely needed
- Render – display or show (in our case our webpages are “rendered” when they can be seen by a user)
- Path – the chain of events that lead to our webpage being displayed in a browser
- Initial view – also known as “above the fold”, the initial view is the part of a webpage visible to a user before they scroll
So in other words the rendering path is just a series of events that occur to make your webpage appear on a browser.
Since virtually every single website on the internet takes unnecessary steps to render, this is the place where truly meaningful and noticeable optimizations can occur.
Optimizing the critical render path can take seconds off your page load time. It is really the quickest path to faster webpages.
The Path
In order to display a webpage, a browser must get all the resources that are called by the webpage. A simple example would be a webpage that has one image, one CSS file, and one javascript file.
Let’s look at the path that this page takes before it gets displayed…
- Browser downloads the HTML file
- Browser reads the HTML and sees that there are one CSS file, one javascript file, and one image
- The browser starts downloading the image
- Browser decides it can not display the webpage without first getting the CSS and javascript
- Browser downloads the CSS file and reads it to make sure nothing else is being called
- The browser decides it still can not display the webpage yet until it has the javascript
- Browser downloads the javascript file and reads it to make sure nothing else is being called
- Browser now decides it can display the webpage
The path above is for a very simple webpage, now image what your path must look like.
You probably have social buttons, several CSS files, several javascript files, many images, widgets, and maybe audio or video too.
This means Your Render Path is likely a Huge Mess
Most websites have absolutely terrible render paths because they are calling so many things that the browser must load before the webpage can be displayed.
This is your advantage over others. If you make your pages faster than your competitors, you are going to make visitors happy (Google likes it when you do that).
The Render
There are certain types of resources that our webpages call that actually block the render of our webpages.
The two most common are the CSS files and the javascript files.
No matter how many of these you have the browser must download and parse each and every one of these files before it can show anything at all to the user. Let’s look at an all too common scenario…
Let’s talk – Rendering in WordPress
WordPress blogs use themes. Many WordPress themes have several css files.
Many have six or seven CSS files (this is why the pagespeed guideline combine external CSS files exists). All of that CSS can be in just one file, but when you add your theme, the fact is that it has several CSS files. So before even one letter can be displayed of your blog the browser must load and parse (read) each of those files which means six or seven roundtrips to a server just to get started. This is known as render blocking css.
The visitor to your page is staring at a blank white screen while this is happening because nothing will show up until these “critical” steps are completed.
But even after your CSS is downloaded your blog can not yet render because WordPress themes are also known to have several javascript files as well. The page will still not display as it is getting javascript files in many cases. This is known as render blocking javascript.
So a typical render of a WordPress blog page can require twenty-something round trips to just get the main CSS and javascript files. But wait, now you have social buttons or widgets too… uh oh, for each of those several CSS and javascript resources are needed too.
You may be loading dozens of things before your post shows up to an user. Ouch. (to find out what your page is loading use our page requests tool)
But this isn’t just a WordPress thing, I just use them as an example. It is rather common to have multiple requests for resources that are needed for the initial view of a webpage.
These delays to the rendering of your content are controllable, that is what the critical render path is all about.
The Critical
I have painted a very bleak picture thus far, but the good news is that you can call a million things for your webpage and it can have 12000 pictures, 200 javascript files, and the page can still load in a second or so.
How is this accomplished?
By understanding what is critical for your webpage to display the above-the-fold / initial view content.
Optimizing the Render Path
There are really just three things to concentrate on 1 …
- Minimize the number of critical resources.
- Minimize the number of critical bytes.
- And, minimize the critical path length.
Examples
Images – Even if a page has 12000 images, well only one or two are likely to be visible above the fold (critical). That means if we concentrate on those two images, we can make our initial pageload time much better. We don’t have to show 12000 images, we only need to show those one or two which are in the initial view. The rest can be deferred or lazy loaded.
Javascript files – We can have 12000 of those too, but we should only initially load the ones that are critical to show the top part of our webpage, and the other 11,998 javascript files can be deferred.
CSS files – The best way to minimize CSS files is not an online tool – it is to not use so much in the first place. It is likely that your pages use less than 20% of your CSS. There are options though. By combining some of your external CSS files you can reduce the number of files needed to render. You can also inline some of your CSS into your HTML. No matter how big or small your CSS is, your users will have to wait until it downloads to see your page.
Below we will look at a webpage and see how we can use our knowledge of the critical path to make it load significantly faster.
Understanding Pagespeed Measurement
When Google talks about pagespeed, they are not talking about the overall time it takes to download a webpage. What they care about is how quickly does a user starts seeing content on that page (initial view) and how quickly can the user start interacting with that content.
The reason Google has started using pagespeed as a ranking factor 2 is based upon the satisfaction of their users. It is not a good experience for someone searching Google for something when they are sent to a page that takes forever to load.
People complain to Google about this, they say “Why are you sending me to a page that loads soooo slow?”. This is known as perceived speed.
If a user is looking at a blank white webpage for 10 seconds waiting for it to load, that is bad and Google doesn’t want to show that page in their results. If that same webpage displayed information in the first second, it would then be a great experience, and Google would want it in their results.
Our main concern when we talk about webpage speed is to get content to the user as soon as possible in the initial view.
A Real World Example of Optimizing Critical Rendering Path
The webpage you are reading right now will be our example. This page renders in less than half a second, yet it does quite a few things that are your webpages are doing.
I will show you two versions of this webpage, one version will not be optimized for the critical render path and one version (the page you are reading) is optimized.
This will give you a great comparison of how significant the changes can be. It will also illustrate well how Google measures a pageload, which is an interesting and useful thing to know.
This page uses several javascript calls, rather common ones, let’s see what this page is using…
- Several large images
- CSS
- Google analytics
- Google plus badge (which makes lots of calls)
In a nutshell, I use the main things people need in their webpages (images, css, monitization, analytics, social sharing). You are likely using the same stuff in your pages. By optimizing the critical path, I am actually going to reduce all those calls and all those things to one request. All the browser needs to render this page is the HTML file. One single small 12k file and this page load almost immediately.
On the other hand, the unoptimized version of this page will make dozens of requests and roundtrips, it will take longer to load on desktops, and will take significantly longer to load on a mobile device…. Yet, the two versions of this page will have the exact same content and do the exact same things!
Let’s get our geek on, and show the goods…
The Unoptimized Version of This Page
Time to render: 1.3 seconds
Note: The page is only shown to the user after all those files are downloaded (represented by the light blue vertical line at the far right of the image)
To the right, you will see how many calls the unoptimized version of this page is making. The unoptimized version takes 1.5 seconds to load and can be found here if you want to see the actual HTML and how the page loads. The page is a rather simple static webpage, but it still requires 20 requests to load. That means the page has to wait for 20 things to load before a user can see it.
Note that the browser first downloads the HTML, then the CSS, then the images, then it goes into the javascript files, all of which have to download and be parsed before the user is shown the page.
This unoptimized version does not pay any attention to the critical rendering path at all, and so basically all files that are called must be downloaded before the page is rendered.
The Optimized Version of This Page
Time to render: .25 seconds (250 milliseconds)
Note: The page is shown to the user after just one file is downloaded (represented by the light blue vertical line near the middle of the image)
The optimized version of this page (the one you are reading now) only makes one call for the initial pageview. The page is shown to the user five times faster(represented by the light blue vertical line in the diagram) but still does all the same things. It still loads most of the same files, it still uses the same javascripts, but the difference is that the user is shown the page in only 250 milliseconds (a quarter of a second). This is five times faster than the unoptimized page. If your page takes 5 seconds to load, you can probably make it load in less than a second. Seems like magic, huh?
How I Examined My Webpage
I looked at my page and I asked myself.. “What does this page really need to load only the above-the-fold content?” I realized that the following things were definitely above the fold on a desktop screen:
- The logo (an external small image)
- The first large image to the right (an external image)
- My css (an external file)
This meant that the following things, were not needed for the initial view of the page…
- The Google plus badge
- The remaining images
- Google analytics
I then looked at the waterfall (the image showing what the page was downloading) and I realized that the things that I did not need to load were the things that actually took the most time to load. So if I could somehow move those un-needed things outside of render path, then my page would load significantly faster.
Optimizations I performed
- Inlined the CSS – I took my CSS from an external file and added it right into the HTML
- Base 64 encoded the logo and the first image – I used the base 64 encoding tool to inline my logo into the HTML
- Optimized all images – I reduced the file sizes of all my images
- Lazy load / defer images – using javascript (without jQuery) I deferred all my images
- Deferred the javascript of analytics
- Checked my page with the page speed tool
The result of these optimizations was that I took everything I could out of the render path. I reduced, in fact, the critical render path to just one call, the actual HTML file, which had everything the browser needed to render the webpage to a user.
CSSOM
A more technical way of looking at the critical rendering path would include a basic understanding of the CSSOM. The CSSOM is the CSS Object Model.
The CSSOM is basically a map of your styles and where those styles should go.
If you really want to fine-tune things, an understanding of the CSSOM is fundamental to doing so.
Key Points
- The critical rendering path is the chain of events that need to take place to display a webpage
- The way to improve the render path is to remove or defer calls made that are not needed for the initial page view
- Most of the things you are using javascript for can probably be deferred to load after the page view (things like social buttons, analytics, etc.)
- I examined my page by considering what the page needs to load the above the fold content (thereby identifying what the page did not need to load to show the initial view)
- I used pagespeed optimizations to remove or defer all the things that the page did not need to load for the above-the-fold content.
Note: I made some optimizations that were less than ideal to point out the power of the critical render path. (the lazy loading added alot of bytes to my html, creating an oversized html file – it was still only 19k, but the ideal html would be less than 14k)