11

I’m thinking of using HTML5 data attributes for easier third-party scripting of my application. So, consider two cases:

  1. There are 10'000 HTML elements on page like <div>Sticker</div>.
  2. There are other 10'000 HTML elements like <div data-id="{{id}}" data-category="{{category-id}}">Sticker</div>.

The second case (presence of attrs) probably affects DOM / rendering performance, doesn’t it? If so, how much?

Just to clarify, I don’t plan to use data attributes on my own, just exposing them for third-party scripts or browser addons. Consider dotjs or so. With data attributes it’s very easy to scrape / crawl page.

Ben
  • 51,770
  • 36
  • 127
  • 149
Paul Miller
  • 1,960
  • 1
  • 13
  • 15
  • 2
    Excuse me but why exactly didn't you test and benchmark each solution ? – Denys Séguret Nov 23 '12 at 12:49
  • The amount of data always affects performance. Can you be more specific about your concerns? Is loading your main concern? Or manipulation? Or data transfer? Etc... – Lukas Eder Nov 23 '12 at 12:50
  • My main concern is manipulation, user interaction. Performance of scrolling, responding to DOM events, CSS / DOM query selections. For example, does it affect `document.querySelectorAll('div')` etc? I have single-page web app which generates this kind of HTML from lightweight JSON feed from the server, so the size isn’t a concern. As for benchmarking: it’s hard to benchmark all aspects of using this. Maybe people that are familiar with implementations of renderer engines know something that can’t be benchmarked. – Paul Miller Nov 23 '12 at 12:55
  • Both cases will obviously affect performance. As a rule, the less you have DOM nodes, the faster the browser will process the page. You could use Ajax to add nodes when they are needed or design a REST API that will allow some flexibility in the HTML your application serve. – Eric Nov 23 '12 at 12:59
  • 1
    I know-I know, the question is: **how** the presence or lack of HTML attributes (`data-id`, `consumer-id`) in these nodes affect performance. – Paul Miller Nov 23 '12 at 13:13

2 Answers2

24

The primary perf hit this causes is in Parsing HTML. This time is captured and shown in the Chrome DevTools timeline, but in the great scheme of things, it's quite small.

Data attributes don't affect the renderTree and therefore the impact to Layout and Paint is zero. querySelector('div') performance will not be affected either. What performance influence this could have is just that you're storing truth in the DOM, so you'll be doing DOM manip to read the values out. Grabbing an element to read data off (with elem.dataset) will always be slower than grabbing that data out of a structure that's not on the DOM. So you can use the CPU profiler or Timeline to ascertain the perf overhead of manip inside the app. Depends really on how much and how often.

TL;DR: no impact to rendering/scrolling. super-minimal impact to page load time. small impact to runtime performance.

All these things are measurable with the Chrome DevTools Timeline.

Paul Irish
  • 47,354
  • 22
  • 98
  • 132
2

For data attributes, there are two interesting articles that it's important to read:

1- https://hacks.mozilla.org/2012/10/using-data-attributes-in-javascript-and-css/

  • The performance of reading data-attributes compared to storing this data in a JS data warehouse is bad. Using dataset is even slower than reading the data out with getAttribute().
  • Some browsers [IE] have a support problem: http://caniuse.com/#feat=dataset
  • Here you can find a performance measure for each browser: http://jsperf.com/data-dataset

2- http://html5doctor.com/html5-custom-data-attributes/

  • As data attributes become more widely used, the potential for clashes in naming conventions becomes much greater
  • From a performance point of view, accessing the DOM via getAttribute() is obviously slower than accessing to a JS variable, event stored in an array, so the use case you give of a JS game using it to store values will probably never happen : developers will use it to transmit info from server to client, but once the DOM has been harvested, it’s best to keep all the values in JS for quicker access

So, in my opinion, if you have atencion to variable names, if you don't care with some problems in IE (maybe only IE7<, because I think that in 9 and 8 data attr will work ), use data attributs will be a nice solution. About the performance, you can try the link above and see the differences, but I think it's bether to store the values in a consistent data structure in Javascript variables.

red_alert
  • 1,738
  • 14
  • 24
  • Just to clarify, I don’t plan to use data attributes on my own, just exposing them for third-party scripts or browser addons. Consider dotjs or so. With data attributes it’s very easy to scrape / crawl page. – Paul Miller Feb 21 '13 at 19:50
  • 1
    *“The performance of reading data-attributes compared to storing this data in a JS data warehouse is bad.”* – I've just written [a jsPerf](http://jsperf.com/getattribute-vs-property-vs-variable) for that. For Chrome it's true. But it seems Firefox has almost achieved zero impact! – tomekwi Apr 11 '15 at 20:03