Critical Rendering Path (CRP) For Web Development In 2025

Always learn the basics before jumping into the deep end.

Before we move on, don't lose sight of our bigger goal.

This course is all about optimising the Critical Rendering Path. This will involve discussion about things like requests, responses, ajax, rendering engines, network layers, etc. etc.

Talking about the "old-school" way can be a little boring. But trust me, you need to understand this in order to understand how browsers interact with servers today. Enjoy!

AJAX is awesome. It allows web pages to be updated asynchronously by exchanging data with a web server behind the scenes. This means that its now possible to update parts of a web page, without reloading the whole page. Cool hey!

You may be confused at this point why we are learning about AJAX and not just talking about the CRP.

As it turns out, the CRP and AJAX are closely related.

AJAX is a Web API available in all browsers that allows you to use JavaScript to send and receive HTTP requests over the wire.

Sometimes you can't see the wood for the trees. So in this video I take a step back and remind you why we are looking at ajax and what it all means in the bigger picture.

We use AJAX, or in other words, the XMLHttpRequest (XHR) object, to interact with servers. Using AJAX allows us to get data from a URL without having to do a full page refresh. This lecture explains how we set up the XMLHttpRequest object in 3 simple steps. Lets jump right into it!

As developers, we find ourselves in the console a lot, specifically DevTools.

And you have or may not have noticed that when you open up objects, the properties and methods on those objects are in the color purple. But sometimes, if you look closely enough, you'll notice that some are bright and others are dimmed.

This lecture attempts to explain why this is the case.

XMLHttpRequest can be used to fetch data in a number of formats including XML, HTML, JSON or plain text. In our example, we're going to fetch data from a server. When we receive the data from the server, we are going to display "ALL DONE" to the webpage.

Up until now we haven't dealt with the actual response data. We've made a request to a server, received a response, but then left it there. Now its time to jump in and deal with the data that has been received from the server.

This is a brief article on storage. Did you know that when you visit a site, there is a ton of information that is stored on your browser (DNS records, cached data, and so on).

This is another example of fetching data (in this case, the time) from a server and then displaying that to the window.

This is the second part of building our AJAX time function.

I was asked a question about how important it is to follow particular orders when writing up these AJAX methods. This brief article should put your mind at rest ;)

The more AJAX examples we do together, the better programmer you will become. So, lets make another AJAX call to a server using the XMLHttpRequest object.

When we receive the data from the server, we've executed a function to deal with the data. But, we have not yet built the function. This is what we're going to do now.

A quick summary of what we've just done.

The Fetch API allows us to use JavaScript to access and manipulate parts of the HTTP pipeline, such as requests and responses. It also provides us with a fetch() method that gives us an easy way to fetch resources asynchronously across the network.

The Fetch() API takes one mandatory argument, and a further optional argument. It also returns a Promise. But what does this all mean? 

We've seen that the fetch() request returns a Response object. What you may not know is that the body of this Response object is a Stream object, which means that we need a method to return it to us. When we call the json() method, a Promise is returned since the reading of the stream will happen asynchronously.

We've seen how a GET request works. But for the sake of completeness, lets now look at a POST request. Remember, its not scary. A POST request method requests that a web server accepts the data enclosed in the body of the request message. Mostly your intention is for the server to store this information. A POST request is often used when uploading a file or when submitting a completed web form.

According to Google Developers Documentation Fetch makes it easier to make asynchronous requests and handle responses better than with the old school XMLHttpRequest object. Remember how we built a webpage using XMLHttpRequest. Now lets build the same thing but using Fetch. You'll see first hand how much more intuitive the Fetch API is.

WHEW! Well done for completing section 1. Lets take a quick look at what we've learnt.

CHAMPION! You've just complete the first section of this course.

AJAX is a technique for creating fast and dynamic webpages. Why does it speed things up? Well, it allows data to be loaded into your browser in the background, without the need for a page refresh. Neat huh!

Before AJAX, you would have to manually refresh a page to see updated content (yawn). And yes, this means re-loading all of the HTML and CSS, which is slow and inefficient. That's why the XMLHttpRequest API was introduced. It solved this issue.

In this section we looked at what an HTTP request is, what AJAX is, and why we use it. You used methods to help you make requests and receive responses from a server.

Now its time to put your knowledge to the test with these fun questions.

Don't worry if you can't get them all right. The most important point at this stage is to have fun and enjoy!

AJAX enables real-time data retrieval and interaction, allowing developers to create features like auto-complete search fields, live form validation, and infinite scrolling, which significantly enhance user engagement.

If you want to learn more about AJAX, then check out my AJAX courses - they will NOT disappoint you.

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.

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.

COWABANGA!

The core technology that your browser uses to fetch and display data to your phone or computer, is HTTP.

In other words, HTTP allows for communication between a browser and a server. The communication itself usually takes place over TCP/IP (or UDP if using HTTP/3).

Every HTTP interaction includes a request and a response. Every request must have a URL address and a method (like POST or GET).

We’ve also seen that HTTP is stateless, meaning that each request is separate from each other. This means that each request that your browser makes must contain enough information on its own for the server to fulfill the request.

You've learnt a lot already (pat yourself on the back), and we're only just getting started.

So, grab a coffee and take a moment to tackle these questions!

See you in the next section.

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.

Well done. You've built your very own polyfill. 

A polyfill in JavaScript is just a piece of code that provides modern functionality to older browsers that do not natively support it. This allows developers to use newer JavaScript features, APIs, or HTML/CSS standards in environments where they are not yet supported.

While polyfills are less critical today due to improved browser standardization, they remain a valuable tool for ensuring cross-browser compatibility and supporting modern features in older environments.

But as I always say, don't get lost in the all the detail. What I mean by this is that we sometimes need to take a step back and recap what we've learnt.

A brilliant way to recap is to test yourself.

Good luck my dear student, and see you in the next section!

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!

You've come a long way. Well done!

Most of us work with the web every day. We're used to getting all the information we need almost instantly. But how that web page is actually put together and delivered to us is a bit of a mystery for most people.

But not you.

The performance of your site will depend on an entire process of server requests and responses, loading, scripting, rendering, layout, and the painting of the pixels to the screen.

One of the best ways to solidify your knowledge is to test yourself. Remember, there's nothing to worry about. These quizzes are purely for your benefit. So, have fun, enjoy and see you soon.

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.

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.