Hero-Slider para TYPO3

O hero slider é a área mais cara de um site TYPO3, medida em tempo de carregamento

A área hero é a primeira coisa que visitantes veem. Com um slider, é também a mais lenta. Um hero slider típico no TYPO3 carrega 3 a 5 imagens em grande formato (500 KB a 2 MB cada), uma biblioteca JavaScript (jQuery + plugin de slider: 120 a 200 KB), animações CSS e scripts de inicialização. Juntos são 3 a 12 MB de dados antes que o visitante possa clicar em qualquer coisa. O Largest Contentful Paint (LCP) com tais configurações fica rotineiramente acima de 4 segundos, o que o Google classifica como “ruim” e custa rankings.

A solução não é um slider melhor, mas nenhum slider ou um radicalmente leve. Soluções CSS-only e bibliotecas de slider modernas como Swiper alcançam o mesmo efeito visual com uma fração do tempo de carregamento.

Cenários típicos de uso

Páginas iniciais com campanhas rotativas. Marketing quer posicionar 3 a 5 mensagens proeminentemente: campanha sazonal, novo produto, anúncio de evento, premiação. O slider rota automaticamente, cada slide tem imagem, headline e botão CTA. O problema: estudos mostram consistentemente que apenas 1 a 2% dos visitantes interagem além do primeiro slide. Os outros 4 slides são carregados, mas não vistos. Uma imagem hero estática com uma mensagem clara performa regularmente melhor em testes A/B que um slider.

Galerias de imagens na área do header. Hotéis, restaurantes e locais de eventos mostram impressões como hero slider: vista externa, interior, terraço, pratos. Aqui um slider faz sentido, porque visitantes esperam múltiplas impressões. A otimização de performance: carregar apenas a primeira imagem imediatamente, as restantes via lazy loading. Com Intersection Observer e loading="lazy", isso é possível sem biblioteca de slider.

Destaques de produto com animação. Sites de e-commerce mostram destaques de produto como slides animados. A animação deve gerar atenção. Na prática: transições CSS (transform, opacity) são mais performantes que animações JavaScript e usam GPU em vez de CPU. Um slider CSS-only com scroll-snap-type e transition alcança 60 fps em qualquer dispositivo.

Arquitetura técnica

Hero sliders no TYPO3 são tipicamente implementados como Content Element: um FlexForm com configuração de slides (imagem, texto, link, ordem) e um template Fluid que renderiza os slides. A lógica do slider é executada por uma biblioteca JavaScript.

As bibliotecas mais utilizadas em projetos TYPO3: FlexSlider (desatualizado, jQuery), Slick (desatualizado, jQuery), Owl Carousel (desatualizado, jQuery), Swiper (moderno, sem jQuery, 139 KB) e Splide (moderno, sem jQuery, 29 KB). A escolha da biblioteca determina as características de performance de toda a área hero.

A arquitetura ideal para um hero slider em 2026:

Opção 1: CSS-only (0 KB JavaScript). scroll-snap-type: x mandatory no container, scroll-snap-align: start nos slides. Navegação via scroll-behavior: smooth e anchor links. Autoplay via animação CSS (@keyframes). Sem JavaScript necessário. Funciona em todos os navegadores modernos. Desvantagens: sem autoplay programático com pause-on-hover, sem animações de swipe.

Opção 2: Swiper/Splide (29-139 KB JavaScript). Funcionalidade completa de slider com touch, swipe, autoplay, paginação, lazy loading. Tree-shakeable, apenas os módulos usados são carregados. Integração no TYPO3 via Custom Content Element com FlexForm.

Opção 3: Hero estático (0 KB JavaScript, 1 imagem). Uma imagem, uma headline, um CTA. A configuração mais rápida e com maior conversão. A imagem é entregue como <picture> com srcset: 375px para mobile, 768px para tablet, 1440px para desktop. Com formato AVIF/WebP abaixo de 100 KB por variante.

Problemas frequentes e soluções

LCP acima de 4 segundos. A imagem hero é o elemento LCP. Se carrega tarde demais, o score LCP é ruim. Solução: carregar a primeira imagem do slide com fetchpriority="high" e loading="eager" (não lazy). As demais slides com loading="lazy". Converter formato de imagem para WebP/AVIF. Limitar tamanho de imagem ao tamanho real de exibição (sem imagem de 4000px para um viewport de 1440px).

Cumulative Layout Shift (CLS) por slider que carrega depois. O container do slider inicialmente não tem altura, após a inicialização JavaScript o layout salta. Solução: fixar a altura do container do slider via CSS (p.ex. aspect-ratio: 16/9 ou min-height: 60vh). Assim o navegador reserva o espaço antes do JavaScript ser carregado.

Autoplay não funciona em dispositivos móveis. iOS Safari bloqueia autoplay de vídeos e algumas animações CSS por razões de economia de energia. Solução: desativar autoplay em dispositivos móveis e oferecer navegação por swipe. Visitantes em smartphones sabem que podem deslizar. Uma indicação estática (“Deslize para mais”) é desnecessária.

Migração e compatibilidade de versões

A maioria das extensões de hero slider no TER são desatualizadas e suportam no máximo TYPO3 v10 ou v11. Para v12/v13, recomenda-se sem exceção um Custom Content Element no sitepackage que incorpora uma biblioteca moderna ou aposta completamente em CSS.

A migração de sliders existentes ocorre em três passos: exportar dados de slides (imagens, textos, links do FlexForm ou banco de dados), configurar novo Content Element (FlexForm com os mesmos campos, mas template moderno) e converter os elementos de conteúdo existentes via SQL para o novo CType. O esforço: 1 a 2 dias para a configuração técnica, mais 0,5 dia por 10 sliders existentes para a migração de dados.

A Gosign recomenda em todo projeto de hero slider primeiro a pergunta: o site realmente precisa de um slider? Em 70% dos casos, um elemento hero estático performa melhor. Para os 30% restantes, a Gosign entrega uma solução Swiper ou CSS-only que permanece abaixo de 1,5 segundos de LCP.