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.
Let’s look at the path that this page takes before it gets displayed….
- browser downloads the html file
- browser starts downloading the image
- browser downloads the CSS 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.
This means your render path is likely a big 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).
There are certain type of resources that our webpages call that actually block the render of our webpages.
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…
WordPress blogs use themes. Almost every wordpress theme has 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.
You may be loading dozens of things before your post shows up to an user. To find out what your page is loading use our Google PageSpeed Insights tool and check render blocking resources.
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.
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
- Minimize the number of critical resources.
- Minimize the number of critical bytes.
- Minimize the critical path length.
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.
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 amount 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 start 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 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 the 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 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.
- Several large images
- Google analytics
- Social Share Buttons
In a nutshell, I use the main things people need in their webpages (images, css, monetization, 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 loads 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 version 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 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)
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
- checked page with Google Pagespeed insights tool
The result of these optimizations were 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.
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.
- 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
- I examined my page by considering what the page need 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 needed to load for the above the fold content.
note: I made some optimizations than 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)