3 ms·

I thought preferred method was to record performance of a user's flow based on selector I think Chromium specifically got rid of a tool like this in "Drop the

• luckylion 4y ago
  > This will also reduce the fraction of developers trying to micro-optimize already fast selectors. I always feel like browser devs regularly look at the web naively and think "yeah nobody should waste time optimizing for that", but then you get sites having 800kb of CSS and lots of terrible selectors and you have no tools to analyze them besides generic coverage. Personally, I've never felt overwhelmed by choice when it comes to options regarding optimization. It's fine if it's hidden behind a flag, but "nobody could ever need this" feels weird.
  • weego 4y ago
    Slightly exaggerated numbers there, but how bad can a css selector really be to the client experience when it's likely based on today's UI dev trends that we're loading 3mb of react + other JS
    • luckylion 4y ago
      I wish I was exaggerating, that's something I recently had to deal with :( You're right, "I need an OS written in JS to run before I can toggle that menu" dwarfs all of it. I'm lucky in that regard, I usually deal with jQuery-based things; you can still trim 95% of the code if you got rid of it (carousels are stopping me, people love carousels), but even if you don't, you land at like 100kb JS and you can defer it.