SVGs and child nodes referenced from local SVG sprite count towards "Avoid an excessive DOM size"

Provide the steps to reproduce

1. Run LH on https://andro4all.com/

What is the current behavior?

SVGs pointing to a local svg are adding nodes like they were the whole svg.

<svg class="mrf-Icon mrf-Icon--s">
	<use xlink:href="#mrf-Icon--bullet"></use>
</svg>

becomes

<svg class="mrf-Icon mrf-Icon--s">
	<use xlink:href="#mrf-Icon--bullet">
		<!-- shadow root -->
		<svg id="mrf-Icon--bullet" viewBox="0 0 24 24">
			<circle cx="12.5" cy="12.5" r="4.5"></circle>
		</svg>
	</use>
</svg>

So, lighthouse evaluates this nodes too.

What is the expected behavior?

This svgs are pointing to a shared sprite SVG, so, lighthouse doesn’t have to add the nodes inside the use tag. This rule penalizes reusing svgs instead of adding a new svg all the time.

Replacing this SVGs for dummy nodes in this page, for instance, like

<span class="mrf-Icon mrf-Icon--s">
	<span xlink:href="#mrf-Icon--bullet"></span>
</span>

decreases the total by 376 nodes.

Environment Information

• Affected Channels: Devtools
• Lighthouse version: Lighthouse 4.0.0-beta
• Node.js version: macOS

[patrickhulce]

Just curious, will you count as dom objects actual pixels…?

Lighthouse counts the same number of pixels as the number of times snark has solved a GitHub issue 😉

Unless there’s evidence someone can point to that the original concern is not valid for SVGs with <use>, Lighthouse won’t be treating them any differently. I’m skeptical that rendering additional copies of an SVG is a completely free operation.

The goal of the audit is to capture the render/style/layout costs of many nodes. IIUC, using <use href> doesn’t necessarily eliminate the cost of extra DOM bookkeeping/rendering of having an extra copy of the SVG while replacing the SVGs with dummy spans does eliminate the associated costs.

Also keep in mind, this audit has absolutely no impact on the performance score and is just a diagnostic pointing to a potential issue. As with everything in the performance section, if the metrics are good, the score is good, skip the diagnostics. If the metrics are bad, then the diagnostics like this are a good place to start investigating.

[PerfectedApp]

Just curious, will you count as dom objects actual pixels…?