Benchmark: innerhtml vs removechild vs replacechildren

HTML Preparation code:

<div id="container"></div>

Script Preparation code:

var node = document.getElementById('container');

for(var i = 0; i < 1000; i++) node.appendChild(document.createElement('div'));

Tests:

innerHTML
var node = document.getElementById('container'); node.innerHTML = '';
removeChild
var node = document.getElementById('container'); while(node.firstChild) node.removeChild(node.firstChild)
replaceChildren
var node = document.getElementById('container'); node.replaceChildren();

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
innerHTML
removeChild
replaceChildren

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: 8 months ago)

User agent: Mozilla/5.0 (iPhone; CPU iPhone OS 18_6_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.6 Mobile/15E148 Safari/604.1

Browser/OS: Mobile Safari 18 on iOS 18.6.2

View result in a separate tab

Test name	Executions per second
innerHTML	21276488.0 Ops/sec
removeChild	54315196.0 Ops/sec
replaceChildren	17202370.0 Ops/sec

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):

LLMs can make mistakes. Check important info.

Let's break down the provided benchmark definition and test cases.

**Benchmark Definition**

MeasureThat.net uses JavaScript microbenchmarks to compare the performance of three different approaches:

1.  `innerHTML`: setting the inner HTML of an element
2.  `removeChild` (and its variants): removing children from an element using a while loop or the `removeChild()` method
3.  `replaceChildren`: replacing the children of an element using the `replaceChildren()` method

**Approaches**

Here's a brief overview of each approach, their pros and cons, and considerations:

*   **innerHTML**: This approach is often considered the fastest because it updates the DOM directly, which can be more efficient. However, this approach has a few drawbacks:
    *   It requires creating a new string with the updated content, which can lead to memory allocation overhead.
    *   If the HTML structure changes frequently, using `innerHTML` might not be the best choice due to potential DOM inconsistencies.

*   **removeChild**: This approach involves removing individual elements and re-appending them. While it's more flexible than `innerHTML`, it has some limitations:
    *   It requires creating a new array of elements or objects, which can lead to memory allocation overhead.
    *   If the child nodes are complex (e.g., have event listeners, attributes), this approach might not be suitable due to potential issues with these nodes.

*   **replaceChildren**: This approach is more efficient than `removeChild` because it only updates the children without creating new elements. However, it has its own set of challenges:
    *   It requires updating the child nodes' content and/or properties.
    *   If the child nodes are complex (e.g., have event listeners, attributes), this approach might not be suitable.

**Libraries and Special Features**

There is no explicit library mentioned in the benchmark definition. However, some libraries like jQuery or React might be used in a real-world scenario to achieve similar performance optimizations.

Some special JavaScript features, such as async/await or promises, are not explicitly used in this benchmark but can affect performance in other scenarios.

**Alternatives**

Other alternatives for improving performance in DOM manipulation include:

*   Using `textContent` instead of `innerHTML`
*   Creating a document fragment to update the DOM
*   Using Web Workers for computationally intensive tasks

These alternatives might be more suitable depending on the specific use case and requirements.

Related benchmarks:

innerhtml vs removechild vs replacechildren (version: 0)

Comparing performance of: innerHTML vs removeChild vs replaceChildren

Created: 3 years ago by: Guest

Jump to the latest result

innerHTML

removeChild

replaceChildren

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):