jQuery 3.x hot paths: cached selectors versus native DOM APIs as the optimization boundary

Answer the question first

For most interaction‑heavy code that repeatedly queries the DOM and binds events, stay inside jQuery if:

• The selector is a simple ID or class (e.g., $('#foo') or $('.bar')) and you can cache the jQuery object.
• The matched set is small (tens of elements) and the same nodes are reused for the lifetime of the interaction.
• There is no plan to replace the subtree that the selector covers via innerHTML, .replaceWith(), or similar DOM‑bypass operations.

Switch to native APIs if:

• The selector forces Sizzle (e.g., :eq(), :visible, attribute filters) and the matched set is large (hundreds or thousands of elements).
• You need to avoid the fixed Sizzle overhead that scales with element count.
• You are already performing layout reads/writes in the same loop; the bottleneck is reflow, not the selector.
• You’re replacing subtrees frequently and can’t afford to keep stale jQuery references.

In short, use jQuery for cheap, cached selectors that hit querySelectorAll and stay inside it when the cost of Sizzle is negligible compared to layout work. Use native methods when the selector’s Sizzle cost dominates or when you need guarantees that cached references won’t become stale.

Why this rule works

1. Selector cost: Simple ID/class selectors are delegated to querySelectorAll in jQuery 3.x, so the only overhead is the jQuery wrapper (≈1–3 µs). Complex selectors always invoke Sizzle, which can add 10–50 µs per call depending on element count.

2. Layout thrashing: The dominant factor in many hot paths is reading layout (e.g., offsetHeight) followed by writing to the DOM. The selector engine’s cost is dwarfed by the reflow cost, so micro‑optimizing the selector rarely improves overall performance.

3. Stale references: Cached jQuery objects do not automatically update when the underlying subtree is replaced via innerHTML or .replaceWith(). The wrapper still points to the old nodes, leading to silent bugs. Native queries always hit the current DOM tree.

Practical measurement steps

1. Create a test page with a known number of elements (e.g., 10,000 <div>s).
2. Wrap the selector in performance.mark('start') and performance.mark('end') and compute the delta with performance.measure(). Run 1,000 iterations for both $('#id') and document.querySelector('#id') to confirm wrapper overhead.
3. Repeat the test with a complex selector (e.g., $('.item:visible:eq(5)')) and a hand‑rolled native equivalent (querySelectorAll + JavaScript filtering). Compare total times to quantify Sizzle cost.
4. Insert a layout read/write cycle inside the loop (read offsetHeight, then set style.display) and observe the Chrome DevTools Performance panel. If reflow dominates, the selector choice matters little.
5. Replace a subtree with innerHTML and then access a cached jQuery object; verify that length or nodeName no longer matches the new DOM.
6. Repeat the measurements in at least two browsers (Chrome, Firefox) to account for JIT warm‑up and engine differences.

Handling subtree replacement

When you need to replace a subtree, always:

• Clear cached jQuery references that belong to the replaced portion.
• Re‑cache after the replacement if you will continue to query that subtree.
• Prefer event delegation (e.g., $(document).on('click', '.item', handler)) so that new nodes inherit handlers automatically.

What to ask next

To fine‑tune the rule for your project, it helps to know:

• How many elements does the selector typically match in production?
• How often does the subtree that the selector covers get replaced?

Providing those numbers lets you decide whether the Sizzle cost or layout cost dominates and whether you should switch to native APIs.