Como construí animações 3D de scroll estilo Apple com IA

Como construí animações 3D de scroll estilo Apple com IA

A landing page carregou e eu fiz scroll. Um teclado estava centralizado sobre um fundo escuro — preto fosco, iluminação nítida, o tipo de foto de produto que você esperaria numa keynote da Apple. Então, conforme minha roda de scroll se movia, o teclado começou a se desmontar. Teclas se elevando. Circuitos internos se revelando. Um efeito de raio-X lento e elegante que acompanhava perfeitamente minha posição de scroll — não reproduzindo um vídeo, mas respondendo ao meu dedo como se a página em si estivesse viva.

Parei de fazer scroll na metade, voltei para cima e assisti o teclado se remontar. Desci novamente, mais rápido desta vez. A animação acompanhou o ritmo. Sem tremores. Sem frames carregando. Sem indicador de buffering. Apenas movimento suave como manteiga, perfeito frame a frame, vinculado diretamente à barra de scroll.

Esta não era uma página construída por uma agência de design cobrando seis dígitos. Foi construída em aproximadamente uma hora usando três ferramentas de IA e Claude Code. E a técnica por trás — animação de scroll frame a frame — é a mesma que a Apple usa nas suas páginas de produto para AirPods, MacBook Pro e iPhone.

O que me pegou de surpresa: a parte mais difícil de todo este fluxo de trabalho não foi a animação em si. Não foi a programação. Nem sequer foi acertar o timing. A parte mais difícil foi saber que essa combinação de ferramentas existia. Assim que você enxerga o pipeline, tudo se encaixa — e você nunca mais vai olhar para um site genérico gerado por IA da mesma forma.

Vou te guiar pelo processo exato, ferramenta por ferramenta, frame por frame. Mas primeiro, você precisa entender por que essa técnica de animação específica funciona tão melhor do que aquilo que a maioria dos desenvolvedores usa por padrão.

Por que vídeos incorporados matam a sensação premium (e o que a Apple faz no lugar)

A maioria dos desenvolvedores que quer animação acionada por scroll num site recorre a uma de duas abordagens: animações CSS controladas por scroll ou um vídeo incorporado com listeners de scroll em JavaScript. Ambas funcionam. Nenhuma delas transmite sensação premium.

Animações CSS controladas por scroll — o tipo que você constrói com @keyframes e animation-timeline: scroll() — são ótimas para efeitos parallax, fade-ins e transformações de elementos. São leves, performáticas e nativas do navegador desde 2024. Mas não conseguem fazer o que acabei de descrever. Você não consegue animar com CSS um teclado se desmontando numa vista de raio-X. Isso requer renderização 3D fotorrealista, e CSS não renderiza objetos 3D.

Vídeos incorporados chegam mais perto. Você pode usar a API Intersection Observer para reproduzir um vídeo baseado na posição de scroll, e muitas bibliotecas tornam isso simples. Mas a reprodução de vídeo durante scroll tem um problema fundamental: a busca. Quando você navega num vídeo alterando currentTime em resposta a eventos de scroll, você está pedindo ao decodificador de vídeo do navegador para buscar frames arbitrários em tempo real. O resultado é irregular, inconsistente e notavelmente diferente de dispositivo para dispositivo. Mobile Safari lida com isso de forma diferente do Chrome. Dispositivos de baixa potência gaguejam. E o arquivo de vídeo em si — mesmo um clipe curto de 5 segundos — pode ter 3-8MB, o que arruina seus Core Web Vitals.

A abordagem da Apple é diferente. Se você inspecionar uma página de produto do MacBook Pro ou AirPods, não vai encontrar uma tag <video> alimentando essas animações de scroll. Você vai encontrar um elemento <canvas>. E o que alimenta esse canvas é uma sequência de frames de imagem pré-extraídos — tipicamente 60 a 180 imagens individuais — carregadas progressivamente e desenhadas no canvas conforme o usuário faz scroll.

Funciona como um flipbook. Cada posição de scroll mapeia para um número de frame específico. O navegador desenha esse frame no canvas. Como você está desenhando uma imagem estática (não buscando num fluxo de vídeo comprimido), a renderização é instantânea. Sem atraso do decodificador. Sem busca de keyframes. Sem buffering. A animação parece travada na posição de scroll do usuário porque literalmente está — não há motor de reprodução de vídeo entre o evento de scroll e a saída visual.

