Improving performance

[fabiospampinato]

I'm taking a closer look at my style recalculations, and it turns out the all CSS property is incredibly slow for no reason.

With no other CSS on the page, and a 4x CPU slowdown, I get ~14ms for a page of mine with ~200 elements on the page, which just this CSS:

*:where(:not(html, iframe, canvas, img, svg, video):not(svg *, symbol *)) {
  all: unset;
  display: revert;
}

If I exclude divs, like the following, my style recalculations drop to ~9ms:

*:where(:not(html, iframe, canvas, img, svg, video, div):not(svg *, symbol *)) {
  all: unset;
  display: revert;
}

If I also exclude spans, like the following, the time drops to ~4ms:

*:where(:not(html, iframe, canvas, img, svg, video, div, span):not(svg *, symbol *)) {
  all: unset;
  display: revert;
}

The crazy thing is that Chrome's user agent stylesheet, only sets display: block for div, and it doesn't even set anything for span.

So an insane amount of performance is being thrown out of the window for nothing really.

Possibly this should be taken into account, and some common elements, if not every element, should be special-cased and not be reset with all: unset.

[fabiospampinato]

Upstream issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1441129

This seems a bug in Chrome really, I'm not sure if it's also a bug in other browsers. But who knows if and when it will get fixed.

[fabiospampinato]

FYI it turns out that something like this is way faster, it basically gets optimized away, other ways of writing the same thing, even if they are equivalent, are just not as optimized in Chrome.

:where(abbr), :where(address), :where(area), :where(article), :where(aside), :where(audio), :where(b), :where(base), :where(bdi), :where(bdo), :where(big), :where(blockquote), :where(body), :where(br), :where(caption), :where(cite), :where(code), :where(col), :where(colgroup), :where(data), :where(datalist), :where(dd), :where(del), :where(details), :where(dfn), :where(dialog), :where(dl), :where(dt), :where(em), :where(embed), :where(fieldset), :where(figcaption), :where(figure), :where(footer), :where(form), :where(h1), :where(h2), :where(h3), :where(h4), :where(h5), :where(h6), :where(head), :where(header), :where(hgroup), :where(hr), :where(i), :where(input), :where(ins), :where(kbd), :where(keygen), :where(label), :where(legend), :where(li), :where(link), :where(main), :where(map), :where(mark), :where(menu), :where(menuitem), :where(meta), :where(meter), :where(nav), :where(object), :where(ol), :where(optgroup), :where(option), :where(output), :where(param), :where(picture), :where(pre), :where(progress), :where(q), :where(rp), :where(rt), :where(ruby), :where(s), :where(samp), :where(slot), :where(script), :where(section), :where(select), :where(small), :where(source), :where(strong), :where(style), :where(sub), :where(summary), :where(sup), :where(table), :where(template), :where(tbody), :where(td), :where(textarea), :where(tfoot), :where(th), :where(thead), :where(time), :where(title), :where(tr), :where(track), :where(u), :where(ul), :where(var), :where(wbr), :where(div), :where(span), :where(button), :where(a), :where(p) {
  all: unset;
  display: revert;
}

[reanimatedmanx]

It's crazy to me that the browsers even come with a "default" styles that is actually just trash, stupid values that no one needs, and we have to fallback to use this kind of packages.

[elad2412]

This is interesting. First, thanks for this deep testing of performance.

I will take on a deeper look, thinking of adding the <div> and <span> to the list f un-affecting selectors.

[QINGCHARLES]

LOL, the Chromium team have snark "If you are using a CSS reset like this, it is probably time to just stop doing so."

[larrifax]

This blog post brought all: revert-layer; to my attention. Maybe it could improve performance just a tad bit?

An excerpt from the blogpost:

Anyway, all: revert-layer is like all: revert but actually useful. It can be used as a drop-in replacement for all: revert, even if you are not making use of cascade layers anywhere else. When there is no “previous layer”, revert-layer will revert to the previous origin. But unlike revert which removes the useful styles associated with presentational attributes, revert-layer will correctly preserve them.

[QINGCHARLES]

It looks interesting. That's the first I've heard of it. Damn, CSS has so many properties now it is hard to keep track of them all.