Critical Rendering Path (CRP) For Web Development In 2026

Your browser is nothing more than software that is used to access the internet. Your browser lets you visit websites and do activities within them like login to your accounts, view videos, visit one page from another, print, send and receive emails. The most common browser software titles on the market are Internet Explorer (old school now), Google's Chrome, Mozilla Firefox, Apple's Safari, and Opera. Whether or not you can use a browser on your phone or PC depends on the operating system of your device (for example: Microsoft Windows, Linux, Ubuntu, Mac OS, among others).

We know that a Browser displays information to you, but who defines what the format of this information should look like and what functionality a Browser should perform? Yes, you could say Google, Mozilla, Apple, etc all decide on this, but there also a common set of rules that every Browser should follow. Who creates these rules? Well, the W3C. W3C is short for the World Wide Web Consortium, which is an international consortium of companies involved with the Internet and the Web. The organization's main goal is to develop open standards so that the Web evolves in a single direction rather than being split and scattered.

The W3C is nothing more than a group of people that help to define what browsers should expose users to.

When you are browsing the web, you are actually calling up a list of requests to get content from various resource directories or servers on which the content for that page is stored. It can be compared to a recipe for a cookie - you have a shopping list of ingredients (requests for content) that when combined in the correct order, these ingredients bake a delicious cookie (the web page).

Importantly, the page you visit may be made up from content from different sources. What I mean by this is that images may come from one server, text content from another,  JavaScript from another and ads from another.

A packet is a whole bunch of data that is stored in a ... you guessed it ... packet or package. This packet will then travel along a given network path. Data packets are used in Internet Protocol (IP) transmissions for data that navigates the Web, and in other kinds of networks.

HTTP packets are the tiny bundles of data that carry information back and forth between your web browser and the websites you visit. Imagine them as little envelopes containing instructions and responses, constantly scurrying through the internet cables to make websites appear on your screen.

When you want to visit a web page, chances are you will trigger the use of a TCP/IP protocol. This in turn triggers a chain of events. You computer will bundle data together and that packet of data will pass through the TCP/IP protocol stack on the local machine, and then across the network media to the protocols on the recipient. The protocols at each layer on the sending host add information to the original data.

As the user's command makes its way through the protocol stack, protocols on each layer of the sending host also interact with their peers on the receiving host.

A lot of words I know. Lets see what this all means.

a quick explanation about the 5 layer model.

We've seen the high level structure of a packet, but now lets just solidify our knowledge by going through the steps again. This time, lets apply it to us visiting a web page.

Remember how I said that the application layer is the most important for us developers. This is because it involves the HTTP protocol. HTTP means HyperText Transfer Protocol, and it is the underlying protocol used by the World Wide Web. HTTP defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands.

HTTP works as a request-response protocol between a client (aka: your browser) and server. This lecture digs deeper into what it means to send a HTTP request and what it looks like. We also look at the response.

Learning about protocols, packets and TCPs can be scary. Even more than this, it can seem impractical. Thats why I've put this short video together, just to lighten things up and to remind you how important it is for developers to know this stuff.

This Websockets course is an opportunity to elevate your web skills and unlock the potential of real-time applications. I encourage you to enroll and start your journey to becoming a WebSocket expert.

Unlike traditional methods like AJAX and polling and Server-Sent Events (SSEs), WebSockets provide a persistent, bi-directional communication channel that allows for instant data exchange. Those who take their learning and development career path seriously, will greatly benefit from this course.

Before we begin, I just want to point out that we will be writing JavaScript. If you are unsure of what we're talking about ( arrays, prototypes, this, etc.), then I have you covered. I've done an entire course on JavaScript which I encourage you to look it. If you already know JavaScript, then you're good to go and follow along just fine.

Before you continue to the next lecture ...

Before we go further, let me remind you what a polyfill is.

A polyfill is simply a browser fallback, made in JavaScript, that allows functionality you expect to work in modern browsers to work in older browsers.

Remember, a polyfill is only used if we're trying to use new code that our Browser does not understand. Therefore, the starting point is to determine whether the forEach() method exists on our Browser.

In this case you'll see that it does exist. BUT for our purposes you need to pretend that it does not exist. That's why we're building a polyfill - because we are pretending that our Browser does not know what the forEach() method is.

Before we can build our own polyfill, we need to look at what it is we're building. The forEach() is a method on every Array that we can use to execute a function on each element in that array. When using forEach() , we simply have to specify a callback function that will be executed on each element in the array.

