There is this, which does add a loader slightly earlier…
Do you have a source on the perceived performance impacting search ranking or do you mean FCP/LCP? FCP/LCP do get specific and have technical requirements despite being perception based concepts. Also note that FCP isn’t part of Google’s “core web vitals” (but LCP is).
Some more details from https://web.dev/lcp/:
As currently specified in the Largest Contentful Paint API, the types of elements considered for Largest Contentful Paint are:
<img>elements<image>elements inside an<svg>element<video>elements (the poster image is used)- An element with a background image loaded via the
url()function (as opposed to a CSS gradient)- Block-level elements containing text nodes or other inline-level text elements children.
If a page removes an element from the DOM, that element will no longer be considered. Similarly, if an element’s associated image resource changes (e.g. changing
img.srcvia JavaScript), then that element will stop being considered until the new image loads.
These requirements make it a little difficult, maybe a loading element with a large image/text could work if instead of removing it from the DOM you hide it some other way? The spinner above uses z-index to hide itself, so maybe that could work… but the spinner itself isn’t enough because it isn’t an image or text (it’s CSS).
Agree that some sort of loader would be good for users on slow connections, but there are specific hoops to jump through for Google (and we don’t know if it would solve the issue covered by OP).