Een bezoeker typt een vraag, drukt op enter en kijkt naar drie stipjes. Eén seconde is prima, drie seconden voelt lang, en na zes seconden is de helft weg. Als uw chatbot antwoordt traag, dan is dat geen mysterie: er zit een keten van stappen tussen de vraag en het antwoord, en in elke stap kan tijd verdwijnen. Hieronder ziet u waar precies, en wat u eraan kunt doen.
De keten van een enkel antwoord
Wat er gebeurt tussen enter en antwoord, in volgorde:
- Het chatvenster stuurt de vraag naar de server van de aanbieder of naar uw eigen WordPress-site.
- Daar wordt gezocht in uw eigen teksten naar stukken die bij de vraag passen.
- Vraag, gevonden teksten en uw vaste instructie gaan samen naar het taalmodel.
- Het model schrijft het antwoord, woord voor woord.
- Het antwoord reist terug en verschijnt in beeld.
Stap vier is bijna altijd de grootste. Een taalmodel produceert tekst in kleine stukjes achter elkaar, dus een antwoord van tweehonderd woorden duurt eenvoudigweg langer dan een antwoord van veertig. Dat is geen storing maar de aard van de techniek.
Oorzaak 1: te lange antwoorden
De meest voorkomende oorzaak, en gelukkig de makkelijkst te verhelpen. Staat er in uw instructie niets over lengte, dan schrijft het model uitgebreid. Zet er een maximum in, bijvoorbeeld tachtig woorden, met de toevoeging dat de bot mag doorvragen als er meer nodig is. U wint er zomaar een paar seconden mee, en de gesprekken worden bovendien beter leesbaar.
Oorzaak 2: te veel meegestuurde tekst
Bij elk gesprek stuurt het systeem uw instructie, de gevonden bronteksten en de hele gespreksgeschiedenis mee. Hoe meer dat is, hoe langer het model erover doet voordat het begint met schrijven. Wie tien lange pagina’s meestuurt in de hoop op betere antwoorden, krijgt vooral tragere antwoorden.
De oplossing is scherper zoeken: drie relevante fragmenten meesturen in plaats van tien complete pagina’s. Dat vraagt eenmalig instelwerk aan de kant van de zoekstap, maar het helpt aan twee kanten, want kortere context levert doorgaans ook preciezere antwoorden op.
Oorzaak 3: het gekozen model
Aanbieders bieden meestal meerdere modellen aan: een groot model dat beter redeneert en een kleiner, sneller model. Voor het beantwoorden van vragen over openingstijden, levertijden en retouren is het kleine model vrijwel altijd voldoende. Veel installaties staan standaard op het zwaarste model omdat dat in de demo het mooist oogde.
Wilt u het beste van twee: laat eenvoudige vragen door het snelle model afhandelen en schakel alleen bij ingewikkelde vragen over. Dat heet routeren en het is bij de meeste serieuze aanbieders in te stellen zonder programmeerwerk.
Oorzaak 4: de drukte bij de aanbieder
Hier houdt uw invloed op. Taalmodellen draaien op gedeelde apparatuur bij een handvol partijen, en op piekmomenten worden antwoorden merkbaar trager. U ziet dat vaak in de late Nederlandse middag, wanneer Europa en de Amerikaanse oostkust tegelijk actief zijn.
Wat u wél kunt doen: laat het chatvenster een eerlijke melding tonen als een antwoord langer dan enkele seconden duurt, in plaats van drie stipjes die eindeloos knipperen. En zorg dat er een tijdslimiet is, zodat een vastgelopen aanvraag netjes eindigt met “het lukt me nu niet, mag ik uw e-mailadres” in plaats van met stilte.
Oorzaak 5: het venster zelf vertraagt uw pagina
Dit is iets anders dan een traag antwoord, maar bezoekers ervaren het als hetzelfde probleem. Een chatwidget laadt scripts van een externe partij, soms een paar honderd kilobyte, en die concurreren met het laden van uw eigen pagina. Op mobiel merkt u dat direct.
Drie maatregelen die in de praktijk het meeste opleveren:
- Laad het venster pas na de rest van de pagina, of pas bij de eerste beweging van de bezoeker. Vrijwel elke aanbieder ondersteunt dat, al staat het zelden standaard aan.
- Zet de chat niet op pagina’s waar hij niets toevoegt, zoals de afrekenpagina of de bedankpagina.
- Meet het verschil, met en zonder venster. Een halve seconde op mobiel is veel bij een pagina die toch al drie seconden nodig had.
Dat zoiets echt gebeurt, laat het voorbeeld in een uitgewerkt geval waarin een chatvenster een volle seconde laadtijd kostte goed zien. De techniek eromheen verschilt niet van andere externe scripts.
Wat een realistische snelheid is
Voor een goed ingerichte opstelling op een Nederlandse site is dit ongeveer waar u op mag mikken: het eerste woord verschijnt binnen één tot twee seconden, en een kort antwoord staat er binnen drie tot vier. Duurt het structureel langer dan zes seconden, dan is er iets mis in de keten hierboven, meestal bij oorzaak één of twee.
Zorg ook dat het antwoord woord voor woord verschijnt in plaats van in één klap aan het eind. Technisch duurt het even lang, maar de bezoeker ziet dat er iets gebeurt en wacht daardoor merkbaar langer geduldig af. Dat is geen trucje maar gewoon nette vormgeving van wachten.
Tot slot: kijk niet alleen naar de chat. Als uw site zelf traag is, wordt elk onderdeel traag, ook een venster dat op zichzelf snel zou zijn. De reactietijd van uw server, uitgelegd in het verhaal over de tijd tot de eerste byte, telt bij elk verzoek mee. Wij nemen de snelheidsmeting daarom mee zodra er iets van AI op een site wordt gezet; wat daar verder bij komt kijken, staat bij AI-functies die op uw eigen hosting blijven presteren.
Praktische eerste actie: open uw site op een telefoon met mobiel netwerk, stel de bot een vraag die u vaak krijgt en tel hardop mee. Dat getal is uw uitgangspunt, en het is bijna altijd hoger dan het getal uit de demo.
