You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We could walk the DOM before rendering a template and remove the comment nodes and in some cases merge adjacent text nodes in order to get a better Lighthouse score, but in benchmarking we've found that comment nodes are very cheap, and that it's generally slower to do so.
While I do appreciate that each DOM node does have a memory cost, it seems like the predominant cost is in style calculation, layout, and paint, and on those metrics comments and adjacent text nodes are far cheaper than an element.
The text was updated successfully, but these errors were encountered:
The large DOM size audit does not contribute directly to your performance score. Style calculation, layout and paint tasks which block the main thread do contribute to the performance score via the TBT metric.
That being said this idea sounds fine to me. Our audits shouldn't implicitly encourage users to remove all their comment nodes if comment nodes have negligible performance impact.
@adamraine it would be great to get comments out of the audit altogether, or find some empirical cost-based weighting (memory?). From everything we can see, comments are nearly free compared to elements, and only show (slightly) up in tree-walk scenarios like cloning and non-cached queries.
Some HTML rendering systems use comments to separate static and dynamic parts of HTML. For example, in Lit, the template:
Will render as the HTML:
Or in the latest proposed API for the DOM Parts standard a template system would render the HTML:
We could walk the DOM before rendering a template and remove the comment nodes and in some cases merge adjacent text nodes in order to get a better Lighthouse score, but in benchmarking we've found that comment nodes are very cheap, and that it's generally slower to do so.
While I do appreciate that each DOM node does have a memory cost, it seems like the predominant cost is in style calculation, layout, and paint, and on those metrics comments and adjacent text nodes are far cheaper than an element.
The text was updated successfully, but these errors were encountered: