Un visiteur parcourt une catégorie, descend jusqu’au quarantième produit, ouvre une fiche, revient en arrière et se retrouve en haut de la page 1. Il doit tout refaire. C’est l’une des frictions les plus signalées sur les catalogues importants, et c’est aussi l’une des moins coûteuses à corriger.
Pourquoi le retour ne fonctionne pas
Trois causes distinctes, avec des solutions différentes.
La page est rechargée depuis le serveur. Sur un retour arrière, le navigateur peut servir la page depuis son cache ou la redemander. Dans le second cas, tout l’état visuel est perdu, y compris la position de défilement.
Le contenu est chargé après le rendu initial. Sur une catégorie en défilement infini ou avec filtres asynchrones, la page revient dans son état de départ : les produits chargés par défilement n’existent plus au retour.
L’état de navigation n’est pas dans l’URL. Si la pagination, les filtres et le tri ne sont pas reflétés dans l’adresse, le navigateur n’a aucun moyen de les restituer.
Cette dernière cause est la plus structurante : sans état dans l’URL, aucune restauration fiable n’est possible.
Ce qu’il faut mémoriser
Quatre éléments, dont seulement deux sont évidents.
La position de défilement. Le plus visible, et paradoxalement le moins important : si les bons produits sont affichés, un visiteur retrouve rapidement son repère.
La page courante ou le nombre de lots chargés. C’est le point décisif. Un visiteur arrivé au soixantième produit doit retrouver ces soixante produits, pas les vingt premiers.
Les filtres et le tri actifs. Ils doivent être dans l’URL, ce qui règle le problème indépendamment de tout mécanisme de mémorisation.
Le produit consulté. Restaurer la position est bien, ramener le visiteur exactement sur la vignette du produit qu’il vient de voir, avec un léger surlignage, est nettement mieux. Il retrouve son fil immédiatement.
Scroll Infini PrestaShop — Pagination SEO & Retour PositionScroll infini en catégorie avec pagination SEO préservée et retour à la position exacte après visite d'une fiche produit.€69.00
Les deux approches techniques
L’état dans l’URL. Chaque changement de filtre, de tri ou de page met à jour l’adresse sans recharger. Le retour arrière restitue naturellement l’état parce que l’adresse le décrit.
C’est l’approche la plus robuste : elle fonctionne aussi pour le partage de lien, l’ouverture dans un nouvel onglet et l’indexation. Elle demande en revanche une gestion propre de l’historique de navigation, avec la distinction entre les changements qui créent une entrée d’historique et ceux qui remplacent l’entrée courante.
La règle utile : un changement de filtre crée une entrée, un simple défilement remplace l’entrée courante. Sans cette distinction, le bouton retour oblige le visiteur à traverser dix états intermédiaires pour sortir de la catégorie.
Le stockage de session. L’état est enregistré côté navigateur au départ de la page et restauré au retour. Plus simple à mettre en œuvre, et limité : cela ne fonctionne pas sur un lien partagé ni sur un nouvel onglet.
La combinaison qui fonctionne : l’URL porte les filtres, le tri et la pagination, le stockage de session porte la position de défilement et l’identifiant du dernier produit consulté.
Le cas du nouvel onglet
Comportement très répandu et rarement traité : le visiteur ouvre les fiches produits dans de nouveaux onglets, en garde cinq ouverts, et revient sur l’onglet de la catégorie.
Bonne nouvelle : dans ce cas, l’onglet de la catégorie n’a pas été rechargé et son état est intact. Aucun mécanisme n’est nécessaire.
Deux points de vigilance malgré tout. Si votre page recharge automatiquement son contenu au retour de focus, pour rafraîchir les stocks par exemple, vous détruisez cet état. Et le surlignage du dernier produit consulté ne fonctionne pas dans ce scénario, puisque plusieurs produits ont été ouverts.
La bonne pratique consiste à marquer visuellement tous les produits déjà consultés dans la grille, pas seulement le dernier. C’est utile dans les deux scénarios et cela aide le visiteur à se repérer dans une longue liste.
Défilement infini ou pagination
Le retour à la position est plus difficile en défilement infini, et cela pèse dans l’arbitrage entre les deux.
En pagination classique, l’URL contient le numéro de page, le retour fonctionne naturellement, et l’indexation est simple. L’inconvénient est le clic supplémentaire à chaque page.
En défilement infini, l’expérience de parcours est plus fluide mais trois problèmes apparaissent : le retour à la position, l’accès au pied de page devenu inatteignable, et l’indexation des produits chargés dynamiquement.
La solution intermédiaire résout la plupart de ces points : un défilement qui charge automatiquement deux ou trois lots, puis un bouton « voir plus » explicite, avec une mise à jour de l’URL à chaque lot. Vous conservez la fluidité du début de parcours, l’adresse reste partageable, et le pied de page redevient atteignable.
Ce qui casse la restauration
Quatre situations à vérifier après implémentation.
Le cache serveur. Une page mise en cache peut être servie dans un état différent de celui attendu. Vérifiez le comportement en conditions réelles, pas seulement en environnement de développement.
Le changement de stock. Si un produit devient indisponible entre le départ et le retour, la grille change et la position mémorisée ne correspond plus. Restaurez sur l’identifiant du produit plutôt que sur une position en pixels.
L’affichage responsive. Une position en pixels calculée sur desktop n’a aucun sens si le visiteur a tourné son téléphone entre-temps. C’est une raison de plus de raisonner en produit plutôt qu’en distance.
Les blocs de hauteur variable. Un bandeau promotionnel ou un bloc chargé tardivement décale la grille. Attendez la fin du chargement des éléments au-dessus de la grille avant de restaurer.
Mesurer
Deux indicateurs suffisent, et le second est celui qui compte.
Le nombre de produits vus par session sur les catégories concernées. Un visiteur qui ne perd plus sa position en consulte mécaniquement davantage.
Le taux de retour vers la catégorie depuis les fiches produits. S’il augmente après la mise en place, votre parcours de comparaison fonctionne. S’il reste bas, le problème est ailleurs, probablement dans la fiche elle-même.
Le module Scroll Infini pour PrestaShop traite ce comportement sur PrestaShop 8 et 9 : chargement progressif avec mise à jour de l’adresse à chaque lot, restauration de la page et de la position au retour depuis une fiche, repérage des produits déjà consultés et bouton explicite après les premiers lots pour conserver l’accès au pied de page.
