Preloader e Core Web Vitals: cuidados para não prejudicar seu WordPress
LCP, INP, CLS — essas métricas do Google afetam diretamente o ranqueamento do seu site. Um preloader mal implementado pode prejudicar todas elas. Entenda os riscos reais e como mitigá-los sem abrir mão da experiência visual.
O que são Core Web Vitals
Core Web Vitals são três métricas definidas pelo Google para avaliar a experiência real do usuário em páginas web. Desde 2021 fazem parte dos sinais de ranqueamento:
- LCP (Largest Contentful Paint): quando o maior elemento visível da página é renderizado. Meta: < 2,5s
- INP (Interaction to Next Paint): quão rápido a página responde a interações do usuário. Meta: < 200ms
- CLS (Cumulative Layout Shift): quanto o layout se move de forma inesperada. Meta: < 0,1
Impacto no LCP
O LCP é a métrica mais afetada por um preloader. A razão é direta: o preloader
é uma sobreposição com position: fixed e z-index altíssimo.
Enquanto ele está visível, o maior elemento de conteúdo da página está tecnicamente
presente no DOM mas inacessível visualmente.
Como o Lighthouse mede o LCP com preloader
O Lighthouse (ferramenta do Google que mede Core Web Vitals em laboratório) identifica o LCP como o momento em que o maior elemento visível é pintado. Se o preloader bloquear esse elemento visualmente durante a medição, o LCP registrado será mais alto.
O CrUX (Chrome User Experience Report), que mede usuários reais, também pode ser afetado. Usuários que esperam o preloader antes de ver o conteúdo contribuem com um LCP maior para a média do site.
O que fazer
- Desative o preloader nas páginas mais críticas para SEO (especialmente as indexadas com prioridade alta)
- Configure um tempo mínimo muito curto (100–200ms) ou zero nessas páginas
- Use o controle por página para ser seletivo — não precisa desativar em todo o site
Impacto no INP
O INP mede a capacidade de resposta da página a interações. O preloader em si raramente afeta o INP diretamente, com uma exceção importante:
Se o JavaScript do preloader for mal escrito e bloquear a thread principal por tempo significativo (mais de 50ms contínuos), pode aumentar o INP. Isso acontece principalmente quando o preloader usa bibliotecas pesadas ou executa processamento desnecessário durante a inicialização.
Animações CSS executadas via GPU (como rotação de spinner) não afetam o INP.
O JavaScript apenas monitora o evento window.load — uma operação
extremamente leve que não prejudica a thread principal.
Impacto no CLS
O CLS mede deslocamentos inesperados no layout. Um preloader que cobre toda a
tela com position: fixed geralmente não contribui para o CLS enquanto
está ativo — porque está em cima do conteúdo, não deslocando elementos.
O risco está no momento da saída: quando o preloader desaparece, se o layout ainda está sendo montado (imagens sem dimensões definidas, fontes ainda carregando), o usuário pode ver elementos se movendo. Esse CLS não é causado pelo preloader em si, mas é revelado por ele.
width e height explícitos em imagens.
Isso reserva o espaço no layout antes do carregamento e elimina o principal
contribuidor de CLS — com ou sem preloader.
JavaScript e thread principal
O JavaScript de um preloader bem implementado é minúsculo e assíncrono. O que pode criar problemas:
- Script carregado no
<head>semdefer: bloqueia o parsing do HTML. O preloader não deve usar scripts síncronos no head. - Dependência de jQuery para operação simples: exige que o jQuery seja carregado antes de qualquer ação do preloader — criando uma dependência desnecessária.
- Animações JavaScript (GSAP, Anime.js) pesadas: podem bloquear a thread principal e aumentar o INP.
O script do preloader deve ser carregado no rodapé ou com defer,
e as animações devem ser CSS — não JavaScript.
Recursos externos
Cada requisição a um servidor externo tem latência. Se o preloader precisa buscar um arquivo GIF animado em um CDN, ou uma animação Lottie em outro servidor, esse carregamento pode demorar — e o preloader fica visível até os recursos estarem prontos.
Um preloader que depende de recursos externos pode ironicamente permanecer visível por mais tempo do que o próprio conteúdo da página demoraria para carregar.
Prefira: animações CSS puras e embutidas no stylesheet do plugin. Nenhuma requisição adicional, nenhuma latência.
Carregamento condicional de assets
Um problema comum em plugins de preloader: carregar o CSS e o JavaScript em todas as páginas, mesmo nas que o preloader não está ativo.
Isso cria um peso desnecessário — arquivos baixados pelo navegador que não fazem nada naquela página. Para o Core Web Vitals, isso representa bytes desperdiçados na transferência e processamento no parser.
O correto: o plugin deve verificar se o preloader está ativo para aquela URL
antes de enfileirar os assets com wp_enqueue_scripts.
Quando desativar o preloader por CWV
Se você monitora os Core Web Vitals do seu site (via Google Search Console ou PageSpeed Insights) e perceber regressões após ativar o preloader, avalie:
- Desative o preloader nas páginas com pior LCP e observe se melhora
- Reduza o tempo mínimo de exibição ao mínimo necessário
- Verifique se os assets (CSS/JS) são carregados condicionalmente
- Se os problemas persistirem nas páginas mais importantes para SEO, desative-o nelas completamente
Plugin com carregamento condicional e controle por página
O Smart Preload DL carrega assets apenas onde o preloader está ativo e permite desativar seletivamente em páginas críticas para SEO.