Speed Critical Rendering Path

defer javascript

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:

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.

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....

  1. browser downloads the html file
  2. browser reads the html and sees that there are one css file, one javascript file and one image
  3. browser starts downloading the image
  4. browser decides it can not display the webpage without first getting the css and javascript
  5. browser downloads the CSS file and reads it to make sure nothing else is being called
  6. browser decides it still can not display the webpage yet until it has the javascript
  7. browser downloads the javascript file and reads it to make sure nothing else is being called
  8. 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, and maybe audio or video, or whatever. This means your render path is 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.

The render

There are certain type 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...

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.

resources to load one webpage

But even after those are downloaded your blog can not yet render because wordpress themes are also known to have several javascript files as well. 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 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 critical

above the fold, initial view

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. Remember the Google definition of the critical rendering path?...

"the code and resources required to render the initial view of a web page"

That means that we only need to display the initially visible part of the webpage quickly, not the whole thing. So even if a page has 12000 images, well only one or two are likely to be visible above the fold. 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 which are in the initial view. Javascript files? well 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 until after the pageload. I discuss the way to accomplish these tasks on my prioritize visible content page, but first let's look at a webpage and see how we can use our knowlege 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. 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.
This page uses several javascript calls, rather common ones, let's see what this page is using...

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

webpage requests - 20

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

webpage requests - 20

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 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:

This meant that the following things, were not needed for the initial view of the page...

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

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.

Key points

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)

Patrick Sextonby Patrick Sexton