Vídeos de fundo, autoplay e Core Web Vitals

#O que um vídeo de fundo realmente custa em 2026

Um hero com movimento vende atmosfera. Também compete pelo mesmo orçamento de rede, CPU e paint que o título, o CTA e a imagem que o Lighthouse trata como Largest Contentful Paint. Em sites WordPress geridos a partir de Portugal e servidos a clientes em PT, ES e DE, o padrão que mais aparece nas auditorias é o mesmo: o vídeo entra no HTML inicial, o poster é irrelevante ou inexistente, e o autoplay falha em Safari porque faltou muted ou playsinline.

Este tutorial trata o vídeo de fundo como um recurso de performance, não como um embelezamento. A pergunta útil não é “como faço o ficheiro tocar”, e sim “em que condições o movimento merece bytes no caminho crítico”.

Nos browsers modernos, autoplay sem gesto do utilizador só é fiável quando o áudio está silenciado. A documentação da MDN sobre autoplay e o elemento video descrevem exatamente esse contrato. O guia da web.dev sobre otimizar LCP mostra porque um vídeo mal colocado empurra o maior elemento da viewport para fora do orçamento de 2,5 s.

#Políticas de autoplay com muted

Chrome, Firefox, Edge e Safari permitem autoplay de media quando o elemento está muted (ou o volume efetivo é zero) e, no iOS Safari, quando playsinline está presente. Sem estes atributos, o play() devolve uma Promise rejeitada. O hero fica com um frame preto ou com o poster congelado, e o visitante assume que a página está partida.

Atributos mínimos para um fundo decorativo:

<video
  class="hero-video"
  autoplay
  muted
  loop
  playsinline
  preload="none"
  poster="/media/hero-poster.avif"
>
  <source src="/media/hero.webm" type="video/webm" />
  <source src="/media/hero.mp4" type="video/mp4" />
</video>

Notas práticas que evitam tickets de suporte:

• muted tem de estar no markup. Definir video.muted = true só em JavaScript chega tarde para a primeira tentativa de autoplay em alguns WebViews.
• playsinline é obrigatório no iOS; sem ele o Safari tenta ecrã completo e aborta o autoplay de fundo.
• loop sem faixa de áudio reduz surpresas quando o utilizador reativa o som por engano noutro separador.
• Não dependa de autoplay sozinho: chame video.play().catch(() => {}) depois de anexar o src, e trate a rejeição como estado normal em redes lentas ou com poupança de dados ativa.

Em Portugal, muitos formulários de contacto abrem em telemóveis com poupança de dados da operadora. Nesse cenário o browser pode adiar media mesmo com atributos corretos. O poster deixa de ser “nice to have” e passa a ser o único conteúdo estável do hero.

#Poster, LCP e o primeiro paint útil

Se o maior elemento da viewport inicial for o <video>, o LCP espera por frames descodificados. Em ligações 4G instáveis isso empurra o LCP para 4-6 s com facilidade. A correção padrão é tratar o poster como o candidato a LCP e só depois substituir por movimento.

Regras que funcionam em produção:

1. Exporte o poster no mesmo enquadramento do primeiro frame do vídeo (evita CLS quando o vídeo arranca).
2. Sirva o poster em AVIF ou WebP com dimensões explícitas no CSS ou nos atributos width/height.
3. Faça preload do poster (<link rel="preload" as="image" href="...">) se ele for o LCP declarado, não do ficheiro de vídeo.
4. Não coloque preload="auto" no <video> do hero. Isso compete com CSS e fontes no caminho crítico.

A web.dev resume o princípio: otimize o recurso que realmente pinta o LCP. Num hero com vídeo, esse recurso é quase sempre a imagem estática, não o stream.

Numa landing de serviços WordPress dirigida ao mercado lusófono europeu, medimos o mesmo template duas vezes: com src no HTML inicial o LCP mediava acima de 3,8 s em lab mobile; com poster AVIF no HTML e src injetado após window.load o LCP caiu para a faixa do poster (~1,6-2,1 s), e o vídeo arrancava 1-2 s depois sem bloquear o CTA.

#Preload: none, metadata e auto

O atributo preload controla quanto o browser descarrega antes de um gesto explícito:

Para fundos, o default sensato é preload="none" mais um src diferido. Se o markup já inclui <source>, alguns browsers ignoram parcialmente a intenção de none. A abordagem mais previsível é omitir src/source no HTML inicial e atribuir o URL só quando as condições de motion e viewport forem cumpridas.

<video class="hero-video" muted loop playsinline preload="none"
       poster="/images/hero-poster.avif" data-src="/videos/hero.webm"></video>
<script>
  const video = document.querySelector('.hero-video');
  const allowMotion = !matchMedia('(prefers-reduced-motion: reduce)').matches;
  if (video && allowMotion && matchMedia('(min-width: 768px)').matches) {
    addEventListener('load', () => {
      video.src = video.dataset.src;
      video.play().catch(() => {});
    }, { once: true });
  }
</script>

Este padrão mantém o HTML inicial leve, respeita motion reduzido e evita gastar dados móveis em movimento decorativo abaixo de 768 px.

#prefers-reduced-motion sem meias medidas

A media query prefers-reduced-motion: reduce não é um detalhe de acessibilidade opcional. Visitantes com vestibulopatia, migrânea ou simplesmente com a opção ativada no sistema operativo pedem menos movimento. Um loop infinito atrás do texto falha esse pedido.

Implementação mínima e honesta:

@media (prefers-reduced-motion: reduce) {
  .hero-video {
    display: none;
  }
  .hero {
    background-image: url("/images/hero-poster.avif");
    background-size: cover;
  }
}

