Sérgio Gomes

> The identification could be done client-side. Yes, definitely, the browser can determine that with 100% accuracy. However, that gives you the LCP for that particular client, which will not...

> If the same resource is common across all three, then it should definitely be preloaded. I don't agree with that. Preload is a pretty heavy-handed approach, and it's easy...

> Well I don't agree, except for what you noted about different image sizes I'm happy to go into more detail for any of those points! I don't really know...

> The main difficulty with detecting the LCP image would be the browser cache. Once an image is cached, then something else could end up being the LCP. I don't...

> I think, to a degree @sgomes - @westonruter suggestion can be scoped. For instance, LCP is only measured against items above the fold. So if the PerformanceObserver was running,...

> Agreed. But this is why I'm suggesting to look at the same page in the most common viewports for mobile, tablet, and desktop. If there is a common element...

I should note that [Chrome DevRel's own Priority Hints explainer reads](https://web.dev/priority-hints/#using-preload-after-chrome-95): > With the fix in Chrome 95 and the enhancement for priority hints, we hope that developers will start...

After some further research into this, I'd be happy with supporting this proposal if it moved to Priority Hints instead of preloads. Priority Hints solve some of my main concerns:...

> ensure that the LCP image is part of the critical assets needed for page rendering @dainemawer I completely disagree with this approach at a conceptual level, as I mention...

Thank you, @adamsilverstein! > I agree with most of your points about the potential tradeoff of prioritizing even the correct image and agree Priority Hints seems like a hopeful/safer path...