We know the theory. Now lets see what the forEach method looks like and how we could use it in a real life scenario.

Lets start building our very own forEach polyfill.

We know that the first item that is passed into the forEach() method has to be our callback function. It makes sense then that the first thing we need to ensure is that the user has indeed passed a function into the forEach() method.

The main part of the forEach() method is the callback function that iterates through each item in the array. Lets build this from scratch.

The "this" keyword can cause confusion so in this lecture I explain what "this" refers to in JavaScript.

Enough is enough. Lets finally finish building our very own polyfill.

A quick recap on what we've done.

Up until this point you should have a very good idea about what an HTTP request is and why its important. Now you're ready to dive into what this course is really about - and that is the steps the browser goes through in order to render HTML, CSS and JS onto your device. I hope you enjoy this section. Remember, although it can be tough, sit back, relax and try to enjoy every moment.

There are different execution contexts that exist in your browser. All of these environments have to work together in order to display content to your device. This lecture gives you a high level summary of the environments.

I hope you enjoy this lecture, as it goes through in detail how the Browser works and the 4 steps it needs to go through in fetching data from a server and eventually displaying that data to your screen.

The Critical Rendering Path refers to the sequence of steps the browser goes through to convert the HTML, CSS, and JavaScript into pixels on the screen. This lecture is a quick introduction to the CRP and what it means.

An overview of the CRP

In order to become a brilliant coder, we need to understand the steps the Browser goes through in fetching data from a server, all the way to displaying the content on your screen. A large part of this process is the construction of the Document Object Model - or the DOM. This is a 2-part lecture about how the DOM is constructed. Enjoy!

We've seen that your HTML, CSS and JS files have to be sent to your computer in Bytes. These Bytes are then converted to Characters (usually using UTF-8 encoding), but now what? Well, as I'm sure you can agree with me, a whole bunch of characters - or text - given to the Browser is meaningless. How does your Browser know what these characters mean? How does it know where to place all the characters? etc. etc. Lets find out what happens next.

We've done a lot. Now its time to step back to discuss what we've learnt. Keep going. Web development is awesome is you should be having a whole lot of fun!

We've discussed the critical rendering path. Now its time to see it in action by looking at the Performance Tab in DevTools.

Looking at all your website activity in the MAIN tab is not the only way we can look at performance. We can also look at it in tabular format. There are 3 different types of tables we can look at. The first is the Call Tree.

We've looked at the Call Tree ... now its time to review the Bottom-Up and Event Log tabs.

Remember, all we're doing here is trying to look at how our website performed. In other words, how quickly it managed to fetch data from a server and then display that to our screen. There are many ways to skin a cat as they say - that's why we're looking at all the different ways we can view this critical rendering process.

Enjoy!

What is the CSSOM? The CSSOM stands for the CSS Object Model. You can think of it as a "map" of the CSS styles found on a web page. It is similar to the DOM, but for the CSS rather than the HTML.

When a browser displays a document, it must combine the document's content with its style information. It needs to know where to place styles and what styles to use. For this reason, a tree is needed.

We've already had a look at the Parse HTML activity in DevTools. But what do we look for to find the CSSOM construction? Lets find out.

Up until now we've constructed the DOM and the CSSOM. Are we done? Unfortunately not.

The next step is to combine the DOM and CSSOM into a render tree. The Render Tree is then passed to the layout phase and eventually to the paint phase which paints the actual pixels on the screen and the content is visible to you.

Lets look at a practical example of the render tree construction process.

Lets find out whether you managed to figure out the finale render tree.

Sometimes we stand too close to the wall we can't see the painting. This is a good time to quickly recap what we've learnt so far.

Lets compare the DOM, CSSOM and Render Tree

We've discussed the DOM, the CSSOM and the construction process of the Render Tree. But we're not done yet are we? Nope. There are 3 stages to the render tree process - the construction, layout and painting process. When the render tree is created, its nodes and elements do not have a position and size. Calculating these values is called layout or reflow.

Lets jump into the layout process, which computes the exact position and size of each node on your page. 

Now that we know whats involved in the layout process, lets see how to practically see it happen in real life.

In the painting stage, the render tree is traversed and the renderer's "paint()" method is called to display content on the screen. Painting uses the UI infrastructure component.

A brief look at what we've done. I hope you've been enjoying it so far. KEEP going!

Why understanding render blocking resources is important.

We will be looking at JavaScript shortly, but I would like us to begin first by concentrating on CSS.

By default, CSS is treated as a render blocking resource. This just means that the browser will not construct the Render Tree (i.e. it will not render any content) until the CSSOM is constructed. This kinda makes sense right? You would hate to arrive on a webpage only to see a whole bunch of ugly text with no styling attached to it. This is why both the CSS and .html file are render blocking.

We've seen that CSS is render blocking. But sometimes we don't want ALL of our CSS files to be render blocking. Remember, some CSS files are only applicable under certain conditions - like if the screen orientation is a certain angle, or size. And this is where Media Queries come into the picture.

Media Queries are a CSS3 module allowing content rendering to adapt to conditions that we specify (such as screen size). It became a W3C recommended standard in 2012, and is a cornerstone technology of responsive web design.

This lecture shows you how to use it. Enjoy!

Lets look at a practical example of using the "media=print" query.

Should you have 1 large CSS file, or multiple smaller CSS files that target each media query?

We know that the word "render" means loading, so if something is render-blocking, it means that it is keeping the page from loading as quickly as it could. We've been discussing CSS and the fact that it is render-blocking, but we now turn our attention to JavaScript.

JavaScript can interact with the DOM with DOM scripting, so it makes sense for us to dive into the relationship between JavaScript and the DOM in the context of render blocking resources. Enjoy!

Let me code up a simple example, to illustrate why order of your code matters.

In the previous lecture I gave you a challenge. Could you figure it out? 

We've seen that when the browser hits a <script> tag, the parser has traditionally been blocked from continuing to read the remaining HTML until that script file has been fully executed.

But as you will learn shortly, the relationship between JavaScript and CSS behaves a little differently.

We now look at an example of JS having to wait for the CSSOM to load before it can be executed.

Lets take a step back and review what we've learnt so far about the DOM, CSSOM and JavaScript.

A quick description between DOM, CSSOM and JS.

By default, JavaScript execution is "parser blocking". What does this mean? Well, when the browser encounters a JavaScript script in the document it must pause the entire DOM construction. Your browser then hands control over to the JavaScript engine. Only after the JavaScript is executed can the browser then continue with DOM construction.

Placing your JavaScript at the bottom of your <html> document is web development 101.

The idea of placing your JavaScript at the bottom means that if your script is having issues or your user has a slow internet connection, the rest of the page will still load first - it other words, it won't hang.

It can be very daunting when it comes to trying to understand the Critical Rendering Path. I do admit it is quite an advanced topic.  And because it can be difficult, I want to pause here and explain what the DOMContentLoaded event means and why placing JavaScript at the bottom of your file is not necessarily very helpful.

The async attribute was introduced after defer, and it tells the browser to start downloading the resource right away without slowing down HTML parsing (i.e. without blocking the render). However, once the resource is available, HTML parsing is paused so the resource can be loaded. If the script is modular and does not rely on any scripts then we typically want to use async.

We've looked at both approaches: 1. placing JS at the bottom of the page and 2. adding async to the external script tag. Lets compare the two in terms of performance.

By using the defer attribute, we can tell the browser to hold off on downloading the resource until HTML parsing is complete. Once the browser has finished with the HTML it will then download and render all deferred scripts in the order in which they appear in the document. This is the cool thing with defer - it guarantees that your JS files will be executed in the same order that you defined in your markup.

It can get confusing when talking about async compared with defer. That's why this lecture is about comparing the two approaches in terms of performance.

