Consider including SVG elements

[npm1]

Currently the API only includes image inside of SVG. We should include SVG elements as a whole. In order to do this, we'd need to answer some questions:

1. What should be the rendering time of an SVG element?
2. What should be the size for the LCP algorithm?

[npm1]

Related issue (should make sure these APIs behave similarly when tracking similar types of content): w3c/element-timing#56

[yoavweiss]

One interesting compication to take into account: SVG elements behave slightly different than SVG images, in that they can load other images. We should make sure that LCP takes that behavior into account, and considers the SVG image including resources it may have downloaded.

[yoavweiss]

Strong support for this last time we discussed it. Needs someone to pick up the task.

[benschwarz]

@yoavweiss, I'd like to resurface this issue for discussion. SVGs are content and IMO shouldn't be disregarded.

On sites where SVG is used for the initial viewport, no LCP can be reported. This is true of Chrome Devtools, CrUX and Lighthouse.

Example	Image
Chrome devtools
Pagespeed

How can we go about revisiting SVGs inclusion to LCP evaluation?

[noamr]

Perhaps we could treat SVG as in image if it is made accessible as an image, like in https://www.deque.com/blog/creating-accessible-svgs/?

<svg role=img>
   <title>...</title>
</svg>

Then we can treat this whole SVG as one big image, as if it was an <img src="foo.svg"> with equivalent sizing etc