Vídeo piora os Core Web Vitals de uma loja virtual?
Depende inteiramente da implementação, e a resposta honesta é que a implementação ingênua piora as três métricas de uma vez. Um vídeo com autoplay, sem lazy loading e com preload de metadados compete por banda com o elemento principal da página e piora o LCP. Um embed de YouTube ou Vimeo carrega centenas de kilobytes de JavaScript de terceiro que ocupam o main thread e degradam o INP. Um player inserido sem espaço reservado no layout empurra o conteúdo para baixo quando aparece e gera CLS. Feito corretamente, com o vídeo servido por CDN, preload="none", poster leve, carregamento só ao entrar na viewport e proporção reservada em CSS, o vídeo entra depois da renderização inicial e o LCP continua sendo o elemento que já era antes. Core Web Vitals são sinal público de ranqueamento do Google, então a diferença entre as duas implementações tem consequência em busca orgânica, não só em experiência.
As três métricas, sem simplificação
A maior parte do material sobre Core Web Vitals para lojistas para em "carregue mais rápido". Sem entender o que cada métrica mede, é impossível saber qual decisão de vídeo afeta qual número.
LCP: Largest Contentful Paint
Mede o tempo até o maior elemento de conteúdo visível na área inicial da tela terminar de renderizar. Em página de produto, esse elemento é quase sempre a imagem principal ou o banner. O bom é até 2,5 segundos no percentil 75 dos acessos reais. Vídeo afeta o LCP de duas formas. Diretamente, se o vídeo estiver dentro da área visível inicial e for maior que a imagem. Nesse caso o poster do vídeo passa a ser o candidato a LCP e o número depende do peso desse poster. Indiretamente, e é o caso mais comum, por competição de banda: um arquivo de vídeo que começa a baixar junto com a imagem principal rouba banda em conexão móvel e atrasa o elemento que define o LCP, sem nunca aparecer como culpado no relatório.
INP: Interaction to Next Paint
Substituiu o FID em 2024 e é a métrica mais sensível a vídeo. Mede a latência entre a interação do usuário (toque, clique, tecla) e o próximo quadro pintado na tela, considerando a pior interação da sessão. O bom é até 200 milissegundos. Quem piora o INP é JavaScript ocupando o main thread: enquanto uma tarefa longa está executando, o navegador não consegue responder ao toque. Player de terceiro é o pior caso, porque traz bundle grande, faz parsing, registra listeners e às vezes inicializa analytics próprio. O sintoma clássico no celular é o usuário tocar no botão de comprar e nada acontecer por meio segundo.
CLS: Cumulative Layout Shift
Mede o quanto o conteúdo se desloca visualmente sem que o usuário tenha provocado o deslocamento. O bom é abaixo de 0,1. É a métrica mais fácil de estragar com vídeo e a mais fácil de consertar. Se o container do vídeo não tem dimensão definida antes de o vídeo carregar, ele ocupa altura zero e, quando o conteúdo chega, empurra tudo abaixo dele. Em página de produto isso significa o botão de comprar descendo no instante em que o dedo já estava indo até ele. Além de métrica ruim, isso é causa de compra errada e de abandono.
TTFB e a camada abaixo das três
Não é Core Web Vital, mas condiciona o LCP. Time to First Byte é o tempo até o primeiro byte da resposta chegar. Se o vídeo é servido do mesmo servidor de origem da loja, cada requisição de vídeo compete com as requisições de HTML e API pela mesma capacidade. É a principal razão técnica para servir vídeo por CDN e não do host da loja.
Dado de laboratório vs. dado de campo
Distinção que muda a conclusão. PageSpeed Insights roda um teste sintético, em um ambiente controlado, e devolve nota de laboratório, útil para diagnosticar. O que o Google usa como sinal é o dado de campo do CrUX, coletado de usuários reais do Chrome, em janela móvel de 28 dias, no percentil 75. Por isso uma correção de vídeo aparece no laboratório no mesmo dia e no relatório de Core Web Vitals do Search Console só depois de semanas. Quem espera ver o campo mudar em dois dias conclui erradamente que a correção não funcionou.
Percentil 75 e por que a média engana
A avaliação usa o percentil 75 dos acessos, não a média. Significa que o aparelho intermediário em 4G, e não o iPhone do gerente de e-commerce em Wi-Fi, é quem define a sua nota. Toda decisão de peso de vídeo deveria ser tomada pensando nesse aparelho. É também por isso que testar apenas no DevTools do desktop dá falsa segurança.
Lojas que já vendem com vídeo
Mais de 6 mil lojas usam o iShorts nas principais plataformas do Brasil.
Por que embed de YouTube ou Vimeo é caro na página de produto
Colocar um iframe do YouTube na página de produto é a solução gratuita mais tentadora e a que mais custa em métrica. O que o navegador precisa fazer para renderizar aquele iframe é bem mais do que baixar um vídeo: ele abre conexões com múltiplos domínios de terceiro, resolve DNS para cada um, negocia TLS, baixa e executa o bundle do player, e só então decide o que carregar de mídia. Cada uma dessas etapas acontece no main thread ou compete pela rede, e o custo aparece principalmente no INP.
O detalhe que agrava é que o iframe é um documento separado com seu próprio ciclo de vida. Você não controla o que ele carrega, quando carrega ou quanto JavaScript ele executa, e uma atualização do lado do provedor pode aumentar esse peso sem aviso e sem deploy seu. Em uma página de produto que já carrega galeria, script de pixel, app de avaliação e app de frete, o embed é frequentemente o item que empurra a nota do amarelo para o vermelho.
Há um mitigador conhecido: a técnica de facade, em que a página exibe apenas uma imagem de capa e só carrega o iframe real depois do clique. Funciona para o problema de performance e é bem melhor do que embed direto. O que ela não resolve é o problema de intenção. O player de YouTube existe para manter a pessoa no YouTube; ao fim do vídeo ele sugere conteúdo relacionado, sem que você controle o que entra nessa lista, inclusive de concorrente. Você paga tráfego para levar o visitante à página de produto e coloca ali uma porta de saída.
A alternativa tecnicamente correta é servir o próprio arquivo por CDN, em um elemento de vídeo controlado pela sua página. Você decide o codec, o bitrate, o poster, o momento de carregar e o que acontece quando o vídeo termina, que, em página de produto, deveria ser um caminho para o carrinho e não uma sugestão de outro vídeo.
A implementação que não estraga métrica
Cada item abaixo ataca uma métrica específica. Se você for auditar um fornecedor de video commerce, essa é a lista de perguntas técnicas que separa quem resolveu o problema de quem não olhou para ele.
preload="none" e carregamento na viewport
O elemento de vídeo deve nascer com preload="none" e só iniciar o download quando entrar na área visível, tipicamente via IntersectionObserver. Sem isso, mesmo um vídeo três telas abaixo começa a baixar durante o carregamento inicial e compete com o elemento de LCP. preload="metadata" parece inofensivo e ainda abre conexão e baixa cabeçalho de cada arquivo. Em um carrossel de dez vídeos, são dez requisições concorrentes no pior momento possível.
aspect-ratio reservado em CSS
O container precisa ter proporção definida por CSS antes de qualquer mídia chegar: aspect-ratio: 9 / 16 para vertical, ou width e height explícitos no elemento. É o que garante que o espaço já esteja ocupado e que nada abaixo do vídeo se mova quando ele aparecer. É a correção de CLS mais barata que existe e a mais frequentemente esquecida, especialmente em carrossel montado por JavaScript depois da renderização.
Poster leve e explícito
Todo vídeo deve ter poster. Sem poster, o container fica em branco até o primeiro quadro decodificar. O poster precisa ser um arquivo pequeno, em WebP ou AVIF, dimensionado para o tamanho real de exibição, não o primeiro quadro exportado em PNG. Atenção ao caso em que o vídeo está na área visível inicial: ali o poster é o candidato a LCP, e um poster de 400 KB significa um LCP de 400 KB.
Autoplay somente com muted e playsinline
Autoplay sem muted é bloqueado por política dos navegadores, então o atributo muted é obrigatório para que sequer funcione, e playsinline é o que evita o vídeo abrir em tela cheia no iOS. A decisão relevante é outra: autoplay de vários vídeos ao mesmo tempo consome banda e CPU em paralelo. Em feed vertical, apenas o vídeo em foco deve reproduzir; os vizinhos ficam pausados, no máximo com o próximo pré-carregado.
Codec e bitrate adequados a mobile em 4G
Vídeo de trinta segundos em 1080x1920 não precisa passar de poucos megabytes. H.264 garante compatibilidade ampla; AV1 e HEVC entregam o mesmo com arquivo menor onde há suporte. O erro comum é subir o arquivo exportado do editor, com bitrate de master, e servir isso ao celular. Transcodificar para múltiplas resoluções e entregar a adequada ao dispositivo é o que separa uma implementação profissional de um upload direto.
CDN com edge próximo e cache longo
Vídeo servido do host da loja compete com HTML e chamadas de API pela mesma capacidade e sobe o TTFB de todas as requisições sob tráfego. Serve por CDN, com cache imutável e origem separada do domínio da loja. Para vídeos maiores ou catálogo grande, streaming adaptativo em HLS entrega o segmento na qualidade que a rede aguenta em vez de baixar o arquivo inteiro.
JavaScript assíncrono e fora do caminho crítico
O script do player precisa ser carregado com async ou defer e não deve bloquear renderização. Ao avaliar um app de vídeo, peça o número de kilobytes que ele adiciona e verifique no painel de rede se ele executa tarefas longas durante o carregamento inicial. É esse trecho que aparece no INP quando o cliente toca no botão de comprar e a página demora a reagir.
Quer ver isso aplicado ao seu catálogo?
Uma demonstração guiada, com os seus produtos e os seus vídeos.
Como medir antes e depois, corretamente
A sequência importa: sem baseline registrado antes de ativar, não existe como saber se o vídeo custou ou não custou performance.
Registre o baseline antes de ativar qualquer coisa
Rode o PageSpeed Insights em três URLs representativas (home, uma listagem de categoria e a página de produto de maior tráfego) e salve as capturas com LCP, INP e CLS de laboratório e de campo. Anote a data. Sem esse registro, qualquer discussão posterior sobre "a loja ficou mais lenta" é opinião.
Anote também o dado de campo do Search Console
No relatório de Core Web Vitals, registre quantas URLs estão classificadas como boas, a melhorar e ruins, em mobile e desktop. Esse é o dado que o Google usa como sinal, e é a referência que vale para a discussão de SEO.
Ative o vídeo em um subconjunto de páginas
Não ative no catálogo inteiro de uma vez. Ligue nos vinte produtos do teste, o que permite comparar páginas com e sem vídeo no mesmo período, no mesmo mix de tráfego e no mesmo aparelho médio.
Meça o laboratório em 24 horas e o campo em quatro semanas
O PageSpeed Insights responde no dia. O CrUX e o Search Console trabalham em janela de 28 dias, então a leitura de campo confiável só existe cerca de um mês depois. Concluir que "não mudou nada" na semana seguinte é ler o instrumento errado.
Se piorou, identifique a métrica antes de culpar o vídeo
CLS pior indica falta de espaço reservado. INP pior indica JavaScript de terceiro ou autoplay simultâneo. LCP pior indica vídeo na área visível inicial, poster pesado ou preload ativo. Cada diagnóstico tem correção específica, e desligar o vídeo é a última opção, não a primeira.
Perguntas frequentes
Sim, o Google declara publicamente que Core Web Vitals fazem parte dos sinais de experiência de página usados em busca. O que não existe é peso numérico divulgado, e desconfie de quem afirma um. Na prática o efeito é mais decisivo em disputa entre páginas de relevância parecida: entre dois resultados equivalentes, o mais rápido tende a levar vantagem. Relevância de conteúdo continua acima de velocidade.
