just fixed a huge perf issue on my site by removing some instances of `:has()`!
-
just fixed a huge perf issue on my site by removing some instances of `:has()`!
went from ~2s style recalc
to ~7ms style recalcdefinitely try out the new selector stats feature of devtools!!
-
@argyleink any specific insights from the change that can be shared beyond “measure”?
-
@westbrook The performance panel was great at reporting the recalc time, I triggered it with getBoundingClientRect
Then I saw in the selector stats feature that has usage was top for slowest. Commented out the has code, and ran a perf measure again. Boom, saw the small recalc and was like, dang.
-
@argyleink Also, for my own sanity, did it really say ~2s or did it say ~2ms, which seems to be the default display time when I run this. 2 whole seconds for style recalc is 🤯 There is a deeper article to be written if something about :has() actually pushed it that high as it has to point to some sort of magic footgun that people should know about.
-
@westbrook @argyleink The cost of `:has()` is why it wasn't added sooner. I'm actually quite worried about the state of CSS perf tooling
-
@slightlyoff @westbrook We agree and recently spun up a team to investigate so we can make guidance
-
@argyleink @slightlyoff That's awesome, looking forward to what yall put together!!
-
@westbrook @argyleink We contributed selector stats after hitting several apps with unbelievably bad recalcs (huge DOMs, expensive rules, etc). The frontend community thinks of styling as "free", but with stuff as expensive as `:has()`, that will need to change, likely through more use of Shadow DOM to isolate costs