In order to track an almost entirely dynamic DOM layout I am considering using the HTML5 data attribute to track elements.
Would placing one on each DOM element begin to affect load performance, or negatively affect other searching mechanisms such as getElementById or $(#Selector)?
It will not affect any other searching mechanism. As far as load performance goes, if you were to measure it down to the microsecond, sure... The more markup gets rendered, the slower it will be. If you're talking about data- attributes, the difference is probably negligible.
Related
Trying to reduce the amount of DOM nodes I did some research on this, but have not found any comparing numbers, like is it better to use two DOM elements instead of two pseudo-elements or is it better to use 20-characters text-nodes instead of 10-characters DOM-elements (assuming it contains much more extra parameters than a text-node (aren't they cached or something?))?
The target is to simplify work with big DOM tree (mostly a table with some structure in each cell with about a 30000 DOM-elements total).
I've read W3 specs on pseudo-elements, but did not found any useful info.
So is there any common rules or is it may be discovered only with benchmarks?
I've seen this question as well, but it did not help a lot, as my question is about comparing different nodes - which should be preferred to improve performance?
And yes, I know about the cell-reusing approach, but it also depends on the complexity of cells (in IE11 scrolling lagging a lot, much more than just render entire structure at once).
i wonder if there's a difference between
1.) 10,000 tablerow which is visible
2.) 10,000 tablerow which is hidden using display:none
what i want to know is that. if all 10,000 row is visible on the page, could it cause the page scrolling to lag?
but if i hide for example the 9000 of them. could this reduce the lagging? Thanks guys.
In general display: none; will save the browser some work.
The browser will start by parsing your HTML and building the so called DOM (document object model), when all the CSS is received it will go on and build the CSSOM (CSS object model). Those two combined will give the render tree.
With the render tree in hand the browser will perform a layout step (deciding where each element goes on the screen and how big it will be) and then paint the page on the screen.
When combining DOM and CSSOM to become the render tree, however, the browser will discard all subtrees that are display: none; and thus, have less work to do in the layout and paint step.
Great question! It is not too broad, it is not discussed enough.
I'm in the middle of researching this based on a lazy-loading issue I'm having and cross-referencing other websites like Twitter and Reddit feeds.
Lighthouse flags pages with DOM trees that:
Have more than 1,500 nodes total.
Have a depth greater than 32 nodes.
Have a parent node with more than 60 child nodes.
For example I see that Reddit scores a dismal 26.
"Avoid an excessive DOM size 1,456 elements" is included as a recommended action.
Reddit.com: Lighthouse says:
A large DOM will increase memory usage, cause longer style
calculations, and produce costly layout reflows. Learn more. React
Consider using a “windowing” library like react-window to minimize
the number of DOM nodes created if you are rendering many repeated
elements on the page. Learn more. Also, minimize unnecessary re-renders
using shouldComponentUpdate, PureComponent, or React.memo and skip
effects only until certain dependencies have changed if you are using
the Effect hook to improve runtime performance.
https://web.dev/dom-size/#how-to-optimize-the-dom-size
Just ran into this question and wanted to put my 2 cents as well
even though modern browsers get smarter on fast rendering and
machines are getting faster, the best practice still stand that don't
render too many table rows. Use pagination.
it also depends how you render your table rows. If you're using JS to
render it, it will definitely have a negative impact on scroll
performance. There are very good js templating solutions you can
minimize js execution overhead. Call me old-school but I rather using
less js rendering on the client.
Will it make any performance degradation if I use lot absolute and fixed positioning in my HTML app?
Any HTML experts?
Simple answer, no.
More complex answer, no, at least not measurably slower. The page will still be rendering the same amount of objects whether it decides where to place them or you explicity tell it where to place them.
No, it won't! :) Setting position variables will not affect performance as it not not loading anything externally, just telling where the object must be placed. In some cases, it is a necessity to be used.
No it wont. Just keep DOM as simple as possible without making it too deep. And use CSS selectors with maximum level of 3 qualifiers. The lesser the better.
For sites with very large numbers of DOM elements, is there be any performance benefit to presenting some of the content within an iframe? For example, the application I'm working on has a very large html-based tree which could contain tens of thousands of nodes at one time (albeit not loaded all at once). Putting aside the usability problems a tree this size presents, would there be any benefit to placing this content within an iframe, rather than within the main page? Do browsers handle memory differently for content embedded within iframes? Would this improve jquery selector performance by isolating this content? I'm most interested in how this applied to IE 7, although I would be curious if it differs between browsers.
+1 for a good question. I'm not aware of any differences in memory handling between frames and non-frames based content; I've written a few XHTML parsers and memory is memory; nodes take up memory regardless of where they are stored. All ID lookups are done by keys (hashtable), so the collections can be quite large with a non-linear impact.
That's the parsing and memory side; However, I've found that the rendering times can suffer on large innerHTML inserts, so try to use the document.createElement pattern instead (if applicable). I experienced this behavior in a variety of browsers, including IE7.
Where the DOM elements originate also matters. Are all the nodes rendered server-side, or do you send JSON to the client and create the tree in JavaScript? I can confirm that properly constructed JavaScript object trees can handle thousands of nodes very efficiently, so if your rendering scheme is client-based and all the nodes aren't displayed at once, the actual DOM will be much smaller.
The real decision point would be round-tripping. If you are rebuilding a complex page over and over, then that may be justification enough for breaking it out into frames, so that all that content doesn't need to be sent over the wire again and again.
Does it impact performance to have classes that are not used for styling on elements?
E.g.:
<div class="translatable">...</div>
where .translatable is used to find all the elements that are going to have their content dynamically altered in certain situations.
These classes increase the document load time (more text = more time) and have a very tiny impact on the time required to interpret any class reference (I assume class names are in hashtables and an extra name could cause such a hashtable to be allocated a little larger).
So... there will be an impact, but unless your unused classes make up a significant percentage of your CSS, it will be hard to see or measure. I can't see worrying about a single class.
if you are using it purely for lookups later then it should be fine but if you have a large document and then start updating that specific style then you are going to hit performance issues when the browser does a reflow and repaint.
Stoyan Stefanov of Yahoo! explains it quite well on his blog http://www.phpied.com/rendering-repaint-reflowrelayout-restyle/