*NEW* Web Development Secrets 2020 - CRP, HTTP, AJAX & More
4.8 (49 ratings)
Course Ratings are calculated from individual students’ ratings and a variety of other signals, like age of rating and reliability, to ensure that they reflect course quality fairly and accurately.
465 students enrolled

*NEW* Web Development Secrets 2020 - CRP, HTTP, AJAX & More

Understand the Critical Rendering Path, AJAX, HTTP and how to fetch data from a server. Novice to pro in easy steps.
4.8 (49 ratings)
Course Ratings are calculated from individual students’ ratings and a variety of other signals, like age of rating and reliability, to ensure that they reflect course quality fairly and accurately.
465 students enrolled
Created by Clyde Matthew
Last updated 6/2020
English [Auto]
Current price: $139.99 Original price: $199.99 Discount: 30% off
5 hours left at this price!
30-Day Money-Back Guarantee
This course includes
  • 7.5 hours on-demand video
  • 19 articles
  • 1 downloadable resource
  • Full lifetime access
  • Access on mobile and TV
  • Certificate of Completion
Training 5 or more people?

Get your team access to 4,000+ top Udemy courses anytime, anywhere.

Try Udemy for Business
What you'll learn
  • 120+ lectures and 7.5+ hours of well-structured content
  • *Download lectures (for offline viewing)
  • Understand the DOM, CSSOM, Render Tree and Layout
  • Master HTTP, HTTP/2 and AJAX
  • Learn how to optimize any website for speed by writing better code
  • Learn where to write your JavaScript for optimized performance (we take an advanced look at async, preload, defer, etc.)
  • Understand the Network Panel, Performance Panel and Audit Lighthouse functions within DevTools
  • Understand HTTP, TCP, Data Packets and a whole bunch more!
  • Real examples of how AJAX works (we use both the XMLHttpRequest object and the newer Fetch API)
  • Master the Critical Rendering Path
  • Understand what are Render Blocking Resources and how we solve this problem
  • Skills that will help you to apply for jobs like Web Developer, Front End Developer, Javascript Developer, and Full Stack Developer
  • From beginner to expert (advanced +)
  • Ongoing updates to keep you current
  • You will emerge an expert
  • Write JavaScript and understand what a Polyfill does
  • Write your own Polyfill
  • Introduction to HTTP/2 and how it improves the current HTTP/1.1 protocol
  • How to use a text editor that is completely free
  • Gives you depth of knowledge to boost your ability and confidence
  • All the techniques used by professional programmers
  • Support from me
  • A strong desire to become a full stack web developer
  • Basic HTML, CSS and JavaScript will be helpful, but not absolutely necessary
  • Desire to KNOW the full process of how your webpage works behind the scenes
  • Desire to KNOW how to use DevTools – Performance and Network Panels
  • A computer is required as you need to code alongside me to learn effectively

Let me share my web developer secrets with you

Understanding the Critical Rendering Path will enable you to become an awesome programmer. Take control through understanding. Delivering a fast web experience requires a lot of work by the browser. Most of this work is hidden from web developers: we write the markup, and a nice looking page comes out on the screen. But how exactly does the browser go from consuming our HTML, CSS, and JavaScript to rendered pixels on the screen? By understanding this, you will be able to write better code in order to boost your website traffic, know how to precision fix and tweak behaviour and performance, improve your market penetration and your margins. You’ll also gain an advantages over other developers who seem to just push the buttons without fully appreciating what is happening.

What this course covers?

In this course you’ll learn about the Critical Rendering Path. This refers to the set of steps browsers must take to fetch and then convert HTML, CSS and JavaScript into living, breathing websites. From there, you’ll start exploring and experimenting with tools to measure performance. You’ll learn simple, yet very powerful strategies to deliver the first pixels to the screen as early as possible.

Knowledge of the CRP is incredibly useful for understanding how a site's performance can be improved. There are various stages to the CRP, such as constructing the DOM, constructing the CSSOM, running JavaScript, creating the Render Tree, generating the Layout and finally Painting pixels to the screen. As you can see, this covers a whole bunch of interesting material.

By the end of this course, you'll be able to “speak” CRP by gaining an understanding of how to fetch data from a server and then get that data to your user as quickly as possible. We dig deeper in every lecture, learning about things like HTTP, TCP, data packets, render blocking resources, and a whole bunch more! This course has many bonus lectures which extend your knowledge base and test your skills.

Through practical examples, this course helps you understand the CRP piece by piece. And we use the latest and best features of JavaScript and browsers (like the new Fetch API) along the way so you can stay ahead of the pack.

*** The most important Web Development course on Udemy ***

Successful programmers know more than rote learning a few lines of code. They also know the fundamentals of how web development works behind the scenes. If you’re wanting to become a full stack developer, you need to know how to deal with server requests and responses, loading, scripting, rendering, layout, and the painting process of the pixels to the screen.

I want you to become a successful programming Grandmaster.

I want you to be able to apply what your learn in this course to your webpage.

This course is perfect for you.


