Log yielded time in the Component Track

[sebmarkbage]

Stacked on #31552. Must be tested with enableSiblingPrerendering off since the use() 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 useActionState path doesn't work yet because the use() 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.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 19, 2024 6:45pm

[react-sizebot]

Comparing: 6177b18c66c010d2b2f03202623a0533e7a89004...0d4052a432b7b8119b342811fd3062f9c6ac8855

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.68 kB	6.68 kB	=	1.83 kB	1.82 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	=	509.94 kB	509.94 kB	=	91.24 kB	91.24 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	=	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	=	514.88 kB	514.88 kB	=	91.95 kB	91.95 kB
facebook-www/ReactDOM-prod.classic.js	=	594.55 kB	594.55 kB	=	104.89 kB	104.90 kB
facebook-www/ReactDOM-prod.modern.js	=	584.81 kB	584.81 kB	=	103.32 kB	103.32 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-experimental/react-reconciler/cjs/react-reconciler.profiling.js	+0.32%	429.88 kB	431.28 kB	+0.23%	69.69 kB	69.85 kB
oss-experimental/react-reconciler/cjs/react-reconciler.development.js	+0.27%	662.37 kB	664.13 kB	+0.18%	105.97 kB	106.16 kB
oss-experimental/react-art/cjs/react-art.development.js	+0.25%	579.62 kB	581.08 kB	+0.18%	93.48 kB	93.64 kB
oss-experimental/react-dom/cjs/react-dom-profiling.profiling.js	+0.24%	557.25 kB	558.59 kB	+0.20%	98.94 kB	99.14 kB

Generated by 🚫 dangerJS against 112f44b

[sebmarkbage]

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.

[eps1lon]

Do these become >=1ms when CPU throttling is turned on?

[sebmarkbage]

Maybe for the really slow ones. Depends on the overhead of yielding on the platform I guess.

[eps1lon]

How do we decide the numeric value of these thresholds?

[sebmarkbage]

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.

[sebmarkbage]

Stacked on #31552. Must be tested with enableSiblingPrerendering off since the use() 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 useActionState path doesn't work yet because the use() 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.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 19, 2024 6:45pm

[react-sizebot]

Comparing: 6177b18c66c010d2b2f03202623a0533e7a89004...0d4052a432b7b8119b342811fd3062f9c6ac8855

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.68 kB	6.68 kB	=	1.83 kB	1.82 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	=	509.94 kB	509.94 kB	=	91.24 kB	91.24 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	=	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	=	514.88 kB	514.88 kB	=	91.95 kB	91.95 kB
facebook-www/ReactDOM-prod.classic.js	=	594.55 kB	594.55 kB	=	104.89 kB	104.90 kB
facebook-www/ReactDOM-prod.modern.js	=	584.81 kB	584.81 kB	=	103.32 kB	103.32 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-experimental/react-reconciler/cjs/react-reconciler.profiling.js	+0.32%	429.88 kB	431.28 kB	+0.23%	69.69 kB	69.85 kB
oss-experimental/react-reconciler/cjs/react-reconciler.development.js	+0.27%	662.37 kB	664.13 kB	+0.18%	105.97 kB	106.16 kB
oss-experimental/react-art/cjs/react-art.development.js	+0.25%	579.62 kB	581.08 kB	+0.18%	93.48 kB	93.64 kB
oss-experimental/react-dom/cjs/react-dom-profiling.profiling.js	+0.24%	557.25 kB	558.59 kB	+0.20%	98.94 kB	99.14 kB

Generated by 🚫 dangerJS against 112f44b

[sebmarkbage]

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.

[eps1lon]

Do these become >=1ms when CPU throttling is turned on?

[sebmarkbage]

Maybe for the really slow ones. Depends on the overhead of yielding on the platform I guess.

[eps1lon]

How do we decide the numeric value of these thresholds?

[sebmarkbage]

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.

[sebmarkbage]

Stacked on #31552. Must be tested with enableSiblingPrerendering off since the use() 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 useActionState path doesn't work yet because the use() 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.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 19, 2024 6:45pm

[react-sizebot]

Comparing: 6177b18c66c010d2b2f03202623a0533e7a89004...0d4052a432b7b8119b342811fd3062f9c6ac8855

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.68 kB	6.68 kB	=	1.83 kB	1.82 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	=	509.94 kB	509.94 kB	=	91.24 kB	91.24 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	=	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	=	514.88 kB	514.88 kB	=	91.95 kB	91.95 kB
facebook-www/ReactDOM-prod.classic.js	=	594.55 kB	594.55 kB	=	104.89 kB	104.90 kB
facebook-www/ReactDOM-prod.modern.js	=	584.81 kB	584.81 kB	=	103.32 kB	103.32 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-experimental/react-reconciler/cjs/react-reconciler.profiling.js	+0.32%	429.88 kB	431.28 kB	+0.23%	69.69 kB	69.85 kB
oss-experimental/react-reconciler/cjs/react-reconciler.development.js	+0.27%	662.37 kB	664.13 kB	+0.18%	105.97 kB	106.16 kB
oss-experimental/react-art/cjs/react-art.development.js	+0.25%	579.62 kB	581.08 kB	+0.18%	93.48 kB	93.64 kB
oss-experimental/react-dom/cjs/react-dom-profiling.profiling.js	+0.24%	557.25 kB	558.59 kB	+0.20%	98.94 kB	99.14 kB

