I'm not the poster in question, but I thought it was pretty well known that querySelector[All] with a class string is shockingly slow - I'm actually a bit confused that everyone here is acting like they said something out of the ordinary. If that's really not common knowledge, it's probably no surprise that people are unintentionally writing websites that run like absolute crap on mobile devices.

Here's a JSPerf (not mine) that you can run and see yourself just how bad the performance is: https://jsperf.com/getelementbyid-vs-queryselector/284. getElementsByClassName runs nearly five million operations per second on my laptop (8th-gen i7, 16GB of RAM, latest Chrome); querySelector[All] with a class name runs less than ten thousand. And the sample HTML is tiny indeed compared to a typical web site or app.

I think what you're referring to is that querySelector is O(n), while the older getElement APIs are O(1).

https://stackoverflow.com/questions/14377590/queryselector-a...

That makes sense, but it has nothing to do with "string parsing", as the OP said. Parsing the query is fast. Executing the query is slow, because it's a more general API.

(And this is why the citation is important: because it shows the real issue, not the one described! Thanks for the clarification.)

See this: https://news.ycombinator.com/item?id=24058409