Hi there, my name is Clyde and together we’re going to learn about the entire critical rendering path and apply it to practical situations. We're going to practice and learn and emerge confident to tackle any challenges modern programs and websites throw at us.

After completing a few university degrees, and post grad studies, I developed a fascination for web design and software languages. For several years I have immersed myself in this. I spent a fair bit on top courses and went on to apply the knowledge practically. I recognized gaps in some of the courses I’ve taken and hence my course teaches what I wish I was taught. My intention is to share the knowledge with you in an easy to follow manner, so that we can benefit together. You benefit form learning, and I from sharing in your success.

This course is for beginners and for intermediates.

A unique view

Understanding web development is a vast topic. To get you up to speed, I’ve spent months thinking about where to focus content and how to deliver it to you in the best possible way.

You will learn "why" things work and not just "how". Understanding the fundamentals of web development is important as it will allow you to write better code. And trust me, every website encounters bugs and slow rendering times, and without understanding the fundamentals you will be totally lost.

How is this course different?

There are lots of great courses on web development. Pity they never get into the detail about how we get our website to your users screen as quickly as possible – which covers full stack development.

In this course, I focus on true web performance. This includes server requests and responses, loading, scripting, rendering, layout, and the painting of the pixels to the screen.

Practice makes perfect

Theory is theory … but there’s nothing like getting behind your computer and typing in code. That’s why we will be coding, laughing and pulling out our hair together as we code real life websites and exercises during this course.

I love practical examples, which is why we build simple pages and analyze the CRP together by using the Network Panel, Performance Panel and Audit Lighthouse within DevTools.

Is this course for you?


It doesn't matter where you are in your web development journey. It's suitable for all levels.

Still unsure? If you fit in any of these categories then this course is perfect for you:

Student #1: You want to dabble in the world of programming: learning the fundamentals of HTTP, AJAX, Data Packets and Rendering will allow you to extend this knowledge to any language

Student #2: You want to gain a solid understanding of web performance

Student #3: You want to start using backend frameworks like Node.js, which are heavily dependent on having a deeper knowledge about how to make AJAX requests, manipulate the response and then deliver it to the screen

Student #4: You kinda know what the Critical Rendering Path is, but have little knowledge about how it works behind the scenes, and how to practically implement it in your code

Student #5: You have taken other courses in web development but just don’t feel like you’ve grasped it


Right this second, your competitors are learning how to become better web developers.

Web development is a blazing hot topic at the moment. But you have a distinct advantage. This course offers memorable learning topics, actionable tactics and real-world examples.

Lets get started!

What do you get?

· Lifetime access to all tutorial videos. No fees or monthly subscriptions.

· Q&A support.

· Quizzes and challenges to help you learn.

Let's get excited about becoming a professional web developer, and to be able to confidently apply it to your own websites.

See you in the lectures.

Who this course is for:
  • Anyone who has completed my “*NEW* JavaScript Complete Grandmaster” course
  • YES: This course is for beginners. Aimed at people new to the world of web development. No previous JavaScript experience is necessary
  • NO: This course is NOT only for beginners. It is a complete beginner to advanced master course that is suitable for intermediates who know the basics and have an idea about how a browser fetches data from a server and displays that to a page. Experienced students sometimes prefer to skip a section that they are very familiar with
  • YES: This course is for someone wanting to be a professional, to be expert and confident in the entire rendering process
  • Those who want to learn modern coding techniques to speed your page loading experience without third party libraries and frameworks
  • Those interested in building their own frameworks, or being better able to learn from the source code of other well-known frameworks and libraries
  • Those wanting to start using frameworks (e.g. like Angular or Node) that are heavily reliant on JavaScript and knowing the process flow of back-end web development
  • Those who have some knowledge of web development, but little knowledge about how it works behind the scenes, and how to practically implement best practices in their websites
Course content
Expand all 127 lectures 07:51:07
+ Introduction
24 lectures 01:41:30

Always learn the basics before jumping into the deep end.

Preview 01:17
Course Overview

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.

What this course covers

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!

Preview 01:31

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!

Preview 04:36
Is AJAX still relevant today?

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.

Quick step back

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!

XMLHttpRequest - introduction

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.

Pause for a second, and lets discuss the console

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.

Building the XMLHttpRequest object

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.

Dealing with the response data

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

Lets stop and talk about storage and files

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

Another example - displaying time from a server

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

Building our custom 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 ;)

Is order important?

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.

Another example - fetching an image and persons name

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.

Defining our requestListener function

A quick summary of what we've just done.

XMLHttpRequest - summary of our picture and name example

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.

Fetch - introduction

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

Fetch - setting it up

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.

Fetch - what is the .json() method

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.

Fetch - with POST

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.

Fetch vs XMLHttpRequest

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


You've seen what an HTTP request is, what AJAX is, and why we use it. You also 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!

Browsers and AJAX
12 questions
+ HTTP protocol, TCP and Packets
8 lectures 26:26

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

The Browser's main functionality

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.

Browsers and W3C

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.

Browsers request - intro

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.


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.

Packets - 5 Layers Explained

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.

