when a React application logic becomes complex, the time taken by the component render increases significantly. If it takes too long to render from the component render to the view, the user will feel the page stutter. there are two ways to solve this problem: change the process of the component render from synchronous to asynchronous, so that the render process page does not get stuck. This is the principle of concurrent updates reduce the number of components requiring render , which is often referred to as React performance optimization usually, we take the above different approach for different types of components. For example, for input boxes with time-consuming logic such as the following, method 1 is more appropriate (because concurrent updates reduce stutters at input): function ExpensiveInput({onChange, value}) { // time-consuming operation const cur = performance.now(); while (performance.now() - cur < 20) {} return <input onChange={onChange} value={value}/>; } so, can you take into account both of these two ways at the whole application level? The answer is-- not really. this is because, for complex applications, concurrent updates are often contrary to performance optimization. That's what this article is about-the concurrency paradox. start with performance optimization for a component, if you want it not to be render , the basic condition that needs to be achieved is that the reference of props remains unchanged. for example, in the following code, Child components depend on fn props . Because fn is inline, references change every time App > component render , which is not conducive to Child performance optimization: function App()…