Understanding Browser Rendering, Event Loop, and Techniques to Avoid Page Jank When Adding Massive DOM Elements

Preface

This article dives from surface symptoms to the underlying browser principles, dissecting why a page becomes unresponsive when a button creates a huge number of elements. It is a self‑written 6000‑word tutorial with original text and illustrations, and the author welcomes corrections.

1.1 Conclusion

When a massive number of elements are synchronously added, the JavaScript code injects too many nodes at once, causing the next frame’s rendering task to be unable to compute all layouts and styles in time, blocking the main thread and preventing other tasks from executing.

1.2 Event Loop and Page Rendering

1.2.1 JavaScript’s Single‑Threaded Nature

Only one task runs at a time; tasks are executed sequentially.

JS was designed as a browser scripting language for DOM interaction; multi‑threaded DOM manipulation would create conflicts, so JavaScript remains single‑threaded and relies on asynchronous mechanisms to handle long‑running operations.

1.2.2 Browser / Node.js Runtime

The browser is a multi‑process, multi‑threaded application. The main rendering process spawns a main thread that runs JS, parses HTML/CSS, computes styles, layouts, and paints at 60 fps. The rendering thread and JS engine thread are mutually exclusive.

1.2.3 Asynchronous Mechanism

JS separates tasks into synchronous (blocking) and asynchronous (off‑loaded) tasks. Asynchronous tasks are handled by Web APIs (e.g., DOM events, timers, network requests) and notify the main thread via callbacks or promises.

1.2.4 Macro‑tasks and Micro‑tasks

Micro‑tasks (e.g., Promise callbacks) have the highest priority and run immediately after the current macro‑task.

Macro‑tasks (e.g., setTimeout, I/O) are queued and processed in order.

After each macro‑task, the engine drains the micro‑task queue before proceeding.

1.2.5 Cooperation Between Event Loop and Rendering

Execute global JS code.

Push callbacks into the appropriate message queues.

Run all micro‑tasks.

Take the earliest macro‑task and execute it.

Check if 16 ms have passed or the page changed; if so, perform a render.

Repeat until queues are empty.

1.2.5 Summary

Creating too many elements in one go blocks the main thread, preventing timely rendering and causing page jank. The following solutions mitigate this issue.

2. Solutions

2.1 Solution 1: setTimeout (Macro‑task Chunking, Recommended)

Split the massive rendering task into small batches (e.g., 10 elements per batch) and schedule each batch with setTimeout . Use recursion to avoid queuing all callbacks at once, which would itself block the thread.

2.2 Solution 2: requestAnimationFrame (Render‑Phase Chunking, Recommended)

Similar to the first method, but uses requestAnimationFrame so each batch runs right before the browser’s next paint, guaranteeing synchronization with the 60 Hz refresh rate.

2.3 Other Solutions

2.3.1 MessageChannel (High‑Priority Macro‑task, Not Recommended)

Works like setTimeout but with higher priority, allowing more batches per frame, yet still risks overload.

2.3.2 requestIdleCallback (Idle‑time Processing, Not Recommended)

Executes callbacks after rendering when the main thread is idle; its execution depends on available idle time, making it less predictable.

References

Juejin articles: [3] , [4]