Performance degradation in `onPress`

[MrFlashAccount]

Provide a general summary of the issue here

After updating react-aria-components to the latest version (1.8.0) we faced a significant performance degradation, increasing passiveMountOnFiber duration from roughly 200ms to 1.8s(!)

After digging into the issue we found that the root cause is in usePress hook: https://github.com/adobe/react-spectrum/blob/main/packages/%40react-aria/interactions/src/usePress.ts#L821 caused by: #8047

Here's a recording from chrome devtools:

Trace-20250412T155902.json

Here's a screenshot, you can see that usePress schedules over 2000 style recalculations.

🤔 Expected Behavior?

---

😯 Current Behavior

---

💁 Possible Solution

---

🔦 Context

---

🖥️ Steps to Reproduce

---

Version

1.8.0

What browsers are you seeing the problem on?

Chrome

If other, please specify.

No response

What operating system are you using?

MacOS

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[devongovett]

I was worried about this but we tested before and couldn't reproduce a slowdown. Is there anything in particular about your page that could cause this? High number of Pressable elements? Which components are you using? Anything that can help us reproduce would be helpful.

[MrFlashAccount]

Thank you for the quick response!

Yeah, in this particular case, we have over 2,000 pressables. It may seem a bit more than you might expect, but for us, it’s the perfect stress test.

[nwidynski]

@devongovett Shouldn't the override in #8047 also be running on every render, making this degradation possibly worse? Currently the useEffect is dependent on domRef, but what if touch-action: auto were to apply conditionally?

@MrFlashAccount Unfortunately I can't reproduce the degradation just by rendering 2000 <Button />'s.

Maybe it makes sense to add a data-pressable attribute on each element instead? Optionally, we could then inject a global style with low specificity so user styles would still override. Ideally users would still just set <meta name="viewport" content="width=device-width"> whenever possible.

[MrFlashAccount]

We have the ‘<meta name=“viewport” content=“width=device-width”>’ set. Is it possible to provide an option or simply query the meta once in a provider?

I can prepare a pull request to bump react-aria’s version in the meantime. However, you’d need to download an IDE and register. Also, since the product is open-source, it’s possible to explore the code.

[MrFlashAccount]

Unfortunately I can't reproduce the degradation just by rendering 2000 '

it’s worth noting that we have a variety of styles, and some of them may be ineffective, such as ‘.some-selector span’ and over 25,000 nodes on the page.

[MrFlashAccount]

@devongovett, @nwidynski , I’ve prepared a pull request (PR) where you can observe the degradation. Here’s the link: enso-org/enso#12846

To reproduce the issue, follow these steps:

1. Download the IDE.
2. Open the IDE.
3. Register and add a large directory (preferably more than 2000 elements). A good candidate is the node_modules folder in the react-spectrum package.

Here’s the link to the job with the IDE artifacts: https://github.com/enso-org/enso/actions/runs/14442904237?pr=12846

—

Here's a video how to register.

CleanShot.2025-04-14.at.13.07.03.mp4

Additionally, I’ve uploaded a video demonstrating the reproduction of the issue (due to its large size, it had to be uploaded to YouTube):

https://youtu.be/Vxydt6b4Jes

[MrFlashAccount]

@devongovett here's a codesandbox with a repro: https://codesandbox.io/p/devbox/modern-architecture-forked-5tyh5y?workspaceId=ws_FJECc2QX6MEMWWYxSwGxqp

Hope this helps!

[devongovett]

You might need to add permissions for that code sandbox. I can't see it.

[MrFlashAccount]

You might need to add permissions for that code sandbox. I can't see it.

Oh, I apologize for any inconvenience caused.

https://codesandbox.io/p/devbox/modern-architecture-forked-5tyh5y?workspaceId=ws_FJECc2QX6MEMWWYxSwGxqp

Hope now it works!

[nwidynski]

@MrFlashAccount Thanks for the repro 👍

While I can observe the forced reflow now, on my machine, the commitPassiveMountEffects only takes ~120ms?

[MrFlashAccount]

@MrFlashAccount Thanks for the repro 👍

While I can observe the forced reflow now, on my machine, the commitPassiveMountEffects only takes ~120ms?

That's a lot, don't you think?

[devongovett]

As @nwidynski mentioned, we could potentially try inserting a CSS rule for this and see if that helps. It would need to be in the lowest CSS @layer possible, with as low specificity as possible. Basically like this:

<style>
@layer {
  :where([data-react-aria-pressable]) {
    touch-action: pan-x pan-y pinch-zoom;
  }
}
</style>

If this rule is inserted at the start of the <head> it should be in the lowest possible layer. That way other CSS on the page could override it when needed.

[MrFlashAccount]

I think ':where' + putting this as the topmost style tag might be enough