Core Web Vitals et événement unload : ce que Chrome change pour les agences web

Introduction

Chrome change deux choses que les agences web doivent intégrer dans leurs recettes. Le Chrome UX Report (CrUX) publie des variantes expérimentales des Core Web Vitals qui incluent les navigations fluides, et Chrome 155 ne déclenche plus l’événement unload par défaut. Ces évolutions n’offrent aucun gain SEO garanti, mais elles justifient une checklist de vérification lors d’une création ou d’une refonte de site.

Nous détaillons ici ce qui est publié, ce qu’il faut lire avec prudence, et les contrôles que nous recommandons.

1. CrUX ajoute des variantes expérimentales avec navigations fluides

Le 13 octobre 2026, l’équipe CrUX a annoncé, dans les notes de version du jeu de données de septembre 2026, de nouvelles variantes expérimentales des Core Web Vitals (LCP, INP et CLS). Ces variantes incluent les soft navigations (navigations fluides), telles que les utilisent les sites SPA (applications monopage). Ces métriques sont disponibles dans BigQuery et dans les API CrUX.

La documentation des métriques CrUX renvoie vers un billet détaillant ces variantes et précise que certaines métriques incluent à la fois les chargements complets et les navigations fluides. Nous n’avons pas accès au calendrier de sortie de la phase expérimentale : ne le présumez pas. Tant que ce statut dure, nous recommandons de traiter ces valeurs comme un complément et de garder les données stables comme référence de reporting.

Question de diagnostic : votre interface change-t-elle de vue sans rechargement de page ? Si oui, les variantes expérimentales avec navigations fluides sont à examiner ; sinon, vérifiez ce point avec votre agence.

2. Lire les chiffres CrUX sans les surinterpréter

Les notes de version publient des parts d’origines ayant de bonnes métriques, sur 18 376 044 origines pour le jeu de données de septembre 2026.

Ce tableau compare deux méthodes de calcul sur la même population. Il ne mesure pas une amélioration réelle de l’expérience des utilisateurs, et il n’indique rien sur la France, un secteur ou un CMS. Il ne vaut donc pas pour un site client précis.

Autre limite : les données BigQuery sont agrégées à l’échelle de l’origine. Pour une analyse par URL, la documentation propose de collecter vos propres mesures d’utilisateurs réels (RUM, real user monitoring) avec les API standard de la plateforme web exposées par les navigateurs. Elle précise aussi que les autres navigateurs ne prennent pas forcément en charge tous les indicateurs, d’après la documentation CrUX. Pour l’impact SEO de ces métriques, nous vous renvoyons à notre article sur l’impact des Core Web Vitals sur le SEO.

3. Chrome 155 : unload ne se déclenche plus par défaut

Le 16 octobre 2026, Chrome a annoncé avoir terminé la dépréciation de l’événement unload avec Chrome 155. Par défaut, les gestionnaires unload ne se déclenchent plus dans Chrome et les navigateurs basés sur Chromium. Cette désactivation doit bientôt devenir la valeur par défaut dans le code Chromium, ce qui concernera les autres navigateurs Chromium, sauf s’ils changent cette valeur.

Deux nuances importantes :

• Des sites peuvent avoir choisi de réactiver unload via la Permission Policy ou les paramètres Chrome Enterprise. Chrome indique ne pas prévoir de retirer ces options, tout en encourageant ces sites à abandonner l’événement.
• Selon la page dédiée, unload peut encore se déclencher sur iOS pour les utilisateurs de Chrome, car ce navigateur y repose sur WebKit, comme Safari.

Pourquoi cette décision ? Chrome juge l’événement de plus en plus peu fiable : beaucoup de pages se ferment sans pouvoir l’exécuter, en particulier sur mobile, où le système ferme souvent silencieusement les pages en arrière-plan. Il complique aussi le bfcache.

4. Unload, bfcache et alternatives

Le bfcache (back/forward cache) conserve la page en mémoire quand l’utilisateur la quitte. S’il revient en arrière, la page est restaurée presque instantanément, sans retour au réseau. Tous les grands navigateurs en proposent un. Le gain dépend de la page : nous ne promettons aucun résultat chiffré. Un cas fournisseur (Yahoo! JAPAN) existe, mais il est isolé et non transposable.

