preface

To be a qualified front-end engineer, it is necessary to understand how browsers work, so that you have a complete body of knowledge. “If you can understand how browsers work, you can solve 80% of the front-end problems.”

Other articles:

  • 54 JavaScript interview questions
  • The 9 basic operations of the “Algorithms and Data Structures” list
  • [Dry goods 👍] From detailed manipulation of JS arrays to an analysis of array.js in V8
  • [full of sincerity 👍]Chrome DevTools debugging tips, efficiency ➡️🚀🚀 ➡️
  • [suggestion 👍] Again 100 JS output questions sour cool continue (total 1.8W words + consolidate JS foundation)
  • [1.2w word 👍] To his girlfriend’s secret – how the browser works (on)

This article is going to take a look at the rendering process, which is how the browser takes HTML, CSS, JS, images and other resources and renders them into a beautiful page.

Again, “Understanding how the browser works gives you a higher level of understanding of the front end.”

I hope that through this article, you can re-understand the browser, and JavaScript, network, page rendering, browser security and other knowledge connected together, so that you have a new understanding of the whole front-end system.

This article is mainly to sort out several important steps in the rendering process, as well as what optimization points, how to avoid and reduce redraw, rearrangement, to optimize performance has certain help.

After reading this installment, you will learn

  • The underlying logic of front-end performance optimization;
  • The core process of browser page rendering
  • JavaScript runtime mechanism parsing
  • Browser network and security mechanism analysis

Whisper: You are welcome to share your thoughts with me in the comments section, and you are welcome to record your thought process in the comments section 👊


If you like it, you can like it/follow it and support it. I hope you can get something out of this article

Review the previous issue

Talk about the rendering process in the browser, first to comb the content of the previous overview

Previous article: [1.2W word 👍] to his girlfriend’s secret – browser works (on)

Browser Architecture (Mainly Chrome)

Mainly comb the following knowledge points:

  • Comb through the concept of single thread and multi-thread,Processes are different from threads
  • Based on Chrome browser, combs the history of Chrome browser development, from single process browser to multi-process browser
  • Single-process architecture to multi-process architecture trends, the pros and cons of these trends
  • Most browsers now have multi-process architectures:Main process Renderer process Plug-in process GPU process Network process

The Http request

Mainly comb the following knowledge points:

  • The overall flow of Http requests is roughly divided into eight stages

  • The eight phases are summarized as follows: Build request lookup cache prepare IP and port wait for TCP queue Establish TCP connection initiate HTTP request server process request server return request and disconnect

  • The general working principle of each stage has been combed

  • Browser caching is mentioned in passing as a part of performance optimization

Navigation process: Enter url to page display

Main knowledge points:

  • The overall process, combing the process of the most important three processes, browser process network process rendering process, their respective responsibilities and communication between the three
  • Try to analyze each stageThe details are omitted.

After the renderer receives the CommitNavigation message, it starts to pipe the data to the network process, at which point the renderer starts working

So with that in mind, how does the rendering process work

Rendering process

The first concepts to understand:

  • Rendering Engine: The core Rendering Engine is the browser’s Rendering Engine, which is generally referred to as the browser core.

  • The rendering engine mainly consists of the following threads:

  • The main responsibilities of each thread

    • GUI rendering thread: GUI rendering thread is responsible for rendering browser interface, parsing HTML, CSS, building DOM tree and RenderObject tree, layout and drawing, etc. This thread executes when the interface needs to be repainted or when some operation causes Reflow.
    • JavaScript engine threads: JavaScript engine threads are responsible for parsing JavaScript scripts and running the associated code. The JavaScript engine has only one JavaScript thread running the JavaScript program on a Tab page (Renderer process) at any given time. It should be mentioned that GUI threads and JavaScript engine threads are mutually exclusive, which is why JavaScript takes too long to render the page incoherently, causing the page to block.
    • Event-triggering thread: When an event is triggered, the thread adds the event to the end of the queue, waiting for the JavaScript engine to process it. Typically JavaScript engines are single-threaded, so these events are queued up for JS execution.
    • Timer trigger: setInterval and setTimeout are used in this thread. The reason may be that: as the JS engine is single-threaded, if it is in the blocking thread state, it will affect the accuracy of time keeping. Therefore, it is more reasonable to use a separate thread to keep time and trigger the responding event.
    • Http request thread: After the XMLHttpRequest connects, the browser opens a new thread, which is the Http thread, and it detects a state change. If a callback function is set, the asynchronous thread generates a state change event and places it in the JavaScript engine’s processing queue for processing.

