Wat AI doet met de snelheid van uw site

Elk van die stappen kost tijd. Het opzetten van een verbinding met een nieuw domein kost al iets voordat er ook maar één nuttige byte binnen is, en op een mobiele verbinding is dat merkbaar. Daarna komt de omvang van het bestand zelf, en die valt bij chatvoorzieningen doorgaans tegen: het is niet zeldzaam dat een compleet chatvenster met alles erop en eraan een paar honderd kilobyte aan code meebrengt.

Belangrijker dan de omvang is wanneer het gebeurt. Een script dat wordt opgehaald terwijl de browser nog bezig is uw pagina op te bouwen, concurreert met alles wat de bezoeker daadwerkelijk wil zien. Wordt het pas opgehaald nadat de pagina staat, dan merkt vrijwel niemand er iets van.

Dit is dus geen AI-probleem maar een probleem van externe scripts in het algemeen. Wij zien exact hetzelfde patroon bij meetcodes, sociale knoppen en beoordelingswidgets; de uitleg over wat externe scripts met uw laadtijd doen geldt hier onverkort. Het verschil is dat een chatvenster meestal zwaarder is dan een meetcode.

Het moment waarop de pagina bruikbaar oogt

Als het chatscript vroeg wordt opgehaald, duurt het langer voordat de hoofdinhoud is opgebouwd. Op een snelle verbinding is dat een fractie; op een matige mobiele verbinding kan het oplopen tot een merkbaar deel van een seconde.

De reactie op de eerste klik

Zwaardere scripts houden de browser bezig. Tikt de bezoeker in die periode op een menu of een knop, dan gebeurt er even niets. Dat is de meetwaarde die het gevoel van traagheid het scherpst weergeeft, en het is ook de waarde waar chatvensters het vaakst in terugkomen.

Verschuivende opmaak

Een venster dat na twee seconden verschijnt en de inhoud eronder een stukje opzij duwt, telt mee als verschuiving. Dat is te voorkomen door de ruimte vooraf vast te leggen, maar dat gebeurt alleen als iemand erop let bij de installatie.

Welke waarden dit precies zijn en hoe u ze afleest, staat in de uitleg over de meetwaarden waarop pagina\'s worden beoordeeld. Voor deze pagina volstaat: meet voordat u het toevoegt, en meet er een week later opnieuw op dezelfde manier.

Uw bezoekers zitten voor een groot deel op een telefoon, en niet zelden op een toestel van een paar jaar oud met een verbinding die wisselt. Op zo\'n apparaat kost het uitvoeren van scriptcode veel meer tijd dan op uw laptop, en dat verschil is niet klein maar een veelvoud. Een script dat u een tiende van een seconde kost, kost daar makkelijk een halve.

Daar komt bij dat de schermruimte op mobiel schaars is. Een chatknop die op een groot scherm netjes rechtsonder staat, bedekt op een telefoon met enige regelmaat de bestelknop, het telefoonnummer of het onderste deel van een formulier. Wij komen dit vaker tegen dan u zou denken en het kost direct omzet.

De praktische conclusie is eenvoudig. Beoordeel de toevoeging op een echte telefoon, buiten uw kantoornetwerk, en doe dat op de pagina\'s waar het geld verdiend wordt: uw belangrijkste dienstpagina, uw productpagina en uw afrekenscherm. Wat daar aan vertraging bij komt, is de vertraging die telt. De rest is theorie.

Wat u dan in de pagina zet, is niet het complete script maar een knop die er precies zo uitziet als het eindresultaat. Klikt niemand, dan is er ook niets opgehaald en kost het onderdeel u vrijwel geen laadtijd. Klikt iemand wel, dan wordt het script alsnog opgehaald en gaat het venster een fractie later open dan anders. Die fractie merkt de bezoeker nauwelijks, want hij heeft net zelf de handeling gedaan die het opent.

De winst hiervan is groot, juist omdat het overgrote deel van uw bezoekers het venster nooit aanraakt. U verplaatst de kosten van iedereen naar de enkeling die er iets aan heeft.

Daarnaast zijn er een paar maatregelen die er standaard bij horen. Reserveer de ruimte voor de knop, zodat er niets verschuift. Zet het venster uit op pagina\'s waar het toch niet gewenst is, zoals een afrekenscherm. Haal de code op zonder de opbouw van de pagina op te houden. En kijk na of het onderdeel niet stilletjes lettertypen of afbeeldingen van een derde partij meebrengt, want dat is een veelvoorkomende verborgen post. Dit is hetzelfde werk als bij het terugbrengen van de laadtijd van uw pagina\'s in bredere zin; er is niets AI-specifieks aan.

Ten eerste loopt het verkeer in veel opzettingen via uw eigen site. Dat is met opzet zo gebouwd, want uw sleutel bij de aanbieder mag niet in de browser van de bezoeker terechtkomen. Het gevolg is dat elk gesprek een aantal aanvragen bij uw server oplevert, die daar elk een verbinding openhouden zolang het antwoord onderweg is. Op een goedkoop gedeeld pakket met een strikte limiet op gelijktijdige verbindingen is dat merkbaar bij drukte.

Ten tweede worden gesprekken vaak opgeslagen. Dat groeit gestaag in uw database en niemand ruimt het op tenzij dat is ingeregeld. Wij komen installaties tegen waar een chatgeschiedenis van jaren de grootste tabel op de site is geworden, met tragere back-ups als gevolg.

Ten derde botst dit soort verkeer met caching. Uw pagina\'s worden normaal gesproken kant-en-klaar bewaard en razendsnel uitgeserveerd, maar een chatverzoek is per definitie uniek en gaat er dus omheen. Bij een piek betekent dat meer werk voor de server dan de bezoekersaantallen doen vermoeden.

Niets hiervan is onoverkomelijk. Het betekent wel dat u dit onderdeel meeneemt in de keuze van uw hostingpakket in plaats van ervan uit te gaan dat het gratis meelift. Zet er in elk geval een limiet op per bezoeker per uur en een opruimtermijn voor oude gesprekken.

Doe dat op drie vaste pagina\'s: uw voorpagina, uw belangrijkste dienst- of productpagina en het scherm waar mensen tot actie overgaan. Meet mobiel, meet op hetzelfde tijdstip van de dag en bewaar de uitslag met datum erbij, bij voorkeur als schermafbeelding. Meet vervolgens een week na de installatie op precies dezelfde manier, met hetzelfde gereedschap.

Waar u naar kijkt, is niet één cijfer maar het verschil. Een tiende seconde erbij is te verdedigen als het venster daadwerkelijk vragen wegneemt. Een hele seconde erbij is dat niet, en dan is de vraag of het anders kan worden geladen of dat het beter helemaal weg kan.

Spreek dat vooraf af met uzelf en zet het op papier: wat is de grens die u accepteert. Zonder die afspraak wint het nieuwe onderdeel altijd, omdat het zichtbaar is en de vertraging niet. Wilt u zo\'n nulmeting laten doen, dan zit dat bij ons in een eerste doorlichting van hoe uw site er nu voor staat, en dat is ook los van AI zinvol.

Uw site is nu al traag. Staat er een laadtijd die op mobiel al pijnlijk is, dan verergert elke toevoeging dat. Eerst de bestaande achterstand wegwerken, dan pas uitbreiden. Dat is niet uitstelgedrag maar volgorde: het rendement van een seconde sneller is bij vrijwel elke site groter dan het rendement van een chatvenster.

Er staan al vijf externe scripts in. Meetcodes, sociale knoppen, beoordelingen, een afsprakenplanner. Elk daarvan is op zichzelf te verdedigen en samen vormen ze het probleem. Voeg er dan niet nog een aan toe zonder eerst op te ruimen.

U zit op een krap hostingpakket. Bij een goedkoop gedeeld pakket dat het bij drukte al zwaar heeft, is het toevoegen van verkeer dat niet uit de cache komt geen goed idee.

Uw belangrijkste pagina\'s zijn afrekenschermen. Daar telt elke afleiding en elke vertraging dubbel.

Dat wij dit hardop zeggen, betekent niet dat wij tegen zijn. Het betekent dat de volgorde vaststaat: eerst de basis, dan de uitbreiding. Wat wij daarna aan AI-onderdelen op een site aansluiten en hoe wij dat inrichten, leest u bij de manier waarop wij dit soort onderdelen toevoegen.