GetElementById vs. QuerySelector

Related: one of my favourite code golfing tricks is named access on the Window object &lt;<a href="https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;window-object.html#named-access-on-the-window-object" rel="nofollow">https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;window-object.html#na...</a>&gt;:<p><pre><code> &lt;div id=result&gt;&lt;&#x2F;div&gt; &lt;script&gt; document.getElementById(&quot;result&quot;).textContent = &quot;Why do it this way—&quot;; document.querySelector(&quot;result&quot;).textContent = &quot;—or even this way—&quot;; result.textContent = &quot;—when you can do it this way?&quot;; &lt;&#x2F;script&gt; </code></pre> <i>Edit:</i> adding another similar test to this page, window[`test${i}`] is taking roughly twice as long as document.querySelector(`#test${i}`) in Firefox, but only <i>half</i> as long in Chromium—which is still a bit slower than document.getElementById(`test${i}`) in Chromium, and than window[`test${i}`] in Firefox.

Edit: seems like I&#x27;m wrong.<p>They are both completely different and almost no one mentions how they differ in these comparison blog articles.<p>querySelector return a static node while getElementById returns a live node. If the element returned by getElementById is deleted in the DOM, the variable becomes unavailable while for querySelector you get a snapshot of the node that lives on.<p>If you use both of them the same way or don&#x27;t know the difference, you are gonna have a bad time.<p><a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;Document_object_model&#x2F;Locating_DOM_elements_using_selectors" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;Document_ob...</a>

Please don&#x27;t listen to this, it&#x27;s misleading.<p>querySelector *does not* take 62ms to run. Both of them take 0.01ms at most, try it yourself. This is the sort of micro optimization you should not concern yourself with.<p>How often do you need to select unique elements by ID? Don&#x27;t use IDs in the first place.<p>This is akin to using `i--` in loops to &quot;speed up your code&quot; — we&#x27;re past that.

&gt; ignores the first 5 results (to avoid caching effects).<p>This would be the correct approach if you&#x27;re interested in the &quot;sterile laboratory&quot; performance of these APIs. But the average webpage is going to not be doing a bunch of throwaway work before it starts selecting elements.<p>I think it would actually be much more interesting to see the cold start results to see if they&#x27;re comparable to each other. Hypothetically if e.g. GetElementById is only faster after the result has been cached by this simulation, then I think any conclusions about real world impact here could be misleading.

I&#x27;m getting getElementById is 2x to 4x faster than querySelector depending on the browser<p><a href="https:&#x2F;&#x2F;jsbenchit.org&#x2F;?src=25e097f939f76b559b2515430fb5e459" rel="nofollow">https:&#x2F;&#x2F;jsbenchit.org&#x2F;?src=25e097f939f76b559b2515430fb5e459</a><p>I&#x27;m a little surprised. Sure i&#x27;d expected getElementById to be faster but honestly I&#x27;d have expected browser implementation of querySelector to do a relatively trivial up front check, is the selector a simple id, if so, call getElementById. I suppose that adds overheads to all queries, but that&#x27;s true of many types of &quot;best case&quot; optimizations. (in the best case it&#x27;s faster but adds some overhead for any non-best case)<p>Still, I don&#x27;t care about this level of optimization. I&#x27;ll just contuinue to use querySelector everywhere because it&#x27;s more flexable. No code I&#x27;ve ever written looks up so many elements in a single interaction that this micro optimization would ever matter to me.

I’m surprised by the apparent magnitude of the difference between Firefox and Chrome. On my laptop I’m getting results roughly twice as fast as reported in the article, but still fairly similar ratios all round:<p>Firefox 96 (Nightly): document.getElementById 2–4ms avg 3ms, document.querySelector 25–27ms avg 27ms.<p>Chromium 96 (stable): document.getElementById 11–37ms avg 19ms, document.querySelector 86–155ms avg 101ms.<p>I’m also a touch surprised by the difference between getElementById and querySelector, because I vaguely recall querySelector being optimised in browsers for the ID case some years back so that there was negligible difference.<p>(P.S. seeing Firefox’s version number continuing to creep up on Chromium’s, soon to overtake, I wish browsers would scrap their version numbering systems and switch to YYYY.MM instead, or even YYMM like Windows if they want just one number. Can’t even claim user-agent sniffing hazards any more since they’re slightly killing those off and reaching three digits is going to cause some trouble anyway.)