More from the elder brother of the Po summary: you don’t know the Web Workers (on) [7.8 K words | multiple warning]

With these concepts in mind, it will be helpful for us to talk about the rendering pipeline

Simplified rendering mechanism

I finished reading how browsers work a long time ago, read a lot of blogs and articles, and then simply combed through some content, as follows 👇

The abbreviated rendering mechanism is generally divided into the following steps

  1. Process THE HTML and build the DOM tree.
  2. Process CSS to build CSSOM trees.
  3. Merge DOM and CSSOM into a render tree.
  4. According to the layout of the render tree, calculate the position of each node.
  5. Call THE GPU to draw, synthesize the layer and display it on the screen.

And it went something like this:

When the CSSOM tree is built, rendering is blocked until the CSSOM tree is built. Building a CSSOM tree is a very performance-intensive process, so you should try to keep the hierarchy flat and reduce excessive layering. The more specific the CSS selector, the slower the execution.

Building the DOM is paused when the HTML is parsed to a Script tag, and then resumed from where it was paused. That is, if you want the first screen to render as fast as possible, the less you should load JS files on the first screen. CSS also affects THE execution of JS, which is executed only after the stylesheet has been parsed, so it is safe to assume that CSS will also pause DOM building in this case.

Finish these, write down to talk about a few interviews will often mention, will ask your knowledge 👇

Load and DOMContentLoaded

The Load event is triggered to indicate that the DOM, CSS, JS and images in the page have all been loaded.

The DOMContentLoaded event is triggered to represent that the original HTML is fully loaded and parsed, without waiting for CSS, JS, and images to load.

The layer

In general, you can think of a normal document stream as a layer. Specific properties generate a new layer. The rendering of different layers does not affect each other, so it is recommended to generate a new layer for frequent rendering to improve performance. However, you should not create too many layers, which will cause the reaction.

New layers can be generated using the following common properties

  • 3 d transform:translate3d,translateZ
  • will-change
  • video,iframeThe label
  • Through animationopacityThe animation transformation
  • position: fixed

Repaint and Reflow

Redraw and backflow are a small part of the rendering step, but these two steps have a significant impact on performance.

  • Redraw is when a node needs to change its appearance without affecting the layout, such as changescolorIt’s called redrawing
  • Backflow is when layout or geometry properties need to be changed.

Backflow must occur redraw, redraw does not necessarily cause backflow. The cost of backflow is much higher, and changing the underlying node is likely to result in a series of backflows from the parent node.

So the following actions can cause performance problems:

  • Change window size
  • Change the font
  • Add or remove styles
  • Text change
  • Position or float
  • The box model

What a lot of people don’t know is that redraw and reflux are actually related to Event loops.

  1. When the Event Loop completes Microtasks, it determines whether the document needs to be updated. Since the browser has a refresh rate of 60Hz, it only updates every 16ms.
  2. And then determine if there isresizeorscrollIf there is, it will trigger the event, soresizescrollEvents are triggered at least once in 16ms and have throttling functions.
  3. Determines whether a Media Query is triggered
  4. Update the animation and send the event
  5. Check whether a full-screen operation event exists
  6. performrequestAnimationFrameThe callback
  7. performIntersectionObserverCallback, a method used to determine whether an element is visible, can be used on lazy loading, but is not compatible
  8. Update the interface
  9. So that’s what you might do in one frame. If there is free time in a frame, it will be executedrequestIdleCallbackThe callback.

The above content is from an HTML document

Reduce redrawing and reflow

  • Use translate instead of top

    <div class="test"></div>
    <style>
    	.test {
    		position: absolute;
    		top: 10px;
    		width: 100px;
    		height: 100px;
    		background: red;
    	}
    </style>
    <script>
    	setTimeout(() => {document.querySelector();'.test').style.top = '100px'
    	}, 1000)
    </script>
    Copy the code
  • Use visibility instead of display: None, because the former will only cause redraw and the latter will cause backflow (changing the layout)

  • Take the DOM offline and modify it, for example: first give the DOM to display: None (once Reflow), then you modify it 100 times before displaying it

  • Do not place DOM node property values in a loop as variables in the loop

    for(leti = 0; i < 1000; I++) {// getting offsetTop will cause backflow because you need to get the correct value console.log(document.queryselector ('.test').style.offsetTop)
    }
    Copy the code
  • Do not use the table layout, it is possible that a small change will cause the entire table to be rearranged

  • Select the speed of the animation implementation, the faster the animation, the more backflows, you can also choose to use requestAnimationFrame

  • CSS selectors match from right to left to avoid DOM depth

  • Turn frequently running animations into layers that prevent backflow from affecting other elements. For the video TAB, for example, the browser automatically turns the node into a layer.


