Does using a document fragment really improve performance?

Question

I've got a doubt regarding performance in JS.

Say, I've got the next code:

var divContainer = document.createElement("div"); divContainer.id="container";
var divHeader = document.createElement("div"); divHeader.id="header";
var divData = document.createElement("div"); divData.id="data";
var divFooter = document.createElement("div"); divFooter.id="footer";
divContainer.appendChild( divHeader );
divContainer.appendChild( divData );
divContainer.appendChild( divFooter );
document.getElementById("someElement").appendChild( divContainer );

This code just creates the shell for some other functions to create a grid, the process to create the grid is very complex and with many validations and currently I'm using 2 methods to fill the grid, one creating the whole html in an array variable and the other one creating elements and appending them to a documentFragment.

My question is if there's really an improvement regarding performance when using fragments, as I understand them - they manage elements on memory, so they're not attached to the document, thus, not triggering DOM recalculation and other nasty stuff. But the way I'm creating my variables, they're not attached to any DOM Element until i append the container to the actual page.

So I was wondering if the previous code has better performance than using a document fragment that wraps it all like so:

var fragment = document.createDocumentFragment();
var divContainer = document.createElement("div"); divContainer.id="container";
var divHeader = document.createElement("div"); divHeader.id="header";
var divData = document.createElement("div"); divData.id="data";
var divFooter = document.createElement("div"); divFooter.id="footer";
divContainer.appendChild( divHeader );
divContainer.appendChild( divData );
divContainer.appendChild( divFooter );
fragment.appendChild( divContainer )
document.getElementById("someElement").appendChild( fragment.cloneNode(true) );

As I've already said, this is a question regarding performance, I know that as a best practice it's recommended to use fragments, but I can't take the thought out of my head that doing that just creates a new object in memory and does nothing, so I assume that ditching the fragment in this case is valid.

Hopefully some js guru / god will shine a light of hope in here and help us with this issue.

---

Edit: So, I've been looking around for stuff related to this issue and it seems that documentFragments doesn't necessarily means better performance.

It's just an "in memory" container of nodes. The difference between a fragment and say, a <div> is that the fragment has no parent and it will never be on the DOM, just in memory, which means that the operations made on the fragment are faster since there's no manipulation of the DOM.

W3C's documentation on documentFragments is very vague but to the point and also, everybody's favorite browser does not uses real fragments, instead it creates a new document according to this MSDN documentation. Which means, fragments on IE are slower.

So, the question prevails, if I create an element (a <div> for example) in a variable but DO NOT APPEND IT TO THE DOM, add elements (divs, tables, etc ) and stuff and after all the work has been done (loops, validations, styling of elements), that element is appended, is it the same as a fragment?

