C’è questa soluzione, che aggiunge un loader leggermente prima…
Hai una fonte sull’impatto percepito delle prestazioni sul posizionamento nei risultati di ricerca, o ti riferisci a FCP/LCP? FCP e LCP sono metriche specifiche con requisiti tecnici, nonostante siano concetti basati sulla percezione. Nota inoltre che FCP non fa parte dei “Core Web Vitals” di Google (mentre LCP sì).
Alcuni dettagli in più da https://web.dev/lcp/:
Come specificato attualmente nella API Largest Contentful Paint, i tipi di elementi considerati per il Largest Contentful Paint sono:
- Elementi
<img>- Elementi
<image>all’interno di un elemento<svg>- Elementi
<video>(viene utilizzata l’immagine poster)- Un elemento con un’immagine di sfondo caricata tramite la funzione
url()(a differenza di un gradiente CSS)- Elementi a livello di blocco contenenti nodi di testo o altri elementi figli a livello di riga.
Se una pagina rimuove un elemento dal DOM, quell’elemento non verrà più considerato. Allo stesso modo, se la risorsa immagine associata a un elemento cambia (ad esempio modificando
img.srctramite JavaScript), quell’elemento smetterà di essere considerato fino al caricamento della nuova immagine.
Questi requisiti rendono la cosa un po’ difficile; forse un elemento di caricamento con un’immagine o un testo di grandi dimensioni potrebbe funzionare se, invece di rimuoverlo dal DOM, lo nascondi in qualche altro modo? Lo spinner sopra menzionato usa lo z-index per nascondersi, quindi forse potrebbe funzionare… ma lo spinner stesso non è sufficiente perché non è un’immagine né un testo (è CSS).
Concordo sul fatto che una sorta di loader sarebbe utile per gli utenti con connessioni lente, ma ci sono ostacoli specifici da superare per Google (e non sappiamo se risolverebbe il problema sollevato dall’OP).