That’s not what I want to tease out

The rendering process above is a year ago I exist in my notes, I remember the way of learning is swallowed, ☝ above a brief version of the rendering process, my mind is in the making, Dennis bergkamp and see above direct Copy down at that time, felt the rendering principle the comb with others good conclusion, see more, You’ll remember that. In fact, in the interview, when you bring up this part, it’s obvious that you don’t have enough depth

I sorted out a detailed version. Frankly speaking, as a scholar, nature is standing on the shoulders of giants to summarize knowledge, which I think is the most effective way for me to learn

Let me walk you through the general rendering process 🚗


Detailed version of the rendering mechanism

More technical terms are summarized as the following stages:

  1. Build a DOM tree
  2. Style calculation
  3. The layout phase
  4. layered
  5. draw
  6. block
  7. rasterizer
  8. synthetic

You can imagine, from 0, 1 byte stream to the last page to show in front of you, inside this rendering mechanisms must be very complex, so the rendering module into many sub stages in the process of execution, rendering engine byte streams from the process of network data, through these sub stages of processing, the final output pixels, this process can be referred to as the rendering pipeline, Let’s look at 👇 from a picture

Then, from each stage to comb through the general process.

Build a DOM tree

The main job of this process is to translate THE HTML content into the browser DOM tree structure

  • Byte → character → token → node → Object Model (DOM)

Document Object Model (DOM)

<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <link href="style.css" rel="stylesheet">
    <title>Critical Path</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg"></div>
  </body>
</html>
Copy the code

Let’s take a look at how the data is converted 👇

General process:

  1. ** Conversion: ** The browser reads the raw bytes of HTML from disk or the network and converts them to individual characters based on the specified encoding of the file (such as UTF-8).
  2. ** Tokenization: ** Browsers convert strings to various tokens specified by the W3C HTML5 standard, such as “”,” “, and other strings in Angle brackets. Each token has a special meaning and a set of rules.
  3. Lexical analysis: tokens issued by ** are converted into “objects” that define their properties and rules.
  4. Finally, because HTML tags define relationships between different tags (some tags are contained within other tags), the objects created are linked within a tree data structure that also captures parent-child relationships defined in the original tags:HTMLThe object isbodyObject’s parent,bodyparagraphObject’s parent, and so on.

We call this process DOM tree building

Style calculation

There are three main steps in this substage

  • Formatting style sheets
  • Standardized style sheets
  • Compute the specific style of each DOM node

Formatting style sheets

So when the rendering engine receives the CSS text, it performs an operation to convert it to a structure that the browser can understand -styleSheets

If you want to know more about the formatting process, you can do some research. Different browsers may have different CSS formatting processes, so I won’t go into detail here.

You can view the final results in the browser console document.stylesheets. Query and modify functionality is done through JavaScript, or this stage provides the foundation for later style manipulation.

Standardized style sheets

What is a standardized style sheet? Take a look at the CSS text 👇

body { font-size: 2em } p {color:blue; } span {display: none} div {font-weight: bold} div p {color:green; } div {color:red; }Copy the code

Font-size :2em; color:red; Font weight:bold, values like these are not easily understood by the rendering engine, so they need to be standardized before calculating styles such as em->px,red->rgba(255,0,0,0),bold->700, etc.

What will the attribute values look like after the above code criteria 👇

Compute the specific style of each DOM node

Through formatting and standardization, the next step is to calculate the specific style information for each node.

Calculation rules: inheritance and cascade

Inheritance: Each child node inherits its parent node’s style by default. If it is not found in the parent node, it adopts the browser’s default style, also known as UserAgent style.

Cascading: Cascading styles, a basic feature of CSS, define algorithms for merging property values from multiple sources. In a sense, it is at the core, and the specific cascading rules are in the domain of the CSS language, which is covered here.

It is important to note, however, that after calculating the style, all the style values are hung in window.getComputedStyle, which means that you can get the calculated style from JS.

