Log yielded time in the Component Track #31563
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Comparing: 6177b18...0d4052a Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: Expand to show
|
|
I kind of want a different color for this but I'm using secondary (purple) to mean commit phase and the component track also has commit phase. I use warning (yellow) to mean event and that should ideally stick how so you can easily find real interactions. I want to use ternary (green) to mean Hydrated. |
| if (yieldDuration < 1) { | ||
| // Skip sub-millisecond yields. This happens all the time and is not interesting. | ||
| return; | ||
| } |
There was a problem hiding this comment.
Do these become >=1ms when CPU throttling is turned on?
There was a problem hiding this comment.
Maybe for the really slow ones. Depends on the overhead of yielding on the platform I guess.
| yieldDuration < 5 | ||
| ? 'primary-light' | ||
| : yieldDuration < 10 | ||
| ? 'primary' | ||
| : yieldDuration < 100 |
There was a problem hiding this comment.
How do we decide the numeric value of these thresholds?
There was a problem hiding this comment.
Originally the render time ones are <1, <10, <100, and above.
This comes from that a typical component should really be less then 1ms. If it's less than 10 you can still comfortably fit the rendering within a frame with some additional overhead but that's still very high for a single component. You can do a lot in 10ms. That still lets you do JS based animations.
Above that you're starting to be unable to do JS animations without dropping frames. Approaching error territory but ideally an event should respond in about 50ms. If on average your click hits in the middle of 100ms, and we yield 50ms after that. Assuming the response renders fast after that, you're still within the range of feeling responsive so it's ok. But that's the very top end.
Above 100ms you're really in error territory. You can no longer be responsive to new input.
The effect ones are more permissive because they are expected to kind of happen in the seams like when you commit a brand new page rather than in the background or continuously. E.g. the animation probably just finished and is about to restart. However, we probably should maybe lower this for Blocking lane because a long commit in blocking lane is also not good because it's likely to maybe happen more repeatedly.
For yields I'm trying to mirror the time coloring of component render. In that case it's something else blocking us so whatever that is has the same constraints as we do. However, it's more likely to have small little 1-5ms yields due to some little timer or something yielding that I increased the minimum number a little bit.
f0799b3
to
112f44b
Compare
Stacked on #31552. Must be tested with
enableSiblingPrerenderingoff since theuse()optimization is not on there yet.This adds a span to the Components track when we yield in the middle of the event loop. In this scenario, the "Render" span continues through out the Scheduler track. So you can see that the Component itself might not take a long time but yielding inside of it might.
This lets you see if something was blocking the React render loop while yielding. If we're blocked 1ms or longer we log that as "Blocked".
If we're yielding due to suspending in the middle of the work loop we log this as "Suspended".
If the render doesn't commit because it restarts due to some other prewarming or because some non-
use()suspends, it doesn't have from context components.The
useActionStatepath doesn't work yet because theuse()optimization doesn't work there for some reason. But the idea is that it should mark the time that the component is blocked as Action instead of Suspended.