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

jQuery 3.x delegates simple ID and class selectors to the browser's native querySelectorAll, while positional and visibility selectors such as :eq() and :visible still run through jQuery's own selector engine. That split leaves the optimization boundary unclear for an interaction dominated by repeated DOM queries and per-element event bindings.

The goal is a defensible rule for deciding when a hot path stays inside jQuery — cached jQuery objects, delegated handlers, batched appends — and when it should be rewritten against native querySelector, classList, or fetch. The constraint is that the decision must rest on measured attribution rather than selector micro-benchmarks, which vary by browser and by jQuery major version.

Two uncertainties remain: cached references can go stale when a subtree is replaced, and jQuery's abstraction cost is not uniform across selector types or event patterns.

• Which measurements reliably separate jQuery overhead from layout and scripting cost for a given interaction?
• At what point does a hot path justify leaving jQuery's API surface for native DOM calls?
• How should caching decisions account for subtrees that are replaced at runtime?