Slick Carousel für TYPO3

Slick Carousel zwingt TYPO3-Websites, jQuery zu laden, obwohl es seit Jahren Alternativen ohne gibt

Slick (von Ken Wheeler) war zwischen 2014 und 2020 der populärste JavaScript-Slider. “The last carousel you’ll ever need” versprach die Dokumentation. Responsive, Touch-fähig, Lazy Loading, Autoplay, Infinite Scroll, Variable Width. Für TYPO3 gibt es mit slickcarousel eine Extension, die Slick als Content-Element einbindet. Das Problem in 2026: Slick hängt an jQuery. Das letzte Slick-Release stammt von 2017 (v1.8.1). Keine Updates seit über 8 Jahren, keine Bug-Fixes, keine Sicherheitspatches.

jQuery selbst wird von immer weniger TYPO3-Projekten benötigt. TYPO3 v12 und v13 liefern jQuery nicht mehr standardmässig aus. Wer Slick Carousel nutzt, muss jQuery (90 KB minifiziert) als zusätzliche Abhängigkeit laden, nur für den Slider. Das ist technische Schuld, die bei jedem Seitenaufruf Performance kostet.

Typische Einsatzszenarien

Bild-Karussells auf Unterseiten. Produktseiten, Referenzseiten oder Galerie-Seiten mit 5 bis 20 Bildern, die als horizontaler Slider durchblätterbar sind. Slick rendert die Bilder mit Navigations-Pfeilen und optionalen Dots. Autoplay lässt die Bilder automatisch durchlaufen. In der Praxis zeigen Analytics-Daten, dass Nutzer selten über das dritte Bild hinaus klicken.

Testimonial-Slider. Kundenzitate, die als Karussell rotieren. Jede Slide zeigt ein Zitat, den Namen und optional ein Foto. Slick wird hier oft mit centerMode (das aktive Element ist grösser als die Nachbarn) und adaptiveHeight (die Slider-Höhe passt sich an den Inhalt an) konfiguriert.

Logo-Slider für Kundenreferenzen. Eine horizontale Leiste mit 10 bis 30 Kundenlogos, die automatisch durchlaufen. Slick im variableWidth-Modus (verschiedene Logo-Breiten) mit infinite Scroll (nahtloses Durchlaufen). Dieses Szenario ist besonders einfach durch CSS-only-Lösungen (CSS-Animation mit @keyframes) ersetzbar, völlig ohne JavaScript.

Technische Architektur

Die slickcarousel-Extension für TYPO3 bindet die Slick-Library (slick.min.js, 43 KB) und das zugehörige CSS (slick.css + slick-theme.css, 8 KB) ein. jQuery (90 KB) wird als Abhängigkeit geladen, sofern nicht bereits global vorhanden. Das Content-Element erlaubt Redakteuren, Bilder hochzuladen und Slider-Optionen zu konfigurieren: Slides to Show (1 bis 6), Slides to Scroll, Autoplay (ja/nein), Autoplay Speed (ms), Dots, Arrows, Fade-Effekt, Responsive Breakpoints.

Die Konfiguration wird als data-Attribut am Slider-Container gespeichert. Das Initialisierungsskript liest die Optionen und ruft $('.slick-element').slick(options) auf. Für mehrere Slider auf einer Seite wird jeder separat initialisiert.

Die TYPO3-Integration nutzt ein Fluid-Template, das die Bilder als <div>-Elemente innerhalb des Slider-Containers rendert. Jede Slide kann neben dem Bild auch Text, Links und CTA-Buttons enthalten, je nach Template-Konfiguration.

Häufige Probleme und Lösungen

Slider springt beim Laden (Layout Shift). Slick initialisiert den Slider per JavaScript. Bis das Script geladen und ausgeführt ist, werden alle Bilder untereinander angezeigt. Dann springt das Layout, wenn Slick die Bilder horizontal anordnet. Das erzeugt einen messbaren Cumulative Layout Shift (CLS), einen Core Web Vital. Lösung kurzfristig: CSS-Regeln definieren, die den Slider-Container vor der JavaScript-Initialisierung bereits korrekt dimensionieren (feste Höhe, overflow:hidden). Lösung langfristig: Auf eine Library umsteigen, die CLS nativ vermeidet.

Touch-Events funktionieren nicht konsistent. Slick’s Touch-Handling basiert auf einer eigenen Event-Implementierung, die auf aktuellen iOS- und Android-Versionen teilweise nicht mehr korrekt funktioniert. Besonders betroffen: Swipe-Geste wird als Scroll interpretiert, Slider reagiert nur auf sehr schnelle Wischbewegungen. Lösung: Es gibt keinen Fix, weil Slick nicht mehr gewartet wird. Migration ist die einzige Option.

Accessibility-Mängel. Slick erzeugt Markup, das nicht WCAG-konform ist: fehlende ARIA-Labels, keine Tastaturnavigation für Dots, Autoplay ohne Pause-Button. Für Unternehmen, die WCAG 2.1 AA einhalten müssen (öffentliche Einrichtungen, Barrierefreiheitsstärkungsgesetz ab 2025), ist Slick ohne umfangreiche Anpassungen nicht nutzbar. Lösung: Splide als Alternative (vollständige ARIA-Unterstützung, Tastaturnavigation, Autoplay-Pause nativ).

Migration und Versions-Kompatibilität

Die slickcarousel-Extension unterstützt TYPO3 v10 und v11. Für TYPO3 v12 und v13 gibt es keinen offiziellen Release (Stand April 2026). Die Slick-Library selbst ist seit 2017 auf v1.8.1 eingefroren und wird nicht weiterentwickelt.

Gosign migriert Slick-basierte Slider auf Swiper (175+ Features, Touch-native, kein jQuery, 40 KB) oder Splide (WCAG-konform, kein jQuery, 30 KB). Die Migration umfasst drei Schritte: Slider-Konfigurationen inventarisieren (welche Optionen werden genutzt), die neue Library einbinden und konfigurieren, Fluid-Templates anpassen (Markup-Struktur und CSS-Klassen ändern sich). Pro Slider dauert die Migration 2 bis 4 Stunden. Bei einer Website mit 5 verschiedenen Slider-Typen ist das Projekt in 2 bis 3 Tagen abgeschlossen.

Für Logo-Slider empfiehlt Gosign eine reine CSS-Lösung ohne JavaScript: Eine CSS-Animation (@keyframes scroll) bewegt die Logos horizontal, animation-play-state: paused bei Hover stoppt die Bewegung. Das Ergebnis ist 0 KB JavaScript-Overhead und funktioniert auf allen Browsern ab IE 11.

Für Testimonial- und Content-Slider empfiehlt Gosign Splide, weil die Extension volle ARIA-Unterstützung und Tastaturnavigation mitbringt. Seit dem Barrierefreiheitsstärkungsgesetz (BFSG, ab Juni 2025 wirksam) müssen neue Websites WCAG 2.1 AA erfüllen. Slick Carousel besteht diesen Test nicht, Splide schon. Die Migration von Slick auf Splide lohnt sich also nicht nur für Performance, sondern auch für Compliance.

Gosign dokumentiert nach jeder Slider-Migration die Performance-Verbesserung: PageSpeed Score vorher/nachher, jQuery-Entfernung (falls Slick die einzige jQuery-Abhängigkeit war), Core Web Vitals Delta. Bei Projekten, die von Slick auf Splide umgestellt wurden, lag die durchschnittliche PageSpeed-Verbesserung bei 12 bis 25 Punkten, primär durch den Wegfall von jQuery und die kleinere Library-Grösse.