In this stage, the specific style of each element in the DOM node is completed. In the calculation process, CSS inheritance and cascading rules should be followed. The final output content is the style of the DOM of each node, which is saved in the ComputedStyle.

To see how each DOM element will look Computed, open Chrome’s Developer Tools and select the first “Element” TAB. For example, I chose the DIV TAB below, and then the “Computed” child TAB, as shown below:

Another way to say it is CSSOM

If you don’t quite understand, you can go to 👇

As with HTML, we need two more rules of CSS: inheritance and cascading into something that a browser can understand and process, similar to how it handles HTML, as shown in ☝

CSS bytes are converted into characters, which are then converted into tokens and nodes, and finally linked into a tree structure called the CSS object model (CSSOM) 👇

Many of you will be familiar with this. Indeed, many blogs are based on the CSSOM statement. I would like to say this:

Unlike DOM, CSSOM does not exist in the source code, so CSSOM should be styleSheets, which we can print out

A lot of articles say that rendering trees were 16 years old, but now that the code has been refactored, we can think of LayoutTree as rendering trees, but there are some differences.

Generate layout tree

After the DOM Tree is built and the DOM style is calculated, the next step is to determine the location of the elements through the browser’s Layout system. This is to generate a Layout Tree, formerly called a render Tree.

Creating a layout tree

  1. Elements that are not visible in the DOM tree, such as head elements, meta elements, and elements that use the display: None attribute, do not end up in the layout tree, so the browser layout system needs to build an additional layout tree that contains only visible elements.

  2. Let’s look at the layout tree building process directly with the diagram:

    To build the layout tree, the browser layout system basically does the following:

  • Walk through the DOM tree and add the visible nodes to the layout tree
  • For invisible nodes, head,meta tags, and so on are ignored. For the body.p.pan element, its attribute contains display: None, so the element is not included in the layout tree.

Layout calculation

Next is to calculate the coordinate position of the layout tree node, the layout of the calculation process is very complex, open the introduction, will appear too bloated article, in most cases, we only need to know what it is doing, want to know how to do it, you can see the following two articles 👇

  • How to view layout from Chrome source
  • Everyone FED team article – from Chrome source view browser layout

Comb through the first three stages

A diagram summarizes the above three phases

layered

  • Generate Layer Tree
  • Elements with cascading context attributes are promoted to a separate layer
  • Layers are also created where you need to clip
  • Layer to draw

First need to know is, the browser in the build after the layout of the tree, they require a series of operations, it may consider to some complex scenarios, such as some complex 3 d transform, page scrolling, or use the z – indexing, etc., make the z axis to order and how to control such as contain cascading context show and hide, and so on and so forth.

Generate layer tree

The final page you see is made up of these layers stacked on top of each other, in a certain order, to form the final page.

The browser page is actually divided into many layers, which are superimposed to create the final page.

Let’s take a look at the relationship between layers and layout trees, as shown below 👇

In general, not every node in the layout tree contains a layer, and if a node has no corresponding layer, then the node is subordinate to the layer of the parent node.

When does the rendering engine create a new layer for a particular node?

There are two cases that need to be discussed separately, one is explicit and the other is implicit.

Explicit synthesis

A node with a cascading context.

A cascading context is also basically created with a few specific CSS properties, typically the following:

  1. The HTML root element itself has a cascading context.
  2. A cascading context occurs when a normal element does not set position to static and z-index is set.
  3. The opacity value of the element is not 1
  4. The transform value of the element is not None
  5. The filter value of the element is not None
  6. The isolation value of the element is ISOLATE
  7. Will-change specifies the value of any of the above attributes. (More on will-change later)

Two, the need for clipping (clip).

For example, if a tag is very small, 50 by 50 pixels, and you put a lot of text in it, the extra text will have to be cropped. Of course, if the scroll bar is present, the scroll bar will also be promoted to a separate layer, as shown below

You can see where the arrow of the number 1 points to. It may not be very obvious. You can open the Layers and explore it yourself.

An element that has the properties of a cascading context or needs to be clipped at any point is promoted to a single layer.

Implicit synthesis

What kind of situation is this? In the common sense, it means that the nodes with a lower Z-index level will be promoted to a separate layer, and the nodes with a higher layer level will become an independent layer.

Summary of browser rendering process &Composite

