Hero Slider for TYPO3

Der Hero-Slider ist der teuerste Bereich einer TYPO3-Website, gemessen in Ladezeit

Der Hero-Bereich ist das erste, was Besucher sehen. Bei einem Slider ist es auch das langsamste, was sie sehen. Ein typischer Hero-Slider in TYPO3 lädt 3-5 großformatige Bilder (je 500 KB-2 MB), eine JavaScript-Library (jQuery + Slider-Plugin: 120-200 KB), CSS-Animationen und Initialisierungs-Scripts. Zusammen sind das 3-12 MB Daten, bevor der Besucher irgendwo klicken kann. Der Largest Contentful Paint (LCP) liegt bei solchen Setups routinemäßig über 4 Sekunden, was Google als “schlecht” einstuft und Rankings kostet.

Die Lösung ist nicht ein besserer Slider, sondern entweder kein Slider oder ein radikal leichtgewichtiger. CSS-only-Lösungen und moderne Slider-Libraries wie Swiper erreichen den gleichen visuellen Effekt bei einem Bruchteil der Ladezeit.

Typical use cases

Startseiten mit wechselnden Kampagnen. Marketing will 3-5 Botschaften prominent platzieren: saisonale Kampagne, neues Produkt, Event-Ankündigung, Award-Nachricht. Der Slider rotiert automatisch, jede Slide hat Bild, Headline und CTA-Button. Das Problem: Studien zeigen konsistent, dass nur 1-2% der Besucher über die erste Slide hinaus interagieren. Die restlichen 4 Slides werden geladen, aber nicht gesehen. Ein statisches Hero-Bild mit einer klaren Botschaft performt in A/B-Tests regelmäßig besser als ein Slider.

Bildergalerien im Header-Bereich. Hotels, Restaurants und Eventtlocations zeigen Impressionen als Hero-Slider: Außenansicht, Innenraum, Terrasse, Speisen. Hier macht ein Slider inhaltlich Sinn, weil Besucher mehrere Eindrücke erwarten. Die Performance-Optimierung: Nur das erste Bild sofort laden, die restlichen per Lazy Loading nachladen. Mit Intersection Observer und loading="lazy" ist das ohne Slider-Library möglich.

Produkt-Highlights mit Animation. E-Commerce-Websites zeigen Produkt-Highlights als animierte Slides. Die Animation soll Aufmerksamkeit erzeugen. In der Praxis: CSS-Transitions (transform, opacity) sind performanter als JavaScript-Animationen und belasten die GPU statt der CPU. Ein CSS-only-Slider mit scroll-snap-type und transition erreicht 60 fps auf jedem Gerät.

Technical architecture

Hero-Slider in TYPO3 werden typischerweise als Content Element implementiert: ein FlexForm mit Slide-Konfiguration (Bild, Text, Link, Reihenfolge) und ein Fluid-Template, das die Slides rendert. Die Slider-Logik übernimmt eine JavaScript-Library.

Die verbreiteten Libraries in TYPO3-Projekten: FlexSlider (veraltet, jQuery), Slick (veraltet, jQuery), Owl Carousel (veraltet, jQuery), Swiper (modern, kein jQuery, 139 KB) und Splide (modern, kein jQuery, 29 KB). Die Wahl der Library bestimmt die Performance-Charakteristik des gesamten Hero-Bereichs.

Die optimale Architektur für einen Hero-Slider in 2026:

Option 1: CSS-only (0 KB JavaScript). scroll-snap-type: x mandatory auf dem Container, scroll-snap-align: start auf den Slides. Navigation per scroll-behavior: smooth und Anchor-Links. Autoplay per CSS-Animation (@keyframes). Kein JavaScript nötig. Funktioniert in allen modernen Browsern. Nachteile: Kein programmatisches Autoplay mit Pause-on-Hover, keine Swipe-Animationen.

Option 2: Swiper/Splide (29-139 KB JavaScript). Volle Slider-Funktionalität mit Touch, Swipe, Autoplay, Pagination, Lazy Loading. Tree-Shakeable, nur die genutzten Module werden geladen. Integration in TYPO3 über ein Custom Content Element mit FlexForm.

Option 3: Statisches Hero (0 KB JavaScript, 1 Bild). Ein Bild, eine Headline, ein CTA. Das schnellste und conversion-stärkste Setup. Das Bild wird als <picture> mit srcset ausgeliefert: 375px für Mobile, 768px für Tablet, 1440px für Desktop. Mit AVIF/WebP-Format unter 100 KB pro Variante.

Common problems and solutions

LCP über 4 Sekunden. Das Hero-Bild ist das LCP-Element. Wenn es zu spät lädt, ist der LCP-Score schlecht. Lösung: Das erste Slide-Bild mit fetchpriority="high" und loading="eager" laden (nicht lazy). Die restlichen Slides mit loading="lazy". Bildformat auf WebP/AVIF umstellen. Bildgröße auf die tatsächliche Darstellungsgröße begrenzen (kein 4000px-Bild für einen 1440px-Viewport).

Cumulative Layout Shift (CLS) durch nachladende Slider. Der Slider-Container hat zunächst keine Höhe, nach dem JavaScript-Init springt das Layout. Lösung: Die Höhe des Slider-Containers per CSS fixieren (z.B. aspect-ratio: 16/9 oder min-height: 60vh). Damit reserviert der Browser den Platz, bevor das JavaScript geladen ist.

Autoplay auf Mobilgeräten funktioniert nicht. iOS Safari blockiert Autoplay-Videos und manche CSS-Animationen aus Energiespar-Gründen. Lösung: Autoplay auf Mobilgeräten deaktivieren und stattdessen Swipe-Navigation anbieten. Besucher auf Smartphones wissen, dass sie wischen können. Ein statischer Hinweis (“Wischen für mehr”) ist unnötig.

Migration and version compatibility

Die meisten Hero-Slider-Extensions im TER sind veraltet und unterstützen maximal TYPO3 v10 oder v11. Für v12/v13 empfiehlt sich ausnahmslos ein Custom Content Element im Sitepackage, das eine moderne Library einbindet oder komplett auf CSS setzt.

Die Migration bestehender Slider erfolgt in drei Schritten: Slide-Daten exportieren (Bilder, Texte, Links aus der FlexForm oder Datenbank), neues Content Element aufsetzen (FlexForm mit denselben Feldern, aber modernem Template) und die bestehenden Content-Elemente per SQL auf den neuen CType umstellen. Der Aufwand: 1-2 Tage für das technische Setup, plus 0,5 Tage pro 10 existierenden Slidern für die Datenmigration.

Gosign empfiehlt bei jedem Hero-Slider-Projekt zuerst die Frage: Braucht die Website wirklich einen Slider? In 70% der Fälle performt ein statisches Hero-Element besser. Für die restlichen 30% liefert Gosign eine Swiper- oder CSS-only-Lösung, die unter 1,5 Sekunden LCP bleibt.