O problema? Criar 180 frames de produto fotorrealistas tradicionalmente exigia um artista 3D, um pipeline de renderização (Blender, Cinema 4D, Houdini) e dias de trabalho. Exatamente por isso que essa técnica ficou trancada dentro do orçamento da Apple até agora.

É aqui que o pipeline de IA muda completamente a equação.

O pipeline de três ferramentas que torna isso possível

O fluxo de trabalho que vou detalhar usa três ferramentas de IA em sequência, cada uma cuidando de uma etapa específica do processo. Aqui está a visão geral antes de mergulharmos em cada uma:

Ferramenta 1: Nano Banana 2 (modelo de geração de imagens do Google no Higgsfield) gera os keyframes inicial e final — duas imagens de alta qualidade representando o estado inicial e final da animação.

Ferramenta 2: Kling 3.0 (modelo de geração de vídeo IA da Kuaishou) pega esses dois keyframes e gera um vídeo de transição suave entre eles — a animação propriamente dita, renderizada como MP4.

Ferramenta 3: Claude Code pega esse MP4, extrai frames individuais usando FFMPEG, converte-os para WEBP e constrói todo o site de animação controlada por scroll usando Next.js e Tailwind CSS.

Tempo total de trabalho do primeiro prompt ao site publicado: aproximadamente 45-90 minutos dependendo de quanto você personalizar. E o resultado parece algo que uma agência criativa passou semanas produzindo.

Deixe-me detalhar cada etapa. Os detalhes importam — especialmente os prompts de geração de imagem, porque errar neles propaga problemas por todo o pipeline.

Passo 1: Gerando seus keyframes com Nano Banana 2

Nano Banana 2 é o modelo Gemini 3.1 Flash Image do Google, lançado em 26 de fevereiro de 2026. Está disponível no Higgsfield, uma plataforma de criação de conteúdo com IA que agrupa geração de imagens, geração de vídeo e ferramentas de edição em um só lugar.

Por que Nano Banana 2 especificamente? Três razões que importam para este fluxo de trabalho:

Resolução 2K nativa. A maioria dos geradores de imagens produz 1024x1024 ou requer upscaling. Nano Banana 2 renderiza em 2K nativamente, o que significa que seus frames de animação permanecem nítidos mesmo em telas grandes de desktop. Como Kling 3.0 produz vídeo em 1080p, você quer que suas imagens-fonte ao menos igualem essa resolução — 2K te dá margem.

Iluminação fisicamente precisa. O modelo planeja cenas antes de renderizar, o que significa que fontes de luz, reflexos e sombras se comportam consistentemente. Quando você gera duas imagens que precisam parecer pertencer à mesma cena (um teclado montado vs. desmontado), consistência de iluminação não é negociável. Sombras inconsistentes entre seus frames inicial e final farão o vídeo de transição parecer errado de maneiras difíceis de articular mas imediatamente óbvias.

Renderização de texto que realmente funciona. Se seu produto tem texto — um logotipo, uma etiqueta de tecla, um display de tela — Nano Banana 2 trata texto como um elemento de primeira classe ao invés de uma textura visual. Isso importa mais do que você esperaria quando a câmera está fazendo zoom num detalhe do produto.

Aqui está o processo real:

Gerando a imagem inicial

Abra o Higgsfield e selecione Nano Banana 2 como seu modelo. Seu prompt precisa alcançar três coisas simultaneamente: descrever o produto, estabelecer o ângulo de câmera e — este é o que a maioria esquece — especificar a cor de fundo para combinar com seu site.

A premium mechanical keyboard, matte black finish, centered on a pure
#0F172A dark background. Studio lighting from above-right creating subtle
highlights on keycaps. Photorealistic product photography style. Sharp
focus. 2K resolution. No additional objects or surfaces — just the
keyboard floating against the dark background.

Esse código hexadecimal — #0F172A — é a cor de fundo do site que estou construindo. Isso é crítico. Se sua imagem gerada tem um tom de escuro levemente diferente (digamos, puro #000000 ou um cinza escuro #1a1a1a), você verá uma borda retangular visível ao redor da imagem quando ela for colocada no site. O produto não vai parecer que está flutuando na página. Vai parecer uma imagem colada numa página. A diferença entre "premium" e "amador" vive nesse único detalhe.

Gerando a imagem final

