More articles

What happens to the input URL (1)–DNS resolution

What happens to the input URL (2)–TCP

What happens to the input URL (3)–HTTP

preface

After the HTTP request is sent, the browser has the resource, and then the rendering work begins. Basically, this piece is understood, and the general process from the input URL to the page rendering appears is clear

Rendering process

  1. The HTML is parsed, the DOM tree is generated, and usually the browser does not get the HTML completely before it starts rendering. This is a process of parsing and rendering
  2. Parse the CSS and build the CSSOM tree
  3. Generate Render tree from CSSDOM tree and DOM tree
  4. Calculate the geometric information (location, size, color, etc.) of each DOM node based on the Render tree
  5. Draw the page based on the calculated information

Block rendering

During DOM parsing, external resources such as (link, image) need to be loaded. The process of loading resources will not block rendering, but the process of CSS parsing and JS execution will block rendering

CSS

By default CSS is treated as a resource that blocks rendering:

  1. The Render tree requires both the DOM tree and the CSSDOM tree. The DOM is required, and if the CSSDOM is not built, the Render tree will be blocked
  2. JS modifies the CSS, and the CSSDOM build blocks the execution of subsequent JS statements

Usually, we will put the CSS in the head tag, and load and parse the CSS as soon as possible.

<! The media type is set and loads but does not block. The print declaration is only used when printing a web page. -->
<link href="print.css" rel="stylesheet" media="print">
<! -- blocks rendering if a condition is met. -->
<link href="other.css" rel="stylesheet" media="(min-width: 30em) and (orientation: landscape)">
Copy the code

Media limitations are still relatively high, the need for a specific scenario can be used, in addition to we can also use the strong cache and negotiation cache learned in the front, the daily compression of what I believe old drivers are handy, here we introduce preload and prefetch

  • preload

Preload provides a declarative command that allows the browser to load a specified resource in advance (not execute it after loading) and then execute it when needed. Use the following command:

<! You need to use the as attribute to specify a specific resource type so that the browser assigns it a priority -->
<link href="pre.css" rel="preload" as="style">
Copy the code

Do not use preload arbitrarily. If you use preload, the resource will be loaded in advance regardless of whether it is used, which will put unnecessary burden on the web page

  • prefetch

It tells the browser what resources are likely to be used to load the next page. It can be used to optimize the loading speed of the next page by using:

<link href="pre.css" rel="prefetch">
Copy the code

Preload and prefetch also apply to JS:

<link href="pre.js" rel="preload" as="script">
<link href="pre.js" rel="prefetch">
Copy the code

JS

JavaScript might modify the DOM or CSS, so when the browser encounters a script tag, it wakes up the JavaScript parser and stops parsing HTML, so everyday development usually puts the script tag at the bottom, and usually when it encounters a script tag, it loads the resource. We can load asynchronously through defer and async

  • defer

The js script is completed before the document is loaded and parsed before DOMContentLoaded executes

  • async

The process of loading and rendering subsequent document elements takes place in parallel with the JS script, with a lot of uncertainty, either before or after the document is parsed

As defer is more in line with our day-to-day needs, it’s safe to suggest putting the script tag last

conclusion

Without further ado, the input URL to the page rendering process is over!!