Productfilters verversen de hele pagina

Een filterklik is een taak: de klant klikt en wil een bruikbaar, bijgewerkt productoverzicht zien. Meet daarom de tijd tussen de klik en het moment waarop de nieuwe resultaten zichtbaar en bruikbaar zijn, niet alleen de laadtijd van een losse pagina. MDN omschrijft webperformance als een combinatie van objectieve metingen en de ervaren snelheid, inclusief de vraag of knoppen reageren en of scrollen soepel gaat (MDN over webperformance). Dezelfde bron noemt richtwaarden voor reactie op invoer van 50 tot 200 milliseconden, maar zegt ook dat er geen harde regels zijn voor wat traag is. Gebruik zulke richtwaarden dus als referentie, niet als norm die je moet halen.

Definieer vooraf drie momenten: de klik, het eerste zichtbare teken van reactie en het moment waarop de lijst volledig bruikbaar is. Zo zie je of de klant vooral wacht op het netwerk, op de server of op het opbouwen van de pagina.

Open de ontwikkelaarstools van je browser, ga naar het netwerkoverzicht en wis de lijst. Klik daarna op één filter. Waar je dat scherm precies vindt, verschilt per browser, controleer dat in de documentatie van jouw browser. Kijk dan naar drie dingen:

1. Is er een nieuw document opgevraagd (een volledige navigatie), of alleen een kleiner gegevensverzoek?
2. Welke bestanden laden telkens opnieuw: afbeeldingen, stijlbladen, scripts, lettertypen?
3. Verandert de URL, en komt de terugknop op de vorige filterstand uit?

Test dit op een gewone verbinding en daarna met de vertraging die de ontwikkelaarstools kunnen nabootsen. MDN raadt aan om performance ook te testen met hoge latency, voor bezoekers met een trage of onstabiele verbinding. Noteer elke keer wat je ziet, zodat je later kunt vergelijken.

Een volledige herlading is geen fout op zich. Het kan een prima keuze zijn als het document snel binnenkomt en het herladen weinig extra werk geeft. Gebruik deze beslistabel op basis van je eigen metingen.

De web.dev-cursus behandelt onder meer HTML-caching, parser-blokkering en render-blokkering als onderdelen van het eerste HTML-verzoek (web.dev over performance). De bron schrijft geen volgorde voor bij filters. Als redactioneel voorstel: controleer eerst deze punten en kies een gedeeltelijke update pas als je meting laat zien dat ze de oorzaak niet wegnemen.

Geef je ontwikkelaar of bureau een compacte opdracht met meetgegevens in plaats van het woord traag. Stappenplan:

1. Kies drie veelgebruikte filtercombinaties van je eigen categorie.
2. Meet per combinatie klik, eerste reactie en bruikbaar resultaat, op een gewone en een vertraagde verbinding.
3. Noteer per klik of het document opnieuw wordt opgehaald en welke bestanden herladen.
4. Noteer URL-gedrag en terugknop.
5. Kies met de beslistabel één verbetering, geen drie tegelijk.
6. Voer door en herhaal exact dezelfde meting.

Fictief overdrachtsvoorbeeld. Invoer: een webwinkel met een categorie schoenen en de filters maat 42 en kleur zwart. Verwachte technische controles: de URL bevat beide filterwaarden, de terugknop gaat naar de stand zonder kleurfilter, een gedeelde link opent dezelfde selectie, en het netwerkoverzicht toont welke bestanden bij de klik opnieuw laden. Er staan hier bewust geen uitkomsten in, want die moet je zelf meten.

Herhaal na elke aanpassing dezelfde drie combinaties met dezelfde instellingen, anders vergelijk je appels met peren. Controleer daarnaast het gedrag:

• Verschijnt bij elke filterstand een eigen, deelbare URL die bij openen in een nieuw venster dezelfde selectie toont?
• Brengt de terugknop je naar de vorige stand, en de vooruitknop weer terug?
• Kun je filters bedienen met alleen het toetsenbord, en blijft zichtbaar waar de focus is na het bijwerken?
• Krijgen gebruikers van hulptechnologie te horen dat de resultaten zijn veranderd? Test dit met de hulpmiddelen die jouw team ter beschikking heeft.

De W3C-tutorials over toegankelijkheid bundelen praktische richtlijnen voor veelvoorkomende onderdelen van websites en koppelen die aan WCAG-criteria (W3C-toegankelijkheidstutorials). Lees per tutorial welke criteria worden genoemd en zoek zelf de pagina's over formulieren en dynamische inhoud op. Deze bron bewijst niet dat jouw filter conform is, dat blijft een eigen test.

Deze procedure meet jouw filter op jouw apparaat en verbinding. Ze zegt niets over hoe alle bezoekers het ervaren, en een verbetering in een testsessie is geen garantie voor meer conversie of betere zoekresultaten. Ook de bronnen zijn algemeen: ze leggen principes uit, geen exacte instelling voor jouw winkelsysteem. Controleer in de documentatie of bij de beheerder van je platform welke opties bestaan.

Wil je daarnaast weten welke zichtbare signalen je website publiek toont, bekijk dan je site via Marketing Scan. Een publieke scan meet zichtbare signalen en bewijst geen volledige technische implementatie, en ze vervangt de metingen in je eigen browser niet.