Hero-Slider dla TYPO3

Hero-slider to najdroższa sekcja strony TYPO3, mierzona w czasie ładowania

Sekcja hero to pierwsze, co widzą odwiedzający. Przy sliderze jest to również najwolniejsze, co widzą. Typowy hero-slider w TYPO3 ładuje 3-5 wielkoformatowych obrazów (po 500 KB-2 MB każdy), bibliotekę JavaScript (jQuery + plugin slidera: 120-200 KB), animacje CSS i skrypty inicjalizacyjne. W sumie to 3-12 MB danych, zanim odwiedzający może gdziekolwiek kliknąć. Largest Contentful Paint (LCP) w takich konfiguracjach rutynowo przekracza 4 sekundy, co Google klasyfikuje jako “zły” wynik i co kosztuje pozycje w rankingu.

Rozwiązaniem nie jest lepszy slider, lecz albo żaden slider, albo radykalnie lekki. Rozwiązania CSS-only i nowoczesne biblioteki slidera jak Swiper osiągają ten sam efekt wizualny przy ułamku czasu ładowania.

Typowe scenariusze zastosowań

Strony główne ze zmieniającymi się kampaniami. Marketing chce umieścić 3-5 komunikatów w widocznym miejscu: kampania sezonowa, nowy produkt, zapowiedź wydarzenia, informacja o nagrodzie. Slider obraca się automatycznie, każdy slajd ma obraz, nagłówek i przycisk CTA. Problem: badania konsekwentnie pokazują, że tylko 1-2% odwiedzających wchodzi w interakcję poza pierwszym slajdem. Pozostałe 4 slajdy są ładowane, ale nieoglądane. Statyczny obraz hero z jednym jasnym komunikatem regularnie wypada lepiej w testach A/B niż slider.

Galerie obrazów w sekcji nagłówka. Hotele, restauracje i miejsca wydarzeń pokazują wrażenia jako hero-slider: widok zewnętrzny, wnętrze, taras, dania. Tu slider ma sens merytorycznie, ponieważ odwiedzający oczekują wielu wrażeń. Optymalizacja wydajności: ładować natychmiast tylko pierwszy obraz, a pozostałe doładowywać przez lazy loading. Z Intersection Observer i loading="lazy" jest to możliwe bez biblioteki slidera.

Produkty highlight z animacją. Strony e-commerce pokazują produkty highlight jako animowane slajdy. Animacja ma przyciągać uwagę. W praktyce: przejścia CSS (transform, opacity) są wydajniejsze niż animacje JavaScript i obciążają GPU zamiast CPU. Slider CSS-only z scroll-snap-type i transition osiąga 60 fps na każdym urządzeniu.

Architektura techniczna

Hero-slidery w TYPO3 są zwykle implementowane jako Content Element: FlexForm z konfiguracją slajdów (obraz, tekst, link, kolejność) i szablon Fluid, który renderuje slajdy. Logikę slidera obsługuje biblioteka JavaScript.

Popularne biblioteki w projektach TYPO3: FlexSlider (przestarzały, jQuery), Slick (przestarzały, jQuery), Owl Carousel (przestarzały, jQuery), Swiper (nowoczesny, bez jQuery, 139 KB) i Splide (nowoczesny, bez jQuery, 29 KB). Wybór biblioteki determinuje charakterystykę wydajności całej sekcji hero.

Optymalna architektura dla hero-slidera w 2026 roku:

Opcja 1: CSS-only (0 KB JavaScript). scroll-snap-type: x mandatory na kontenerze, scroll-snap-align: start na slajdach. Nawigacja przez scroll-behavior: smooth i kotwice. Autoplay przez animację CSS (@keyframes). Nie potrzebny JavaScript. Działa we wszystkich nowoczesnych przeglądarkach. Wady: brak programowego autoplay z pauzą po najechaniu, brak animacji swipe.

Opcja 2: Swiper/Splide (29-139 KB JavaScript). Pełna funkcjonalność slidera z touch, swipe, autoplay, paginacją, lazy loading. Tree-shakeable - ładowane są tylko używane moduły. Integracja w TYPO3 przez własny Content Element z FlexForm.

Opcja 3: Statyczny hero (0 KB JavaScript, 1 obraz). Jeden obraz, jeden nagłówek, jeden CTA. Najszybsza i najbardziej konwertująca konfiguracja. Obraz jest dostarczany jako <picture> z srcset: 375px dla mobile, 768px dla tableta, 1440px dla desktopa. W formacie AVIF/WebP poniżej 100 KB na wariant.

Częste problemy i rozwiązania

LCP powyżej 4 sekund. Obraz hero to element LCP. Jeśli ładuje się za późno, wynik LCP jest zły. Rozwiązanie: pierwszy obraz slidera ładować z fetchpriority="high" i loading="eager" (nie lazy). Pozostałe slajdy z loading="lazy". Przełączyć format obrazu na WebP/AVIF. Ograniczyć rozmiar obrazu do rzeczywistej wielkości wyświetlania (bez obrazu 4000px dla viewportu 1440px).

Cumulative Layout Shift (CLS) przez doładowujące się slidery. Kontener slidera początkowo nie ma wysokości, po inicjalizacji JavaScript layout skacze. Rozwiązanie: ustalić wysokość kontenera slidera przez CSS (np. aspect-ratio: 16/9 lub min-height: 60vh). Dzięki temu przeglądarka rezerwuje miejsce zanim JavaScript zostanie załadowany.

Autoplay na urządzeniach mobilnych nie działa. iOS Safari blokuje autoplay wideo i niektóre animacje CSS ze względu na oszczędzanie energii. Rozwiązanie: wyłączyć autoplay na urządzeniach mobilnych i zamiast tego zaoferować nawigację swipe. Odwiedzający na smartfonach wiedzą, że mogą przesuwać palcem. Statyczna wskazówka (“Przesuń, aby zobaczyć więcej”) jest zbędna.

Migracja i kompatybilność wersji

Większość rozszerzeń hero-slider w TER jest przestarzała i obsługuje maksymalnie TYPO3 v10 lub v11. Dla v12/v13 bezwzględnie zalecany jest własny Content Element w sitepackage, który podpina nowoczesną bibliotekę lub całkowicie opiera się na CSS.

Migracja istniejących sliderów odbywa się w trzech krokach: eksport danych slajdów (obrazy, teksty, linki z FlexForm lub bazy danych), założenie nowego Content Element (FlexForm z tymi samymi polami, ale nowoczesnym szablonem) i przełączenie istniejących content-elementów przez SQL na nowy CType. Nakład pracy: 1-2 dni na konfigurację techniczną plus 0,5 dnia na każde 10 istniejących sliderów dla migracji danych.

Gosign przy każdym projekcie hero-slidera zadaje najpierw pytanie: czy strona naprawdę potrzebuje slidera? W 70% przypadków statyczny element hero wypada lepiej. Dla pozostałych 30% Gosign dostarcza rozwiązanie Swiper lub CSS-only, które pozostaje poniżej 1,5 sekundy LCP.