Slow rendering times can also frustrate your users and may cause them to abandon your page.

1.8 seconds is important for First Contentful Paint! HTTP Archive collects data from the previous approximately 7 million urls. Lighthouse uses this data to determine the best performing sites. Then set the “green” level at the point where performance improvements increase with diminishing returns.

HTTP Archive (HTTP Archive keeps track of how the Web is built by regularly crawling top sites on the Web and recording details about resources acquired, Web platform apis and features used)

What are the key render paths

We write HTML, CSS, and JavaScript in files, and then send those files to the browser. The browser converts these files into pages that you see through the key render path. Steps are:

  1. Download the HTML

  2. Read HTML while:

    • Building the Document Object Model (DOM)
    • Pay attention to<link>Style sheet TAB and downloadCSS

  3. Read CSS and Build CSS Object Model (CSSOM)

  4. Combine DOM and CSSOM into a render tree

  5. Using the render tree, calculate the layout (size and position of each element)

  6. Draws or renders pixels on a page

What is rendering blocking resource

Render blocking resources are files that “press pause” on key render paths. They interrupt one or more steps.

HTML is technically rendering blocking because you need it to create the DOM. Without HTML, we wouldn’t even have a page to render.

However, HTML is usually not the cause of our problems……

CSS is rendering blocking. Browsers need it before creating CSSOM, which prevents all subsequent steps. Once the browser encounters a stylesheet or

JavaScript can render blocking. When the browser encounters a script to run synchronously, it stops DOM creation until the script is finished running.

Also, if CSS comes before the script, the script will not be executed until the CSSOM is created. This is because JavaScript can also interact with CSSOM, and we don’t want a race condition between them.

CSS prevents script execution, and JavaScript prevents DOM construction!

Note:Images and fonts do not prevent rendering.

Why are they important for performance

Rendering blocking resources can cause a cascade of failures in network performance. The first draw is slow, which causes maximum content draw (LCP) to be slow. LCP is now one of the core Web Vitals used to calculate your search engine rankings.

Search engine optimization is important for discovering your site. Performance is critical to keeping visitors on your page. If the page does not load within 3 seconds, the page abandonment rate increases significantly.

How do I test my site rendering block resources?

If you fail this metric in Lighthouse, you’ve found a way to test it.

We all have rendering blocking resources on our website (all CSS!). . The problem arises when it significantly affects our performance. As this happens, Lighthouse will flag it and we should do something about it.

The Lighthouse candidates for rendering a blocking resource include scripts and styles:

  • <script>In the label<head>Does not have at least one of the following attributes:async.defer.module
  • Media queries with no attributes or mismatches<link>Style sheet tag in (for example,)<head>``disabled``print

If you fail this metric, your Lighthouse results will look like this:

Lighthouse lists bootstrap, Google Fonts stylesheets, and JQuery scripts. Let’s dig a little deeper. Let’s check<head>Failure site for samples. It shows us two stylesheets, followed by two scripts:

<head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, Initial - scale = 1.0 "> < link rel =" stylesheet "href =" https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstrap.min.css" integrity="sha384-Gn5384xqQ1aoWXA+058RXPxPg6fy4IWvTNh0E263XmFcJlSAwiGgFAW/dAiS6JXm" crossorigin="anonymous"> <link Href = "https://fonts.googleapis.com/css?family=Roboto:100, 100 I, 300300 I, 400400 I, 500500 I, 700700 I, 900900 I" Rel = "stylesheet" > < script SRC = "https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/js/bootstrap.min.js" integrity="sha384-JZR6Spejh4U02d8jOt6vLEHfe/JQGiRRSQQxSfFWpi1MquVdAyjUar5+76PVCmYl" crossorigin="anonymous"> </script> < script SRC = ". / jquery - 3.5.1 track of js "> < / script > < title > Document < / title > < / head >Copy the code

Lighthouse can tag either of these two initial stylesheets. The root causes of this failure are:

  • The first two stylesheets prevent two synchronous scripts from running. The browser must first download the stylesheet and create the CSSOM.
  • The browser cannot build the rest of the DOM until these two scripts are downloaded, parsed, and executed.

Another way to test rendering blocking resources is to use WebPageTest. WebPageTest is the next step in performance analysis. If you enter a URL, it will run the performance test on a real mobile device. When the test is complete, click the waterfall running in the middle. Each render blocking resource will have an orange circle with a white X next to it