A imagem final representa onde a animação pousa quando o usuário fez scroll completamente pela seção. Pode ser qualquer coisa — uma vista explodida, uma perspectiva de raio-X, uma mudança de cor, uma transformação. A liberdade criativa aqui é genuinamente ampla.

O truque com o prompt da imagem final: você pode referenciar a imagem inicial diretamente. O Higgsfield permite que você faça upload de uma imagem de referência, o que significa que seu prompt pode ser mais simples porque o modelo já tem contexto sobre o produto, a iluminação e o fundo.

The same keyboard from the reference image, now deconstructed — keys
floating slightly above the board, internal PCB circuitry visible,
transparent casing revealing RGB LED components underneath. Same studio
lighting. Same #0F172A background. X-ray effect showing the engineering
beneath the surface. Photorealistic. 2K resolution.

Ao referenciar a imagem inicial, você não precisa re-descrever cada propriedade de material. O modelo transfere a identidade do produto, ângulo de iluminação e cor de fundo — e você só precisa descrever o que é diferente.

Uma nota sobre complexidade: Mantenha o estado final relativamente simples em termos de implicação de movimento. Você está pedindo a um modelo de vídeo para gerar a transição entre esses dois estados, e estados finais excessivamente complexos (como "o teclado derrete em metal líquido que se reforma como um laptop") produzirão vídeo confuso com artefatos. Os melhores resultados vêm de transições com lógica física clara — montagem/desmontagem, rotação, zoom, revelação de transparência, mudança de cor.

Passo 2: Gerando o vídeo de transição com Kling 3.0

Com ambos os keyframes em mãos, você precisa de um modelo de vídeo IA para gerar a transição suave entre eles. Eu usei Kling 3.0, que a Kuaishou lançou em 4 de fevereiro de 2026. Você também pode usar Veo 3.1, o modelo de geração de vídeo do Google — ambos suportam geração de imagem para vídeo com frames inicial e final.

Por que Kling 3.0 funciona bem para isso

A simulação de física do Kling 3.0 é a mais realista de qualquer modelo de vídeo atual. Para animações de produtos especificamente, isso significa que materiais se comportam corretamente — metal reflete luz ao rotacionar, plástico refrata adequadamente, elementos transparentes interagem com fontes de luz atrás deles. O modelo produz em 1080p a até 60fps, e você pode gerar clipes de até 15 segundos.

Para fins de animação de scroll, você quer um clipe de 3-5 segundos. Clipes mais curtos significam menos frames para extrair e carregar, o que impacta diretamente o desempenho da página. Um clipe de 5 segundos a 30fps te dá 150 frames — são 150 imagens individuais que o navegador precisa pré-carregar. Um clipe de 3 segundos a 30fps te dá 90 frames. Ambos funcionam. O clipe mais curto carrega mais rápido; o mais longo permite uma sensação de animação mais gradual e prolongada.

O processo de geração de vídeo

No Kling 3.0 (ou Veo 3.1), selecione o modo de imagem para vídeo. Faça upload da sua imagem inicial como primeiro frame e da imagem final como último frame. Então escreva um prompt descrevendo a transição:

Smooth transition from assembled keyboard to deconstructed X-ray view.
Keys lift gradually, casing becomes transparent, internal components
reveal. Steady camera position. Even, unhurried motion. Studio lighting
maintained throughout.

Duas configurações críticas para ficar atento:

1. NÃO ative o auto-aprimoramento do prompt. Tanto Kling quanto Veo oferecem aprimoramento de prompt por IA que reescreve sua entrada para ser "mais detalhada". Para este caso de uso, esse aprimoramento tende a adicionar floreios criativos — movimentos de câmera, mudanças dramáticas de iluminação, efeitos de partículas — que arruínam a transição limpa e controlada que você precisa. Mantenha simples. Quanto mais simples o prompt, mais suave a saída.

2. Combine a proporção de aspecto com suas imagens. Se você gerou imagens 16:9, gere um vídeo 16:9. Proporções não combinadas significam que o modelo de vídeo vai cortar ou preencher seus keyframes, o que mata o alinhamento perfeito que você precisa.

Gere o vídeo. Revise-o. Se a transição tem artefatos, interpolação de frames estranha ou não pousa limpa na sua imagem final, regenere. Kling 3.0 é razoavelmente consistente, mas modelos de geração de vídeo são inerentemente probabilísticos — às vezes a segunda ou terceira tentativa é notavelmente melhor.

