Performance proves that rendering a web page is a macro task

Rendering web pages is a macro task. That’s the conclusion I came to.

Don’t push back. I’ll give you proof later.

Let’s talk about debugging first:

Debugging is to obtain various data at a certain time or period of time during the running process through tools, helping developers to clarify logic, analyze performance, troubleshoot problems, and so on. The various running environments of JS will provide the debugger, in addition, we will also do some buried points to report to do debugging and statistics.

The most common debugging tool we use is THE JS Debugger, which supports breakpoints that can be broken at one point to see variables in the current context, call stack, etc. This is very helpful for clarifying logic.

However, debugging tools for performance analysis cannot do this. They cannot be viewed in real time by stopping, because the authenticity of the data will be affected. The Performance tool in Chrome Devtools is used to record data for a period of time and perform statistics and analysis afterwards. (Even run the page in traceless mode to avoid browser plugins)

Click the Record button to start recording (if you want to record data from the start of the page load, click the Reload button), and Performance records all aspects of the recording time.

What are the numbers?

The operation of a Web page has multiple threads. The main thread is responsible for constantly executing JS and rendering through the Event Loop. There are also some other threads, such as the thread for synthesizing rendering layers, the thread of Web Worker, etc., where every frame rendered will be drawn on the interface.

The web page works like this, and the data recorded are all like this:

Performance records the data of each thread of the web page, among which the most important is the Main thread, namely Main in the figure, which records the execution process of Event Loop, the call stack executed by JS and the page rendering process.

See the little gray blocks in the picture? They are tasks, which are macro tasks. An Event Loop is a Loop that executes a macro task. Each Task has its own call stack, and you can see the execution path of the function, time and other information. In the figure, the width represents the time consuming, and the performance can be analyzed intuitively by the width of the block.

After executing the macro task, all the microtasks will be executed, which can be clearly seen in the figure:

Click on each block to see the location of the code, you can locate the corresponding code, so that you can analyze which piece of code is not performing well.

This is the execution logic of the Main thread, which uses the Event Loop to continuously execute JS and render.

Of course, there are other threads, such as the raster thread, which is responsible for combining the rendered layers into a single frame:

In short, just as there is no secret about the execution of JS in front of the Debugger, there is no secret about the execution of web threads in front of Performance.

This is just to make it clear what the debugger and Performance do and what information it records.

We want to know if rendering is a macro task, which can be easily analyzed by Performance.

Let’s continue with the Event Loop execution for the Main thread:

You’ll see a little gray block that will be executed every once in a while. Click on it and you’ll see that what it does is actually render, including calculating the layout, updating the render tree, merging layers, rendering, etc.

What does that mean? It means rendering is a macro task.

So, we conclude that rendering is a macro task, which is rendered a frame by Event Loop.

Using the Performance debugging tool, we can see the details of the Main thread Event Loop and see the detailed process of JS execution and rendering.

Sometimes you might see parts of a Task marked in red with a warning that this is a Long Task.

Because rendering and JS execution are done in the same Event Loop, if there is a Task that takes too long to execute, it will naturally lead to rendering delay, that is, frame drop, and the user will feel that the page is stuck.

Avoid Long Task, which is a key aspect of web performance optimization. This is why React uses Fiber to render the whole tree recursively instead of creating Long tasks.

conclusion

The purpose of this article is to prove that rendering is not a macro task, but more importantly to clarify the significance of debugging tools.

Debugging tools can analyze various aspects of data during a certain moment or period of time in the running process of the program. There are two ways: one is the way of the breakpoint of the Debugger, you can see the value of context variables and call stack, which can help clarify logic and locate problems. Performance analysis tools are another way to record data during a period of time for later analysis and statistics to ensure data authenticity.

Performance, a Performance analysis tool for web pages, can record the execution of various threads in the execution process of web pages, mainly the execution process of the Event Loop of the main thread, including JS execution and rendering.

With Performance, it’s easy to conclude that rendering is a macro task.

Just like in front of the Debugger, JS execution process has no secrets. In the face of Performance, there is no secret about how web pages are executed.