Routage par hachage ou par chemin

Les SPA ont besoin d’URL que le navigateur ne récupère pas. Deux approches sont possibles : la stratégie fondée sur le fragment utilise le fragment (tout ce qui suit #), que le navigateur n’envoie jamais au serveur, tandis que la stratégie fondée sur le chemin utilise le chemin et les mécanismes de l’API d’historique.

Les URL ressemblent à https://example.com/#/about. Le serveur ne voit que / et sert le même document HTML pour chaque URL. Le JavaScript côté client lit location.hash pour décider quelle vue afficher. C’est simple et cela ne nécessite aucune configuration du serveur.

Les routeurs fondés sur les fragments écoutent l’événement hashchange, qui se déclenche chaque fois que location.hash change. Avec la lecture de window.location.hash, c’est toute l’API nécessaire au routage côté client — aucune API d’historique n’intervient.

Les URL ressemblent à https://example.com/about — elles sont indiscernables des URL générées par le serveur. La méthode pushState de l’API d’historique modifie le chemin sans recharger la page ; l’événement de navigation dans l’historique se déclenche lors des navigations arrière ou avant ; l’interception des clics transforme <a> en navigation de SPA.

Pour le routage fondé sur le chemin, le serveur doit renvoyer le fichier index.html de la SPA pour tout chemin que l’utilisateur pourrait saisir directement (ou actualiser). Sinon, l’actualisation de /about renvoie une erreur 404. Configurez le serveur pour essayer le fichier, puis utiliser index.html comme solution de repli (solution de repli de l’historique dans Nginx, module de repli de l’API d’historique dans Vite en développement).

Les moteurs de recherche et de nombreux outils ne peuvent pas du tout explorer les fragments de hachage — le contenu de /#/about est invisible pour les anciens robots (Google le traite avec un rendu sans interface, mais ce n’est pas forcément le cas des autres). Les URL fondées sur le chemin sont explorées normalement, ce qui les rend nettement meilleures pour le référencement.

Les URL avec fragment semblent visiblement « bizarres » — les utilisateurs remarquent le # et peuvent ne pas faire confiance au lien ou oublier de copier l’URL complète. Les URL fondées sur le chemin ressemblent à toutes les autres URL du Web, comme les utilisateurs s’y attendent. Les SPA modernes choisissent presque toujours cette approche pour cette seule raison.

Routage fondé sur le fragment : environ 10 lignes de JS (écouteur de changement de fragment et affichage). Routage fondé sur le chemin : appels à pushState, écouteur de navigation dans l’historique, interception des clics sur les liens et solution de repli côté serveur. Le fragment est le choix le plus léger ; le chemin exige davantage d’infrastructure pour offrir une meilleure expérience utilisateur.

Les hébergeurs entièrement statiques (configuration par défaut de GitHub Pages) ne peuvent pas assurer une solution de repli côté serveur ; le routage fondé sur le chemin échoue donc lors d’une actualisation. Solutions possibles : astuces de redirection avec 404.html, hébergement sur Netlify ou Vercel, qui comprennent la solution de repli pour SPA, ou choix du routage par fragment pour les projets destinés exclusivement à un hébergement statique.

Certaines applications combinent les deux : le chemin pour la route principale, et le fragment pour les sections de la page (fenêtres modales, ancres d’onglets). L’événement de changement de fragment se déclenche toujours dans ces cas et complète le routeur fondé sur l’historique pour gérer l’état des sous-pages sans encombrer l’URL principale.

Pour passer du fragment au chemin : réécrivez tous les liens internes, ajoutez une solution de repli côté serveur, remplacez la logique de changement de fragment par la gestion de la navigation dans l’historique, puis redirigez les anciennes URL avec fragment vers leurs équivalents fondés sur le chemin à l’aide d’un petit script d’amorçage exécuté une fois et appelant history.replaceState.

Choisissez le routage fondé sur le fragment pour les hébergeurs statiques sans réécriture, les outils d’administration internes pour lesquels le référencement n’est pas important et les widgets intégrés. Choisissez le routage fondé sur le chemin pour tout ce qui est destiné aux utilisateurs, doit être indexé par les moteurs de recherche ou est partagé sur les réseaux sociaux — ce qui concerne la plupart des applications.

Pourquoi le routage de SPA fondé sur le chemin exige-t-il une configuration du serveur contrairement au routage fondé sur le fragment ?

Le routage fondé sur le fragment (URL comme /#/about) ne nécessite aucune configuration du serveur, mais offre un référencement médiocre et utilise des URL peu élégantes. Le routage fondé sur le chemin (URL comme /about) nécessite une solution de repli du serveur vers index.html, mais produit des URL propres, adaptées au référencement et faciles à partager. Les SPA modernes destinées au public utilisent le chemin ; les projets statiques ou internes peuvent encore choisir le fragment par souci de simplicité.