[Performance] Fast path to resolve body selector #1545
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It's a pretty common pattern to define trigger events using the
from:body
syntax.The issue: this "body" selector currently results in a call to
document.querySelectorAll
insidequerySelectorAllExt
While this may seem a negligible thing, it turns out that on large HTML pages, this makes the initial page load & parsing way slower.
querySelectorAllExt called 5000 times with 'body', took 180 ms
querySelectorAllExt called 5000 times with 'body', took 3.5 ms
The example code here is simply letting htmx initialize 5 000 divs, that have the exact same hx-trigger specified, which is in this example
hx-trigger="customEvent from:body"
While it is negligible on a typical HTML page where you wouldn't have thousands of divs, this example isn't taken out of nowhere, it's actually a real use case I have on Zorro, where a board could totally have thousands of tasks at once.
I'm using a similar
hx-trigger
specifier for every task to trigger individual refreshes on some actions, such ashx-trigger="refreshTask{{ .ID }} from:body"
.The suggested change here helps cutting down initial page load times, which contributes to user experience.
The cost is simply 2 more lines of code in the core.