←back to thread

446 points talboren | 1 comments | | HN request time: 0s | source
Show context
muglug ◴[] No.45039093[source]
Improvements merged within the last two days by the WebKit team: https://github.com/orgs/community/discussions/170922#discuss...

For my sins I occasionally create large PRs (> 1,000 files) in GitHub, and teammates (who mostly all use Chrome) will sometimes say "I'll approve once it loads for me..."

replies(6): >>45039371 #>>45039546 #>>45039877 #>>45040882 #>>45043276 #>>45050622 #
Sesse__ ◴[] No.45040882[source]
Interesting how _everyone_ here blames JS and React, yet the fixes you linked are about CSS performance.
replies(4): >>45041372 #>>45041777 #>>45042832 #>>45049426 #
psygn89 ◴[] No.45042832[source]
JS is the logical place to start with all the virtualization and fanciness.

But CSS has bit me with heavy pages (causing a few seconds of lag that even devtools debugging/logging didn't point towards). We know wildcard selectors can impact performance, but in my case there were many open ended selectors like `:not(.what) .ever` where the `:not()` not being attached to anything made it act like a wildcard with conditions. Using `:has()` will do the same with additional overhead. Safari was the worst at handling large pages and these types of selectors and I noticed more sluggishness 2-3 years ago.

replies(1): >>45043040 #
1. Sesse__ ◴[] No.45043040[source]
`:not(.what) .ever` should be fairly fast, unless you have lots of `class="ever"` elements. Not ideal, but not as bad as e.g. `.ever :not(.what)` would be. `:has()` is just inherently slow if there's a significant amount of elements to search, even though browsers have some caching and tricks.

Normally, you be able to debug selector matching performance (and in general, see how much style computation costs you), so it's a bit weird if you have phantom multi-second delays.