Hero Slider for TYPO3

The hero slider is the most expensive part of a TYPO3 website, measured in load time

The hero area is the first thing visitors see. With a slider, it’s also the slowest thing they see. A typical hero slider in TYPO3 loads 3-5 large images (500 KB to 2 MB each), a JavaScript library (jQuery plus a slider plugin: 120-200 KB), CSS animations and initialization scripts. Together, that’s 3-12 MB of data before the visitor can click anything. With setups like this, Largest Contentful Paint (LCP) routinely exceeds 4 seconds, which Google rates as “poor” and which costs rankings.

The answer is not a better slider. It’s either no slider at all or a radically lightweight one. CSS-only solutions and modern slider libraries such as Swiper achieve the same visual effect at a fraction of the load time.

Typical use cases

Homepages with rotating campaigns. Marketing wants 3-5 messages in a prominent spot: a seasonal campaign, a new product, an event announcement, an award. The slider rotates automatically, and each slide has an image, a headline and a CTA button. The problem: studies consistently show that only 1-2% of visitors interact beyond the first slide. The other 4 slides get loaded but never seen. In A/B tests, a static hero image with one clear message regularly outperforms a slider.

Image galleries in the header. Hotels, restaurants and event venues use a hero slider to show off their setting: exterior, interior, terrace, food. Here a slider makes sense content-wise, because visitors expect several impressions. The performance fix: load only the first image immediately and lazy-load the rest. With Intersection Observer and loading="lazy", that works without any slider library.

Product highlights with animation. E-commerce websites present product highlights as animated slides meant to catch the eye. In practice, CSS transitions (transform, opacity) perform better than JavaScript animations and put the load on the GPU instead of the CPU. A CSS-only slider with scroll-snap-type and transition reaches 60 fps on any device.

Technical architecture

In TYPO3, hero sliders are typically implemented as a content element: a FlexForm with the slide configuration (image, text, link, order) and a Fluid template that renders the slides. A JavaScript library handles the slider logic.

The libraries you find most often in TYPO3 projects are FlexSlider (outdated, jQuery), Slick (outdated, jQuery), Owl Carousel (outdated, jQuery), Swiper (modern, no jQuery, 139 KB) and Splide (modern, no jQuery, 29 KB). The choice of library determines the performance profile of the entire hero area.

The optimal architecture for a hero slider in 2026:

Option 1: CSS-only (0 KB of JavaScript). scroll-snap-type: x mandatory on the container, scroll-snap-align: start on the slides. Navigation via scroll-behavior: smooth and anchor links, autoplay via a CSS animation (@keyframes). No JavaScript required, and it works in every modern browser. The drawbacks: no programmatic autoplay with pause on hover, no swipe animations.

Option 2: Swiper or Splide (29-139 KB of JavaScript). Full slider functionality with touch, swipe, autoplay, pagination and lazy loading. Both are tree-shakeable, so only the modules you use get loaded. They integrate into TYPO3 through a custom content element with a FlexForm.

Option 3: A static hero (0 KB of JavaScript, 1 image). One image, one headline, one CTA. The fastest setup and the one that converts best. The image is delivered as a <picture> element with srcset: 375px for mobile, 768px for tablet, 1440px for desktop. In AVIF or WebP format, each variant stays under 100 KB.

Common problems and solutions

LCP above 4 seconds. The hero image is the LCP element. If it loads too late, the LCP score suffers. Solution: load the first slide image with fetchpriority="high" and loading="eager" (not lazy), and the remaining slides with loading="lazy". Switch the image format to WebP or AVIF, and cap the image size at the actual display size (no 4000px image for a 1440px viewport).

Cumulative Layout Shift (CLS) from late-loading sliders. The slider container starts out with no height, and the layout jumps once the JavaScript initializes. Solution: fix the height of the slider container in CSS (for example aspect-ratio: 16/9 or min-height: 60vh). That way, the browser reserves the space before the JavaScript has loaded.

Autoplay doesn’t work on mobile devices. iOS Safari blocks autoplay videos and some CSS animations to save power. Solution: disable autoplay on mobile devices and offer swipe navigation instead. Smartphone users know they can swipe, so a static hint (“Swipe for more”) is unnecessary.

Migration and version compatibility

Most hero slider extensions in the TER are outdated and support TYPO3 v10 or v11 at most. For v12/v13, the recommendation is always the same: a custom content element in the sitepackage that either embeds a modern library or relies entirely on CSS.

Existing sliders are migrated in three steps: export the slide data (images, texts and links from the FlexForm or the database), set up the new content element (a FlexForm with the same fields but a modern template) and switch the existing content elements to the new CType via SQL. The effort: 1-2 days for the technical setup, plus 0.5 days per 10 existing sliders for the data migration.

With every hero slider project, Gosign starts with one question: does the website really need a slider? In 70% of cases, a static hero element performs better. For the remaining 30%, Gosign delivers a Swiper or CSS-only solution that keeps LCP under 1.5 seconds.