What is the principle of passive? what's the effect?

What this article brings to you is about the principle of passive? what's the effect? It has certain reference value. Friends in need can refer to it. I hope it will be helpful to you.

What is the use of passive?

passived is mainly used to optimize the performance of browser page scrolling and make page scrolling smoother~~

passived generated historical timeline

addEventListener(): As everyone knows, add a trigger event to the dom, and the story starts here.
In the early days, addEventListener was like this:

addEventListener(type, listener, useCapture)

useCapture: Whether to allow event capture, but true is rarely passed, and then it becomes optional:

addEventListener(type, listener[, useCapture ])

It has changed now It looks like this:

addEventListener(type, listener, {
    capture: false, //捕获
    passive: false, 
    once: false    //只触发一次
})

Our protagonist passive appears

Why can passive optimize the scrolling performance of the page?

Brief description of chrome's threaded rendering framework

The two threads of chrome's threaded rendering framework:

• Kernel thread (Main /Render Thread): Responsible for DOM tree construction, element layout, layer drawing record part (main-thread side), and JavaScript execution

• Compositor Thread (Compositor Thread): Layer Drawing implementation part (impl-side), layer image synthesis

As can be seen from the figure, after page Frame#1 completes js execution, layout and drawing in the kernel thread, it goes through a cycle of synthesis threads to perform the synthesis of the Frame#1 page image.

User input event classification:

• Events processed by the kernel thread

• Events processed directly by the synthesis thread

So what’s the difference?

Events processed in the kernel thread: Input events that need to be processed by the kernel thread must execute logic in the kernel thread. If the kernel thread is busy, it cannot respond immediately. For example, most of the user's input events are related to page elements. Once the page element registers a listener for the corresponding event, the logic code (JavaScript) of the listener must be executed in the kernel thread (the V8 engine runs in the kernel thread), so this Such input events often do not receive an immediate response.
Events processed directly by the composition thread: Input events that can be processed quickly without going through the kernel thread are gesture input events (swipe, pinch).

Key point: Here comes the most annoying thing. Although gesture events can not be processed in the kernel thread, the generation of gesture events is still inseparable from the kernel thread.

The reason why the page is stuck

The gesture event has an attribute cancelable, its function is to tell the browser whether the event allows the listener to pass preventDefault() Method blocking, defaults to true. If preventDefault() is called inside the touch event, the default behavior of the event is canceled and the page becomes stationary. However, the browser does not know whether preventDefault() is called internally in the touch event. The browser can only know whether the preventDefault function will be called internally to prevent the default behavior of the event until the kernel thread executes the JavaScript code corresponding to the event listener. Therefore, browsing The server itself cannot optimize this scenario. Gesture input events are composed of continuous ordinary input events. In this scenario, they cannot be generated quickly, which will cause the page to be unable to quickly execute the sliding logic, causing the user to feel that the page is stuck.

The Chrome team analyzed from statistical data that 80% of pages that have registered mousewheel/touch related event listeners do not call the preventDefault function internally to prevent the default behavior of the event. For these 80% of pages, even if nothing is done inside the listener, compared to pages that have not registered mousewheel/touch event listeners, 10% of the pages will have a delay of at least 100ms in terms of sliding smoothness, and 1% of the pages will even Add more than 500ms delay. The Chrome team believes that for 80% of the pages in the statistics, they do not want to increase the sliding delay due to registering mousewheel/touch related event listeners.

The birth of passive

So, the passive listener was born. Passive means "obedient", which means that it will not say no to the default behavior of the event. Once the browser knows that a listener is passive, it can execute the JavaScript code in the listener and the browser's default behavior in two threads at the same time.

After the above analysis, we learned that Passive Event The Listeners feature is actually designed to solve the problem of browser page sliding smoothness. It allows web developers to tell the browser whether the listener will block the default behavior of the event by extending the event attribute passive, so that the browser can make smarter decisions. And optimization, which involves Chrome's multi-threaded rendering framework, input event processing and other knowledge.

The above is the detailed content of What is the principle of passive? what's the effect?. For more information, please follow other related articles on the PHP Chinese website!