Disadvantages: According to the above article, in a large project, when a node with a low Z-index is promoted to a separate layer, all elements on top of it will be promoted to a separate layer. As we know, thousands of layers will increase the pressure on memory, and sometimes the page will crash. That’s a layer explosion

draw

Now that the layer is constructed, the next thing to do is draw the layer. The layer drawing is the same as our daily drawing, each time a complex layer is divided into small drawing instructions, and then a drawing list is formed according to the order of these instructions, similar to the following 👇

As can be seen from the figure, the instructions in the draw list are actually very simple. They are asked to perform a simple drawing operation, such as drawing a pink rectangle or a black line. Drawing an element usually requires several drawing instructions, because each element’s background, foreground, and borders require separate instructions to draw.

You can open more Tools in the Chrome Developer Tools Settings bar and select Layers to see the following drawing list:

In this figure, the area ** pointed to by ** arrow 2 is the drawing list of Document, and the progress bar in the dragging area ** pointed to by ** arrow 3 can reproduce the drawing process of list.

Of course, drawing layers has a special thread in the render process called the composition thread.

block

  • Next we start drawing, which is actually done in the rendering process by a special thread called the composite thread.

  • When the drawing list is ready, the main thread of the renderer process sends a COMMIT message to the composition thread, which submits the drawing list to the composition thread. Now it’s time for synthetic threads to show off.

You want to ah, sometimes, your layers is very big, or the page you need to use the scroll bar, and then the content of the page is too much, more can’t imagine, this time need to scroll to scroll to the bottom for a long time, but through the viewport, users can only see a small portion of the page, so in this case, to draw out all layer content, will generate too much overhead, And there’s no need.

  • For that reason, the composition thread will tell you to divide layers into tiles.
  • The size of these blocks is usually not particularly large, usually 256 * 256 or 512 * 512. This will greatly speed up the first screen of the page.

First screen rendering acceleration can be interpreted as:

Since the data of the following image blocks (non-image blocks in the viewport) needs to enter the GPU memory, it takes a long time to upload the browser memory to the GPU memory, even if part of the image blocks are drawn. Aiming at this problem, Chrome has adopted a strategy: in the first composite block using a low resolution images, so that the first screen to display the time just show low resolution images, this time to continue synthesis operation, when the normal block content mapping to end, will replace the current low resolution image block. This is also a way for Chrome to optimize the first screen loading speed.

rasterizer

Following the above steps, once the blocks are in place, the compositing thread will prioritize bitmap generation based on the blocks near the viewport. The actual bitmap generation is performed by rasterization. Rasterization refers to the transformation of a map block into a bitmap.

  • The graph block is the smallest unit of rasterization execution
  • One is maintained in the render processRasterize thread poolsIn charge ofThe mapconvertThe bitmap data
  • The composite thread will select the one near the viewportFigure block (tile)Give it to meRasterize thread poolsGenerate a bitmap
  • The bitmap generation process is actually accelerated using the GPU, and the resulting bitmap is finally sent toSynthesis of the thread

The operating mode is 👇

Generally, GPU is used to accelerate the generation of bitmaps during rasterization. The process of using GPU to generate bitmaps is called fast rasterization, or GPU rasterization. The generated bitmaps are stored in GPU memory.

As you may recall, GPU operations are run in the GPU process, and if rasterization operations use the GPU, then the final bitmap generation is done in the GPU, which involves cross-process operations. You can refer to the picture below for the specific form:

As can be seen from the figure, the rendering process sends the instruction of generating map blocks to GPU, and then executes the bitmap of generating map blocks in GPU, which is saved in GPU memory.

Composition and display

Once the rasterization operation is complete, the composite thread generates a draw command, called “DrawQuad”, and sends it to the browser process.

The viz component in the browser process receives this command, draws the page content into memory, generates the page, and then sends the memory to the graphics card, so you must be curious about how graphics cards work.

A blogger explained the principle of the display image:

Whether PC monitor or mobile phone screen, there is a fixed refresh frequency, generally 60 HZ, that is, 60 frames, that is, update 60 pictures a second, a picture stays about 16.7ms. Each update comes from the graphics card’s front buffer. The graphics card receives the browser process from the page, will synthesize the corresponding image, and the image saved to the back buffer, and then the system will automatically swap the front buffer and the back buffer, so the cycle update.

At this time, there is a bit of a concept in mind, such as a large amount of memory occupied by an animation, when the browser generated images will be slow, image transmission to the graphics card will not be timely, and the display or constant frequency refresh, so there will be stuck, that is, the obvious phenomenon of frame drop.


