Skip to content

Clear width/height from Keyframes to Optimize View Transitions #33576

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 2, 2025

Conversation

sebmarkbage
Copy link
Collaborator

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.

@github-actions github-actions bot added the React Core Team Opened by a member of the React Core Team label Jun 19, 2025
@react-sizebot
Copy link

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
Copy link
Member

kassens commented Jun 26, 2025

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
Copy link
Contributor

bramus commented Jun 26, 2025

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
Copy link
Collaborator Author

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.

@sebmarkbage sebmarkbage merged commit c0d151c into facebook:main Jul 2, 2025
241 checks passed
github-actions bot pushed a commit that referenced this pull request Jul 2, 2025
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](https://www.bram.us/2025/02/07/view-transitions-applied-more-performant-view-transition-group-animations/).

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.

DiffTrain build for [c0d151c](c0d151c)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed React Core Team Opened by a member of the React Core Team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants