Quand le routage côté client reste-t-il rentable maintenant que les navigateurs offrent bfcache, le prérendu et les transitions de vue entre documents ?

Question ouverte

Le routage côté client (interception des clics sur les liens, appel de history.pushState, rendu de la vue suivante sur place) a été adopté pour éviter les rechargements complets de page : pas de flash de page blanche, état en mémoire préservé, transitions instantanées. Ses coûts sont bien documentés : le serveur doit servir la coquille (shell) de l'application pour chaque route et signaler « introuvable » par un autre moyen ; la position de défilement, le focus et le titre du document doivent être restaurés à la main ; l'analytique et le suivi des erreurs ont besoin de crochets de route ; et aucune navigation ne fonctionne tant que le paquet (bundle) JavaScript n'est pas arrivé et exécuté.

Depuis, les navigateurs ont ajouté des fonctionnalités qui répondent aux motivations d'origine des sites multipages. Le cache avant/arrière (back/forward cache) restaure depuis la mémoire une page précédemment visitée, à condition que rien sur la page (MDN cite le gestionnaire unload) ne l'en empêche. La Speculation Rules API permet à une page de déclarer quels documents devraient être préchargés ou prérendus, afin que la page suivante puisse être prête avant le clic. Les transitions de vue entre documents animent le passage entre deux documents, ce que la page MDN note comme ayant été historiquement impossible.

Compte tenu de cela, pour quels types de site (contenu, tableau de bord, éditeur) et quels schémas d'interaction (navigation fréquente, widgets de longue durée tels qu'un lecteur multimédia, état en mémoire important) un routeur interne à la page améliore-t-il encore l'expérience mesurée, et où une architecture multipage avec des règles de spéculation et des transitions de vue l'égale-t-elle désormais à moindre coût ?

Ce qu'une réponse utile contient

Le type de site, la fréquence de navigation et l'état qui doit survivre à une navigation ; des mesures de latence de navigation, de LCP, d'INP et de CLS pour les deux architectures sur le même contenu, avec les versions de navigateur et la part des visiteurs dont le navigateur prend en charge le prérendu ; la part des navigations qui ont été prérendues ou restaurées depuis le bfcache ; le volet des coûts (taille du paquet, routes cassées lors d'un rechargement complet, manière dont les 404 sont signalés) ; des constats d'accessibilité (focus, annonces, position de lecture) ; et si l'équipe a conservé l'architecture un an plus tard. Les réponses provenant d'éditeurs de frameworks devraient le préciser, et les anecdotes portant sur un seul site devraient être présentées comme telles.