No JavaScript, a mesma condição deve impedir a atribuição de src. Esconder o elemento com CSS depois de o ficheiro já ter sido descarregado não recupera a largura de banda gasta.

Se o vídeo transporta informação (demonstração de produto, tutorial), não o use como fundo silencioso. Coloque-o num player com controlos, legendas e botão de play explícito. Fundo decorativo e conteúdo informativo são contratos diferentes com o utilizador.

#Armadilhas do media library no WordPress

O media library do WordPress foi desenhado para imagens e PDFs. Vídeos de hero expõem vários atalhos perigosos:

• Upload direto para uploads/ sem reencode. Um .mov de 80 MB filmado no iPhone passa a URL pública. O tema faz <video src="...mov"> e o primeiro visitante em 4G paga a fatura.
• Plugins de “background video” que injetam YouTube no above-the-fold. O iframe puxa o player completo, cookies e scripts de recomendação antes do primeiro paint útil. O LCP e o INP sofrem mesmo com fachada mal configurada.
• Dependência de oEmbed no conteúdo do hero. O bloco Embed resolve o provider no servidor, mas o HTML final ainda é um iframe pesado. Para fundo, prefira ficheiro self-hosted curto ou um shortcode que só imprime <video> com poster.
• Falta de loading strategy no tema. Muitos temas filhos copiam o markup do customizer sem preload="none" e sem teste em staging com throttling 4G.
• CDN que cacheia o HTML com src absoluto de staging. Depois do go-live o vídeo 404 e o poster fica sozinho - o que, ironicamente, é melhor para performance, mas parte a narrativa visual.
• Áudio residual no ficheiro. Designers exportam “sem som” mas deixam uma faixa silenciosa. Alguns browsers tratam isso de forma inconsistente face a autoplay. Remova a faixa com FFmpeg (-an) e volte a gerar WebM/MP4.

Fluxo de trabalho que reduz regressões:

1. Reencode local (WebM + H.264 MP4), alvo tipicamente abaixo de alguns megabytes para loops de 6-12 s em 720p ou 1080p cropado.
2. Carregue o poster otimizado e o vídeo via SFTP ou media library, mas referencie-os no tema com caminhos estáveis.
3. Teste em Safari iOS real, Chrome Android e Firefox desktop com prefers-reduced-motion ligado.
4. Meça LCP no PageSpeed Insights e no campo (CrUX) depois de uma semana, não só no Lighthouse local.

Veja também os nossos serviços de otimização de velocidade WordPress quando o gargalo já não é só o markup do hero.

#Self-host versus embeds de terceiros

YouTube e Vimeo resolvem transcoding e CDN. Para um fundo full-bleed no primeiro ecrã, o custo de JavaScript do player raramente compensa.

• YouTube: precisa de mute=1, controls=0, e o truque da playlist com o mesmo ID para loop. Continua a descarregar o player.
• Vimeo: background=1 simplifica a UI, mas o iframe e a API continuam no caminho crítico se o embed estiver no HTML inicial.
• Self-host: controlo total de preload, poster e codecs. Exige disciplina de compressão e um fallback MP4 para Safari quando o primário é AV1/WebM.

A fachada (lite embed) faz sentido quando o vídeo é conteúdo a pedido. Para atmosfera de fundo, a fachada correta é o poster estático - sem player por baixo até haver condições de motion.

#Quando não usar vídeo de fundo

Salte o vídeo e fique no poster (ou num still bem composto) quando qualquer uma destas condições for verdadeira:

• A página depende de um LCP agressivo para campanhas pagas ou SEO local (ex.: landings de cidade com orçamento de anúncios limitado).
• Mais de metade do tráfego chega em redes móveis lentas ou com poupança de dados.
• O texto do hero já compete visualmente com o movimento (contraste fraco, CTA pequeno).
• O “vídeo” é um slideshow disfarçado: três fades lentos não precisam de um contentor <video>.
• Há obrigação legal ou de marca de legendas/áudio - isso pede player com controlos, não um loop muted.
• A equipa não tem processo para reencode e para testar prefers-reduced-motion em cada release.

Um still AVIF de 80-120 KB, bem enquadrado, supera um WebM de 3 MB que falha o autoplay em iOS. Movimento só vale a pena quando sobrevive a throttling, a políticas de autoplay e a preferências de acessibilidade sem empurrar o LCP para fora do verde.

#Medição antes de declarar vitória

Checklist curto após cada alteração de hero:

1. Lighthouse mobile e desktop: LCP, CLS, pedidos de vídeo no caminho crítico.
2. Filmstrip: o CTA é legível antes do primeiro frame em movimento?
3. Safari iOS com Low Power Mode: o autoplay falha com elegância para o poster?
4. prefers-reduced-motion: reduce simulado nas DevTools: zero downloads de vídeo?
5. WordPress staging com um editor sem perfil técnico a trocar o media: o markup ainda sai com muted e playsinline?

Se o vídeo só “funciona” no MacBook do designer em Wi-Fi da empresa, ainda não está pronto para produção.

#Síntese operativa

Trate autoplay como um privilégio com regras: muted + playsinline + falha segura para poster. Proteja o LCP com uma imagem estática pré-carregada. Use preload="none" e atrase o src. Honre prefers-reduced-motion. No WordPress, não deixe o media library servir ficheiros de telemóvel sem reencode. E quando o movimento não sobrevive a estas restrições, publique o poster e siga em frente - a conversão raramente pede um loop de 8 segundos atrás do H1.

Fontes de referência usadas neste guia: optimize LCP (web.dev), elemento video (MDN), guia de autoplay (MDN).