How do I remove resources that block rendering?

It’s time to fill that hole and fix our website. Let’s dive into CSS and JavaScript. Our goal is not to eliminate all rendering blocking resources, but to reduce their impact on performance. The Lighthouse metric helps determine when you reach that point.

Optimize CSS for critical render paths

For our CSS, we want

  1. Minimize the size of our style
  2. And provide customers with fast and efficient

The first question I want to ask is:

Do I need all of these dependencies?

Don’t skip the first question. The easiest way to minimize the total size of any asset is to eliminate it. Burn it to the ground. For example, 12 Google fonts seems too many. I try to keep my Web fonts down to 3-4 style sets at most.

The next easiest way to minimize the total amount of CSS is to minimize it. Narrowing is the process by which the build tool removes unused white space. Fewer characters = smaller size = faster downloads. If you use a CSS package, be sure to use a smaller version of it. The next step is to use the build tool to automatically minimize all CSS. Sample tools include Gulp, Grunt, Webpack, and Parcel. Snowpack and Vite are interesting new tools.

Next, I’ll try to break my CSS into smaller pieces. Ideally, we just want to deliver the CSS we’ll actually use. You can see how much CSS (and JavaScript) is actually used with Coverage drawers in Chrome Dev Tools.

  1. Open the development tool
  2. Press Cmd + Shift + P to open the shortcut menu
  3. Type ‘Coverage’ and then select ‘Show Coverage’

You can click the reload button to start a new coverage analysis. The interface is as follows:

If your CSS total number of bytes is small, the unused percentage becomes less important. For example, many of my pages are more than 90% unused. Because my CSS total is small, my Lighthouse score is still around 97-100.

Note that it only applies to the styles (or scripts) used so far. These numbers rise as you interact or resize the page.

Your goal is not necessarily 0% unused. However, if you see big red bars and lots of unused bytes, it’s time to reduce the CSS required for initial rendering. Remove dependencies, use code split or inline key CSS, and defer the rest.

If you have a lot of non-screen styles, consider extracting them into your own stylesheets. Then use the media query on the tag. Such as:

<link href="styles/main.css" type="text/css" rel="stylesheet" media="screen"> <! -- Only downloadedfor print: -->  
<link href="styles/main_print.css" type="text/css" rel="stylesheet" media="print">
Copy the code

Finally, do not use @import in your stylesheets to load more stylesheets. The browser won’t find it until later. It is best to load them in HTML using tags.

Optimize JavaScript for critical render paths

As I mentioned earlier, JavaScript is blocked by the parser. This means that it blocks the DOM build until it completes execution. Like CSS, we want to:

  1. Minimize the size of our script
  2. And provide customers with fast and efficient

The Coverage drawer also analyzes your scripts. You can filter the results between CSS and JavaScript. Again, the first question to ask yourself is:

Do I need all of these dependencies?

JavaScript is our most expensive asset, and prone to inflation. Delete unused dependencies. Also, use code-splitting, tree-shaking, or lazy loading as needed. Your build tool is a friend to all of these strategies.

Let’s talk about delivering our JavaScript efficiently. The best diagram I’ve seen to understand async vs defer vs Module comes from the HTML specification:

  • No attributes: The HTML parser is blocked during script download and execution.
  • Defer: The HTML parser is not blocked. The browser downloads the script when it recognizes it. It only executes the script after DOM creation is complete.
  • Async: THE HTML parser is blocked during script execution. The browser downloads the script when it recognizes it. Once downloaded, the script blocks the HTML parser until execution is complete.
  • Module: Behaves like defer but manages ES6 module imports.

Choose wisely. In most cases, you’ll want to defer or Async to optimize key render paths. If you have an inline script that must be run synchronously, test moving it above the style in the HTML.

conclusion

Rendering blocking resources can cause a number of performance issues. These performance issues can cause dissatisfied users to abandon your pages more quickly.

Lighthouse and Coverage tools can help you identify this problem and evaluate your best options. We learned:

  • Reduce our CSS and JavaScript bytes,
  • Lazy loading of non-critical CSS and JavaScript, as well
  • usedefer.asyncormoduleFor our script properties.