Benchmark: querySelectorAll vs. querySelector+querySelectorAll

HTML Preparation code:

<!--your preparation HTML code goes here-->

Script Preparation code:

function createTestElement(threshold = 0.5) {
    const element = document.createElement('div');
    if (Math.random() > 0.8) {
        element.setAttribute('data-test', 'foo');
    }

    while (Math.random() > threshold) {
        element.append(createTestElement(threshold + 0.1));
    }

    return element;
}

const testElements = Array.from({
    length: 100
}, () => createTestElement());

Tests:

querySelectorAll
testElements.forEach((el) => { const matches = el.querySelectorAll('[data-test]'); matches.forEach(() => {}); });
querySelector + querySelectorAll
testElements.forEach((el) => { if (el.querySelector('[data-test]')) { const matches = el.querySelectorAll('[data-test]'); matches.forEach(() => {}); } });
querySelectorAll again (in case of caching)
testElements.forEach((el) => { const matches = el.querySelectorAll('[data-test]'); matches.forEach(() => {}); });

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
querySelectorAll
querySelector + querySelectorAll
querySelectorAll again (in case of caching)

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: 11 days ago)

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:133.0) Gecko/20100101 Firefox/133.0

Browser/OS: Firefox 133 on Linux

View result in a separate tab

Test name	Executions per second
querySelectorAll	18178.4 Ops/sec
querySelector + querySelectorAll	38450.6 Ops/sec
querySelectorAll again (in case of caching)	17060.7 Ops/sec

Autogenerated LLM Summary (model gpt-4o-mini, generated 14 days ago):

LLMs can make mistakes. Check important info.

The benchmark focuses on comparing the performance of DOM query operations using two different approaches in JavaScript: `querySelectorAll` used alone versus a combination of `querySelector` followed by `querySelectorAll`. The specific operations being tested are as follows:

### Options Compared

1. **`querySelectorAll`**:
   - The first test case measures the performance of using `querySelectorAll` by itself, which retrieves all elements matching a given CSS selector.
   - The code executed iterates through a collection of elements and calls `querySelectorAll('[data-test]')`, which returns all descendants with the attribute `data-test`.

2. **`querySelector + querySelectorAll`**:
   - The second test combines `querySelector` and `querySelectorAll`. Here, it first checks if an element has at least one matching element with `querySelector('[data-test]')` before calling `querySelectorAll` on it.
   - This approach can potentially save overhead if most elements do not have the `data-test` attribute by skipping the `querySelectorAll` call for those non-matching elements.

3. **`querySelectorAll again (in case of caching)`**:
   - This final test repeats the first test case to check performance differences potentially influenced by caching, which could relate to how the browser caches results of previous DOM queries.

### Pros and Cons of Approaches

- **`querySelectorAll`**:
  - **Pros**: Simple and straightforward API for retrieving all elements matching a selector. It's more direct and may have optimizations in certain browsers.
  - **Cons**: If called on a large number of elements that do not contain matches, it could introduce unnecessary processing overhead, as it must evaluate all elements regardless of relevance.

- **`querySelector + querySelectorAll`**:
  - **Pros**: This approach could reduce the number of expensive `querySelectorAll` calls by first checking for the presence of matching elements, leading to better performance if many elements do not match.
  - **Cons**: The additional call to `querySelector` introduces some overhead, which may not be beneficial if many elements do contain the matching attribute.

### Other Considerations

- **Caching**: Caching can improve performance in repetitive operations but can also add complexity if state changes alter the DOM between calls. The third test aims to measure how effective the browser might be at caching results from previous queries.

### Benchmark Results

The benchmark results indicate the number of executions per second for each method:

1. **`querySelector + querySelectorAll`**: 54,223.91 executions/sec, performing notably well.
2. **`querySelectorAll again (in case of caching)`**: 34,062.99 executions/sec, demonstrating that reusing cached results may provide better performance under specific conditions.
3. **`querySelectorAll` (first test)**: 32,685.01 executions/sec, which is the least efficient of the three as expected.

### Libraries and Features

In this benchmark, no specific JavaScript library is used, but the features employed are native to the JavaScript and DOM APIs. The capabilities of `querySelector` and `querySelectorAll` are built-in methods of the DOM API, allowing for efficient manipulation and querying of HTML elements.

### Alternatives

- **Using CSS selectors directly in various DOM manipulation libraries** (like jQuery, although it's less common in modern applications) can streamline such queries but may come with additional overhead due to the library's abstractions.
- Native methods like `getElementsByClassName` or `getElementsByTagName` may be alternatives for scenarios where specific selectors aren't necessary, although they do not support complex CSS selectors like `querySelectorAll`.

This benchmark highlights the importance of understanding the context in which these querying methods are used, as performance can vary significantly based on the overall structure of the DOM and the presence of matching elements.

Related benchmarks:

querySelectorAll vs. querySelector+querySelectorAll (version: 1)

Comparing performance of: querySelectorAll vs querySelector + querySelectorAll vs querySelectorAll again (in case of caching)

Created: 14 days ago by: Guest

Jump to the latest result

querySelectorAll

querySelector + querySelectorAll

querySelectorAll again (in case of caching)

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model gpt-4o-mini, generated 14 days ago):