Les passive listeners peuvent-ils vraiment booster vos Core Web Vitals ?

Qu'est-ce qu'un passive listener exactement ?

Par défaut, quand vous attachez un event listener sur un événement de scroll ou de touch, le navigateur doit attendre l'exécution complète de votre code JavaScript avant de déclencher le défilement. Pourquoi ? Parce qu'il ne sait pas si votre code va appeler preventDefault() pour bloquer l'action.

Un passive listener, c'est une option que vous passez à addEventListener : {passive: true}. Vous dites au navigateur : "Mon code n'empêchera jamais le défilement par défaut". Le navigateur peut alors faire défiler immédiatement, même si votre JavaScript tourne encore en arrière-plan.

Pourquoi Google insiste sur ce point maintenant ?

Cette recommandation s'inscrit dans la logique des Core Web Vitals, particulièrement l'INP (Interaction to Next Paint). Chaque milliseconde compte quand le navigateur doit répondre à une interaction utilisateur.

Si vos listeners ne sont pas passifs, le thread principal bloque. Le scroll lag. L'utilisateur ressent une friction. Google pénalise l'expérience. Les outils comme Lighthouse remontent d'ailleurs des warnings spécifiques sur ce point depuis des années — mais beaucoup de sites les ignorent encore.

Tous les événements sont-ils concernés ?

Non. Les événements critiques sont touchstart, touchmove, wheel, et mousewheel. Ce sont eux qui bloquent le scroll par défaut si le navigateur ne sait pas que votre listener est passif.

Les événements de type click ou scroll pur ne posent pas le même problème. Mais dès que vous touchez au touch ou au wheel, la question se pose.

• Un passive listener permet au navigateur de dissocier le scroll du thread principal
• L'option {passive: true} se déclare dans addEventListener
• Impact direct sur INP et fluidité perçue, surtout mobile
• Principaux événements concernés : touchstart, touchmove, wheel, mousewheel
• Lighthouse remonte des warnings si vos listeners bloquent le scroll

Cette recommandation est-elle vraiment prioritaire ?

Soyons honnêtes : si votre site n'a pas de listeners sur touchstart ou wheel, cette déclaration ne vous concerne pas directement. Mais si vous utilisez des bibliothèques JavaScript tierces — et vous en utilisez probablement —, il y a de fortes chances qu'elles attachent des listeners sans l'option passive.

Résultat : vous pouvez avoir un problème sans même le savoir. J'ai vu des sites propres sur le papier perdre 15-20 points d'INP juste à cause de listeners mal déclarés dans une lib de carrousel ou de parallax. [A vérifier] systématiquement avec Lighthouse.

Tous les frameworks modernes gèrent-ils ça automatiquement ?

Non. React, Vue, Angular n'ajoutent pas {passive: true} par défaut sur tous les événements. Vous devez le faire manuellement, ou vérifier que vos composants/plugins le font.

Certains frameworks récents (ou versions récentes) sont plus intelligents — mais la majorité du web tourne encore sur des stacks où ce paramètre n'est pas systématique. Ne présumez jamais que "ça doit être géré".

Quels sont les pièges à éviter ?

Si vous déclarez un listener comme passif mais que votre code appelle quand même preventDefault(), le navigateur ignore l'appel — et votre fonction ne fait plus ce qu'elle est censée faire. Typiquement : vous vouliez bloquer un scroll dans certaines conditions, ça ne marche plus.

Donc ne mettez passive: true que si vous êtes sûr que vous n'aurez jamais besoin d'empêcher le comportement par défaut. Sinon, gardez le listener actif et optimisez autrement (debounce, throttle, code plus léger).

Comment identifier les listeners problématiques sur mon site ?

Ouvrez Lighthouse dans Chrome DevTools et lancez un audit Performance. Si vous avez des listeners non-passifs qui bloquent le scroll, vous verrez un warning explicite : "Does not use passive listeners to improve scrolling performance".

Lighthouse liste même les fichiers JS responsables. Souvent, ce sont des bibliothèques tierces (sliders, modals, parallax). Vous devrez soit les configurer pour activer passive, soit les remplacer, soit patcher manuellement.

Que faire concrètement pour corriger ?

Si vous contrôlez le code : remplacez addEventListener('touchstart', handler) par addEventListener('touchstart', handler, {passive: true}). Simple.

Si c'est une lib tierce : vérifiez la doc pour une option de configuration. Beaucoup de bibliothèques modernes exposent un paramètre pour activer les passive listeners. Sinon, envisagez un polyfill ou une contribution au projet open-source.

• Auditer le site avec Lighthouse pour détecter les listeners bloquants
• Identifier les fichiers JS responsables (souvent des libs tierces)
• Ajouter {passive: true} sur touchstart, touchmove, wheel, mousewheel
• Vérifier que le code n'appelle jamais preventDefault() dans ces handlers
• Tester le comportement sur mobile réel après modification
• Monitorer l'INP avant/après pour mesurer l'impact réel

Faut-il se faire aider pour cette optimisation ?

Si vos listeners sont dispersés dans plusieurs bibliothèques, ou si vous n'avez pas la main sur le code source, l'opération peut vite devenir complexe. Il faut auditer, patcher, tester, régresser.

Ces optimisations techniques demandent une expertise pointue en JavaScript et en performance web. Faire appel à une agence SEO spécialisée peut s'avérer judicieux pour un accompagnement personnalisé, surtout si vous cumulez plusieurs chantiers d'optimisation Core Web Vitals en parallèle.