How browser rendering work affects Interaction to Next Paint
Trace DOM, style, layout, paint, and compositing work to see how each part can delay the next frame measured by INP.
The whole story in 6 lines
INP grows whenever main-thread or rendering work postpones the first frame that acknowledges an interaction.
- HTML and CSS become separate structures that meet only when the browser calculates styles.
- A mutation creates style work according to the dirty region, not merely the size of the changed line of code.
- Layout cost spreads when changed geometry forces neighboring or descendant boxes to move.
- Size, color, and compositor-friendly transforms travel through different portions of the pixel pipeline.
- INP joins input delay, event processing, and the wait until the next painted frame.
- Moving noncritical work after interaction feedback can improve INP without deleting that work.
Setup
A browser turns source code into a visible response, so we will first meet the structures and timing words used along that path.
DOM and CSSOM are organized views of the page structure and its style rules, which gives later work something precise to examine.
Style, layout, paint, and composite progressively decide appearance, geometry, pixels, and layer order before a frame reaches the screen.
The journey rail connects those terms into six questions, ending with the complete INP clock and a scheduling change that paints sooner.
Each color and shape will keep the same meaning throughout the lesson. Now let us start with how HTML and CSS become source trees.
Source trees
The lesson begins with two source streams. HTML describes page relationships, while CSS lists rules that can affect those elements. Neither stream alone contains every decision needed to render the complete page.
The HTML stream becomes ordered tokens. The browser can distinguish each opening element from the children nested inside it.
Those tokens attach as DOM branches. This structure preserves parent and child relationships instead of keeping one flat source list.
CSS rules collect separately in source order. Their selectors and declarations form the CSSOM that the style engine can search.
The DOM now has hierarchy and the CSSOM has rules. What combines them into the appearance assigned to each element?
Both structures finish side by side. The style engine can now match rules against elements and produce computed appearance values.
Source parsing leaves structured inputs rather than pixels. Next, one interaction will invalidate part of that computed style result.
Style scope
Now that both source trees exist, the Buy click changes one DOM node. The engine asks which computed styles may be stale.
The changed button starts a dirty frontier. Every affected DOM node joins the style recalculation queue before rendering can continue.
A local mutation dirties the button and its child. A broader ancestor mutation also exposes neighboring descendants and additional matching rules.
The browser has identified the dirty nodes and matching rules. What result must exist before geometry can be calculated?
Computed-style swatches now appear for every dirty node. Their count exposes the real consequence of the selected invalidation scope. One small source edit can therefore create much larger downstream work.
Try every Mutation option and compare the recalculated node and rule counts. Notice how ancestor scope expands the downstream workload.
Style work converts an invalidated region into updated appearance values. Next, geometry reveals how far one size change can propagate.
Layout spread
The computed styles from the last stage now describe boxes. Layout must turn those values into actual positions and sizes.
The original wireframe gives every box a stable place. That baseline lets us compare the changed geometry using identical shapes.
The hero box grows wider, so boxes depending on its available space must be measured and positioned again.
The hero changed size inside one component. Which other boxes must move when geometry dependencies stay locally contained?
The second wireframe shifts each dependent box. The moved-box count makes the selected propagation scope concrete. A wider dependency chain therefore costs more than the changed box alone across the page.
Try every Layout scope option and compare the moved-box count. Follow the dependency from component-local work to page-wide propagation.
Layout cost follows geometry dependencies rather than element count alone. Next, those boxes must become painted pixels and composed layers.
Pixel paths
Layout has produced stable boxes, but a later visual update does not always need every rendering stage again.
A size change runs style, layout, paint, and composite. Its geometry and its painted pixels both become stale.
A color change preserves geometry, so the browser can skip layout while still painting new pixels before compositing.
An element already has a compositor-friendly layer. Which expensive stages can its transform avoid before the next frame?
The transform path jumps from style to composite. Its consequence readout names exactly which expensive stages were avoided. Skipping either stage reduces the main-thread work that must finish before the browser can compose the next updated frame.
Try every Change option and compare the required pipeline work. Trace why size, color, and a layered transform take different paths.
Avoided rendering work leaves more room before the next frame. Next, we place every remaining interval on the INP clock.
INP clock
The pixel paths now join one interaction clock. It begins when the user clicks and ends when the updated frame appears.
Input delay grows while earlier main-thread work blocks the event. Queued work therefore lengthens the first measured segment.
Processing duration contains the event callbacks. More handler work lengthens the middle segment without changing the meaning of rendering.
The callback has returned, but rendering still separates the user from visible feedback. Which INP interval contains that post-callback work?
Presentation delay reaches the next painted frame. All three computed segments now join into the complete INP total and rating. The threshold shows whether their combined work remains inside the good responsiveness range.
Try every Main thread and Handler combination. Compare how each combination changes the complete INP.
INP measures the complete wait to visible feedback rather than JavaScript alone. Next, we keep the work but move some beyond first paint.
Paint sooner
★ If you remember one thing · The same work can show feedback sooner when noncritical tasks move after the first paint.
We now know the full INP clock. The final stage compares two schedules containing the same critical and noncritical tasks.
The upper schedule runs everything before rendering. Its first-paint marker therefore waits beyond every noncritical task chip.
The lower schedule keeps only the visible update before rendering. Noncritical tasks remain present, but they run after feedback.
Both schedules contain exactly the same work. Can changing only its order make the interface acknowledge the click sooner?
The yielded paint marker lands earlier while deferred tasks remain after it. The readout quantifies how much waiting moved beyond feedback. Total work stays equal because every deferred task still executes after that final marker.
Try every Workload option and compare the time saved before paint. Find the workload that satisfies the deferral challenge.
Early feedback improves responsiveness because INP stops at the first updated frame. Now we can reconnect the complete rendering journey.
Recap
We started with source trees, where HTML hierarchy and CSS rule order became the two inputs needed for style calculation.
Then a DOM mutation exposed its dirty region, which determined how many nodes needed fresh computed styles.
Layout turned those styles into geometry, and the paired wireframes showed how dependency scope controls the number of moved boxes.
The pixel paths showed that size, color, and compositor-friendly transforms do not ask the browser to repeat identical work.
The INP clock joined input delay, callback processing, and presentation delay into the complete wait for visible feedback.
Finally, equal task chips proved that moving noncritical work after the first paint can shorten the wait without deleting work.
All six spokes now converge on the same lesson: responsiveness improves whenever less work stands before the next frame the user can see.
The whole story in 6 lines
INP grows whenever main-thread or rendering work postpones the first frame that acknowledges an interaction.
- HTML and CSS become separate structures that meet only when the browser calculates styles.
- A mutation creates style work according to the dirty region, not merely the size of the changed line of code.
- Layout cost spreads when changed geometry forces neighboring or descendant boxes to move.
- Size, color, and compositor-friendly transforms travel through different portions of the pixel pipeline.
- INP joins input delay, event processing, and the wait until the next painted frame.
- Moving noncritical work after interaction feedback can improve INP without deleting that work.