Swiper

Notre point de vue sur Swiper

Le slider natif Webflow couvre les besoins vraiment basiques. Hero rotatif simple, témoignages clients, galerie photo classique. Mais dès qu'on demande de la finesse (transitions personnalisées, slides à largeur variable, plusieurs slides visibles avec proportions différentes par breakpoint, lazy-loading intelligent), il atteint ses limites.

Swiper est devenu le standard de fait dans l'écosystème Webflow parce qu'il est mature, gratuit, performant et documenté. On l'utilise sur la majorité de nos projets dès qu'un slider sort du basique.

Quand on choisit Swiper

• Slider à slides multiples avec breakpoints custom. 1 slide visible mobile, 2.5 tablette, 4 desktop avec snap intelligent. Impossible en natif Webflow.
• Effets de transition personnalisés. Transitions slide custom, effets 3D (cube, flip, coverflow), parallaxe sur les slides.
• Slider couplé à une miniature ou une pagination dynamique. Quand le slider principal est piloté par des thumbnails ou un menu personnalisé.
• Galerie ou carrousel produit avec interactions complexes. Zoom au clic, lazy-loading intelligent, virtual slides pour les très grosses galeries.
• Intégration avec le CMS Webflow : impossible nativement avec le Slider de Webflow (ou en utilisant un attribute de Finsweet)

Quand on déconseille Swiper

• Site très contraint perf sur mobile. Swiper reste léger, mais ajoute du JS. Sur des projets où chaque kilo compte, on évalue quitte à créer une solution custom (documentée)
• Contenu non-carrousel. Swiper est tentant pour faire du scroll horizontal libre, mais d'autres librairies (ou du CSS pur) sont plus adaptées.
• Composant qui pourrait être une simple grille. Souvent un slider est une fausse bonne idée UX. On challenge le besoin avant d'embarquer la librairie.

Comment on l'utilise concrètement chez Justa

1. Configuration par projet, pas globale

Chaque slider Webflow a sa propre config Swiper, pas une config globale réutilisée mécaniquement. La perf et l'UX dépendent du contexte précis : nombre de slides, breakpoints, comportement souhaité.

2. Lazy-loading natif activé

Sur les sliders avec images lourdes, on active le lazy-loading Swiper natif pour ne charger que les slides nécessaires. Gain LCP réel sur les hero avec galerie longue.

3. Pagination et navigation custom

On évite la pagination Swiper par défaut qui ne suit pas le design system du client. À la place, on style des éléments Webflow custom et on les connecte à Swiper via les options de configuration.

4. Code organisé sur GitHub

Comme tous nos scripts custom, les configs Swiper vivent dans un repo GitHub déployé via Cloudflare ou jsDelivr. Pas de copy-paste dans Webflow.

Les limites qu'on gère

• Poids du JS. Le bundle Swiper complet pèse, mais on charge uniquement les modules nécessaires (pagination, navigation, autoplay) plutôt que tout.
• Conflits avec smooth scroll Lenis. Swiper et Lenis cohabitent bien la majorité du temps, mais sur certains slides verticaux il faut désactiver Lenis localement.
• Accessibilité par défaut limitée. Toujours ajouter ARIA labels, navigation clavier et respecter prefers-reduced-motion. Swiper le permet, encore faut-il le configurer.
• Mise à jour de version qui casse parfois. Les majeures de Swiper introduisent des breaking changes. Pin de version sur les projets clients pour éviter les surprises.

Alternatives qu'on peut aussi utiliser

• Splide. Plus léger que Swiper, suffisant pour des cas simples. À évaluer quand la perf est critique.‍
• Slider natif Webflow : on ne l'utilise plus vraiment mais ça reste une option. On peut aussi l'augmenter grâce à nos scripts dédiés