Packets - Example

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 Protocol - Intro

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.

HTTP - Request and Response

Whew! You've done well.

You now have a high level understanding of the Browser, Packets and HTTP. Put your knowledge to the test with these fun quizzes.

Grab a coffee :)

8 questions
+ Bonus Section - Building a Custom Polyfill
13 lectures 39:45

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.

Quick caveat
Before you continue ...

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.

What is a polyfill?

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.

Testing whether the forEach() method exists in our Browser

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.

What is forEach()

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

Practical example of forEach()

Lets start building our very own forEach polyfill.

Custom forEach() polyfill - introduction

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.

Custom forEach() polyfill - first step
Wait ...

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

Custom forEach() polyfill - callback function

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

What is THIS

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

Custom forEach() polyfill - final

A quick recap on what we've done.


We've built our very own Polyfill. But as I always say, lets not 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.

5 questions
+ Critical Rendering Path - DOM, CSSOM, Render Tree
23 lectures 01:28:34

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.

Preview 04:01

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.

How the Browser works (the steps it takes to fetch data and display it)

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.

Critical Rendering Path - Introduction
Critical Rendering Path Overview

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!

Preview 03:22

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.

Constructing the DOM - Part 2

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!

Quick Recap

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

Preview 10:54

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.

Call Tree - an alternative way to analyse your website's activities

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.


Bottom-Up & Event Log - an alternative way to analyse your website's activities

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.

CSSOM - Introduction

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.

Why do we need to have a CSS Tree?

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.

How to view the CSSOM process for your website - Recalculate Style

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.

Render Tree - Introduction

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

Render Tree - Challenge

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

Render Tree - Solution

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.

Quick Recap - Render Tree

Lets compare the DOM, CSSOM and Render Tree

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

Render Tree - Layout

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

Viewing the Layout process in DevTools

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.

Render Tree - Paint

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

Preview 02:06

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

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

Critical Rendering Path
10 questions
+ Render Blocking Resources
26 lectures 01:37:59

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.

Render Blocking Resources - Intro

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!

How to make CSS non-render blocking (hint: Media Queries)

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

Media Types - Example

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.

Is JavaScript render blocking?

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!

JavaScript and the DOM

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.

JavaScript and the CSSOM

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

Example of JavaScript having to wait for the CSS

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

Step Back: DOM vs CSSOM vs 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.

JavaScript is render blocking

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.

Approach 1: Placing JavaScript at the bottom of your page

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.

Approach 2: Using 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.

Comparing Approach 1 (Bottom) vs Approach 2 (Async)

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.

Approach 3: Defer

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.

Comparing Approach 2 (Async) vs Approach 3 (Defer)

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

Approach 4: Custom event listener - part 1

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.

Approach 4: Custom event listener - part 2 (+ lets analyze the entire render)

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.

Async vs Defer vs Custom

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.

Approach 5: Preload

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

Quick caveat
Preload - More Information

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.

Preload & images and how they affect 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.

Summary of where we can place our JS to improve the CRP
Overview - One Page

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

Preview 01:46

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.

What is speculative parsing
Speculative Parsing - Quick Review

Grab a coffee, relax, and test yourself with these fun questions.

Render Blocking Quiz
13 questions
+ Having Fun: Lets Analyze the Critical Rendering Path Together
25 lectures 01:38:31

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

Section introduction

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.

Why is the Network Panel important

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.

Introduction to Network Panel

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.

What do the all the columns mean 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.

Response and Request Headers

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.

Timing tab and waterfall stack

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.

3 most common network requests you'll see

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 ;)

Time phases - introduction

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.

Lifecycle of a request

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.

Time phases - detailed explanation

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.

CDN - an introduction

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.


Analyzing File Requests in the Network Panel

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

Network Panel - High Level Overview

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.

Analyzing our file's CRP - no CSS and no JS

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

Bonus: what is the size column?

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.

How to identify number of critical resources and server round trips

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.

Lets add JavaScript and CSS

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

Rendering our new file with JavaScript and CSS

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.

Impact that JavaScript and CSS has on our CRP

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? 

Inline JavaScript

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.

Adding ASYNC to our file, and its impact on the CRP

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.

Steps to take to optimize the Critical Rendering Path
What now?

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.

Audit Lighthouse - Introduction

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

Audit Lighthouse - Example

This has been an epic section - well done for getting this far. Seriously!

Now, grab a coffee and try these fun questions. Remember, there's no pressure to get these 100% correct. They are here for your benefit.


Waterfall, Timing and CRP Quiz
8 questions
+ Bonus Section - HTTP/2
6 lectures 17:10

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/1.1 - Recap

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 - where did it come from?
HTTP/2 - Did you know?

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.

HTTP/2 - what is it?
Quick comment on HTTP/2
HTTP/2 Questions and Answers

HTTP/2 is a major revision of the HTTP network protocol used by the World Wide Web. We know this. But how well have you watched the videos? Put your knowledge to the test.

HTTP/2 Quiz
7 questions
+ Closing Comments
2 lectures 01:08
Well Done
Where to next?