Browserterug toont een verouderde winkelmand

Browsers proberen heen-en-terugnavigatie snel te laten voelen. Daarvoor kunnen ze een eerder opgebouwde pagina opnieuw tonen in plaats van hem volledig opnieuw te laden. Hoe sterk dat gebeurt, hangt af van de browser, de cache-instellingen van je server en de scripts op de pagina. Algemene uitleg over hoe browsers pagina's opbouwen en wat laadgedrag beïnvloedt, vind je in de MDN-documentatie over webprestaties. De bron beschrijft het principe, geen kant-en-klare oplossing voor jouw winkel.

Voor een webshop zijn er grofweg vier plekken waar een oude toestand kan blijven hangen:

• de pagina zelf, die uit de cache van de browser of een tussenlaag komt;
• een tussenlaag zoals een CDN of paginacache aan serverzijde;
• gegevens in lokale opslag van de browser, bijvoorbeeld een bewaarde mand;
• een script dat bij het laden de mand opbouwt uit eerder opgehaalde data.

Zolang je niet weet welke laag de oude gegevens levert, is elke aanpassing gokwerk. Eerst diagnose dus, daarna pas een ingreep.

Test op een manier die je kunt herhalen en overdragen. Werk met een testproduct dat je zelf kunt wijzigen, zodat je geen echte klanten of bestellingen raakt.

1. Open de shop in een schoon browserprofiel of privévenster en voeg het testproduct toe aan de mand.
2. Ga naar de winkelmandpagina en noteer prijs, aantal en beschikbaarheid zoals je ze ziet.
3. Ga door naar de afrekenstap, maar bevestig niets.
4. Wijzig nu in het beheer de prijs of de voorraad van het testproduct.
5. Druk op de terugknop van de browser en kijk wat er verschijnt, zonder te vernieuwen.
6. Ga opnieuw vooruit en kijk of de afrekenstap de nieuwe of de oude waarde toont.
7. Herhaal de reeks met de terugknop twee keer, en daarna via de eigen navigatie van de shop.

Noteer per stap wat je zag. Het verschil tussen terug via de browser en doorklikken via een link in de shop is al informatief: als alleen de browserterug fout gaat, wijst dat op een hergebruikte pagina. Gaat ook de normale navigatie fout, dan zit het probleem eerder in de gegevens zelf.

Gebruik de ontwikkelaarstools van je browser, het netwerkpaneel in het bijzonder. De exacte menu's en schermnamen verschillen per browser en versie, dus controleer in jouw browser waar je dit paneel vindt. Het idee: kijk bij de terugnavigatie of de browser een nieuw verzoek naar de server stuurt en welke antwoordheaders (zoals cache-instructies) de pagina meekreeg. De achtergrond over caching van het HTML-document en over hoe resources worden geladen staat in de cursus Learn Performance op web.dev.

Volg daarna deze beslislijn:

• Geen nieuw verzoek bij terug: de pagina lijkt uit de browser te komen (cache of een bewaarde paginatoestand). Kijk naar de cache-instructies van de mand- en afrekenpagina's en controleer in een tweede browser.
• Wel een verzoek, maar het antwoord bevat oude waarden: de server of een tussenlaag levert verouderde inhoud. Vraag je hostingpartij of platformbeheerder welke paginacache actief is.
• Het antwoord is correct, maar het scherm toont toch oude waarden: een script of lokaal bewaarde mand overschrijft de gegevens.

Wat je hier vindt, is een vaststelling voor jouw shop. Het zegt niets over andere shops of andere thema's.

Kies de ingreep op basis van wat je in stap 2 zag. De tabel is een leidraad. Laat de eigenlijke implementatie over aan degene die je shopplatform beheert, want de beschikbare instellingen verschillen per systeem.

Pas één ding per keer aan. Anders weet je achteraf niet welke wijziging het effect had.

Zelfs met een goede cacheconfiguratie kan een klant een tabblad uren open laten staan. Maak de bevestiging daarom robuust: de server controleert op het moment van bevestigen prijs en voorraad opnieuw, ongeacht wat de klant op zijn scherm ziet.

1. Vergelijk bij bevestigen de prijs en beschikbaarheid van elk artikel met de actuele gegevens.
2. Is er een verschil, toon dan een duidelijke melding die zegt wat er veranderd is en vraag opnieuw om bevestiging.
3. Laat de bestelling nooit stilzwijgend tegen een afwijkend bedrag doorgaan.
4. Zorg dat de melding bereikbaar en leesbaar is voor iedereen, ook met toetsenbord of schermlezer. Richtlijnen daarvoor staan in de toegankelijkheidstutorials van het W3C.

Of jouw platform deze controle al uitvoert, moet je testen. Neem het niet aan.

Een fictieve webwinkel verkoopt keramische bekers. Testproduct: een beker met testprijs 12,00 euro en een voorraad van 3. De tester voegt twee stuks toe, gaat naar de afrekenstap, laat de prijs in het beheer wijzigen naar 14,00 euro en drukt op Terug. De verwachte controle: toont de mandpagina na terug nog 12,00 euro, dan noteert de tester dat en geeft hij de vaststelling door aan de beheerder, samen met de browser en de stappen. Daarna wordt een ingreep gekozen via de matrix hierboven.

Na elke wijziging herhaal je het volledige script uit stap 1 en voeg je de controles toe in minstens twee browsers en op een mobiel toestel. Controleer ook of de bevestigingsstap een melding geeft wanneer je de voorraad op nul zet terwijl het artikel nog in de mand zit. Doe dit alleen in een testomgeving of met een testproduct dat niet echt verkocht kan worden. Verschijnt er bij bevestigen een time-out of foutmelding, controleer dan eerst of de bestelling toch is opgeslagen, en gebruik een unieke, opvraagbare testactie zodat een herhaalde poging geen dubbele bestelling maakt. Leg de resultaten vast in een korte overdrachtsnotitie: wat getest, welke browser, wat gezien, wat aangepast. Een geslaagde test op je eigen toestel bewijst niet dat alle klanten hetzelfde zien.

Wil je ook nagaan welke zichtbare signalen je site naar buiten toe geeft, bekijk dan de publieke signalen van je website via Marketing Scan. De scan meet publiek zichtbare signalen en voert de controles uit dit artikel niet uit.