Sum up 👇 with a picture

Let’s put the entire rendering line above, with a picture more intuitive representation 👇

Reflow – redraw – Synthesis

There are three ways to update a view

  • backflow
  • redraw
  • synthetic

backflow

Also known as rearrangement, backflow is triggered when a change in the DOM structure causes a change in the DOM geometry.

Specifically, the following actions trigger backflow:

  1. The geometry of a DOM element changes. Common geometry properties arewidth,height,padding,margin,left,top,borderWait, that’s easy to understand.
  2. Make the DOM node happenIncrease or decreaseormobile.
  3. Read and writeoffsetThe family,scrollandclientIn order to retrieve these values, the browser needs to perform a backflow operation.
  4. callwindow.getComputedStyleMethods.

Some common properties and methods that cause backflow:

  • clientWidth,clientHeight,clientTop,clientLeft
  • offsetWidth,offsetHeight,offsetTop,offsetLeft
  • scrollWidth,scrollHeight,scrollTop,scrollLeft
  • scrollIntoView(),scrollIntoViewIfNeeded()
  • getComputedStyle()
  • getBoundingClientRect()
  • scrollTo()

Following the rendering pipeline above, when backflow is triggered, if the DOM structure changes, the DOM tree is re-rendered and the rest of the process (including tasks outside the main thread) is completed.

redraw

When a change in the style of an element in a page does not affect its position in the document flow (e.g., color, background-color, visibility, etc.), the browser assigns the new style to the element and redraws it, a process called redraw.

Based on the concept, we know that since there is no change in the DOM geometry, the element position information does not need to be updated, thus eliminating the layout process as follows:

Skipped the layout tree and build layer tree, directly to draw the list, and then to block, generate a bitmap and a series of operations.

As you can see, redrawing does not necessarily cause backflow, but backflow must have redrawn.

synthetic

In another case, if you change a property that neither lays nor draws, the rendering engine skips layout and drawing and directly performs subsequent compositing operations, a process called compositing.

For example, using CSS’s Transform to animate effects avoids backflow and redraw, and executes compositing animations directly in a non-main thread. Obviously, this method is more efficient. After all, this method is composed on the non-main thread and does not occupy the main thread resources. In addition, it avoids the two sub-stages of layout and drawing, so compared with redrawing and rearrangement, composition can greatly improve the drawing efficiency.

Take advantage of this:

  • The bitmap of the composite layer will be synthesized by the GPU faster than the CPU
  • When repaint is required, only repaint itself is required and no other layers are affected
  • Layout and Paint are not triggered for Transform and opacity effects

The best way to improve the composition layer is to use the WILL-change property of CSS

GPU acceleration Causes

For example, CSS3’s transform, opacity and filter properties can be used to achieve the synthetic effect, which is commonly referred to as GPU acceleration.

  • In the case of composition, skip the layout and drawing process and enterThe main threadThe processing part, that is, directly toSynthesis of the threadTo deal with.
  • Give full play toGPUAdvantage, the thread pool is called and used by the synthetic thread during bitmap generationGPUAnd gpus are good at processing bitmap data.
  • There are no resources tied up in the main thread, and even if the main thread is stuck, the effect is still smooth.

Practical significance

  • usecreateDocumentFragmentPerform batch DOM operations
  • For resize, scroll, etc., perform anti-shake/throttling.
  • Animations are implemented using transform or opacity
  • Set will-change of the element to opacity, transform, top, left, bottom, and right. In this way, the rendering engine will implement a separate layer for it, and when these transformations occur, it will only use the composition thread to process them without involving the main thread, greatly improving the rendering efficiency.
  • For browsers that do not support the will-change attribute, use a 3D Transform attribute to enforce promotion to compositiontransform: translateZ(0);
  • RAF optimization and so on

reference

You don’t know the Web Workers (on) [7.8 K words | multiple warning]

Geek Time – Rendering process

From browser multi process to JS single thread, JS running mechanism is the most comprehensive combing

How Browsers Work: Behind the scenes of modern web browsers

The most complete ever! Illustrate how a browser works

The W3C HTML 5 standard

Summary of browser rendering process &Composite

Browser layer composition and page rendering optimization

Reflow & Repaint for browsers

Wireless performance optimization: Composite

CSS GPU Animation: Doing It Right

This article is formatted using MDNICE