Very large transparent SVG should not count as LCP

[rik]

This technique is floating around to game the metric.

<img
    width="99999"
    height="99999"
    style="pointer-events: none;
        position: absolute;
        top: 0; left: 0;
        width: 99vw; height: 99vh;
        max-width: 99vw; max-height: 99vh;"
    src="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c3ZnIHdpZHRoPSI5OTk5OXB4IiBoZWlnaHQ9Ijk5OTk5cHgiIHZpZXdCb3g9IjAgMCA5OTk5OSA5OTk5OSIgdmVyc2lvbj0iMS4xIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIj48ZyBzdHJva2U9Im5vbmUiIGZpbGw9Im5vbmUiIGZpbGwtb3BhY2l0eT0iMCI+PHJlY3QgeD0iMCIgeT0iMCIgd2lkdGg9Ijk5OTk5IiBoZWlnaHQ9Ijk5OTk5Ij48L3JlY3Q+IDwvZz4gPC9zdmc+"
>

The base64 string encodes the following SVG

<svg width="99999px" height="99999px" viewBox="0 0 99999 99999" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
    <g stroke="none" fill="none" fill-opacity="0">
        <rect x="0" y="0" width="99999" height="99999"></rect>
    </g>
</svg>

[yoavweiss]

I agree this should not count as LCP, as the metric should be well-aligned with user experience, and this hack prevents that alignment and erodes trust in the metric.

/cc @clelland

[noamr]

Not sure there is a solution to hermetically seal against this type of hack in the spec, even if we introduce some intricate solution specifically for SVG with only transparent elements.

I think the solution for this lies outside the standard LCP metric - to detect LCP fraud in whatever piece relies on LCP for rewarding/penalizing the site somehow (e.g. search-engine ranking and the likes).

[noamr]

One thing that comes to mind though is to somehow take overlapping elements into account. If you have something big and then a lot of small things start to come and overlap with it, only count the non-overlapping parts as "early". Something like this:

• When a large image (SVG or otherwise) appears, it gets its full LCP candidate entry
• As more elements are added that overlap with it, the overlap area is deduced from the size of that early LCP

[onlinebizsoft]

I think this change solved this https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/speed/metrics_changelog/2023_04_lcp.md

[clelland]

It should solve that; I just need to write it up as a spec change before this can be closed.