Een autosuggestzoekveld reageert te laat

Begin met een meetbare omschrijving, anders discussieer je over gevoel. MDN geeft geen harde regel voor wat traag is, maar wel richtwaarden voor reactie op invoer van 50 tot 200 milliseconde, en benadrukt dat latentie ook uit netwerkafstand komt (overzicht van webperformance). Gebruik dat als oriëntatie, niet als garantie of norm voor jouw publiek.

Leg voor je iets aanpast vast:

• Welke zoekterm je typt, en hoe snel je typt.
• Op welk apparaat en welke verbinding je test, en of de browsercache leeg is.
• Wanneer de eerste suggestie verschijnt, en of die bij de laatste of een eerdere letter hoort.
• Of de vertraging bij elk woord optreedt of enkel bij nieuwe, nog niet gecachete zoektermen.

Zo heb je straks een vergelijkbare nulmeting.

Open de netwerkweergave in de ontwikkelaarstools van je browser, filter op het zoekeindpunt en typ je testterm in één vloeiende beweging. Tel de verzoeken. Gaat er bij acht letters ook acht keer een verzoek weg, dan belast je je server en je eigen verbinding onnodig.

Controleer drie dingen. Eerst: start het verzoek na een korte pauze in het typen of bij elke toetsaanslag? Daarna: is er een minimumaantal tekens voordat gezocht wordt? Ten slotte: hoe lang duurt het antwoord zelf, en hoe groot is het? Een antwoord vol velden die de suggestielijst nooit toont, kost tijd zonder iets op te leveren.

De cursus Learn Performance behandelt hoe de browser resources laadt en wat de kritieke weg is. Dat helpt om te zien of de vertraging vooral uit je eigen verzoeken komt, of uit zware scripts die de pagina tegelijk bezighouden. Welke stappen jouw oplossing nodig heeft, bepaal je met je eigen meting.

Een klassiek probleem is de volgordefout. Je typt 'sch', daarna 'scho'. Het antwoord op 'sch' komt als laatste binnen en overschrijft de lijst voor 'scho'. Het resultaat is een lijst die niet bij het zoekveld past.

Test dat bewust: vertraag in de ontwikkelaarstools je netwerk, typ een term in twee stukken en kijk welk antwoord de lijst vult. Zijn er verzoeken die nog lopen terwijl er al een nieuwer is gestart, dan mist je code een annulering of een controle.

1. Annuleer het vorige lopende verzoek zodra je een nieuw start, bijvoorbeeld via een annuleermechanisme van je codebasis.
2. Of vergelijk bij het binnenkomen van een antwoord de gebruikte zoekterm met de huidige inhoud van het veld, en negeer verouderde antwoorden.
3. Toon bij een mislukt of geannuleerd verzoek geen foutmelding aan de bezoeker.
4. Test met leeg veld: de lijst moet dan weg of terug naar de beginstaat.

Of je de ene of de andere aanpak kiest, hangt af van je framework. Dat bespreek je met wie de code beheert.

Snelheid nuttig maken betekent ook dat de lijst bediend kan worden zonder muis. De W3C-tutorials leggen uit hoe je toegankelijke webcomponenten bouwt en welke technieken en succescriteria per voorbeeld horen (toegankelijkheidstutorials van W3C). Raadpleeg daar het patroon dat bij jouw onderdeel past. Het pagina-overzicht noemt zelf geen specifiek autosuggestpatroon, dus controleer dat in de bijbehorende detailpagina's en in WCAG.

Test zonder muis:

• Tab brengt je naar het veld en daarna naar de rest van de pagina, zonder vast te lopen in de lijst.
• Pijltoetsen verplaatsen door de suggesties en de actieve suggestie is zichtbaar.
• Enter kiest de actieve suggestie, of verstuurt de eigen tekst als er niets gekozen is.
• Escape sluit de lijst en laat de getypte tekst staan.
• Controleer of wijzigingen in de lijst ook zonder zicht merkbaar zijn, bijvoorbeeld via een melding of ander patroon uit de W3C-tutorials of WCAG. Test dat met een schermlezer, want gedrag verschilt per combinatie en deze controle bewijst geen volledige WCAG-conformiteit.

Een lijst die snel verschijnt maar niet met het toetsenbord bedienbaar is, lost het probleem maar half op.

Los één rij per keer op en meet opnieuw, anders weet je niet welke aanpassing hielp.

Herhaal na elke aanpassing exact de nulmeting uit het begin: dezelfde term, hetzelfde apparaat, dezelfde netwerkinstelling. Vergelijk het aantal verzoeken, de volgorde van antwoorden en de toetsenbordtest. Welke verbetering je mag verwachten, kun je vooraf niet zeggen. Je rapporteert dus wat je meet.

Fictief overdrachtsvoorbeeld, enkel invoer en verwachte controles: je typt de term 'wandelschoenen' in één vloeiende beweging. Voorheen gaat er bij elke toetsaanslag een verzoek weg. Na de wijziging verwacht je in de netwerkweergave minder verzoeken dan letters, geen foutmelding bij geannuleerde verzoeken, en een lijst die bij de laatste invoer hoort. Daarna loop je de toetsenbordlijst door. Noteer in de overdracht wat gemeten werd, op welk apparaat en wat nog onbekend is, zoals gedrag op trage mobiele verbindingen.

Wil je ook zien welke signalen je site publiek toont, bekijk dan je eigen website via Marketing Scan. Een publieke scan ziet geen interne zoekcode, dus de testen hierboven blijven nodig.