Les sources citent unload parmi les éléments qui peuvent empêcher une page d’être éligible au bfcache. CrUX expose aussi un type de navigation permettant d’observer la part des navigations via bfcache, d’après l’annonce de 2024.

Côté remplacement, la documentation Chrome sur le cycle de vie déconseille d’utiliser unload. Un billet de Chrome sur l’isolation des sites recommande pagehide plutôt que beforeunload ou unload, et un autre billet (Chrome 80) conseille sendBeacon ou Fetch keep-alive pour envoyer des données au déchargement de la page. Nous vous proposons d’étudier, selon le cas d’usage : pagehide pour détecter le départ de la page, sendBeacon pour envoyer des données, et visibilitychange, dont le rôle est à valider selon votre besoin. À valider sur vos navigateurs cibles.

5. Checklist de vérification pour l’agence

Ces contrôles relèvent de notre analyse éditoriale, pas d’une exigence publiée.

1. Séparer les mesures : dans les rapports, distinguez données CrUX stables et variantes expérimentales avec navigations fluides.
2. Qualifier l’architecture : site classique, SPA ou mixte, pour savoir si les navigations fluides comptent.
3. Inventorier les écouteurs unload : dans votre code, vos bibliothèques et vos scripts tiers (analytics, chat, publicité). Chrome indique que les sites peuvent découvrir cet usage, y compris via des bibliothèques.
4. Tester le bfcache : dans DevTools, Application > Background services > Back/forward cache, puis « Test back/forward cache ». L’audit signale les blocages, dont unload. C’est un test de laboratoire, pas un usage réel.
5. Mettre en place un RUM si vous avez besoin d’analyses par URL.
6. Documenter les exceptions : opt-out Permission Policy ou règle d’entreprise, et comportement iOS.

Conseil : intégrez ces points au cahier de recette d’une refonte, et à la maintenance web ensuite. Pour la performance générale, voyez aussi comment optimiser la vitesse de votre site.

En bref

• CrUX propose des variantes expérimentales de LCP, INP et CLS incluant les navigations fluides.
• Le tableau compare deux méthodes de calcul, sans conclure à une amélioration.
• Chrome 155 ne déclenche plus unload par défaut, avec des exceptions (opt-outs, iOS).
• Auditez unload, y compris dans les scripts tiers, et testez le bfcache.
• Aucun gain SEO automatique n’est démontré.

Conclusion

Ces deux évolutions appellent surtout de la rigueur : mesurer séparément, repérer unload et tester le bfcache. Restez prudent sur les chiffres agrégés et sur le statut expérimental. Pour cadrer un projet plus large, consultez notre article sur le site vitrine professionnel B2B.

Sources

• CrUX, notes de version
• CrUX, métriques
• CrUX, types de navigation
• Unload event deprecated in Chrome
• Deprecating the unload event
• Page Lifecycle API
• Back/forward cache, web.dev

Glossaire

CrUX : jeu de données de mesures d’utilisateurs réels de Chrome.

Navigation fluide (soft navigation) : changement de vue sans rechargement complet.

SPA : application monopage.

bfcache : cache de navigation retour/avant en mémoire.

RUM : mesure des utilisateurs réels sur votre site.

Origine : ensemble de pages regroupées sous une même origine web dans les données BigQuery CrUX.

FAQ

Un site non SPA est-il concerné ?

Cela dépend de vos pages. Pour les variantes avec navigations fluides, vérifiez si votre interface change de vue sans rechargement. Pour unload, vérifiez si un écouteur est présent dans votre code, vos bibliothèques ou vos scripts tiers.

Le SEO s’améliore-t-il automatiquement ?

Non, aucune preuve ne le montre. Ces changements justifient des vérifications techniques.

Les métriques expérimentales remplacent-elles les données stables ?

Nous ne les présentons pas comme un remplacement des données stables : gardez les deux séparées dans vos rapports.

Comment tester le bfcache ?

Ouvrez DevTools, Application > Background services > Back/forward cache, puis lancez le test.

Par quoi remplacer unload ?

À étudier : pagehide, visibilitychange et sendBeacon, selon votre besoin.