In the worst case<p>&gt; around 44ms and 206ms<p>so around 162ms difference per 100,000 elements. This doesn&#x27;t concern most of us for anything less than 1,000 elements (1.62ms).<p>I use querySelector more often simply for aesthetics (consistent with other calls and qsAll).

This is not measuring what the author thinks it&#x27;s measuring in Chrome. The benchmark iterates through 100,000 sequential IDs, and does so 105 times.<p>For getElementById:<p>This is a map lookup every time.<p>For querySelector:<p>Chrome caches the parsed selector, but the benchmark doesn&#x27;t use the same ID twice in any run, so the cache is not effective within a given run. Chrome also has a 256 query limit (per document) on the cache [1] which means that even though the benchmark runs 105 times, each time the browser is parsing 100,000 selectors since the cache would have the last 256 but it always starts at 0. querySelector does have a fast path [2] that calls getElementById which the benchmark hits, but the parsing cost is dominating.<p>So the benchmark is really measuring selector parsing vs a map lookup. Firefox might have a separate fast path for ID looking selectors that skips the real css parser. It might also have a larger cache.<p>Chrome&#x27;s cache should probably be bigger than 256 for modern web apps , but even so that wouldn&#x27;t help a benchmark that&#x27;s parsing 100k selectors repeatedly since it doesn&#x27;t make sense to have a cache that size just for micro benchmarks and real apps don&#x27;t use 100k unique queries.<p>[1] <a href="https:&#x2F;&#x2F;source.chromium.org&#x2F;chromium&#x2F;chromium&#x2F;src&#x2F;+&#x2F;main:third_party&#x2F;blink&#x2F;renderer&#x2F;core&#x2F;css&#x2F;selector_query.cc;l=487;drc=66f8666257dd5d2687c37c155f40cc72e0176270" rel="nofollow">https:&#x2F;&#x2F;source.chromium.org&#x2F;chromium&#x2F;chromium&#x2F;src&#x2F;+&#x2F;main:thi...</a><p>[2] <a href="https:&#x2F;&#x2F;source.chromium.org&#x2F;chromium&#x2F;chromium&#x2F;src&#x2F;+&#x2F;main:third_party&#x2F;blink&#x2F;renderer&#x2F;core&#x2F;css&#x2F;selector_query.cc;l=382;drc=fde2db9853cab5681586ea71d877f4cefd5eee13" rel="nofollow">https:&#x2F;&#x2F;source.chromium.org&#x2F;chromium&#x2F;chromium&#x2F;src&#x2F;+&#x2F;main:thi...</a>

It occurs to me that, during querySelector execution, components of a selector which match only by ID (or maybe by ID at all) could be maybe linearly or sublinearly resolved by calling the native-code implementation of getElementById. Per at least the MDN docs [1] [2], both return an Element, so nothing downstream will see any difference.<p>If the entire selector is a single ID matcher, execution time for querySelector probably would not be that much longer than for direct calls to getElementById; depending on implementation there might not even be any more stack frames. (Which would be a pain and might not matter, but there are a few ways you could do it if it did.)<p>In iOS 14.8 on this iPhone 12 mini with about half a battery, the getElementById test took 20ms, and the querySelector test 47. Of course I don&#x27;t know what the implementation is actually doing, but those times seem awfully close together compared to those the author quotes.<p>[1] <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;Document&#x2F;getElementById" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;Document&#x2F;ge...</a><p>[2] <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;Document&#x2F;querySelector" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;Document&#x2F;qu...</a>

Interesting, but, if you are handling anywhere near 100,000 elements you should probably be maintaining references rather than querying the DOM each time.

Why is Chrome so slow with this? Does anyone know

I love seeing little &quot;science&quot; experiments like these. Definitely interesting, ty article author.

Was halfway expecting some counterintuitive result like that infamous &quot;JSON.parse() is faster than an actual JSON literal&quot; meme a while ago.<p>Somewhat relieving the results here follow the common-sense expectation. (I.e. getElementById is faster than querySelector)

Interestingly, getElementById was 62% slower than querySelector on my computer with FF94. I reckon this is a moot issue as neither of these is likely to be a bottleneck for a web application.

The histograms are essentially completely broken for me in Chrome on dark mode. Had to switch to light mode, refresh, and re-run.

I would expect the performance to be worse, given that it does something much more complex. But it’s still great to have it.

You shouldn&#x27;t be using either of these directly in 2021