[lhorie]

OP is explaining their methodology poorly. The 62ms number is the time it takes to run the call 100,000 times, in a loop, with a string interpolation. And measurement is done by taking the delta of two performance.now() calls, which are known to be precise to only about 1ms for spectre mitigation[0].

FWIW, JS old timers have known querySelector is slower than getElementById since querySelector became a thing.

[0] https://developer.mozilla.org/en-US/docs/Web/API/Performance...

[rudian]

I know, that's why it's misleading and it should not be considered. A quick reader will think that "using getElementById will save me 32ms", but it'd be off by several orders of magnitude.

[lhorie]

That sounds like a pit of success, though. The gain just isn't that significant. IMHO, misleading would be if querySelector was faster under normal circumstances but shown to be slower through bad benchmarking

[leeoniya]

yep. and please dont query the dom 100k times, or in a loop :)

[afiori]

also with querySelector you can use queries like

> ids.map(id=> `#test${id}`).join(" , ")

or

> `[id^="test"]`

to get all elements that have an id that starts with test

[jfrunyon]

Thus opening up a whole swarm of potential bugs, you should probably just use a class if you need to reference a list of elements when possible.

[afiori]

well at that point it would be wise not to use ids for queries, but the logic remains the same.