Een bezoeker doorloopt een categorie, daalt af tot het veertigste product, opent een productpagina, gaat terug en staat bovenaan pagina 1. Hij moet alles overdoen. Een van de meest gemelde fricties op grote catalogi, en ook een van de goedkoopste om te corrigeren.
Waarom de terugkeer niet werkt
Drie aparte oorzaken, met verschillende oplossingen.
De pagina wordt herladen vanaf de server. Bij een terugkeer kan de browser de pagina uit zijn cache serveren of opnieuw opvragen. In het tweede geval is de hele visuele staat verloren, inclusief de scrollpositie.
De content wordt na de initiële rendering geladen. Op een categorie met oneindig scrollen of asynchrone filters komt de pagina terug in haar beginstaat: de door scrollen geladen producten bestaan bij de terugkeer niet meer.
De navigatiestaat staat niet in de URL. Worden de paginering, de filters en de sortering niet in het adres weerspiegeld, dan heeft de browser geen enkel middel om ze te herstellen.
Die laatste oorzaak is de meest structurerende: zonder staat in de URL is geen enkel betrouwbaar herstel mogelijk.
Wat te onthouden
Vier elementen, waarvan er maar twee evident zijn.
De scrollpositie. Het meest zichtbare, en paradoxaal genoeg het minst belangrijke: worden de juiste producten getoond, dan vindt een bezoeker snel zijn houvast terug.
De huidige pagina of het aantal geladen batches. Het beslissende punt. Een bezoeker die bij het zestigste product was, moet die zestig producten terugvinden, niet de eerste twintig.
De actieve filters en sortering. Ze moeten in de URL staan, wat het probleem regelt los van elk onthoudmechanisme.
Het bekeken product. De positie herstellen is goed, de bezoeker exact terugbrengen op de tegel van het product dat hij net heeft gezien, met een lichte markering, is duidelijk beter. Hij vindt zijn draad onmiddellijk terug.
Oneindig Scrollen PrestaShop: SEO-paginering & PositieherstelOneindig scrollen op de categoriepagina met behoud van de SEO-paginering en terugkeer naar de exacte positie na een bezoek aan een productpagina.€69,00
De twee technische aanpakken
De staat in de URL. Elke wijziging van filter, sortering of pagina werkt het adres bij zonder te herladen. De terugkeer herstelt de staat natuurlijk omdat het adres hem beschrijft.
De robuustste aanpak: ze werkt ook voor het delen van een link, het openen in een nieuw tabblad en de indexering. Ze vraagt daarentegen een proper beheer van de navigatiegeschiedenis, met het onderscheid tussen wijzigingen die een geschiedenisitem creëren en die welke het huidige item vervangen.
De nuttige regel: een filterwijziging creëert een item, een eenvoudig scrollen vervangt het huidige item. Zonder dat onderscheid dwingt de terugknop de bezoeker tien tussenliggende staten te doorlopen om de categorie te verlaten.
De sessieopslag. De staat wordt aan browserzijde opgeslagen bij het verlaten van de pagina en hersteld bij de terugkeer. Eenvoudiger te implementeren, en beperkt: het werkt niet op een gedeelde link noch op een nieuw tabblad.
De combinatie die werkt: de URL draagt de filters, de sortering en de paginering, de sessieopslag draagt de scrollpositie en de identifier van het laatst bekeken product.
Het geval van het nieuwe tabblad
Een zeer verspreid en zelden behandeld gedrag: de bezoeker opent de productpagina’s in nieuwe tabbladen, houdt er vijf open, en komt terug op het tabblad van de categorie.
Goed nieuws: in dat geval is het categorietabblad niet herladen en is zijn staat intact. Geen enkel mechanisme is nodig.
Toch twee waakpunten. Herlaadt uw pagina automatisch haar content bij het terugkrijgen van de focus, bijvoorbeeld om de voorraden te verversen, dan vernietigt u die staat. En de markering van het laatst bekeken product werkt niet in dit scenario, aangezien meerdere producten werden geopend.
De goede praktijk bestaat erin alle al bekeken producten visueel te markeren in het raster, niet alleen het laatste. Nuttig in beide scenario’s en het helpt de bezoeker zich te oriënteren in een lange lijst.
Oneindig scrollen of paginering
De terugkeer naar de positie is moeilijker bij oneindig scrollen, en dat weegt in de afweging tussen beide.
Bij klassieke paginering bevat de URL het paginanummer, werkt de terugkeer natuurlijk, en is de indexering eenvoudig. Het nadeel is de extra klik bij elke pagina.
Bij oneindig scrollen is de doorloopervaring vloeiender maar verschijnen drie problemen: de terugkeer naar de positie, de toegang tot de onbereikbaar geworden footer, en de indexering van de dynamisch geladen producten.
De tussenoplossing lost de meeste van die punten op: een scrollen dat automatisch twee of drie batches laadt, dan een expliciete knop “meer tonen”, met een URL-update bij elke batch. U behoudt de vloeiendheid van het begin van het parcours, het adres blijft deelbaar, en de footer wordt weer bereikbaar.
Wat het herstel breekt
Vier situaties om na de implementatie te controleren.
De servercache. Een gecachete pagina kan in een andere staat worden geserveerd dan verwacht. Controleer het gedrag in reële omstandigheden, niet alleen in de ontwikkelomgeving.
De voorraadwijziging. Wordt een product onbeschikbaar tussen het vertrek en de terugkeer, dan verandert het raster en komt de onthouden positie niet meer overeen. Herstel op de identifier van het product in plaats van op een positie in pixels.
De responsive weergave. Een positie in pixels berekend op desktop heeft geen enkele betekenis als de bezoeker intussen zijn telefoon heeft gedraaid. Een reden te meer om in producten te redeneren in plaats van in afstand.
De blokken met variabele hoogte. Een promotiebanner of een laat geladen blok verschuift het raster. Wacht tot de elementen boven het raster geladen zijn voor u herstelt.
Meten
Twee indicatoren volstaan, en de tweede is degene die telt.
Het aantal bekeken producten per sessie op de betrokken categorieën. Een bezoeker die zijn positie niet meer verliest, bekijkt er mechanisch meer.
Het terugkeerpercentage naar de categorie vanaf de productpagina’s. Stijgt het na de opzet, dan werkt uw vergelijkingsparcours. Blijft het laag, dan ligt het probleem elders, waarschijnlijk in de productpagina zelf.
De Oneindig Scrollen module voor PrestaShop behandelt dit gedrag op PrestaShop 8 en 9: progressief laden met adresupdate bij elke batch, herstel van de pagina en de positie bij terugkeer vanaf een productpagina, markering van de al bekeken producten en expliciete knop na de eerste batches om de toegang tot de footer te behouden.