Assim que tiver um MP4 limpo da transição, a parte divertida começa.

Passo 3: De vídeo a flipbook — Claude Code faz o trabalho pesado

É aqui que o fluxo de trabalho muda de trabalho criativo assistido por IA para engenharia assistida por IA. E é aqui que Claude Code conquista sua reputação.

O objetivo: pegar esse arquivo MP4 e convertê-lo numa animação controlada por scroll pronta para produção incorporada num site Next.js. Isso significa extrair frames, convertê-los para um formato otimizado, construir o listener de scroll, gerenciar o pré-carregamento e embrulhar tudo numa landing page polida.

Aqui está o passo a passo.

3a: Extração de frames com FFMPEG

FFMPEG é o cavalo de batalha aqui. Se você não tem instalado, Claude Code normalmente pedirá que instale (brew install ffmpeg no macOS, apt install ffmpeg no Ubuntu). O comando de extração é assim:

ffmpeg -i keyboard-transition.mp4 -vf "fps=30" -c:v libwebp -quality 85 frames/frame_%04d.webp

Detalhando:

• -i keyboard-transition.mp4 — seu vídeo de entrada
• -vf "fps=30" — extrair a 30 frames por segundo (correspondendo à taxa de frames nativa do vídeo)
• -c:v libwebp — codificar cada frame como WEBP (não JPEG, não PNG)
• -quality 85 — configuração de qualidade WEBP; 85 é o ponto ideal entre qualidade visual e tamanho de arquivo
• frames/frame_%04d.webp — saída para um diretório frames/ com numeração preenchida com zeros

Por que WEBP ao invés de JPEG? Tamanho de arquivo. Imagens WEBP são aproximadamente 25-35% menores que JPEGs de qualidade equivalente, e quando você está carregando 90-180 frames, essa vantagem de compressão se acumula rapidamente. Uma sequência de frames que pesa 12MB em JPEG pode ser 8MB em WEBP. Numa conexão móvel, essa é a diferença entre uma experiência fluida e um indicador de carregamento.

Para um clipe de 5 segundos a 30fps, você terá aproximadamente 150 frames. Cada frame WEBP em 1080p qualidade-85 tipicamente pesa 30-60KB, colocando sua sequência total em 4,5-9MB. Isso é gerenciável — especialmente com pré-carregamento, que configuraremos a seguir.

3b: Usando prompts com Claude Code para construir a animação de scroll

Aqui é onde fica bom. Você não precisa escrever o listener de scroll, a lógica de renderização do canvas, o sistema de pré-carregamento ou o layout da página manualmente. Você dá o prompt ao Claude Code com o contexto certo e ele constrói tudo.

O prompt que usei:

Build a product landing page for a premium mechanical keyboard called
"Void MK1" using Next.js and Tailwind CSS. The hero section features a
scroll-driven frame animation.

Technical requirements:
- Load WEBP frames from /public/frames/ directory (frame_0001.webp through
  frame_0150.webp)
- Use a <canvas> element to render frames
- Map scroll position to frame number (scroll 0% = frame 1, scroll 100% =
  frame 150)
- Pre-load all frames on page mount before enabling scroll animation
- Show a subtle loading indicator until all frames are loaded
- The animation section should be pinned (position: sticky) while the user
  scrolls through it
- Use requestAnimationFrame for smooth rendering
- Background color: #0F172A

Design requirements:
- Dark, premium aesthetic
- Product title and tagline overlay on the animation
- Feature cards below the animation section
- Smooth transitions between sections

Claude Code pega isso e constrói a aplicação completa. As peças técnicas principais que ele gera:

O pré-carregador de frames — uma função que cria objetos Image para cada frame, carrega-os em paralelo e rastreia o progresso. A animação não começa até que cada frame esteja em cache na memória. Isso é o que previne aquela experiência irregular de "carregar frames sob demanda".

const preloadFrames = async (frameCount) => {
  const frames = [];
  let loaded = 0;

  const promises = Array.from({ length: frameCount }, (_, i) => {
    return new Promise((resolve) => {
      const img = new Image();
      img.src = `/frames/frame_${String(i + 1).padStart(4, '0')}.webp`;
      img.onload = () => {
        frames[i] = img;
        loaded++;
        setLoadProgress(Math.round((loaded / frameCount) * 100));
        resolve();
      };
    });
  });

  await Promise.all(promises);
  return frames;
};