Generated by 🚫 dangerJS against 112f44b

[sebmarkbage]

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.

[eps1lon]

Do these become >=1ms when CPU throttling is turned on?

[sebmarkbage]

Maybe for the really slow ones. Depends on the overhead of yielding on the platform I guess.

[eps1lon]

How do we decide the numeric value of these thresholds?

[sebmarkbage]

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.

[sebmarkbage]

Stacked on #31552. Must be tested with enableSiblingPrerendering off since the use() 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 useActionState path doesn't work yet because the use() 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.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 19, 2024 6:45pm

[react-sizebot]

Comparing: 6177b18c66c010d2b2f03202623a0533e7a89004...0d4052a432b7b8119b342811fd3062f9c6ac8855

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.68 kB	6.68 kB	=	1.83 kB	1.82 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	=	509.94 kB	509.94 kB	=	91.24 kB	91.24 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	=	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	=	514.88 kB	514.88 kB	=	91.95 kB	91.95 kB
facebook-www/ReactDOM-prod.classic.js	=	594.55 kB	594.55 kB	=	104.89 kB	104.90 kB
facebook-www/ReactDOM-prod.modern.js	=	584.81 kB	584.81 kB	=	103.32 kB	103.32 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-experimental/react-reconciler/cjs/react-reconciler.profiling.js	+0.32%	429.88 kB	431.28 kB	+0.23%	69.69 kB	69.85 kB
oss-experimental/react-reconciler/cjs/react-reconciler.development.js	+0.27%	662.37 kB	664.13 kB	+0.18%	105.97 kB	106.16 kB
oss-experimental/react-art/cjs/react-art.development.js	+0.25%	579.62 kB	581.08 kB	+0.18%	93.48 kB	93.64 kB
oss-experimental/react-dom/cjs/react-dom-profiling.profiling.js	+0.24%	557.25 kB	558.59 kB	+0.20%	98.94 kB	99.14 kB

Generated by 🚫 dangerJS against 112f44b

[sebmarkbage]

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.

[eps1lon]

Do these become >=1ms when CPU throttling is turned on?

[sebmarkbage]

Maybe for the really slow ones. Depends on the overhead of yielding on the platform I guess.

[eps1lon]

How do we decide the numeric value of these thresholds?

[sebmarkbage]

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.

[sebmarkbage]

Stacked on #31552. Must be tested with enableSiblingPrerendering off since the use() 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 useActionState path doesn't work yet because the use() 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.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 19, 2024 6:45pm

[react-sizebot]

Comparing: 6177b18c66c010d2b2f03202623a0533e7a89004...0d4052a432b7b8119b342811fd3062f9c6ac8855

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.68 kB	6.68 kB	=	1.83 kB	1.82 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	=	509.94 kB	509.94 kB	=	91.24 kB	91.24 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	=	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	=	514.88 kB	514.88 kB	=	91.95 kB	91.95 kB
facebook-www/ReactDOM-prod.classic.js	=	594.55 kB	594.55 kB	=	104.89 kB	104.90 kB
facebook-www/ReactDOM-prod.modern.js	=	584.81 kB	584.81 kB	=	103.32 kB	103.32 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-experimental/react-reconciler/cjs/react-reconciler.profiling.js	+0.32%	429.88 kB	431.28 kB	+0.23%	69.69 kB	69.85 kB
oss-experimental/react-reconciler/cjs/react-reconciler.development.js	+0.27%	662.37 kB	664.13 kB	+0.18%	105.97 kB	106.16 kB
oss-experimental/react-art/cjs/react-art.development.js	+0.25%	579.62 kB	581.08 kB	+0.18%	93.48 kB	93.64 kB
oss-experimental/react-dom/cjs/react-dom-profiling.profiling.js	+0.24%	557.25 kB	558.59 kB	+0.20%	98.94 kB	99.14 kB

Generated by 🚫 dangerJS against 112f44b

[sebmarkbage]

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.

[eps1lon]

Do these become >=1ms when CPU throttling is turned on?

[sebmarkbage]

Maybe for the really slow ones. Depends on the overhead of yielding on the platform I guess.

[eps1lon]

How do we decide the numeric value of these thresholds?

[sebmarkbage]

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.

[sebmarkbage]

Stacked on #31552. Must be tested with enableSiblingPrerendering off since the use() 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 useActionState path doesn't work yet because the use() 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.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 19, 2024 6:45pm

[react-sizebot]

