Preloader deixa o WordPress mais lento? Impacto real na performance
Essa é uma das perguntas mais frequentes antes de instalar um preloader. A resposta honesta é: depende de como foi implementado. Entenda o que muda de verdade, o que é mito e o que você precisa monitorar.
Velocidade real vs. velocidade percebida
Antes de responder se o preloader deixa o site mais lento, é fundamental entender essa distinção. São duas métricas completamente diferentes:
Velocidade real é o tempo que o servidor e o navegador levam para transferir e renderizar o conteúdo. É medida em milissegundos, aparece no PageSpeed Insights e é o que os Core Web Vitals avaliam.
Velocidade percebida é a sensação subjetiva do usuário. Um site que carrega em 3 segundos com uma animação elegante pode parecer mais rápido do que um que carrega em 2 segundos com layout se montando aos pedaços.
Um preloader atua exclusivamente na velocidade percebida. Ele não move um byte de conteúdo a mais. A mesma quantidade de dados é transferida — o preloader apenas substitui o "vazio" visual durante esse processo.
O que um preloader NÃO faz
- Não comprime imagens
- Não reduz requisições HTTP
- Não melhora o TTFB (Time to First Byte)
- Não reduz o LCP por si só
- Não melhora automaticamente o score do PageSpeed
- Não substitui otimização real de performance
O que realmente impacta na performance
O preloader em si introduz alguns recursos adicionais na página. O impacto depende da qualidade da implementação:
JavaScript
O script do preloader precisa ser executado para monitorar o evento window.load
e remover a sobreposição. Um script bem escrito tem menos de 1 KB minificado e não
bloqueia o parsing do HTML se carregado com o atributo defer ou no rodapé.
O problema real ocorre quando o plugin de preloader depende de jQuery. O jQuery carregado no WordPress pesa cerca de 30 KB minificado e gzip. Se o jQuery já está sendo carregado por outros plugins, não há impacto adicional — mas se você tem um site muito enxuto, isso pode mudar o panorama.
CSS
As animações CSS de um preloader são geralmente muito leves (menos de 2 KB) quando implementadas com CSS puro. O problema surge quando plugins carregam folhas de estilo completas em todas as páginas, mesmo onde o preloader não está ativo.
O ideal é que o CSS seja carregado condicionalmente — apenas nas páginas onde o preloader está configurado para aparecer.
Requisições externas
Alguns plugins buscam animações (Lottie, GIFs, SVGs) em CDNs externos. Cada requisição adicional tem latência. Um preloader que faz 2 ou 3 chamadas para servidores externos antes de inicializar a animação já impacta o TTFB percebido.
Prefira preloaders com animações CSS ou SVG embutidos — sem dependências de rede.
Impacto nos Core Web Vitals
Aqui está o ponto mais crítico para sites que levam SEO a sério:
LCP (Largest Contentful Paint)
O LCP mede quando o maior elemento visível da página é renderizado. Se esse elemento (normalmente uma imagem de hero ou um bloco de texto grande) está coberto pelo preloader, o Google pode registrar um LCP mais alto — porque o elemento ficou "invisível" para o usuário por mais tempo.
Na prática, o Google considera o LCP do conteúdo real, não do preloader em si. Mas a sobreposição pode interferir na forma como o Lighthouse e o CrUX medem o momento em que o elemento se torna visível.
INP (Interaction to Next Paint)
O preloader em si não impacta diretamente o INP, a menos que o JavaScript seja mal escrito e bloqueie a thread principal por tempo significativo. Animações CSS são executadas na GPU e não afetam a thread JavaScript.
CLS (Cumulative Layout Shift)
Um preloader que cobre toda a tela com posição fixed e desaparece
com fade-out geralmente não contribui para o CLS. O risco está no momento da
remoção: se o layout se "montar" de forma visível após o fade-out, isso pode
gerar shifts pontuáveis.
Boas práticas para minimizar o impacto
| Prática | Por quê importa |
|---|---|
| JavaScript vanilla, sem jQuery | Menos dependências, menos peso |
| CSS e JS carregados condicionalmente | Assets não são carregados onde não são usados |
| Sem requisições externas | Sem latência adicional de rede |
| Animação CSS pura (não JavaScript) | Executada na GPU, sem bloquear a thread principal |
| Safety timeout configurado | Garante que o preloader some mesmo em casos de falha |
| Desativado em páginas críticas de SEO | Não interfere no LCP das páginas mais importantes |
Tempo mínimo e safety timeout
Dois parâmetros que muitos desenvolvedores ignoram e que têm impacto direto na experiência:
Tempo mínimo: define por quanto tempo o preloader deve aparecer, mesmo que a página carregue muito rápido. Sem esse parâmetro, o preloader pode piscar por 50ms — uma experiência que parece um bug, não um recurso. Um valor entre 300ms e 800ms é adequado para a maioria dos casos.
Safety timeout: define o tempo máximo que o preloader pode permanecer visível. Isso protege o usuário em casos onde um recurso demora mais do que o esperado para carregar ou falha completamente. Sem esse parâmetro, um único recurso lento pode travar o preloader indefinidamente. Valores entre 3 e 8 segundos são razoáveis.
Preloader com carregamento condicional de assets
O Smart Preload DL carrega CSS e JS apenas nas páginas onde o preloader está ativo, usa JavaScript vanilla e não faz requisições externas.