O mapeador de scroll para frame — calcula qual frame exibir baseado na posição de scroll do usuário dentro da seção de animação. A seção é fixada com position: sticky, e a distância de scroll é dividida uniformemente pelo total de frames.

const handleScroll = () => {
  const scrollTop = window.scrollY;
  const sectionTop = sectionRef.current.offsetTop;
  const sectionHeight = sectionRef.current.offsetHeight - window.innerHeight;

  const scrollProgress = Math.max(0, Math.min(1,
    (scrollTop - sectionTop) / sectionHeight
  ));

  const frameIndex = Math.round(scrollProgress * (totalFrames - 1));

  requestAnimationFrame(() => {
    const ctx = canvasRef.current.getContext('2d');
    ctx.clearRect(0, 0, canvas.width, canvas.height);
    ctx.drawImage(frames[frameIndex], 0, 0, canvas.width, canvas.height);
  });
};

O renderizador de canvas — desenha o frame atual num elemento <canvas> dimensionado para corresponder à resolução nativa do vídeo. Usar requestAnimationFrame garante que a chamada de desenho esteja sincronizada com o ciclo de atualização do navegador, eliminando tearing visual.

Claude Code embala tudo isso num componente React limpo com gerenciamento adequado de ciclo de vida — estado de carregamento, tratamento de erros, limpeza ao desmontar e listeners de redimensionamento para manter o canvas responsivo.

3c: O arquivo Markdown de melhores práticas

Uma técnica que melhorou dramaticamente a saída do Claude Code: forneci a ele um arquivo markdown de melhores práticas para animações de scroll antes de dar o prompt de construção. Pense nisso como uma injeção de contexto estilo CLAUDE.md, mas focada especificamente no domínio de animação.

O arquivo cobriu coisas como:

• Usar will-change: transform no canvas para composição GPU
• Limitar listeners de scroll a 60fps usando requestAnimationFrame — nunca vincular diretamente ao evento de scroll sem limitação
• Definir dimensões do canvas via JavaScript, não CSS, para evitar escalonamento borrado
• Pré-carregar frames em lotes de 10-20 para mostrar feedback de carregamento progressivo
• Usar decoding: async em objetos Image para evitar bloquear a thread principal
• Manter a altura da seção fixada em 100vh * (totalFrames / 30) para velocidade de scroll natural

Alimentar Claude Code com melhores práticas específicas do domínio antes do prompt de construção produz consistentemente melhores resultados na primeira tentativa do que confiar apenas em seu conhecimento geral. Eu escrevi sobre essa abordagem antes com arquivos CLAUDE.md — funciona aqui pela mesma razão.

Passo 4: Personalização e polimento

A saída bruta do Claude Code é funcional e surpreendentemente polida. Mas é aqui que você a torna sua.

Ajustando a velocidade de scroll

A velocidade de scroll da animação é controlada pela altura da seção fixada. Uma seção mais alta significa mais distância de scroll para percorrer o mesmo número de frames, o que significa animação mais lenta. Uma seção mais curta significa mais rápido.

O padrão que Claude Code gera é geralmente height: 300vh (três alturas de viewport de distância de scroll para a animação completa). Eu tipicamente ajusto baseado no conteúdo da animação:

• Revelações rápidas (rotação ou zoom simples): 200vh se sente natural
• Transições complexas (desmontagem, raio-X): 400vh dá ao usuário tempo para absorver o detalhe
• Efeitos dramáticos (construção do nada): 500vh cria um ritmo cinematográfico

Diga ao Claude Code: "Faça a seção de animação ter scroll mais lento — aumente a altura fixada para 400vh." Ele ajustará e garantirá que a matemática de mapeamento de frames ainda funcione corretamente.

Resolução e nitidez

Kling 3.0 produz em 1080p. Num display 1920x1080, isso preenche a tela perfeitamente. Num display 2560x1440 ou 4K, a animação ficará levemente suave se você escalar para largura total.

Duas soluções:

1. Restrinja a área de animação. Não faça o canvas em largura total. Um max-width: 1080px com margin: auto mantém cada frame pixel-perfeito e parece intencional — como uma vitrine de produto num viewport definido.