Given the fact that IE uses a "fake" fragment I'd say at least in IE using that approach (using an element such as a div, not a fragment) is better, I really don't care for IE but I need to test it ( office's policy ).

Also, if I create all the html on an array like so:

var arrHTML = ["<table>","<tr>", ....]; 

and then do this

document.getElementById("someElement").innerHTML = arrHTML.join(""); 

It's way faster on IE, but other major browsers ( FF, Chrome, Safari and Opera ) perform better when using a container and then appending it (fragment or div).

All of this is because the process to create all the elements is done really fast, around 8 - 10 seconds to create up to 20,000 rows with 24 columns, it's a lot of elements / tags, but the browser seems to freeze a few seconds when they're all appended at once, if I try and append them one by one, it's hell.

Thanks again folks, this is really interesting and fun.

Lymphangitis

Stick it on jsperf and see which is faster on your target audience's browsers. – Bostwick

I've used console's profile in firefox and chrome and they both executes in the same time ( around 180ms ) with real data in the header and data divs, i've tested the "vanilla" way without fragments, just appending all to a cointainer and that container append it to the DOM, also using fragments and creating the whole html on a variable and then adding an innerHTML to that variable, they all seem to work more or less the same, but my question is performance wise, which is better regarding memory and stuff like that. Thanks – Lymphangitis

From what I understand you'd use a document fragment to avoid a lot of reflows, but if you're just appending a small amount (such as what you have shown) it really isn't worth it. – Hartsock

The more elements you want to append, the greater the performance difference will be. – Seaway

Yeah, in this example i'm just appending 4 elements, but the process to create the grid could go from 1 row ( variable columns ) to 20,000 rows ( variable columns ) right now, the 2 methods are doing great, but i'm cleaning the code and this doubt is just eating my brains. Thanks to everyone interested in this. – Lymphangitis

@Bostwick jsPerf test results can be misleading. It's difficult to construct a jsPerf test that is truly representative of real-world DocumentFragment usage. The primary benefit of using DocumentFragments is that you avoid expensive page reflows and/or DOM traversal. None of the jsPerf tests here demonstrate the performance gains from avoiding page reflows and only the answer given by wolfram77 demonstrates the savings of avoiding extensive DOM traversal through the use of DocumentFragments. – Stableboy

Answer 1

Document Fragment is much faster when it is used to insert a set of elements in multiple places. Most answers here point out its un-utility, but this is to demonstrate its strength.

Lets take an example.

Say we need to append 20 divs in 10 elements with class container.

Without:

var elements = [];
for(var i=20; i--;) elements.push(document.createElement("div"));

var e = document.getElementsByClassName("container");
for(var i=e.length; i--;) {
  for(var j=20; j--;) e[i].appendChild(elements[j].cloneNode(true));
}

With:

var frag = document.createDocumentFragment();
for(var i=20; i--;) frag.appendChild(document.createElement("div"));

var e = document.getElementsByClassName("container");
for(var i=e.length; i--;) e[i].appendChild(frag.cloneNode(true));

For me using a document fragment turns out to be 16 times faster on Chrome 48.

Test on JsPerf

Konyn

This is the best answer. While the jsPerf test here does not incorporate page reflows (avoiding page reflows is the primary benefit of using DocumentFragments), it does illustrate the real performance gains in using DocumentFragments to avoid DOM traversal. The DocumentFragment code performs 2x as fast as the non-fragment code in Chrome 48 and nearly 4x as fast in IE11. If you are a developer who builds pages that render dynamically with JavaScript, this is why you use DocumentFragments. – Stableboy

Thanks! Yet to learn on page reflow, and when it occurs. This seems to be well detailed. – Konyn

@Konyn Why are you deep cloning the fragment? Couldn't you just appendChild(frag), works on all browsers. – Bolingbroke

@Bolingbroke I tried what you suggested, but it seems document fragments behave in the same way as normal elements, i.e. they get removed from the source and get added to the destination. However unlike elements, the contents of document fragment gets added, instead of the whole fragment, like it happens in case of an normal element, thus making it possible to add multiple elements in one go. – Konyn

@Bolingbroke you could just use appendChild(frag) only if you intention is to use the fragment just once. – Konyn

jsbench.me/mglaot54dp/1 – Annabel

Answer 2

Normally you'd want to use a fragment to avoid reflows (repainting the page). A good case would be if you were looping over something and appending within the loop, however, I think modern browsers optimize for this already.

I set up a jsPerf to illustrate a good example of when to use a fragment here. You'll notice in Chrome that there is hardly a difference (modern optimization at work, I presume), however, in IE7 I get .08 ops/sec without the fragment, 3.28 ops/sec with a fragment.

So, if you're looping over a large data set and appending A LOT of elements use a fragment instead so you only have one reflow. If you're only appending to the dom a few times or you're only targetting modern browsers it isn't necessary.

Hartsock

Yeah, i'm looping through a json object which varies in size, what i'm doing is creating an element in memory and appending stuff on each loop, and then that element is added to the page (DOM), so it's just one reflow instead of multiple ones, as i said, the method runs ok and it's really fast, both using fragments and creating the html in an array variable then adding it like this element.innerHTML = array.join(""); most browsers display the grid really fast and the worst scenario has been for 20,000 rows and it lasted 10 seconds. My doubt is if the fragment is really an improvement. Thanks! – Lymphangitis

@SamCcp yerp, if you're not appending to the DOM within the loop a fragment isn't going to speed it up. – Hartsock

Then another thing comes to mind, if you're appending elements to the DOM inside a loop, not even a fragment will help you, you're forcing the browser to do reflows right? then, what good are the fragments then? The plot thickens.... – Lymphangitis

@SamCcp You can just keep appending to the fragment then append the fragment to the DOM outside of the loop. – Hartsock

Yeah, but it's the same if i just keep appending elements to another element in memory and then just append that one element to the DOM after the loop, ditching the fragment and just using elements. Right? – Lymphangitis

@SamCcp Indeed, as long as its not actually being appended to the DOM it doesn't make much of a difference. I'd guess that a fragment would be very slightly faster, creating a DIV has a longer proto chain associated so I would imagine it would take slightly longer; but that would be in the realm of a few MS, not worth optimizing for. (DocumentFragment is directly under Node, an html element goes from HTMLSpanElement (or whatever relevant tag) to HTMLElement to Element to Node) – Hartsock

Alrigh, we're getting somewhere, documentFragments are on top of the hierarchy because they're nodes, so they're better than elements since they're tags and are not parsed when appended?, sweet! But as you said before, it seems that the improvement is just by some ms. I'll keep investigating on this since i'm a resource freak. Thanks! – Lymphangitis

Answer 3

I've written a jspref to test this and it appears the node fragment is 2.34 % faster

http://jsperf.com/document-fragment-test-peluchetti

Nelan

Thanks for that, testing it with firefox and safari both show that not using fragments is much faster, IE ( 8 ) just dies. But the question remains, Using Fragments is really better performant than just appending one element (with children in it, like the example) to the DOM? – Lymphangitis

@SamCcp in Firefox i have the same result as in chrome where there is no difference. – Nelan

Yeah, if you take a look at the browserscope from your jsperf, you'll notice that the best results are the ones without using fragments in all the browsers that have tested your jsperf, so based on that, i could say that using a fragment just slow things down, another thing to consider is that when the loop is too big, in IE ( 8 at least ) is better to use innerHTML than appending an element to the dom, fragment or not. – Lymphangitis

For nodes upto 1000, there is anyway no visible performance improvement, not even in millseconds, it just adds up programming complexity in rewriting logic. – Noncombatant

@AkashKava, not true if no logic has been written yet and you are deciding which to use. – Guib

@Guib I didn't get it, there is no evidence of fragment helps in anyway, it is theoretical. Instead can you provide one single evidence? – Noncombatant

@AkashKava, I didn't say using fragment is more performant than using div. I only said "adds up programming complexity" is not true. – Guib

any body notice below the chart - there exist metrics! For this it's operations per second (higher is better) LOL eg No fragment is superior – Quadrillion

@SamCcp This jsPerf test is flawed. The point of DocumentFragments is to avoid expensive page reflows and/or DOM traversals. This jsPerf test incorporates neither. The DOM manipulations performed by the jsPerf test are not visible and there are no page reflows. – Stableboy

Both make reflow once on same platform, but maybe the cloneNode(true) is the flaw? – Fulfill

If expensive page reflows and/or DOM traversals has to be done, then always take out the element and do it in memory. When inserted it reflows once. – Fulfill

Answer 4

I had the exact same question as the OP, and after reading through all the answers and the comments, it didn't seem like anybody really understood what the OP was asking.

I took a cue from the test Nicola Peluchetti posted and modified it a bit.

Instead of appending elements to a <div> and then appending to the documentFragment, the fragment test gets the elements appended directly to it (the documentFragment) instead of first to the <div>. Also, to avoid any hidden overhead costs, both tests begin by creating both the <div> container and the documentFragment, while each test only utilizes one or the other.

I took the original question to be, basically, is it faster to do a single append of nodes using a <div> or a documentFragment as the container?

Looks like using a <div> is faster, at least on Chrome 49.

http://jsperf.com/document-fragment-test-peluchetti/39

The only use case I can think of for documentFragment (at the moment) is if it takes less memory (which could be negligible), or if you have a bunch of sibling nodes to append which you don't want to put into a "container" element. The documentFragment is like a wrapper which dissolves leaving only its contents.

Lapoint

Answer 5

In my experience dom operations usually happen only after call stack is empty. If I put lot of dom operations in the loop, browser just freezes for some time and then displays everything at once. You can break the stack by using setTimeout to display result more frequently if you want. For this reason I believe that both methods should perform similarly. This is actually very strange sometimes, because if in one stack you change some element you will never see its state before the change (had this problem with progress notification object which innerHTML was never updated during the loop - just starting status and then final).

Sueannsuede

It depends on what browser and what DOM element. – Guib

Answer 6

<!DOCTYPE html>
<html>
<head>
    <title>TODO supply a title</title>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">

</head>
<body>
<div ms-controller='for1'>
    <ul>

    </ul>
</div>

<script>
    var ul = document.querySelector('ul');
    console.time('no fragment');
    for(var i=0;i<1000000;i++){
        var li = document.createElement('li');
        li.innerText = i;

        ul.appendChild(li);
    }
    console.timeEnd('no fragment');

    console.time('has fragment');;
    var frg = document.createDocumentFragment()
    for(var i=0;i<1000000;i++){
        var li = document.createElement('li');
        li.innerText = i+'fragment';
        frg.appendChild(li);

    }
    ul.appendChild(frg)
    console.timeEnd('has fragment');
</script>
</body>
</html>

the result is no fragment: 1615.278ms testFragment.html:36 has fragment: 2908.286ms

so,no Fragment is more faster. I think the reason is the chrome had do some thing.

Furnishing

you are nearly doubling the string size in 'has fragment', by doing +'fragment' 😬 – Musquash

the result is right.but you should not add +'fragment'.This is called the controlled variable – Kleist

Answer 7

The jsperf from wolfram77 contains an additional for loop in the non fragment example which is the main cause for the performance difference, not the DocumentFragment. By removing this additional for loop you can achieve the same result but the performance is completely different:

Example on jsperf.com

So I still don't see a performance benefit on the scripting part but there might be one in the browser when it has to repaint for each appended element.

Forwardlooking

on this results, the NoFragment destroys the fragment one, i can see your point on the repaint on the browser, but if you append just one element, there's only one repaint to be done. So this is negligible IMHO. – Lymphangitis

link is borken. – Plumcot

Wait, wolfram77 is showing that with the fragment, the extra loop is indeed not needed. This shows a use case where with fragment is faster. The loop is not needed with the fragment, because using cloneNode(true) clones all the children, and thus looping is not required. – Plumcot