Existe uma solução que adiciona o loader ligeiramente mais cedo…
Você tem alguma fonte sobre o impacto percebido no desempenho que afeta o ranqueamento de busca, ou você está se referindo a FCP/LCP? FCP e LCP são métricas específicas com requisitos técnicos, apesar de serem conceitos baseados na percepção. Além disso, note que o FCP não faz parte dos “Core Web Vitals” do Google (mas o LCP sim).
Mais detalhes em https://web.dev/lcp/:
Conforme especificado atualmente na API Largest Contentful Paint, os tipos de elementos considerados para o Largest Contentful Paint são:
- Elementos
<img>- Elementos
<image>dentro de um elemento<svg>- Elementos
<video>(a imagem poster é utilizada)- Um elemento com imagem de fundo carregada via a função
url()(em oposição a um gradiente CSS)- Elementos de bloco contendo nós de texto ou outros elementos filhos de nível de linha.
Se uma página remove um elemento do DOM, esse elemento não será mais considerado. Da mesma forma, se o recurso de imagem associado a um elemento mudar (por exemplo, alterando
img.srcvia JavaScript), esse elemento deixará de ser considerado até que a nova imagem seja carregada.
Esses requisitos tornam um pouco difícil a implementação; talvez um elemento de carregamento com uma imagem ou texto grande possa funcionar se, em vez de removê-lo do DOM, você o ocultar de outra forma? O spinner acima usa z-index para se ocultar, então talvez isso funcione… mas o próprio spinner não é suficiente porque não é uma imagem ou texto (é CSS).
Concordo que algum tipo de loader seria bom para usuários em conexões lentas, mas existem requisitos específicos a serem atendidos para o Google (e não sabemos se isso resolveria o problema levantado pelo autor da postagem original).