Skip to content
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

Significant performance hit when :has selectors enabled in Firefox #381

Open
brawaru opened this issue Dec 31, 2023 · 2 comments
Open

Significant performance hit when :has selectors enabled in Firefox #381

brawaru opened this issue Dec 31, 2023 · 2 comments

Comments

@brawaru
Copy link

brawaru commented Dec 31, 2023

Describe the bug
After Firefox shipped :has selector in the recent version, Phanpy performance has worsened severely, which is visible by page frequently freezing and overall feeling unresponsive especially with many elements on the screen.

It seems that Phanpy either uses :has selectors in a manner that is very expensive or does something else that causes Firefox to invalidate a huge amount of styles. Perhaps it's the same in Chromium browsers too.

32.0ms spent on Styles. Diagnostics: Elements traversed - 331; Elements styled - 321; Elements matched - 298; Styles shared - 23; Styles reused - 0; Thread - phanpy.social (2/5); Page - phanpy.social. Stack: First invalidated 9.782ms before the flush, at: style::invalidation::element::invalidator::TreStyleInvalidator<style::gecko::wrapper::GeckoElement, styl… (repeated many times)

There is no Styles events like that when :has support is disabled, most of them are very short and have a completely different stack trace.

  • Which site: phanpy.social
  • Which instance: mstdn.social

To Reproduce
Steps to reproduce the behavior:

  1. Ensure :has selector is enabled in about:config (layout.css.has-selector.enabled must be true)
  2. Interact with Phanpy for some time and notice the bad performance
  3. Disable :has selector support via about:config by setting layout.css.has-selector.enabled to false.
  4. Close all Phanpy tabs and re-open it (if you are unsure how to know that preference took effect, just restart Firefox)
  5. Open and interact with Phanpy again. Notice how performant it is.

Expected behavior
Phanpy is performant even when :has support is enabled.

Screenshots
N/A

Desktop (please complete the following information):

  • OS: Windows
  • Browser: Firefox
  • Version: 121.0

Smartphone (please complete the following information):
N/A

Additional context
I'm not sure how to get anything useful from the Firefox profiler.

Chromium blames forced reflows for styles recalculation blaming various scroll accessors.

@cheeaun
Copy link
Owner

cheeaun commented Dec 31, 2023

Hmm, this will probably take some time; either I remove all usage of :has() on my side or wait for Firefox to fix their performance issues.

I've been using :has() on Phanpy since beginning of the year, which works on Chrome, so the base performance evaluation follows Chrome's. They're also coded with progressive enhancement in mind, which means they're optional and shouldn't affect base functionality of the app (It used to, but I fixed them again and again)

Nevertheless I'll try to take some time to test this on my side, and hopefully can report some issues to Firefox too.

@cheeaun
Copy link
Owner

cheeaun commented Jan 22, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants