Fundos de vídeo, reprodução automática e carregamento diferido

Vídeos hero (fundos de vídeo) são um elemento comum do web design atual. Criam atmosfera e prendem a atenção no primeiro ecrã.

São também uma das causas mais frequentes de um First Contentful Paint (FCP) lento e de um Total Blocking Time (TBT) elevado, sobretudo quando o vídeo chega através de um iframe de terceiros.

Se incorporar um iframe padrão do YouTube no topo da página, o browser descarrega o leitor, os seus scripts e as ligações a vários domínios antes de o utilizador ver o conteúdo principal. O mesmo vale para o Vimeo. Este guia junta as regras dos browsers, os parâmetros dos leitores, as técnicas de carregamento diferido e os requisitos de acessibilidade, com a fonte oficial de cada regra.

#Como funciona a política de reprodução automática

Primeiro, as regras. Os browsers (Chrome, Safari, Firefox) bloqueiam vídeos que tentam reproduzir automaticamente com som.

Para garantir que o seu vídeo de fundo reproduz automaticamente, ele TEM de ter estes atributos:

1. autoplay
2. muted (silenciado)
3. playsinline (crítico para iOS)
4. loop

A MDN resume o critério assim: o bloqueio não se aplica a elementos <video> cuja fonte não tem faixa de áudio ou cuja faixa de áudio está silenciada; conteúdo com faixa de áudio ativa conta como audível e é essa que fica bloqueada (MDN, guia de autoplay, tradução própria). Por isso, num vídeo de fundo, remover a faixa de áudio do ficheiro é mais seguro do que confiar apenas no atributo muted.

#O que mudou no Chrome 66 e o Media Engagement Index

O Chrome aplicou a política atual a partir da versão 66, em abril de 2018. A equipa do Chrome resume a regra base numa frase: “A reprodução automática sem som é sempre permitida” (Chrome for Developers, tradução própria). Com som, o autoplay só passa se o utilizador já interagiu com o domínio (clique, toque), se no desktop o limiar do Media Engagement Index (MEI) foi ultrapassado, ou se o utilizador adicionou o site ao ecrã inicial no telemóvel ou instalou a PWA no desktop.

O MEI mede a propensão de cada pessoa para consumir media num site, calculado como a razão entre visitas e eventos de reprodução significativos por origem. Para um evento contar, o Chrome exige quatro condições: consumo superior a sete segundos, áudio presente e não silenciado, separador ativo e vídeo maior do que 200x140 píxeis. Um vídeo de fundo silenciado nunca soma pontos de MEI, por isso não tem sentido esperar que “o Chrome aprenda” a deixá-lo tocar com som.

#O que o iOS exige desde o iOS 10

A WebKit publicou as regras do Safari para iOS em julho de 2016, no artigo de Jer Noble sobre as novas políticas de vídeo. Desde o iOS 10, elementos <video muted> podem reproduzir automaticamente sem gesto do utilizador, e o mesmo vale para vídeos cuja fonte não tem faixa de áudio. Com playsinline, o vídeo toca dentro da página no iPhone e não entra em ecrã inteiro quando a reprodução começa (WebKit).

Há dois comportamentos que surpreendem quem testa só no desktop. Se o vídeo ganhar uma faixa de áudio ou deixar de estar silenciado sem gesto do utilizador, a reprodução pausa. E um <video autoplay> pausa quando deixa de estar visível, por exemplo ao sair da viewport com o scroll. O mesmo artigo explica a motivação: os GIF podem gastar até doze vezes mais largura de banda e o dobro da energia de um codec de vídeo moderno como o H.264.

#Como o Firefox trata o autoplay

O Firefox segue a mesma lógica, com preferências que a MDN documenta. media.autoplay.allow-muted vem a true por omissão e deixa tocar media silenciada. media.block-autoplay-until-in-foreground, também true por omissão, impede o autoplay num separador aberto em segundo plano até o utilizador o trazer para a frente. Por isso um vídeo de fundo não arranca numa página aberta num separador em segundo plano, por exemplo com clique do meio, até o separador ficar ativo.

#Como detetar quando o autoplay falha

Nenhum browser garante que o autoplay acontece. O método play() devolve uma Promise que é rejeitada quando a reprodução não começa, e a MDN recomenda verificar se o erro tem o nome NotAllowedError, que indica bloqueio por permissão. O artigo do Chrome dá o mesmo conselho: não assuma que o vídeo vai tocar e não mostre um botão de pausa se a reprodução não começou.

const video = document.querySelector('.hero-video');
video.play().catch((error) => {
  if (error.name === 'NotAllowedError') {
    document.querySelector('.hero-play').hidden = false;
  }
});

Existe também navigator.getAutoplayPolicy(), que devolve allowed, allowed-muted ou disallowed. Segundo os dados de compatibilidade da MDN (browser-compat-data 8.1.5, outubro de 2026), só o Firefox o suporta, a partir da versão 112. Chrome e Safari não o implementam, por isso o tratamento da Promise continua a ser o mecanismo que funciona em todo o lado.

#Quais parâmetros YouTube e Vimeo usar

Para retirar a UI do leitor e fazê-lo parecer um vídeo de fundo, use estes parâmetros de URL.

#Parâmetros do Vimeo para vídeo de fundo

O Vimeo oferece um “modo de fundo” mais limpo que o YouTube.

<iframe src="https://player.vimeo.com/video/12345678?background=1&dnt=1" frameborder="0" allow="autoplay; fullscreen" allowfullscreen></iframe>

• background=1: desativa os controlos, faz loop, inicia a reprodução e silencia o vídeo.
• Condição de plano: segundo a página de parâmetros do Vimeo, o vídeo tem de estar alojado numa conta Starter, Standard, Advanced, Plus, Pro, Business, Premium ou Enterprise. Numa conta gratuita, background=1 não serve.
• dnt=1: impede o leitor de recolher dados de sessão e analytics, à semelhança do Do Not Track, embora alguns cookies essenciais continuem ativos (Vimeo Help Center).

#Parâmetros do YouTube para vídeo de fundo

O YouTube é mais complicado. Não pode esconder totalmente o leitor, mas pode reduzir a interface.

<iframe src="https://www.youtube-nocookie.com/embed/VIDEO_ID?autoplay=1&mute=1&controls=0&loop=1&playlist=VIDEO_ID&playsinline=1" frameborder="0" allow="autoplay; encrypted-media"></iframe>

• Crucial: para o loop=1 funcionar com um único vídeo, a documentação da Google manda definir playlist com o MESMO ID de vídeo. A mesma página avisa que loop tem suporte limitado em embeds iframe.
• playsinline=1: controla se o vídeo toca dentro da página ou em ecrã inteiro no iOS. A documentação diz que o ecrã inteiro é o valor por omissão atual, por isso o parâmetro é obrigatório num fundo.
• mute=1 não aparece na lista oficial de parâmetros. É usado na prática, mas não é um contrato documentado. Se o silêncio tiver de ser garantido, use a IFrame Player API e chame mute() antes de playVideo().
• modestbranding está obsoleto e não tem efeito. Desde 25 de setembro de 2018 não é possível desligar os vídeos relacionados: rel=0 apenas os limita ao mesmo canal (YouTube IFrame Player API).

A documentação acrescenta um ponto que pesa no RGPD: com autoplay=1, a recolha e partilha de dados de reprodução acontece no carregamento da página, sem interação do utilizador.

#Como delegar a permissão de autoplay a um iframe

O Chrome deixa uma origem com permissão de autoplay delegá-la a iframes de outra origem através do atributo allow="autoplay". Iframes da mesma origem têm autoplay por omissão. Do lado do servidor, o cabeçalho Permissions-Policy com a diretiva autoplay define que domínios podem reproduzir media automaticamente. O valor por omissão é self. Uma lista vazia desativa o autoplay por completo, e pode indicar origens concretas separadas por espaços.

Permissions-Policy: autoplay=(self "https://player.vimeo.com")

Se o site já envia um Permissions-Policy restritivo por razões de segurança, verifique se não bloqueou o leitor sem querer.

#Como carregar vídeos com uma fachada (facade)

Carregar um iframe imediatamente é mau para Core Web Vitals. Carregá-lo de forma diferida é melhor. Usar uma fachada é o melhor.

Uma fachada é uma imagem leve que se parece com o leitor de vídeo. Quando o utilizador interage, trocamos a imagem pelo iframe real. Note a limitação: uma fachada pede um clique, por isso serve para vídeos de conteúdo e não para um fundo que tem de mexer sozinho. Para um fundo verdadeiro, a fachada equivalente é o poster com um vídeo alojado no próprio servidor.

#Como usar o web component lite-youtube

A referência mais usada é o lite-youtube-embed de Paul Irish. O README promete que o elemento “é apresentado tal como o original, mas cerca de 224 vezes mais depressa” (tradução própria).

<link rel="stylesheet" href="/vendor/lite-yt-embed.css">
<script src="/vendor/lite-yt-embed.js"></script>
<lite-youtube videoid="goiWrNiaT0I" playlabel="Play: Crayon Physics Deluxe - Trailer HD"></lite-youtube>