2. Amplie antes da extração. Se precisa de animação sangrada em displays grandes, use um upscaler IA (Topaz Video AI, ou mesmo o filtro scale embutido do FFMPEG) no vídeo antes de extrair frames. Isso aumenta o tamanho do arquivo, então equilibre nitidez contra tempo de carregamento.

Geralmente escolho a opção 1. Restringir a área de animação na verdade parece mais premium — dá ao produto espaço visual para respirar, e o fundo escuro ao redor reforça a estética de flutuando-no-espaço que as páginas de produto da Apple usam.

Ajustando o design

É aqui que o fluxo de trabalho iterativo do Claude Code brilha. Uma vez que a página base está construída, você pode dar prompts de refinamento conversacionalmente:

• "Adicione uma sobreposição de gradiente sutil no topo e no fundo da seção de animação"
• "Faça o título do produto aparecer gradualmente no frame 30 e deslizar de baixo para cima"
• "Adicione uma barra de progresso abaixo da animação que se preenche conforme o usuário faz scroll"
• "Mude os cards de funcionalidades para um layout de duas colunas com estilo glassmorphism"

Cada prompt refina sem reconstruir. Claude Code entende a estrutura de componentes existente e faz mudanças direcionadas. Aqui é onde você sai de "demo tecnicamente impressionante" para "página que eu realmente entregaria para um cliente."

Se preferir que alguém construa toda essa configuração do zero para seu produto ou marca, eu aceito esse tipo de projetos personalizados. Você pode ver o que construí em fiverr.com/s/EgxYmWD.

O que errei da primeira vez (e o que você deve pular)

Quero ser honesto sobre os erros que cometi, porque eles vão te economizar tempo real.

Erro 1: Usar JPEG para os frames. Minha primeira tentativa extraiu frames como JPEGs de alta qualidade. A animação tinha 14MB no total. Depois de mudar para WEBP com qualidade 85, caiu para 8,2MB sem diferença visível. Essa não é uma otimização pequena — é a diferença entre um carregamento inicial de 2 e 4 segundos numa conexão móvel típica.

Erro 2: Não combinar as cores de fundo exatamente. Minhas primeiras imagens geradas usaram um fundo que eu descreveria como "escuro" sem especificar um código hexadecimal. As imagens voltaram com aproximadamente #111111. Meu site era #0F172A — o slate-900 do Tailwind. A discrepância era sutil mas imediatamente visível: uma borda retangular tênue ao redor da animação onde o fundo da imagem encontrava o fundo da página. Regenerei as imagens com o código hexadecimal exato no prompt e o problema desapareceu.

Erro 3: Gerar um vídeo de 10 segundos. Mais frames não é melhor. Meu primeiro vídeo foi 10 segundos de transição lenta e dramática. Extraído a 30fps, isso me deu 300 frames. O tempo de pré-carregamento era doloroso, o tamanho total de arquivo era enorme, e a animação se arrastava tanto que os usuários faziam scroll passando por impaciência. Cortei para 4 segundos (120 frames) e a experiência melhorou dramaticamente. A animação se sentiu mais ajustada, o carregamento foi mais rápido e os usuários realmente interagiram com ela.

Erro 4: Deixar o Kling auto-aprimorar meu prompt. A função de auto-aprimoramento reescreveu meu prompt de transição simples em algo com "mudanças dramáticas de iluminação cinematográfica, efeitos etéreos de partículas e dolly de câmera dinâmico." O vídeo resultante era visualmente deslumbrante — como vídeo. Mas como animação de scroll, todos aqueles movimentos dinâmicos de câmera e mudanças de iluminação faziam o scrubbing frame a frame parecer caótico. Prompts simples produzem transições simples, e transições simples produzem as melhores animações de scroll.

Erro 5: Canvas em largura total num monitor 4K. Os frames de 1080p pareciam bons no meu laptop. No meu monitor externo, pareciam como se eu tivesse dado zoom num JPEG comprimido. Restringir o canvas para max-width: 1080px corrigiu isso imediatamente e na verdade melhorou o design.

Cada um desses erros me custou 15-30 minutos de depuração e regeneração. Pule-os e você já terá cortado seu tempo total de construção pela metade.

As possibilidades criativas são mais amplas do que você pensa

Usei uma desmontagem de teclado para este guia porque é visual e limpo. Mas o mesmo pipeline funciona para qualquer produto e qualquer conceito de transição. Aqui estão abordagens que testei ou vi outros executarem:

Construção do nada: Comece com um fundo escuro vazio. Termine com o produto totalmente montado. O vídeo gera o produto se materializando peça por peça — quase como um timelapse de impressão 3D. Incrível para lançamentos de produtos.

Transição de material: Comece com um render em argila ou wireframe do produto. Termine com a versão final texturizada e iluminada. A animação de scroll revela gradualmente os materiais premium do produto. Funciona lindamente para bens de luxo.

Mudança de ambiente: Comece com o produto num ambiente de estúdio. Termine com ele num contexto de lifestyle (numa mesa, numa mão, num cômodo). A transição mescla os ambientes de forma perfeita.

Mudança de cor: Comece em monocromático. Termine com cor completa. O scroll revela progressivamente a paleta de cores do produto. Simples de gerar, surpreendentemente eficaz visualmente.

Mudança de escala: Comece com uma vista completa do produto. Termine com uma tomada de detalhe macro — uma textura, um botão, um close-up de material. O vídeo gera um zoom suave que o scroll controla.

A limitação é sua imaginação e a capacidade do modelo de vídeo de gerar uma transição limpa entre seus dois keyframes. Desde que a transição tenha lógica física clara, Kling 3.0 e Veo 3.1 lidam bem com isso.

Números de desempenho que vale a pena conhecer

Rodei Lighthouse e WebPageTest na página publicada. Aqui estão os números:

• Carga total de frames (120 frames, WEBP, qualidade 85): 6,4MB
• Carregamento inicial da página (antes dos frames): 0,8 segundos numa conexão de 50Mbps
• Tempo de pré-carregamento dos frames: 2,1 segundos em 50Mbps, 4,8 segundos numa conexão 3G limitada
• Pontuação de Desempenho Lighthouse: 91 (desktop), 78 (mobile)
• Largest Contentful Paint: 1,2s desktop, 2,8s mobile
• Total Blocking Time: 12ms — o carregamento de frames acontece assincronamente e não bloqueia a thread principal

A pontuação mobile de 78 é o ponto fraco. Esses 120 frames WEBP ainda se acumulam em conexões lentas. Para sites mobile-first, eu recomendaria uma de duas abordagens: reduzir para 60 frames (extraindo cada outro frame do vídeo) para dispositivos móveis usando uma verificação responsiva, ou implementar um fallback de animação CSS mais simples para conexões abaixo de um limiar de velocidade.

Para landing pages focadas em desktop e vitrines de produtos — que é onde essas animações mais brilham — o desempenho é excelente.

Como isso se compara aos métodos tradicionais

Para colocar o pipeline de IA em perspectiva:

Abordagem tradicional de renderização 3D (Blender/Cinema 4D):

• Modelar o produto em 3D (4-8 horas para um produto detalhado)
• Configurar materiais, iluminação e câmera (2-4 horas)
• Animar a transição (2-4 horas)
• Renderizar 120-180 frames em 1080p (1-3 horas de tempo de computação)
• Construir a animação de scroll em código (2-4 horas)
• Total: 11-23 horas de trabalho especializado

Abordagem do pipeline IA (Nano Banana 2 + Kling 3.0 + Claude Code):

• Gerar imagens keyframe (10-15 minutos incluindo iterações)
• Gerar vídeo de transição (5-10 minutos incluindo regeneração)
• Extrair frames e construir site com Claude Code (20-40 minutos)
• Personalizar e polir (15-30 minutos)
• Total: 50-95 minutos

Essa não é uma diferença pequena. É aproximadamente uma redução de 10-15x em tempo, e não requer expertise em modelagem 3D, uma fazenda de renderização ou um desenvolvedor frontend sênior que entenda otimização de desempenho do canvas.

A compensação é controle. Com Blender, você controla cada polígono, cada raio de luz, cada frame da animação. Com o pipeline de IA, você controla o início, o fim e o prompt que guia a transição — e o modelo de vídeo decide o que fica entre eles. Para a maioria das landing pages de produto e sites de marketing, esse nível de controle é mais que suficiente. Para trabalho de marca pixel-perfeito onde cada frame precisa de aprovação de um diretor criativo, você ainda vai querer o pipeline tradicional.

Mas para 90% dos sites que eu construo? O pipeline de IA vence disparado. E a distância entre essas duas abordagens está diminuindo a cada atualização de modelo.

