Time Slicing
Slap yourself if
You think time slicing is just 'splitting work' or the same thing as code splitting.
Why this exists
Time slicing exists to prevent long rendering work from blocking the main thread by breaking rendering into small chunks that can yield to more urgent tasks (like user input), keeping the UI responsive.
Mental model
Time slicing turns rendering into interruptible chunks. React does a bit of rendering work, then yields control back to the browser so it can process input, paint, and run other high-priority tasks. React then resumes rendering later.
- A large update is scheduled and React begins rendering.
- React performs rendering work in small units (chunks).
- After a time budget is used, React yields back to the browser.
- The browser can handle user input, run pending tasks, and paint.
- React resumes where it left off until it’s ready to commit.
- Assuming time slicing reduces total work (it mostly changes *when* work happens).
- Janky UI if heavy synchronous work still happens outside React (e.g., layout thrashing).
- Inconsistent app logic if render has side effects (because render can be paused/restarted).
- Priority inversion when low-priority work blocks urgent updates indirectly (locks, shared resources).
- Starvation of background rendering if urgent updates keep arriving.
Time slicing is React’s approach to breaking rendering work into small chunks and yielding to the browser between chunks so the main thread stays responsive to input and painting.
- Time slicing is code splitting.
- Time slicing means React renders in parallel threads.
- Time slicing always makes rendering faster.
Deep dive
Premium deep dives include more internals, more scars.
How time slicing is implemented (units of work + yielding)
- Units of work and incremental Fiber traversal
- Deadlines / budgets and yielding
- Render vs commit: yielding happens in render, not commit
Starvation, priority inversion, and responsiveness traps
Time slicing improves responsiveness until your app creates a pattern that prevents background work from ever finishing.
What time slicing improves (and what it cannot)
- Protects INP by yielding to input and paint
- Does not fix slow layouts or heavy commits
How time slicing exposes 'render is pure' violations
If render has side effects, time slicing makes your bugs deterministic.
Tradeoffs: time slicing vs batching vs 'just optimize'
Time slicing is a scheduling tool, not a performance substitute.
Related terms
Concurrent Rendering
You think concurrent rendering means React renders in parallel threads or it always makes apps faster.
Scheduler priorities
You think priorities are just performance hints and not correctness boundaries.
Task starvation
You think starvation only happens with infinite loops or that yielding 'sometimes' is enough.
Event loop (macro vs microtasks)
You think microtasks are just 'faster callbacks' or believe the event loop runs one task per tick.
Fiber Architecture
You think Fiber is just a rewrite of the Virtual DOM or that it exists only to make React faster.
Reconciliation Algorithm
You think reconciliation is just 'diffing the Virtual DOM' or that React compares trees node-by-node exhaustively.
Long Tasks API
You think a long task just means ‘some slow JavaScript’ and not a UI starvation event.