Il y a ceci, qui ajoute un chargeur légèrement plus tôt…
Avez-vous une source sur l’impact perçu sur le classement dans les résultats de recherche, ou faites-vous référence au FCP/LCP ? Le FCP et le LCP sont des concepts spécifiques avec des exigences techniques, même s’ils sont basés sur la perception. Notez également que le FCP ne fait pas partie des « Core Web Vitals » de Google (mais le LCP, si).
Voici quelques détails supplémentaires depuis Largest Contentful Paint (LCP) | Articles | web.dev :
Tel que spécifié actuellement dans l’API Largest Contentful Paint, les types d’éléments pris en compte pour le Largest Contentful Paint sont :
- Les éléments
<img>- Les éléments
<image>à l’intérieur d’un élément<svg>- Les éléments
<video>(l’image d’affichage est utilisée)- Un élément avec une image de fond chargée via la fonction
url()(par opposition à un dégradé CSS)- Des éléments au niveau du bloc contenant des nœuds de texte ou d’autres enfants d’éléments de texte au niveau en ligne.
Si une page supprime un élément du DOM, cet élément ne sera plus pris en compte. De même, si la ressource d’image associée à un élément change (par exemple, en modifiant
img.srcvia JavaScript), alors cet élément cessera d’être pris en compte jusqu’à ce que la nouvelle image soit chargée.
Ces exigences rendent la chose un peu difficile ; peut-être qu’un élément de chargement avec une grande image ou du texte pourrait fonctionner si, au lieu de le supprimer du DOM, vous le cachez d’une autre manière ? Le chargeur ci-dessus utilise z-index pour se cacher, donc cela pourrait fonctionner… mais le chargeur seul ne suffit pas car ce n’est pas une image ni du texte (c’est du CSS).
Je suis d’accord pour dire qu’un certain type de chargeur serait bénéfique pour les utilisateurs sur des connexions lentes, mais il y a des obstacles spécifiques à franchir pour Google (et nous ne savons pas si cela résoudrait le problème soulevé par l’auteur du sujet original).