The directory structure

The general idea of the article is as follows:

  • The process of a URL from input to page presentation
  • DOM and JavaScript
  • Why DOM manipulation is “slow”
  • The process by which a browser parses HTML
  • rearrangement
  • redraw

The process of a URL from input to page presentation

Before discuss the browser parses HTML, to understand the url from the input to the last page rendering process is a necessary step, it can help us to grasp the overall process, let us know it before know HTML parsing the details in which stages of the request cycle, it is of great help to our build perfect knowledge map.

First, we assume that the input URL request is the simplest Http request. Take GET request as an example, which can be roughly divided into the following steps:

  1. The user enters the URL in the address bar of the browser. The browser will first look at the browser caches – system caches – router caches based on this URL. If there is one in the cache, skip to Step 6. If not, follow these steps.
  2. The browser resolves the host name based on the entered URL.
  3. The browser translates the host name into the server IP address. If yes, go to Step 4. If no, the browser sends a query request to the default DNS server and caches the current IP address to the DNS cache list. For details, see how to search for a domain name in DNS.
  4. After getting the IP address, the browser parses the port number from the URL.
  5. Once the IP and port are in hand, the browser establishes a TCP connection to the target Web server, known as the three-way handshake. Portal: Complete TCP connection.
  6. The browser sends an HTTP request packet to the server.
  7. The server returns an HTTP response packet to the browser.
  8. Close the connection browser to parse the document.

If there are resources in the document, repeat actions 6, 7, and 8 until all resources are loaded. The above steps outline the process of the browser from entering the URL to the final page rendering, but they are not very specific, such as what type of request message the browser will encounter, what error scenarios the browser will parse the response message, and so on.

In fact, there will be some differences in the details of the process of accessing the server in different scenarios such as HTTP request, proxy and load balancing. However, this does not affect our understanding of the whole access link. Interested students can have a detailed understanding on the Internet, which will not be detailed here.

DOM and JavaScript

The Document Object Model (DOM) is a language-independent API for manipulating XML and HTML documents. On the Web side, we often use THE DOM to manipulate HTML, but DOM can also manipulate XML documents.

We now know that DOM is a language-independent API. In other words, DOM is a language-independent API. Other languages can implement specific APIS for manipulating DOM, but it is implemented in JavaScript in the browser. DOM is an important part of JavaScript coding these days, because JavaScript often manipulates underlying documents.

Why is DOM manipulation slow

Although DOM is implemented by JavaScript, DOM and JavaScript are implemented separately in browsers. For example, in IE, the implementation of JavaScript is named JScript and stored in the jscript.dll file. The DOM is in another library called mshtml.dll. In Safari, DOM and rendering are implemented using WebCore in Webkit, while JavaScript is implemented by a separate JavaScriptCore engine. In Chrome, WebCore is also used for rendering. The JavaScript engine is their own V8 engine.

DOM and JavaScript are implemented separately and independently, so every time you manipulate the DOM through JS, you need to connect THE JS and DOM first. We can understand this: Compare the DOM and JavaScript to two islands connected by a toll bridge. Each time you access the DOM, you need to cross the bridge and pay a toll. The more times you access the DOM, the higher the toll. Because browsers have a lot of access to the DOM, the “travel” and “operation” costs naturally increase, which is why DOM manipulation is slow

The steps the browser takes to render HTML

HTML rendering is roughly divided into the following steps:

  1. HTML is parsed into a DOM Tree by an HTML parser, and CSS is parsed into a CSSOM Tree by a CSS parser.
  2. After the DOM Tree and CSSOM Tree are parsed, they are attached together to form the Render Tree.
  3. Node information calculation (rearrangement) is a process called Layout(Webkit) or Reflow(Mozilla). That is, the geometry of each node is calculated based on the render tree (DOM object location and size).
  4. Rendering (repainting) is a process called Painting or Repaint. That is, draw the entire page based on the calculated information.

In theory, every dom change or CSS geometry change will cause a browser rearrangement/redraw process, whereas non-geometric CSS changes will only cause a redraw process. So rearrangement always leads to redrawing, and redrawing doesn’t necessarily lead to rearrangement.

Rearrangement (Relayout/Reflow)

Before we figure out what rearrangement is, it’s important to remember that browsers render pages using a Flow Based Layout model by default.

The so-called rearrangement is actually based on the information of each render object in the rendering tree, calculate the geometry information of each render object (DOM object location and size), and place it in the correct position in the interface.

Since the browser rendering interface is based on the streaming layout model, that is, if the information of a DOM node is changed, the DOM structure needs to be recalculated and the interface is rearranged, causing backflow again. However, the change degree of this structure will determine the change scope of the surrounding DOM, namely the global scope and the local scope. Global scope is to rearrange the entire render tree from the root HTML, for example when we change the window size or orientation or change the root element size or font size; A local layout can be a rearrangement of a part of the render tree or a render object.

Here, summing up operations that would cause a rearrangement are:

  • Page rendered for the first time.
  • The browser window size changed. Procedure
  • The size or position of the element changed.
  • Element content changes (text number or image size, etc.).
  • Element font size changes.
  • Add or remove visible DOM elements.
  • Activate CSS pseudo-classes (such as: :hover).
  • Setting the style property

Query some properties or call some methods. It is common to cause rearrangements of properties and methods

Rearrangement is also called reflux. In fact, the literal meaning of reflow is also reflux. The reason why it is called rearrangement may be because it is better to understand and more in line with the Thinking of Chinese people. Standard documents is called a reflux (Reflow), because the browser rendering is based on the fluid layout model, the flow is actually that we often say that the document flow, at the time of change when the dom or CSS geometric properties, document flows to change by volatile linkage, flow like a river of water, reflux is just like throw a stone into the river, It ripples, and then it ripples the water around it, and that’s why it’s called backflow, which is kind of a more standard way of thinking about it, but it doesn’t really matter what it’s called, it really matters that we understand the process.

Repainting

Redraw is a much simpler process than rearranging. Redraw is the process in which the browser assigns a new style to an element on a page without affecting its position in the document flow, such as changing the font color.

Common attributes that cause the browser to draw include: