Slick Carousel for TYPO3

Slick Carousel forces TYPO3 websites to load jQuery even though alternatives without it have existed for years

Slick (by Ken Wheeler) was the most popular JavaScript slider between 2014 and 2020. “The last carousel you’ll ever need” promised the documentation. Responsive, touch-capable, lazy loading, autoplay, infinite scroll, variable width. For TYPO3, the slickcarousel extension integrates Slick as a content element. The problem in 2026: Slick depends on jQuery. The last Slick release dates from 2017 (v1.8.1). No updates for over 8 years, no bug fixes, no security patches.

jQuery itself is needed by fewer and fewer TYPO3 projects. TYPO3 v12 and v13 no longer ship jQuery by default. Anyone using Slick Carousel must load jQuery (90 KB minified) as an additional dependency - only for the slider. This is technical debt that costs performance on every page load.

Typical use cases

Image carousels on subpages. Product pages, reference pages or gallery pages with 5 to 20 images displayed as a horizontal slider. Slick renders the images with navigation arrows and optional dots. Autoplay cycles the images automatically. In practice, analytics data shows that users rarely click past the third image.

Testimonial sliders. Customer quotes that rotate as a carousel. Each slide shows a quote, name and optionally a photo. Slick is often configured here with centerMode (the active element is larger than its neighbors) and adaptiveHeight (slider height adjusts to content).

Logo sliders for client references. A horizontal strip with 10 to 30 client logos that cycle automatically. Slick in variableWidth mode (different logo widths) with infinite scroll (seamless cycling). This scenario is particularly easy to replace with CSS-only solutions (CSS animation with @keyframes) - entirely without JavaScript.

Technical architecture

The slickcarousel extension for TYPO3 includes the Slick library (slick.min.js, 43 KB) and its CSS (slick.css + slick-theme.css, 8 KB). jQuery (90 KB) is loaded as a dependency if not already available globally. The content element allows editors to upload images and configure slider options: Slides to Show (1 to 6), Slides to Scroll, Autoplay (yes/no), Autoplay Speed (ms), Dots, Arrows, Fade effect, Responsive Breakpoints.

The configuration is stored as a data attribute on the slider container. The initialization script reads the options and calls $('.slick-element').slick(options). For multiple sliders on a page, each is initialized separately.

The TYPO3 integration uses a Fluid template that renders images as <div> elements within the slider container. Each slide can contain text, links and CTA buttons alongside the image, depending on template configuration.

Common problems and solutions

Slider jumps on load (Layout Shift). Slick initializes the slider via JavaScript. Until the script is loaded and executed, all images are displayed stacked vertically. Then the layout jumps when Slick arranges the images horizontally. This produces measurable Cumulative Layout Shift (CLS) - a Core Web Vital. Short-term solution: define CSS rules that correctly dimension the slider container before JavaScript initialization (fixed height, overflow:hidden). Long-term solution: switch to a library that natively prevents CLS.

Touch events do not work consistently. Slick’s touch handling is based on a custom event implementation that no longer functions correctly on current iOS and Android versions. Particularly affected: swipe gesture interpreted as scroll, slider only responds to very fast swipe movements. Solution: there is no fix because Slick is no longer maintained. Migration is the only option.

Accessibility deficiencies. Slick produces markup that is not WCAG-compliant: missing ARIA labels, no keyboard navigation for dots, autoplay without pause button. For organizations that must comply with WCAG 2.1 AA (public institutions, European Accessibility Act from 2025), Slick is not usable without extensive modifications. Solution: Splide as alternative (full ARIA support, keyboard navigation, native autoplay pause).

Migration and version compatibility

The slickcarousel extension supports TYPO3 v10 and v11. There is no official release for TYPO3 v12 and v13 (as of April 2026). The Slick library itself has been frozen at v1.8.1 since 2017 and is not being developed further.

Gosign migrates Slick-based sliders to Swiper (175+ features, touch-native, no jQuery, 40 KB) or Splide (WCAG-compliant, no jQuery, 30 KB). The migration comprises three steps: inventory slider configurations (which options are in use), integrate and configure the new library, adapt Fluid templates (markup structure and CSS classes change). Per slider, migration takes 2 to 4 hours. For a website with 5 different slider types, the project is completed in 2 to 3 days.

For logo sliders, Gosign recommends a pure CSS solution without JavaScript: a CSS animation (@keyframes scroll) moves the logos horizontally, animation-play-state: paused on hover stops the movement. The result is 0 KB JavaScript overhead and works on all browsers from IE 11 onward.

For testimonial and content sliders, Gosign recommends Splide because the extension includes full ARIA support and keyboard navigation. Since the European Accessibility Act (EAA, effective June 2025), new websites must meet WCAG 2.1 AA. Slick Carousel does not pass this test - Splide does. The migration from Slick to Splide pays off not just for performance but also for compliance.

Gosign documents the performance improvement after every slider migration: PageSpeed Score before/after, jQuery removal (if Slick was the only jQuery dependency), Core Web Vitals delta. For projects that switched from Slick to Splide, the average PageSpeed improvement was 12 to 25 points, primarily from eliminating jQuery and the smaller library size.