FlexSlider for TYPO3

FlexSlider has been outdated since 2015, yet it still runs on thousands of TYPO3 websites

Between 2012 and 2015, FlexSlider was one of the most popular website sliders: jQuery-based, responsive, with a choice of animations. The FlexSlider.js jQuery library collected more than 10,000 stars on GitHub. Its last update shipped in 2015. Web development has changed fundamentally since then: jQuery is no longer needed, Core Web Vitals penalize heavy JavaScript libraries, and touch events work natively without a library. Even so, FlexSlider still runs on thousands of TYPO3 websites, because the migration never made it to the top of anyone’s list.

The TYPO3 extension EXT:flexslider embeds the FlexSlider.js library and provides a backend plugin for configuring slides (image, text, link, animation effect). The extension itself is no longer maintained and supports TYPO3 v10 at most. Every TYPO3 website running FlexSlider has a migration on its hands.

Typical use cases

Homepage sliders with rotating campaign images. The classic setup: 3-5 large images on the homepage that rotate automatically, with marketing swapping the content every season. These sliders typically load 3-5 images at once (15-25 MB of data), plus jQuery (90 KB) and FlexSlider.js (30 KB). The result: a load time of 4+ seconds for the visible area (LCP). The modern alternative is a single hero image instead of a slider (higher conversion according to A/B tests) or a CSS-based slider without JavaScript.

Product image galleries with thumbnails. FlexSlider was often used as a thumbnail gallery on product pages: a large main image at the top, a thumbnail strip below. Clicking a thumbnail swaps the main image. Today, you can build this with 30 lines of CSS and 10 lines of vanilla JavaScript, without any external library.

Testimonial carousels. Customer quotes that rotate, often with autoplay animation. FlexSlider offered a “carousel” mode for this. The modern alternative is CSS Scroll Snap with scroll-behavior: smooth: no JavaScript required, full touch support, under 1 KB of code.

Technical architecture

EXT:flexslider consists of three parts: a content element plugin (a FlexForm holding the slide configuration), Fluid templates for frontend rendering and the FlexSlider.js library, which depends on jQuery.

In the backend, editors configure the number of slides, image, headline, text, link, animation effect (slide, fade), autoplay (yes/no), autoplay speed, navigation (arrows, dots, thumbnails) and responsive breakpoints. The data is stored in the FlexForm XML structure of the content element.

In the frontend, TYPO3 loads jQuery (unless it is already present), flexslider.js and flexslider.css. An initialization script starts the slider with the configured options. The output is rendered as a <div class="flexslider"><ul class="slides"><li> structure.

The performance problems are built into the architecture: FlexSlider loads every slide when the page loads (no lazy loading), jQuery blocks rendering (a render-blocking resource), and the animation engine runs on JavaScript instead of CSS transitions, which drives up CPU usage on mobile devices.

Common problems and solutions

Poor Core Web Vitals caused by FlexSlider. LCP above 4 seconds, CLS above 0.25 (layout shift while loading), TBT above 300 ms (JavaScript blocking). This is not a tuning problem, it’s an architecture problem. Solution: replace FlexSlider with a modern alternative. Swiper (no jQuery, lazy loading, CSS transitions) and Splide (lighter than Swiper, 29 KB instead of 140 KB) are the standard choices. Even better: drop the slider altogether and replace it with a static hero element.

jQuery conflicts. TYPO3 v12 no longer ships jQuery in the core, but FlexSlider needs it. If you load jQuery only for FlexSlider, you add 90 KB for a library nothing else on the site uses. Solution: remove jQuery entirely as part of the slider migration and migrate every jQuery-dependent component at the same time.

Responsive images don’t work. FlexSlider knows nothing about the <picture> element or srcset. Every device loads the same image, whether it’s a desktop (1920px) or a smartphone (375px). Solution: Swiper and Splide support srcset and <picture> natively. During the migration, TYPO3’s image processing generates the images in several sizes and delivers them via srcset.

Migration and version compatibility

FlexSlider has no compatibility with TYPO3 v12 or v13 and never will. The jQuery library behind it is end-of-life. Every TYPO3 project moving to v12/v13 has to replace FlexSlider.

The migration takes four steps: first, export the existing slider data (images, texts and links from the FlexForm configuration); second, set up a new content element with Swiper or Splide (as a custom content element in the sitepackage); third, import the slider data into the new structure; and fourth, point the old FlexSlider references to the new element (an SQL update of the tt_content table).

For 10-20 sliders, expect 1-2 days for the technical rebuild and 0.5-1 day for the data migration. The slider-free alternative (a static hero element) is even faster: 0.5 days for the new template, with the data of the first slide carried over and the rest dropped.

With every FlexSlider migration, Gosign raises the fundamental question first: do you really need a slider? A/B tests consistently show that static hero elements achieve higher conversion rates than rotating sliders. If a slider is still needed, Gosign delivers the migration to Swiper or Splide, including performance optimization.