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.
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'm using Scala to produce HTTP, HTML and CSS. I also intend to use Scala to produce Javascript but I haven't got to that stage yet.
What are the advantages of using separate style sheets? CSS offers a form of multiple inheritance by which you can organise the styling of your mark up. However Scala already has its own system of multiple inheritance and other functional languages provide their own powerful methods of problem decomposition and declarative composition. While producing separate style sheets, adds algorithmic complexity and hinders the production of comprehensible clean code.
One of the claimed advantages of separate style sheets is that they use less bandwidth. However I find it difficult to believe that CSS uses significant bandwidth compared to images let alone video. So do separate style sheets give advantages to search engine ranks and site classification? Do they speed up or slow down rendering and layout? Do they help accessibility and user defined style? I would have thought not using separate style sheets might actually speed up delivery in HTTP 1.1 if not in 2.0
Similarly with Head and Body nodes /Tags. Do they serve any advantage to justify the added complexity of producing them programmatically? They don't seem to make any functional difference to what the browser produces.
So the question is how important are separate style sheets and Body and Head nodes to producing optimal web sites? Is it OK to put CSS into the HTML leaf Nodes?
The advantages to using separate stylesheets:
Cachability: no need to re-load the same style over and over again
Smaller size: even with gzip compression, 400 div tags all styled alike will be more bytes on the wire per-page than the page without the styles inlined.
Possibility: Some CSS cannot be expressed in an inline style. For example, any pseudo-element or state selector (:hover, :focus, etc.)
DRY: not applicable if you are building a style tree at compile time to apply to an HTML tree at compile time.
The disadvantages:
Speed: inline styles will be faster to render, since when the browser parses the tag it knows what styles apply.
Locality: inline styles make it easy to see what the element will look like (browser debugging tools make this a moot point)
html / head / body - do I need them?
The general consensus seems to be "yes", principally because you are more likely to run into obscure browser bugs if you don't include them (since the "how to choose what to make a child of which element" algorithm isn't blindingly obvious and some of the corner cases aren't necessarily obvious to the developer).
I would like to know how the browser handles CSS rules that come after most (if not all) of the HTML. Will it have to reparse the whole page due to the new rules or does it use some other kind of technique to handle this type of situation? Thanks.
There are many cases when a repaint must occur, and in many occurences in a page lifetime the DOM is changed.
But once the page is parsed, there is no reason to parse it again, all changes are made on the in memory DOM.
This being said, you should put the CSS links in the HEAD because
it lets the browser start their download faster
it complies with HTML4 norm ("it may only appear in the HEAD section of a document")
it lets the browser start the rendering sooner
it lets your colleagues and your future yourself not be surprised when maintaining the code
Relayout and repaint, perhaps. (That is, if it has already started rendering it and the styles loaded require different display.)
Reparse, no. Style sheets are purely presentational; they do not affect the parsing.
Assuming that the browser has already started rendering the page when it sees the additional CSS (there are quite a few browser-specific triggers for this behavior) and assuming that the new rules result in CSS property changes for at least one element, the browser will simply mark that element as one that needs redrawing.
This will result in any visible changes to the page being shown the next time the browser repaints part of its window.
It's important to keep in mind that modern browsers do all of this asynchronously and schedule events like applying new CSS, recalculating layout and painting to the screen mostly (but not totally) independently of each other.
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.
I have a 50x50px div I want to display on my homepage as fast as possible.
Is it faster for me to do
<div style="height:50px;width:50px">
Or to assign it a class to avoid the inline style:
<div class="myDiv">
And put the myDiv class in a CSS file in the HEAD section of the HTML page?
My thought was that the first one should be faster since it doesn't need to request and recieve a CSS? I guess ultimatley I'm asking if BODY and HEAD get rendered sequentially or in parallel.
Without HEAD loading first there can be no BODY.
Before your BODY gets rendered, it has has to be loaded first. And if it is loaded, then the HEAD has already been loaded.
You're probably interested in whether a browser can load simultaneously both CSS files and the HTML document itself. It will depend on the browser implementation, but I believe most can download at least two documents simultaneously.
One other important thing is that the more files a document consists of, the more chances the request for one of them gets lost. So by using inline CSS you make sure the CSS never gets lost.
But I must point out that inline CSS is considered a bad style. Once you have a sufficient amount of markup, you will find it increasingly difficult to update your pages all at once. You will inevitably be losing one or the other instance. It is a much better idea to declare all styles in a separate document and reference them from pages. This way, when you need to change some color, you do it in one place and not in 37 places to be found in your pages.
As others already pointed out, the right thing to do would be to put the styles in an external file and refer to it in the <head> part of your document.
But if you're going for fast (and this is what you were asking for) then you should use the inline-declaration like
<div style="height:50px;width:50px">
There are several reasons for that:
You don't have to load an external file. This is very slow (compared to the next reason) since there is an additional HTTP request involved which (on top of the request and download itself) might be held back by other external files like JavaScript, favicons etc.
So it will already load faster if you put your declaration in some <style> tags on the same document. But then there is the next reason.
The browser does not have to look through the DOM tree and search for nodes with the class myDiv to apply the styles to. It finds the <div> and immediately (or at the next render turn) applies the style information.
This second delay will hardly be noticeable but if you are going for high performance, this is the way to go.
I agree that these may somewhat be theoretical reasons but here you go. :-)
There are cases when this would be a "good" practice. For example, you have a high value landing page, that requires about 500 bytes of CSS to support, verses the 200K Style sheet.
While true, that they customer will have to download that file on the NEXT page, time to render is often most important on the landing page.
Also, AFAIK, browsers will not begin rending until the entire CSS file is downloaded, which is not the case for inline styles. But yes, Best Practices, and 98% of the time you want to put CSS in a single linked file.
Use an embeded css file. After the first request the file will be cached by the browser and won't have to be downloaded again. Making the page load faster and reducing the strain on your server.
Placing styles inline is not only ugly it also undermines the whole cascading thing.
The differences in performance will be imperceptible and should be irrelevent. Instead of worrying about premature optimisations like this be more concerned with doing the "right thing" - and in this case the right thing is to use external style-sheet files for your CSS as it is more maintainable and separates concerns.