What if using async or defer is not quite enough? What if you want your JavaScript to start executing at a custom event? The good news is that we can access the load event on the window object to achieve this. Remember, the load event is fired when the whole page has loaded. This means it will only fire when all dependent resources (css files, images, etc.) have been downloaded. This is different to DOMContentLoaded, which is fired as soon as the page DOM has been loaded (i.e. the browser doesn't have to wait for css files and images to finish loading).

We've started building our custom load event. Lets now finish it off.

BUT, the good news is that we're going to walk through the entire render process together.

We've come a long way. Well done. But now its time to take a step back and compare the approaches we've implemented so far. Remember what we're trying to do: we're trying to improve our site page speed by defining when JS should be render blocking. For critical JS resources that is required to display above the fold content, we need it to be render blocking. But for other less important JS, we can defer it until a later time - this allows us to get the first page rendered to our users quickly.

Loading assets (by assets I mean things like css, jpegs, js files, etc.) on a page is one of the most important parts to get right in order to achieve a fast first meaningful paint.

Usually, real world apps load multiple assets, and we've seen in the previous lectures that these assets are render-blocking by default, which negatively impacts the loading performance.

How do we solve this? 

One way is by using preload. Preload lets you declare fetch requests in the HTML's <head>, specifying the assets that your page will need very soon and which you want to start loading early in the lifecycle.

Lets see how it works.

We made a mistake in the previous lecture. Can you spot it? 

It can be very confusing when starting out to conceptualize what the Critical Rendering Path really is, and how preload fits into all of this.

That's why I have dedicated this lecture to talking about preload.

This lecture also speaks about images and their impact on the CRP.

Whew, we've covered a ton of useful information. I think its time for us to take a step back and review what we've learnt.

Browsers have traditionally been single-threaded ... but a few years ago browsers implemented a new approach to improve importance.

Pausing the parser whenever a script is encountered means that every JavaScript file you load delays the discovery of the rest of the files that are linked in the HTML. Surely there has to be a better way?

The good news, is that there is.

In 2008 IE introduced “the lookahead downloader” which was way that allowed the browser to keep downloading the files that were needed while the synchronous script was being executed. Firefox, Chrome and Safari followed, and today most browsers use this technique under different names. The name we'll use in this course is Speculative Parsing.

In this section we're going to have fun together by analyzing pages and assessing the critical rendering path. Enjoy!

So far in this course we've used the Performance Panel to assess our webpage activity. But there are many ways to skin a cat - and another way to assess network activity is with the Network Panel. The Network Panel is found within Google Chrome Developers tools, and it allows you to inspect resources as they are accessed over the network. In the upcoming lecture's we're going to use the Network Panel to inspect an HTTP request and its corresponding response so that we can understand what the browser is doing.

As we will see together, there are many things we can see in the Network Panel. The 2 most important things are

1. the blue vertical line displayed in the waterfall timeline on the right (this represents the DOMContentLoaded event); and

2. the red vertical line (this represents the window's Load event).

These two lines help you determine the total time it takes for pages to load and gives you a starting point at which to make improvements to your pages.

So what are you waiting for? Lets jump into it.

There is a wealth of information in the Network Panel, including the ability to assess things like the Size of the transferred file, the name of the file, the status codes returned to us by the server ... and a whole bunch more!

Here we spend some time going through what each column means in the network panel.

Understanding HTTP is very important. This is why I'm taking the time to devote a quick lecture on what HTTP headers look like and where you can find them.

HTTP headers (both response and request) allow the client (browser) and the server to pass information with the HTTP protocol. An HTTP header consists of its case-insensitive name followed by a colon (:), then by its value.

Headers can be grouped into 3 broad categories (which you'll see in this lecture): 

• General headers - these apply to both requests and responses, but the data within this header has no relationship to the data transmitted in the body; and

• Request headers - are provided by the browser and contain information about the resource to be fetched, or about the client requesting the file; and

• Response headers - are provided by the server and hold additional information about the response, like its location or about the server providing it.

We now know that the Network panel records information about each network operation on a page, including detailed timing data, HTTP request and response headers, cookies, and more.

Now we're going to jump into the most important part of the Network panel - the timeline. The timeline column displays a visual waterfall of all network requests.

When you're looking at the waterfall graph, you'll notice that each file or resource requested has its own timeline request bar. There are 3 common patterns which you'll see, and this lecture explains them to you.

When we talk about a time phase of a particular resource, we mean the time it takes for the browser to initialize the request, send it to the server, wait and then download the entire file. Importantly and luckily for us, Google Chrome DevTools gives us all the time phases that we can use to analyze and speed up our site.

Before we discuss what each time phase means, I want to show you what I'm talking about ... just in case you're totally lost ;)

Here's a one pager of the request lifecycle of each and every request your browser makes to a server. Don't understand? Don't stress - we'll jump into this in more detail.

We've seen that all network requests are considered resources. As they are retrieved over the network, resources have distinct lifecycles expressed in terms of resource timing.

By default, Chrome breaks down the life of a request different parts, including:

• Queueing and Stalled, which basically show the time a requests needs to wait before being acted on by the browser.

• DNS Lookup, Initial Connection and SSL, which show the the time spent in these respective parts of the request lifecycle.

• Request Sent is the amount of time the browser takes to send the request to the server.

• Waiting (TTFB) is the amount of time the browser has to wait before beginning to receive data from the server.

• Content Download is the amount of time it takes to receive the entire resource from the server.

A CDN allows you to deliver content from your website or mobile application to people more quickly and efficiently, based on your users geographic location. Cool right! Lets find out more.

In this course we have been using Visual Studio Code as the text editor (its entirely free in case you're wondering).

A plugin I've installed is Live Server which allows me to 'serve' my files to the browser in real time. Unfortunately (or fortunately, depending on how you look at it), this means extra code is inserted into the index.html file. A web socket is established.

In our example, we also see an ng-validate file. Whats this? 

And finally we also see a request for a favicon.ico file. Whaaaat? 

Don't worry, we're going to go into detail about what all these files are, so you can see how I go about analyzing each file and how you can go about figuring it out on your very own website too.

Enjoy!

In the lecture we grabbed an image from placeimg.com. However, this is no longer operational since 30 June 2023, and therefore I wanted to give you an alternative.

Lets turn our attention again to our simple markup and look at the network activity it produces.

Now that we've loaded our page, what conclusions can we draw from it? This lecture will look at some of the most obvious network activities that we should look at and focus on.

I know we've seen the size column before, but because its so important I want us to discuss it again.

We've come a long way. One of the most important things you need to understand on every website you build (or own) is how many critical resources there are and how many server trips are required at a minimum in order to render that page to the screen. This is what we're going to look at now.

You are now becoming a pro at analyzing network requests. Not so fast! Now its time to include both CSS and an external JavaScript file to the mix.

We've added our markup (CSS and JS). Now its time to render our page so we can start assessing the Critical Rendering Path.

The heading of this lecture is self explanatory. We look at how the CSS and JavaScript has impacted the CRP.

We go further and also identify the number of critical resources and the minimum amount of server round-trips required to get this page delivered to the user in the fastest possible time.

In our previous example we used an external JavaScript file. What changes when we remove the external file and write our JavaScript inline? 

Do you think it'll make much of a difference? 

We've seen that adding inline JavaScript does not really make much of a difference to performance compared to an external JS file. This is because under both scenarios, JavaScript blocks the DOM and has to wait for the CSSOM tree to be fully built before the script can execute.

But there are ways we can tell the browser that JavaScript should not be render blocking. Do you remember what some of these ways were? Thats right, we can use attributes like defer, async, preload or even create our own custom event listeners.

In this lecture we will use Async.

Its time to take a step back and discuss at a high level what we've learnt.

As you'll discover, its nothing too scary or difficult, and nothing we haven't already done.

Up until now we've taken quite a hack approach to figuring out the CRP. We've had to use both the Performance Tab and the Network Tab.

But there are better ways and more streamlined ways.

Lighthouse is a great starting point. It is free (i.e. open-source) and is fully automated. You can run it against any web page, public or requiring authentication.

Now its time to actually run Audit Lighthouse and produce a report on our webpage.

A student of mine could not figure out why his mobile rendering was taking longer than desktop. This lecture hopefully gives insight.

A quick introduction about what I'm going to be talking about in this section.

HTTP was developed by Timothy Berners-Lee in 1989 as a communication standard for the World Wide Web. In other words, it is the language that allows browsers and servers to speak to each other. HTTP allows the exchange of information between a client computer and a local or remote web server. In this process, a client sends a text-based request to a server by calling a method like GET or POST. In response, the server sends a resource like an HTML page back to the client.

HTTP is an application protocol that has been the standard for communication on the World Wide Web since it was invented in 1989. From the release of HTTP/1.1 in 1997 until recently, there have been few revisions to the protocol.

That is, until 2015 came along.

HTTP/2 began as the SPDY protocol, developed primarily at Google with the intention of reducing web page load latency by using techniques such as compression, multiplexing, and prioritization.

HTTP/1.1 and HTTP/2 share the same formats / semantics. This was done so that the requests and responses traveling between the server and client in both protocols reach their destinations as traditionally formatted messages (i.e. with headers and bodies, using familiar methods like GET and POST).

But while HTTP/1.1 transfers these in boring old plain-text messages, HTTP/2 encodes these into binary, allowing for a different delivery model. At a very high level, this allows HTTP/2 to encode requests/responses and cut them up into smaller packets of information, which is very powerful.

We've seen HTTP/2. But this section would not be complete if I did not mention the latest protocol being developed - the HTTP/3 protocol.

The CRP is just the beginning. I want to recommend 4 courses of mine that I think will allow you to apply what you've learnt in this course in practical ways.