O elemento mostra a miniatura do vídeo. No código-fonte, ao passar o rato ou ao receber foco, abre ligações antecipadas (preconnect) a youtube-nocookie.com e aos domínios da Google. Ao clicar, insere o iframe com autoplay=1. Os comentários do código registam uma exceção: o Safari desktop e a maioria dos browsers móveis não propagam o gesto do clique através da criação do iframe, por isso nesses casos a biblioteca carrega ainda a YouTube Player API, com dois ficheiros JS sequenciais.

#Autoplay só quando visível com IntersectionObserver

Se precisa que o vídeo inicie automaticamente (sem clique) mas não quer carregá-lo até que esteja visível (ex: um vídeo a meio da página):

document.addEventListener("DOMContentLoaded", function() {
  var lazyVideos = [].slice.call(document.querySelectorAll("video.lazy"));

  if ("IntersectionObserver" in window) {
    var lazyVideoObserver = new IntersectionObserver(function(entries, observer) {
      entries.forEach(function(video) {
        if (video.isIntersecting) {
          for (var source in video.target.children) {
            var videoSource = video.target.children[source];
            if (typeof videoSource.tagName === "string" && videoSource.tagName === "SOURCE") {
              videoSource.src = videoSource.dataset.src;
            }
          }

          video.target.load();
          video.target.classList.remove("lazy");
          lazyVideoObserver.unobserve(video.target);
        }
      });
    });

    lazyVideos.forEach(function(lazyVideo) {
      lazyVideoObserver.observe(lazyVideo);
    });
  }
});

Este padrão coloca o URL real em data-src em cada <source> e só o copia para src quando o vídeo entra na viewport. O artigo do web.dev sobre lazy loading de vídeo usa a mesma ideia: o vídeo não arranca por omissão e só começa quando o Intersection Observer o deteta (web.dev).

#O atributo loading=“lazy” no elemento video

A MDN já documenta loading="lazy" para <video>: o browser adia o carregamento do vídeo, incluindo o poster, até o elemento chegar a uma distância da viewport que o próprio browser calcula. Com autoplay, o download e a reprodução só começam quando o vídeo está perto ou dentro da viewport.

O suporte ainda é parcial. Os dados de compatibilidade da MDN (8.1.5) marcam o atributo como experimental: suporte completo no Chrome e Edge 150, suporte parcial nas versões 148 e 149 (sem efeito em <source>), e nada no Firefox nem no Safari. Pode adicioná-lo hoje como melhoria progressiva, mas o IntersectionObserver continua necessário para os outros browsers.

#Como hospedar vídeo self-hosted (MP4/WebM)

Por vezes, self-hosting é muito mais rápido que YouTube/Vimeo porque controla o buffer e não é necessário JS externo.

Dica: forneça sempre uma imagem poster. A MDN define-a como a imagem mostrada enquanto o vídeo descarrega. Sem ela, nada aparece até o primeiro frame estar disponível.

<video autoplay muted loop playsinline poster="/images/poster.jpg" width="1280" height="720" class="hero-video">
  <source src="/videos/hero.webm" type="video/webm">
  <source src="/videos/hero.mp4" type="video/mp4">
</video>

Os atributos width e height permitem ao browser reservar o espaço com a proporção certa antes de o vídeo carregar, tal como nas imagens. O mecanismo e as falhas típicas estão no nosso guia de erros de dimensão de imagem e CLS.

Bitrate importa: recodifique o vídeo de fundo com o bitrate mais baixo que ainda pareça aceitável e remova a faixa de áudio por completo. Isso poupa bytes e, como vimos acima, elimina qualquer hipótese de o browser o tratar como media audível.

#Que valor de preload usar num vídeo

O atributo preload aceita none (não pré-carregar), metadata (só metadados, como a duração) e auto (o ficheiro inteiro pode ser descarregado). A MDN lembra três detalhes: o valor por omissão varia entre browsers e a especificação aconselha metadata; o atributo é apenas uma sugestão que o browser pode ignorar; e autoplay tem precedência sobre preload, porque um vídeo que arranca sozinho tem de ser descarregado.

Para vídeos que não arrancam sozinhos, o web.dev recomenda preload="none" com um poster, porque na maioria dos browsers o valor por omissão metadata ainda descarrega parte do ficheiro. Num vídeo de fundo com autoplay, o preload não poupa nada; quem decide quando o download começa é o lazy loading.

#Como converter um GIF animado em MP4 e WebM

Se o “vídeo de fundo” é na verdade um GIF, a troca é a vitória mais barata. No exemplo do web.dev, o mesmo conteúdo ocupa 3,7 MB como GIF, 551 KB como MP4 e 341 KB como WebM (web.dev). Os comandos FFmpeg do artigo:

ffmpeg -i my-animation.gif -b:v 0 -crf 25 -f mp4 -vcodec libx264 -pix_fmt yuv420p my-animation.mp4
ffmpeg -i my-animation.gif -c vp9 -b:v 0 -crf 41 my-animation.webm

