Een laadspinner zonder informatie over de voortgang

Een spinner bevestigt hooguit dat er iets bezig is. Hij zegt niet wat er gebeurt, hoe lang het kan duren en wat je mag doen als het te lang duurt. Bezoekers vullen die leemte zelf in, vaak met een tweede klik of een paginaverversing.

Volgens MDN over webperformance gaat performance niet alleen over objectieve meetwaarden, maar ook over de ervaren wachttijd. De bron beschrijft dat je latency kunt verhullen door de ervaring zo snel mogelijk beschikbaar en interactief te maken en trage onderdelen asynchroon na te laden. De bron behandelt geen spinners of statusteksten; de drie vragen hieronder zijn een eigen controle:

• Actie: toont de pagina wat er precies verwerkt wordt, bijvoorbeeld 'We versturen je aanvraag'?
• Wachttijd: weet de bezoeker of dit seconden of minuten kan duren, of komt er een tussenmelding als het langer duurt?
• Herstel: bestaat er een duidelijke uitweg bij mislukking, met behoud van wat de bezoeker al invulde?

Een spinner is daarmee een onderdeel van een boodschap, niet de boodschap zelf. Controleer dus eerst welke vraag op jouw site onbeantwoord blijft.

Niet elke spinner heeft dezelfde oorzaak. Zoek eerst uit waar hij verschijnt en waarop hij wacht. Doorloop deze stappen alleen in een veilige testomgeving, niet met echte klanten, betalingen of aanvragen:

1. Lijst alle plaatsen op waar een spinner of laadindicator verschijnt: formulierverzending, betaling, zoekresultaten, filters, accountpagina's.
2. Open per plaats de netwerkweergave van de ontwikkeltools van je browser en start de actie. Noteer welk verzoek de spinner aanstuurt en wanneer het antwoord binnenkomt.
3. Vertraag de verbinding kunstmatig met de netwerkbeperking van de ontwikkeltools. Controleer of de spinner dan nog steeds iets uitlegt.
4. Onderbreek de verbinding midden in de actie. Kijk wat er gebeurt: blijft de spinner eeuwig draaien, of verschijnt er een foutmelding?
5. Noteer per plaats of de spinner verdwijnt bij een fout. Een spinner die nooit stopt is de gevaarlijkste variant.

Een verzoek dat structureel traag is, is een apart probleem. De cursus Learn Performance op web.dev behandelt onderwerpen als het kritieke renderpad en het optimaliseren van resources. Dat helpt als de oorzaak in het laden van de pagina zelf zit. Een spinner bij een formulier wijst vaker op een trage serverreactie of een wachtende externe dienst. Laat die twee oorzaken niet door elkaar lopen.

Gebruik onderstaand blad als vaste afspraak voor je team. Het is een voorstel om te testen, geen norm.

Bepaal met je team zelf na hoeveel seconden een tussenmelding komt. Baseer dat op je eigen metingen uit de vorige sectie, niet op een getal uit een willekeurige bron.

Dubbele verzending voorkom je op twee niveaus. Aan de voorkant zet je de knop tijdens het verzenden in een wachtstand en toon je een statustekst. Aan de achterkant moet je systeem een herhaald verzoek herkennen, bijvoorbeeld met een uniek aanvraagnummer dat de server per actie één keer accepteert. De voorkant alleen is niet genoeg: een bezoeker kan de pagina verversen of de browser kan een verzoek herhalen.

Maak de status ook toegankelijk. De tutorials van W3C WAI richten zich op webcontent die ook voor mensen met een beperking bruikbaar is en geven praktijkgerichte richtlijnen per onderwerp. Voor een laadstatus betekent dat in de praktijk dat je controleert of de statustekst ook voor een schermlezer wordt aangekondigd en niet alleen als draaiend plaatje bestaat. Welke techniek je daarvoor kiest, zoek je op in de relevante tutorial of bij de technische beheerder, want dat hangt af van je pagina.

Test daarna met het toetsenbord alleen: kun je de knop activeren, en blijft de focus logisch na de verzending? Een bezoeker die geen muis gebruikt, mag niet achterblijven met een spinner die niemand benoemt.

Stel dat je een overdrachtsnotitie schrijft voor een externe webbouwer. Dit is een fictief voorbeeld met alleen invoer en verwachte controles, zonder resultaten.

Pagina: aanvraagformulier. Probleem: na het klikken op 'Verzenden' draait een spinner zonder tekst. Gewenst gedrag: (1) knop toont 'We versturen je aanvraag' en is tijdens het verzenden niet opnieuw klikbaar; (2) bij een traag antwoord verschijnt een tussenmelding; (3) bij een fout verschijnt een melding met een knop om opnieuw te proberen en blijven de ingevulde velden behouden; (4) de server accepteert dezelfde aanvraag maar één keer.

Spreek bij overdracht ook af hoe je dit controleert:

1. Verzend het formulier met een normale verbinding en noteer wat je ziet.
2. Herhaal met een vertraagde verbinding.
3. Verbreek de verbinding tijdens het verzenden.
4. Klik snel twee keer en kijk in het systeem dat de aanvragen ontvangt hoeveel items er binnenkomen.
5. Herhaal alles met alleen het toetsenbord.

Zo heeft de webbouwer een toetsbare opdracht in plaats van de vage vraag 'maak de spinner mooier'.

Voer de testreeks uit na elke wijziging en leg de bevindingen vast, zodat je ze later kunt vergelijken. Let op de volgende grenzen:

• Je test op jouw pagina's en jouw apparaten. Een goed resultaat in je testomgeving bewijst niet dat elke bezoeker, verbinding of browser hetzelfde ziet.
• De bronnen in dit artikel zijn algemene leermiddelen. Ze geven geen vaste drempel voor wanneer een spinner te lang duurt en geen garantie op een hogere conversie.
• Een publieke scan van je site kan zichtbare signalen tonen, maar kan niet bewijzen hoe een verzending achter de schermen wordt verwerkt.

Wil je weten welke publieke signalen je website nu geeft, bijvoorbeeld rond laadgedrag en bruikbaarheid? Bekijk ze dan via Marketing Scan. We beloven daarmee niet dat elke controle uit dit artikel wordt uitgevoerd. Je eigen testreeks blijft nodig voor de laatste stap.