Een installatiebedrijf uit de regio Zwolle meldde zich met een klacht die u vaker hoort: de site voelde traag, terwijl er niets was veranderd. Er was inderdaad niets aan de site gebeurd. Wel was er in het voorjaar een gespreksvenster rechtsonder verschenen. Wat een chat widget website snelheid kan kosten, bleek in dit geval bijna een hele seconde.
Hieronder de meting, de analyse en wat we hebben aangepast. De cijfers komen uit dit ene traject; ze zijn illustratief, niet algemeen geldend.
De klacht en de eerste meting
De aanleiding was concreet: het aantal offerteaanvragen liep terug terwijl het bezoek gelijk bleef. Dat kan tien oorzaken hebben, dus we begonnen bij een nulmeting op mobiel, met een gesimuleerde trage verbinding.
Wat eruit kwam: het grootste element stond na 4,1 seconden in beeld, en de pagina reageerde pas na ruim een halve seconde op de eerste aanraking. Het totale gewicht was 2,6 megabyte, waarvan 1,1 megabyte JavaScript. Voor een site met vijftien pagina’s en weinig beeld was dat opvallend veel.
In de vergelijking met een meting van een jaar eerder, die gelukkig bewaard was, zagen we het verschil: het grootste element was destijds na 2,9 seconden zichtbaar. Er was dus 1,2 seconde bij gekomen.
Chat widget, website, snelheid: wat de analyse liet zien
In het netwerktabblad viel meteen op dat er verkeer naar vier externe domeinen ging die niets met de site te maken hadden. Alle vier hoorden bij dezelfde chatdienst: het hoofdscript, een instellingenbestand, een iconenset en een verbinding die openbleef voor het doorgeven van berichten.
Bij elkaar 780 kilobyte, en belangrijker: het script startte meteen bij het laden en hield de processor van het toestel ruim vierhonderd milliseconden bezig. In het prestatietabblad was dat een aaneengesloten blok waarin de pagina op niets reageerde.
Daar kwam iets bij dat de klant zelf al had opgemerkt zonder het te kunnen benoemen: het venster schoof na anderhalve seconde in beeld en duwde op mobiel de bel-knop naar boven. Bezoekers die op dat moment wilden klikken, klikten mis. Dat verspringen telt mee in de beoordeling die Google uitvoert, zoals beschreven in het overzicht van de drie meetwaarden.
De vraag die we eerst stelden
Voordat we iets aanpasten, wilden we weten wat de widget opleverde. Dat is een gesprek dat vaker gevoerd zou moeten worden, want een script schrappen dat omzet oplevert is geen winst.
Uit de statistieken van de chatdienst bleek dat er over vijf maanden achtenveertig gesprekken waren gevoerd, waarvan de meeste over lopende opdrachten en openingstijden. Ongeveer vier gesprekken hadden tot een aanvraag geleid. Niet niets, maar ook niet iets waarvoor u een seconde laadtijd over hoeft te hebben op elke pagina.
De klant wilde de chat houden, maar wel anders. Dat werd het uitgangspunt.
Wat we hebben aangepast
- De widget alleen nog op de pagina’s waar hij ertoe doet. Contact, de servicepagina en de offertepagina. Op blogartikelen en de startpagina verdween hij.
- Uitgesteld laden. Het script start pas nadat de bezoeker scrollt, de muis beweegt of het scherm aanraakt, of anders na vijf seconden. Voor een bezoeker die alleen even een telefoonnummer zoekt, laadt hij dus helemaal niet.
- Een vaste plek gereserveerd voor de knop, zodat er niets meer verspringt als hij verschijnt.
- De bel-knop op mobiel losgekoppeld van de chat, zodat die altijd op dezelfde plek staat.
- Openingstijden ingesteld in de chatdienst zelf: buiten kantooruren laadt de widget niet, want dan reageerde er toch niemand.
Het uitstellen was het meeste werk, en dat is precies het onderdeel dat u zorgvuldig moet testen. De aanpak zelf staat beschreven in de uitleg over uitgesteld laden van scripts.
Het testen kostte in dit geval meer tijd dan het aanpassen. We hebben op vier toestellen gecontroleerd of het venster nog opende, of een gesprek dat halverwege werd gestart netjes doorliep, en of de knop niet over het menu heen viel op een klein scherm. Dat laatste ging bij de eerste poging mis op een telefoon in liggende stand, wat u alleen ziet als u er daadwerkelijk naar kijkt. Reken bij dit soort ingrepen dus altijd een testronde mee in de planning.
Het resultaat
Na de aanpassing, gemeten op dezelfde manier en op dezelfde pagina’s: het grootste element stond na 2,7 seconden in beeld, het paginagewicht was gezakt naar 1,7 megabyte, en de reactietijd op de eerste aanraking lag onder de tweehonderd milliseconden. Het verspringen van de indeling was verdwenen.
In de maanden daarna liep het aantal chatgesprekken licht terug, van ongeveer tien naar acht per maand. Het aantal telefoontjes en formulieraanvragen steeg. Of dat één op één aan de snelheid ligt, valt niet hard te bewijzen: er waren in diezelfde periode ook twee nieuwe pagina’s gepubliceerd. We zeggen dus liever: het is beter geworden en het is niet slechter geworden door het uitzetten van de chat op de meeste pagina’s.
Wat de klant achteraf het meest verraste, was niet het cijfer maar de reden dat het zo lang onopgemerkt bleef. De widget was door een marketingbureau geplaatst, de site werd door een ander bureau onderhouden, en niemand had de opdracht om naar het geheel te kijken. Dat is het echte patroon achter dit soort trajecten: de vertraging ontstaat op de scheidslijn tussen twee partijen die allebei hun werk goed doen.
Wat u hiervan kunt meenemen
De les is niet “chatvensters zijn slecht”. De les is dat elk script van derden een prijs heeft die niemand op een factuur ziet, en dat u die prijs kunt meten voordat u besluit. Een widget die u tien gesprekken per maand oplevert, is prima, mits hij alleen laadt waar hij nodig is en pas wanneer de bezoeker er is.
Bij WebMaintor kijken we hier standaard naar tijdens een ronde waarin elk extern script tegen zijn opbrengst wordt afgewogen. In veel gevallen is er geen technische ingreep nodig, alleen een besluit over waar iets wel en niet hoort te staan.
Concrete volgende stap: kijk in de statistieken van uw eigen chatdienst hoeveel gesprekken er de afgelopen drie maanden zijn gevoerd. Weet u dat getal, dan kunt u pas een zinnige afweging maken over de laadtijd die u ervoor betaalt.
