If the Virtual DOM explains what React compares between renders, Fiber explains how React performs that work. Fiber is the internal architecture React uses to represent component work, prioritize updates, interrupt rendering, and commit changes in a controlled way.
That matters because modern React is not just a renderer that runs top to bottom until it finishes. It needs to respond to input quickly, coordinate updates with different priorities, and avoid blocking the main thread longer than necessary. Fiber is the mechanism that makes that possible.
What Fiber actually is
At a high level, a fiber is a unit of work that corresponds to a component instance or host node in the React tree. Instead of treating reconciliation as one monolithic recursive pass, React can model the tree as linked work units.
That lets React pause work, resume it, throw away outdated work, and restart with newer state when needed.
Why React needed Fiber
Before Fiber, React reconciliation was more synchronous and harder to interrupt. That was acceptable for many apps, but as trees became larger and interactions more demanding, React needed a way to schedule rendering more intelligently.
The goal was not just raw speed. The goal was control over rendering work.
A useful mental model
You can think about Fiber as splitting render work into smaller tasks instead of forcing the runtime to finish the whole tree in one unbroken pass.
function SearchPage({ query, results }) {
return (
<>
<SearchInput value={query} />
<ResultsList items={results} />
</>
);
}
If the results list is large, React may need to do meaningful work to reconcile it. Fiber gives React a structure for prioritizing urgent updates, such as keeping typing responsive, while handling heavier rendering work more carefully.
Render phase vs commit phase
1 Render phase
React computes what should change, builds the next tree, and decides what work is ready to commit.
2 Commit phase
React applies the prepared changes to the real DOM synchronously so the UI stays consistent.
3 Scheduling happens before commit
Fiber gives React flexibility during rendering, but committed DOM updates still need a reliable final step.
Why interruption matters
If React had to finish every render in one uninterrupted pass, expensive trees could make the UI feel unresponsive. Fiber allows React to treat rendering as schedulable work. That means React can pause lower-priority work and let more urgent updates move first.
startTransition(() => {
setResults(expensiveSearch(input));
});
In this example, the transition marks part of the update as lower priority. Fiber is part of the internal machinery that lets React coordinate this distinction.
Priority and lanes
Modern React associates updates with priority levels, often discussed in terms of lanes. You do not manipulate Fiber nodes directly in application code, but you do interact with APIs that depend on the scheduler understanding which work matters most right now.
function SearchBox() {
const [input, setInput] = useState('');
const [query, setQuery] = useState('');
function handleChange(event) {
const nextValue = event.target.value;
setInput(nextValue);
startTransition(() => {
setQuery(nextValue);
});
}
return <input value={input} onChange={handleChange} />;
}
The typing update should feel immediate. The query-driven rendering work can be treated as less urgent.
Double buffering and work-in-progress trees
Another important Fiber concept is that React maintains a current tree and can build a work-in-progress tree for the next render. That gives React a safe place to calculate the next UI state before touching the real DOM.
If the work becomes stale because newer updates arrive, React can abandon it and build a fresher version. This is one reason React can stay declarative without forcing every partial computation directly into the browser DOM.
What Fiber improves in practice
What Fiber does not do
Fiber is not a magic fix for poor component design.
function SlowPanel({ items }) {
const sorted = [...items].sort((a, b) => a.score - b.score);
return sorted.map((item) => <div key={item.id}>{item.label}</div>);
}
If this component performs expensive work on every render, Fiber does not remove that cost. It gives React more control over scheduling, but it does not make wasteful renders free.
Likewise, once React reaches the commit phase, DOM mutations still have to happen consistently. Fiber improves coordination around rendering work, not the fundamental cost of every possible update.
Bottom line
Fiber is React's internal reconciliation engine and scheduling architecture. It breaks rendering into units of work, lets React prioritize updates, and supports modern features that depend on non-blocking rendering behavior.
It matters because React performance is not only about diffing trees. It is also about deciding when work should run and how much of it should block the user.