|
"I wasted a day on CSS selector performance to make a website load 2ms faster" by @trys https://www.trysmudford.com/blog/i-spent-a-day-making-the-website-go-2ms-faster/ This is one of the unfortunate things about the DevTools' "selector stats." It can really mislead you if you don't notice the text "(slow)" which _really_ means slow. 2 comments
@nolan I think the confusion comes from the expectations set by of all other performance profiling tools. We're used to Lighthouse and WPT being 'slow', but we know we can trust all their tables and graphs to be time-accurate. This particular flavour of 'slow' needs a big ol' tooltip warning you which results are and aren't affected by the enforced slowness. |
Gregory's Server
Another issue I've noticed with "selector stats" is that it might give the impression that selector perf is all that matters for reducing style calculation costs. Whereas if your costs are due to CSS custom properties, or excessive numbers of stylesheets (e.g. this fun issue [1]), or something else during style recalc, you can end up chasing ghosts.
(That said, I *love* selector stats, and it has helped me debug some real perf issues! I am glad we have it!)
[1]: https://issues.chromium.org/issues/40229331
Another issue I've noticed with "selector stats" is that it might give the impression that selector perf is all that matters for reducing style calculation costs. Whereas if your costs are due to CSS custom properties, or excessive numbers of stylesheets (e.g. this fun issue [1]), or something else during style recalc, you can end up chasing ghosts.