Clear width/height from Keyframes to Optimize View Transitions

[sebmarkbage]

View Transitions has this annoying quirk where it adds width and height to keyframes automatically when generating keyframes even when it's not needed. This causes them to deopt from running on the compositor thread in both Chrome and Safari. @bramus has a good article on it.

In React we can automatically rewrite the keyframes when we're starting a View Transition to drop the width and height from the keyframes when they have the same value and the same value as the pseudo element.

To compare it against the pseudo element we first apply the new keyframes without the width/height and then read it back to see if it has changed. For gestures, we have already cancelled the previous animation so we can just read out from that.

[react-sizebot]

Comparing: a947eba...447700e

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.83 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	=	530.57 kB	530.57 kB	=	93.67 kB	93.67 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	+0.41%	651.66 kB	654.36 kB	+0.39%	114.78 kB	115.23 kB
facebook-www/ReactDOM-prod.classic.js	+0.33%	674.81 kB	677.04 kB	+0.30%	118.78 kB	119.13 kB
facebook-www/ReactDOM-prod.modern.js	+0.34%	665.30 kB	667.53 kB	+0.30%	117.19 kB	117.55 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-dom/cjs/react-dom-client.production.js	+0.41%	651.66 kB	654.36 kB	+0.39%	114.78 kB	115.23 kB
oss-experimental/react-dom/cjs/react-dom-unstable_testing.production.js	+0.41%	666.07 kB	668.77 kB	+0.37%	118.36 kB	118.80 kB
oss-experimental/react-dom/cjs/react-dom-profiling.profiling.js	+0.38%	714.36 kB	717.06 kB	+0.36%	123.95 kB	124.39 kB
facebook-www/ReactDOM-prod.modern.js	+0.34%	665.30 kB	667.53 kB	+0.30%	117.19 kB	117.55 kB
facebook-www/ReactDOM-prod.classic.js	+0.33%	674.81 kB	677.04 kB	+0.30%	118.78 kB	119.13 kB
facebook-www/ReactDOMTesting-prod.modern.js	+0.33%	679.70 kB	681.93 kB	+0.30%	120.84 kB	121.19 kB
facebook-www/ReactDOMTesting-prod.classic.js	+0.32%	689.21 kB	691.44 kB	+0.29%	122.37 kB	122.72 kB
facebook-www/ReactDOM-profiling.modern.js	+0.30%	737.03 kB	739.26 kB	+0.28%	126.85 kB	127.20 kB
facebook-www/ReactDOM-profiling.classic.js	+0.30%	745.07 kB	747.30 kB	+0.28%	128.14 kB	128.50 kB
oss-experimental/react-dom/cjs/react-dom-client.development.js	+0.26%	1,175.54 kB	1,178.62 kB	+0.26%	195.67 kB	196.18 kB
oss-experimental/react-dom/cjs/react-dom-profiling.development.js	+0.26%	1,191.92 kB	1,195.00 kB	+0.27%	198.49 kB	199.04 kB
oss-experimental/react-dom/cjs/react-dom-unstable_testing.development.js	+0.26%	1,192.08 kB	1,195.16 kB	+0.25%	199.41 kB	199.91 kB
facebook-www/ReactDOM-dev.modern.js	+0.20%	1,217.82 kB	1,220.30 kB	+0.19%	201.06 kB	201.44 kB
facebook-www/ReactDOM-dev.classic.js	+0.20%	1,226.96 kB	1,229.44 kB	+0.19%	202.79 kB	203.17 kB
facebook-www/ReactDOMTesting-dev.modern.js	+0.20%	1,234.35 kB	1,236.84 kB	+0.19%	204.79 kB	205.17 kB

Generated by 🚫 dangerJS against 447700e

[kassens]

The benefits here are obvious (run on compositor thread)

What are the downsides? Or why wouldn't browsers do this automatically? Is it basically just spec compliance that width/height need to be set?

[bramus]

Is it basically just spec compliance that width/height need to be set?

Yes, the spec mandates it – See step 3.9.5 of “Setup transition pseudo-elements”.

Or why wouldn't browsers do this automatically?

I had suggested this optimization in w3c/csswg-drafts#11657 but retracted my suggestion as it would result in the keyframes no longer being predictable for devs to extract info from. Maybe we should revisit that.

[sebmarkbage]

Having predictable keyframes would be nice. Ofc there's still many bugs that makes that not the case anyway. However, given the choice between having optimizable animations (especially on iOS where the difference results in 60fps vs 120fps even ignoring main thread jank), the choice is going to be to default to optimizable every time.

If we can have both that would be best. So making the implementation optimizable would be best. However, I don't have high hopes for all implementations to actually do the work to do that (Safari). A change to the default keyframes seems smaller in scope for implementors.

Until then it's up to JS frameworks to provide the best possible default given the current state of browsers.