Speed Critical Rendering Path
The most important concept in pagespeed is the critical rendering path. This is true because understanding this concept can help you 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.
What is the critical render path?
Google defines the critical path as "the code and resources required to render the initial view of a web page".
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 the chain of events that occur to make your webpage appear on a browser.
An optimized "critical rendering path" would be a webpage that had only the absolutely necessary events occur to render the things required for just the initial view of that webpage.
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.
- 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
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 each of those files which means six or seven roundtrips to a server just to get started.
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 requests tool) But this isn't a wordpress thing, I just use them as a common 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 code and resources required to render the initial view of a web page"
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. The reason they have 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. So 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 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.
- Several large images
- Google analytics
- Google plus badge (which makes lots of calls)
- Viglinks (this is how I make money from feedthebot)
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 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 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.
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)
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.
What optimizations I did
- 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
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.
- 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)
by Patrick Sexton