Comparing: 6177b18c66c010d2b2f03202623a0533e7a89004...0d4052a432b7b8119b342811fd3062f9c6ac8855

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.68 kB	6.68 kB	=	1.83 kB	1.82 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	=	509.94 kB	509.94 kB	=	91.24 kB	91.24 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	=	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	=	514.88 kB	514.88 kB	=	91.95 kB	91.95 kB
facebook-www/ReactDOM-prod.classic.js	=	594.55 kB	594.55 kB	=	104.89 kB	104.90 kB
facebook-www/ReactDOM-prod.modern.js	=	584.81 kB	584.81 kB	=	103.32 kB	103.32 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-experimental/react-reconciler/cjs/react-reconciler.profiling.js	+0.32%	429.88 kB	431.28 kB	+0.23%	69.69 kB	69.85 kB
oss-experimental/react-reconciler/cjs/react-reconciler.development.js	+0.27%	662.37 kB	664.13 kB	+0.18%	105.97 kB	106.16 kB
oss-experimental/react-art/cjs/react-art.development.js	+0.25%	579.62 kB	581.08 kB	+0.18%	93.48 kB	93.64 kB
oss-experimental/react-dom/cjs/react-dom-profiling.profiling.js	+0.24%	557.25 kB	558.59 kB	+0.20%	98.94 kB	99.14 kB

Generated by 🚫 dangerJS against 112f44b

[sebmarkbage]

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.

[eps1lon]

Do these become >=1ms when CPU throttling is turned on?

[sebmarkbage]

Maybe for the really slow ones. Depends on the overhead of yielding on the platform I guess.

[eps1lon]

How do we decide the numeric value of these thresholds?

[sebmarkbage]

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.

[sebmarkbage]

Stacked on #31552. Must be tested with enableSiblingPrerendering off since the use() 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 useActionState path doesn't work yet because the use() 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.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 19, 2024 6:45pm

[react-sizebot]

Comparing: 6177b18c66c010d2b2f03202623a0533e7a89004...0d4052a432b7b8119b342811fd3062f9c6ac8855

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.68 kB	6.68 kB	=	1.83 kB	1.82 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	=	509.94 kB	509.94 kB	=	91.24 kB	91.24 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	=	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	=	514.88 kB	514.88 kB	=	91.95 kB	91.95 kB
facebook-www/ReactDOM-prod.classic.js	=	594.55 kB	594.55 kB	=	104.89 kB	104.90 kB
facebook-www/ReactDOM-prod.modern.js	=	584.81 kB	584.81 kB	=	103.32 kB	103.32 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-experimental/react-reconciler/cjs/react-reconciler.profiling.js	+0.32%	429.88 kB	431.28 kB	+0.23%	69.69 kB	69.85 kB
oss-experimental/react-reconciler/cjs/react-reconciler.development.js	+0.27%	662.37 kB	664.13 kB	+0.18%	105.97 kB	106.16 kB
oss-experimental/react-art/cjs/react-art.development.js	+0.25%	579.62 kB	581.08 kB	+0.18%	93.48 kB	93.64 kB
oss-experimental/react-dom/cjs/react-dom-profiling.profiling.js	+0.24%	557.25 kB	558.59 kB	+0.20%	98.94 kB	99.14 kB

Generated by 🚫 dangerJS against 112f44b

[sebmarkbage]

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.

[eps1lon]

Do these become >=1ms when CPU throttling is turned on?

[sebmarkbage]

Maybe for the really slow ones. Depends on the overhead of yielding on the platform I guess.

[eps1lon]

How do we decide the numeric value of these thresholds?

[sebmarkbage]

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.

[sebmarkbage]

Stacked on #31552. Must be tested with enableSiblingPrerendering off since the use() 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 useActionState path doesn't work yet because the use() 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.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 19, 2024 6:45pm

[react-sizebot]

Comparing: 6177b18c66c010d2b2f03202623a0533e7a89004...0d4052a432b7b8119b342811fd3062f9c6ac8855

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.68 kB	6.68 kB	=	1.83 kB	1.82 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	=	509.94 kB	509.94 kB	=	91.24 kB	91.24 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	=	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	=	514.88 kB	514.88 kB	=	91.95 kB	91.95 kB
facebook-www/ReactDOM-prod.classic.js	=	594.55 kB	594.55 kB	=	104.89 kB	104.90 kB
facebook-www/ReactDOM-prod.modern.js	=	584.81 kB	584.81 kB	=	103.32 kB	103.32 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-experimental/react-reconciler/cjs/react-reconciler.profiling.js	+0.32%	429.88 kB	431.28 kB	+0.23%	69.69 kB	69.85 kB
oss-experimental/react-reconciler/cjs/react-reconciler.development.js	+0.27%	662.37 kB	664.13 kB	+0.18%	105.97 kB	106.16 kB
oss-experimental/react-art/cjs/react-art.development.js	+0.25%	579.62 kB	581.08 kB	+0.18%	93.48 kB	93.64 kB
oss-experimental/react-dom/cjs/react-dom-profiling.profiling.js	+0.24%	557.25 kB	558.59 kB	+0.20%	98.94 kB	99.14 kB

Generated by 🚫 dangerJS against 112f44b

[sebmarkbage]

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.

[eps1lon]

Do these become >=1ms when CPU throttling is turned on?

[sebmarkbage]

Maybe for the really slow ones. Depends on the overhead of yielding on the platform I guess.

[eps1lon]

How do we decide the numeric value of these thresholds?

[sebmarkbage]

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.