This is the third day of my participation in the August More text Challenge. For details, see: August More Text Challenge

preface

An article on the opening | about the exploration of front end performance optimization, performance optimization need around the process of network request and the browser rendering mechanism to expand. However, the rendering process mentioned here is only part of critical path rendering, and it is not clear why backflow and redraw, UI rendering and THE JS engine are mutually exclusive. To better understand this, let’s take a closer look at how browsers work.

Processes and Threads

• A process is an instance of a program running, is a container of threads, the operating system will allocate independent memory for the process (processes are independent of each other);
• Threads are part of a process and share the resources allocated by the process (including code snippet, data set, heap, etc.).
• A program has at least one process, and a process has at least one thread (a main thread and several child threads);
• Process is the smallest unit of resource allocation, thread is the smallest unit of program execution;
• If a thread fails to execute, the entire process crashes

Windows Task Manager to view background processes:

Multiprocess browser

Essentially, the browser is also a program, so the unit of operation of the browser is the process. Before Google released Its Chrome multi-process browser in 2008, almost all browsers on the market were single-process, which was gradually optimized due to obvious pitfalls such as smoothness, security and stability. Currently, the browsers we use are multi-process browsers.

Browser process

Browser processes mainly have the following types:

Open the Chrome Task Manager (Shift+Esc) to view the current browser process

Multi-process advantages of browsers

• The running resources allocated between processes are relatively independent, so even if one process crashes unexpectedly, the entire browser will not be affected
• Multi-process makes full use of multi-nuclear advantages
• Easy to use sandbox model to isolate processes such as plug-ins, improving browser stability

The rendering process is multi-threaded

The rendering process is the part most closely related to page rendering and performance optimization. This process is multi-threaded, it mainly has GUI render thread, JS engine thread, event triggered thread, timer triggered thread and asynchronous HTTP request thread.

Here are the highlights of these threads:

GUI rendering thread

• Responsible for rendering the browser interface, parsing HTML, CSS, building DOM and RenderObject trees, layout and rendering, etc.
• This thread executes when the interface needs to be repainted or when some operation causes reflow
• Note that the GUI rendering thread is mutually exclusive with the JS engine thread, the GUI thread is suspended while the JS engine is executing, and GUI updates are stored in a queue until the JS engine is idle and executed immediately.

JS engine thread

• Also known as the JS kernel, it handles Javascript scripts. (e.g. V8 engine)
• The JS engine thread is responsible for parsing the Javascript script and running the code.
• The JS engine waits for a task to arrive in the task queue and then processes it. There is only one JS thread running the JS program in the renderer at any given time.
• Also note that the GUI rendering thread and THE JS engine thread are mutually exclusive, so if the JS execution takes too long, the rendering of the page will be incoherent and the page rendering load will be blocked.

Event-triggered thread

• Used to control the event loop (which can be interpreted as assisting the JS engine thread)
• When the JS engine executes a code block such as setTimeOut (or a task from another thread from the browser kernel, such as a mouse click, an AJAX asynchronous request, etc.), the corresponding task is added to the event thread
• When the corresponding event is triggered according to the triggering condition, the thread will add the event to the end of the queue to be processed, waiting for the JS engine to process
• Note that due to the single-threaded nature of JS, the events in the queue are queued for the JS engine to process (only when the JS engine is idle).

Timed trigger thread

• The legendarysetIntervalwithsetTimeoutThe thread
• The browser timing counter is not counted by the JavaScript engine (because the JavaScript engine is single-threaded, if you are in a blocked thread state, it will affect the accuracy of the timing)
• Therefore, the timer is timed and triggered by a separate thread (after the timer is finished, it is added to the event queue, waiting for the JS engine to idle).
• Note that the W3C states in the HTML standard that any interval of less than 4ms in setTimeout is required to count as 4ms.

Asynchronous HTTP request threads

• After the XMLHttpRequest is connected, it opens a new thread request through the browser
• When a state change is detected and a callback function is set, the asynchronous thread generates a state change event and places the callback in the event queue. This is then executed by the JavaScript engine.

summary

Multithreaded with JS event loop

With the above cognitive basis, let’s review the event loop mechanism of JS combined with threads. Here I draw a diagram according to my own understanding:

• The execution stack is generated when the main thread runs
• When code in the stack calls certain apis, it triggers either an asynchronous HTTP request thread or a timed trigger thread, and the callback that completes their execution is handed over to the event trigger thread
• The event-triggering thread manages an event queue
• After the code in the execution stack completes execution, it reads the events in the event queue for execution
• In order to enable JS internal tasks and DOM tasks to be executed in an orderly manner, the browser will re-render the page after completing a task and before the next task starts (that is, to the GUI rendering process). Again, the JS engine thread and UI thread are mutually exclusive and alternate.

Multithreading and page rendering processes

Now that you understand how a multi-threaded browser works, take a look at the process from sending a request to rendering a page. Well, it’s starting to string together

• The Browser main process receives the user request
• Inform the network process to get the page content (make a network request to get the page resource)
  • The DNS
  • Establishing a TCP Connection
  • Making an HTTP request
  • HTTP response, returning data
• After the data is successfully obtained, it is delivered to the Render process.
• Render process work (page rendering)
  • Parse HTML CSS and build Render tree
  • Calculate the layout, draw
  • If you encounter a JS script, the rendering process hangs and the JS engine process works (processes are mutually exclusive).
  • If resources need to be obtained, network processes help to obtain resources (process synchronization)
  • If 3D drawing is required, THE GPU process helps to draw (process synchronization)
  • If backflow/redraw occurs, the Render process adjusts the Render tree, recalculates and draws
  • Render the complete
• GPU composite layer, display to the screen

According to their own understanding of the drawing, I do not know the accurate expression, if there are flaws, please give advice ~

Refer to the link

From browser multi-process to JS single thread, the most comprehensive comb of JS running mechanism (very good, said very detailed) the most complete! Talk a little bit about JavaScript and browsers – engines and threads