Se o GIF tiver dimensões ímpares, o artigo sugere o filtro crop=trunc(iw/2)*2:trunc(ih/2)*2, porque o H.264 com yuv420p exige largura e altura pares. Na marcação, a fonte WebM vem primeiro e o MP4 fica como alternativa, com autoplay loop muted playsinline no elemento.

#Como um vídeo de fundo afeta o LCP

Um vídeo no topo da página é muitas vezes o maior elemento visível, por isso entra na conta do Largest Contentful Paint. Segundo o web.dev, para elementos <video> conta o tempo de carregamento da imagem poster ou o momento em que o primeiro frame é apresentado, o que acontecer primeiro. O objetivo é um LCP de 2,5 segundos ou menos, medido no percentil 75 dos carregamentos, separando mobile e desktop (web.dev).

A consequência prática: o poster é o seu LCP. Use uma imagem leve (AVIF ou WebP), garanta que o URL aparece no HTML inicial e não só em JavaScript, e pré-carregue-a com prioridade alta. O guia do web.dev para otimizar o LCP divide o tempo em quatro partes: TTFB, atraso até o recurso começar a carregar, duração do carregamento e atraso de renderização. Um poster descoberto tarde aumenta a segunda; um ficheiro pesado aumenta a terceira.

<link rel="preload" as="image" href="/images/poster.avif" fetchpriority="high">

Para o resto das métricas, incluindo o INP, veja o nosso guia de Core Web Vitals e INP.

#Que regras de acessibilidade se aplicam a um vídeo de fundo

#WCAG 2.2.2 e o botão de pausa

O critério de sucesso 2.2.2 (Pause, Stop, Hide) é de nível A, o nível mínimo. Diz que qualquer informação em movimento que (1) começa automaticamente, (2) dura mais de cinco segundos e (3) é apresentada em paralelo com outro conteúdo tem de ter um mecanismo para o utilizador a pausar, parar ou esconder, salvo se o movimento for essencial à atividade (W3C, Understanding SC 2.2.2, tradução própria).

Um vídeo de fundo em loop cumpre as três condições: arranca sozinho, dura mais de cinco segundos e fica atrás do título e dos botões. A página do W3C não fala de vídeo de fundo pelo nome, mas lista vídeo e animações como conteúdo em movimento. Na prática, a solução é um botão visível e acessível por teclado:

<button type="button" class="hero-toggle" aria-pressed="false">Pausar vídeo</button>

Se o vídeo tiver som, aplica-se também o critério 1.4.2 (Audio Control), que a mesma página indica para áudio que começa automaticamente.

#Como respeitar prefers-reduced-motion

A media query prefers-reduced-motion deteta se o utilizador ativou no dispositivo a opção de reduzir movimento não essencial. Aceita no-preference e reduce. A MDN explica que animações como escalar ou deslocar objetos grandes podem desencadear mal-estar em pessoas com distúrbios vestibulares. Os utilizadores ativam a opção no Windows 11 em Definições, Acessibilidade, Efeitos visuais; no macOS em Acessibilidade, Movimento (Tahoe) ou Acessibilidade, Ecrã (até ao Sequoia); no iOS em Acessibilidade, Movimento; no Android 9 ou superior em Acessibilidade, Remover animações.

Num vídeo de fundo, a resposta mais simples é não reproduzir e deixar o poster:

const video = document.querySelector('.hero-video');
if (window.matchMedia('(prefers-reduced-motion: reduce)').matches) {
  video.removeAttribute('autoplay');
  video.pause();
}

Como o atributo autoplay já pode ter iniciado a reprodução antes de o script correr, a alternativa mais robusta é omitir autoplay no HTML e chamar play() só quando a preferência é no-preference. Assim o mesmo código serve a regra da redução de movimento e o tratamento da Promise descrito acima.

#O que lembrar sobre vídeo de fundo e performance

1. Silêncio é obrigatório: muted e playsinline em todos os browsers; sem faixa de áudio é ainda melhor.
2. Vimeo ?background=1 é a forma mais fácil de obter vídeo de fundo, mas exige um plano pago.
3. YouTube requer playlist=ID para fazer loop, e mute=1 não é parâmetro documentado.
4. Trate a Promise de play() e mostre um botão de reprodução quando o autoplay falha.
5. O poster é o LCP: imagem leve, descoberta no HTML, pré-carregada.
6. Use fachadas (lite-youtube) para vídeos com clique e IntersectionObserver para adiar o carregamento até à visibilidade.
7. Botão de pausa e prefers-reduced-motion não são opcionais: o WCAG 2.2.2 é nível A.

Veja os nossos serviços de otimização de velocidade WordPress.