Qu'est-ce que l'API History ?

Qu'est-ce que l'API History ?

L'API History (API d'historique du navigateur) est une interface, exposée par window.history, qui permet à JavaScript de parcourir l'historique de la session et d'ajouter ou de modifier des entrées. Avec pushState() et replaceState(), une page peut mettre à jour la barre d'adresse et le bouton Précédent sans rechargement complet, ce qui permet à une application monopage de donner à chaque écran sa propre URL.

Fonctionnement

• history.back(), history.forward() et history.go(n) parcourent les entrées existantes, comme les boutons du navigateur. history.length est le nombre d'entrées.
• history.pushState(state, "", url) ajoute une nouvelle entrée. history.replaceState(state, "", url) écrase l'entrée courante.
• state est un objet sérialisable quelconque stocké avec l'entrée. Le deuxième argument est inutilisé mais ne peut pas être omis : passez une chaîne vide.
• url est facultative et doit avoir la même origine que la page courante, sinon l'appel lève une SecurityError.
• Aucune des deux méthodes ne charge l'URL ni ne vérifie qu'elle existe. Elles changent seulement ce que le navigateur enregistre et affiche.
• L'événement popstate se déclenche quand l'utilisateur parcourt l'historique (Précédent, Suivant, go()). Appeler pushState() ou replaceState() ne le déclenche pas, et les navigateurs peuvent l'ignorer tant que l'on n'a pas interagi avec la page.

La référence MDN de pushState() en documente les détails.

Un routeur minimal

La navigation appelle pushState et affiche la vue elle-même. Précédent et Suivant déclenchent popstate, et le gestionnaire affiche la vue correspondant à l'URL restaurée par le navigateur :

function navigate(path) {
  history.pushState({ path: path }, "", path);
  render(path);
}

window.addEventListener("popstate", function () {
  render(location.pathname);
});

Le rendu agit directement sur le DOM, aucun nouveau document n'est donc demandé.

Le serveur doit toujours répondre à ces URL

Une URL créée avec pushState n'est qu'un enregistrement dans le navigateur. Si un visiteur recharge sur /products/42, l'ajoute à ses favoris ou suit un lien partagé, le serveur reçoit cette requête. Il doit renvoyer l'application (ou un vrai contenu), pas une 404. D'après MDN, le navigateur ne charge pas l'URL après pushState(), mais peut la charger plus tard, par exemple après un redémarrage.

SEO et robots d'exploration

La recommandation de Google pour les sites JavaScript est d'utiliser l'API History pour le routage entre vues et de ne pas utiliser de fragments d'URL pour charger des contenus différents. Les liens doivent être de vrais éléments <a href="..."> : les robots trouvent les liens grâce au href, et un gestionnaire de clic sur un span ou une ancre sans href ne leur donne rien à suivre. Les vues d'erreur demandent aussi de l'attention : une page 404 routée côté client renvoie toujours le statut 200, sauf si vous redirigez vers une URL qui renvoie une vraie 404 ou ajoutez une balise robots noindex. Voir les bases du SEO JavaScript de Google.

Erreurs courantes

• Pas de gestionnaire popstate. L'URL change au clic sur Précédent, mais pas l'écran.
• Liens sans href. Ils fonctionnent dans le navigateur et sont invisibles pour les robots ; le clic central et "ouvrir dans un nouvel onglet" ne marchent plus.
• Routage par hash pour le contenu. Les robots ne résolvent pas de façon fiable les URL à fragment.
• Gros objets d'état. Certains navigateurs plafonnent la taille sérialisée et lèvent une erreur. Gardez l'état léger et utilisez sessionStorage pour davantage.
• Croire que le titre change. Le deuxième argument est ignoré : renseignez document.title vous-même et déplacez le focus pour les lecteurs d'écran.
• Pas de repli côté serveur. Les liens profonds renvoient une 404 au rechargement.

Lien avec les tests et la surveillance

Une navigation par pushState ne demande généralement pas de nouvelle page HTML. Le coût se trouve dans les appels d'API et le rendu qui suivent, si bien qu'un test qui ne récupère que le HTML en manque l'essentiel. Testez les appels d'API de l'application, pondérés comme les utilisateurs les font : voir tests de charge d'applications monopages, à exécuter avec les tests de charge. La surveillance d'API continue de surveiller les endpoints derrière vos routes, et la surveillance synthétique couvre des parcours entiers. Vérifiez aussi les URL profondes directement : une requête vers l'URL d'une route doit renvoyer 200 depuis le serveur, et pas seulement fonctionner après une navigation dans l'application.

Questions fréquentes : API History

pushState recharge-t-il la page ?

Non. Il ajoute une entrée à l'historique et change l'URL affichée dans la barre d'adresse, mais le navigateur ne charge pas cette URL et ne vérifie pas qu'elle existe.

pushState déclenche-t-il l'événement popstate ?

Non. popstate se déclenche quand l'entrée active de l'historique change par navigation de l'utilisateur, comme Précédent, Suivant ou history.go(). Après votre propre appel à pushState, vous mettez la vue à jour vous-même.

Quelle différence entre pushState et replaceState ?

pushState ajoute une nouvelle entrée, donc Précédent revient à la précédente. replaceState écrase l'entrée courante, aucune étape Précédent supplémentaire n'est créée. Utilisez replace pour des corrections comme les redirections ou la mise à jour d'un filtre dans l'URL.

Routage par hash ou API History ?

Pour un contenu qui doit être indexé, utilisez l'API History avec de vrais chemins. Google déconseille d'utiliser des fragments d'URL pour charger des contenus différents. Le routage par hash n'exige aucune configuration serveur, ce qui peut convenir à des outils internes sans trafic de recherche.

Faut-il configurer le serveur pour les routes de l'API History ?

Oui. Le serveur doit répondre à chaque URL de route, en général en renvoyant la coquille de l'application ou du contenu prérendu, car un rechargement, un favori ou un lien partagé demande directement cette URL.