O que vem a seguir para esta técnica

Estou acompanhando três desenvolvimentos que levarão isso ainda mais longe.

Modelos de vídeo de maior resolução. Kling 3.0 chega ao máximo em 1080p. No momento em que esses modelos entregarem saída nativa 4K — e Kling já indicou que isso está vindo — o teto de qualidade de frames desaparece completamente. Animações de scroll em tela cheia em displays 4K sem upscaling.

Geração de vídeo coerente mais longa. Os modelos atuais produzem 5-15 segundos de vídeo coerente. Conforme isso se estender para 30-60 segundos, você poderá construir animações de scroll multi-seção a partir de um único vídeo — uma página inteira que conta a história de um produto através do scroll, não apenas uma única seção hero.

Melhorias nativas do navegador para animações controladas por scroll. A especificação CSS animation-timeline: scroll() ainda está evoluindo. Conforme os navegadores adicionam suporte para animações mais complexas baseadas em timeline — incluindo abordagens baseadas em canvas — o overhead de JavaScript diminuirá. A técnica de frames-em-canvas continuará sendo o padrão ouro para animações fotorrealistas, mas o código ao redor ficará mais simples.

Por enquanto, o pipeline funciona. Funciona hoje, com ferramentas que você pode acessar hoje, produzindo resultados que parecem ter custado cinco dígitos. E cada peça dele — a geração de imagem, a geração de vídeo, a extração de frames, o código de animação de scroll — é tratada por IA.

Isso não é um vislumbre do futuro. É o que está no seu navegador, esperando você experimentar.

Uma ação específica que você pode tomar na próxima hora: vá ao Higgsfield, gere duas imagens de qualquer produto — estado inicial e estado final — com o código hexadecimal exato do fundo do seu site no prompt. Apenas essas duas imagens. Assim que as vir lado a lado e começar a imaginar a transição entre elas, você entenderá visceralmente por que esse pipeline funciona. O resto da construção segue naturalmente daquela única decisão criativa.

A web controlada por scroll não está vindo. Já está aqui. A única pergunta é se sua próxima landing page a utiliza — ou compete contra alguém que utiliza.

Perguntas frequentes

Quantos frames eu preciso para uma animação de scroll suave?

Entre 90 e 150 frames entrega o melhor equilíbrio entre suavidade e desempenho. Abaixo de 60 frames, a animação parece irregular durante scroll lento. Acima de 180, você está adicionando peso de arquivo sem melhoria visível. Para a maioria das animações de produtos, extraia um vídeo de 3-5 segundos a 30fps.

Isso funciona em dispositivos móveis?

Sim, mas com ressalvas. A renderização do canvas e o mapeamento de scroll funcionam em todos os navegadores móveis modernos. O gargalo de desempenho é pré-carregar as imagens de frames — em conexões lentas, considere servir menos frames (60 ao invés de 120) para usuários móveis via uma verificação de breakpoint responsivo.

Posso usar esta técnica com WordPress ao invés de Next.js?

Absolutamente. O plugin Xplode Motion e Scrollsequence ambos suportam animações de scroll baseadas em frames no WordPress sem código personalizado. Para uma implementação personalizada, a mesma abordagem de canvas + frames funciona em qualquer framework — a lógica JavaScript é agnóstica a framework.

E se meu vídeo gerado por IA tiver artefatos ou glitches?

Regenere. Modelos de geração de vídeo são probabilísticos — o mesmo prompt produz diferentes resultados a cada tentativa. Se você consistentemente obtém artefatos, simplifique seu prompt de transição. Transições complexas (múltiplos movimentos simultâneos, mudanças dramáticas de iluminação) produzem mais artefatos que simples (rotação de um eixo, revelação gradual, zoom lento).

Quanto custa este fluxo de trabalho?

Nano Banana 2 no Higgsfield oferece acesso gratuito para geração básica de imagens. Os preços do Kling 3.0 começam em aproximadamente $0,10-0,30 por geração de vídeo de 5 segundos dependendo do seu plano. Claude Code requer assinatura Pro ou Team. Gasto total para uma única animação: menos de $5 na maioria dos casos, excluindo a assinatura do Claude Code que você provavelmente já tem.

Vamos trabalhar juntos

Procurando construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.

• Fiverr (builds e integrações personalizadas): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design e branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io