Chat widget 100% pagespeed

Hoe werkt een chat widget?

Een chat widget komt meestal in de vorm van een stukje JavaScript code. Je voegt deze code toe aan de HTML van je webpagina. Zonder zelf te hoeven programmeren, zie je automatisch een chat widget op je pagina verschijnen.

De JavaScript die de chat widget aanmaakt, doet dit door 1, 2 of zelfs 3 iFrames op je pagina te plaatsen. Een iFrame is een mini-webpagina die in jouw pagina is ingesloten. De chat draait niet op jouw site, maar via de site van de chat plugin zelf. Er wordt een verbinding gemaakt tussen het iframe en de chat server die de gehele chat afhandelt.

Impact van een chat widget op de lighthouse score

Het laden van het chat iframe is vaak een relatief dure aangelegenheid. Binnen jouw pagina moet een nieuwe chatpagina worden geladen. Deze chatpagina vereist vaak veel javascript en dat kost tijd om te laden en uit te voeren. Al met al heeft dat een aanzienlijke impact op je lighthouse score. Bijvoorbeeld: onze lighthouse score daalde met maar liefst 35 punten:

1. Speed index +3.6sec
2. Time to interactive +10.9sec.
3. Total blocking time +1 sec.

Hoe verbeter je de lighthouse score met een chat widget

Veel webmasters denken dat een chat widget de pagina simpelweg vertraagt en dat daar niets aan te doen is omdat ze weinig controle hebben over de chat widget. Ze hebben deels gelijk. Het stukje javascript dat je in je site moet plakken veroorzaakt niet direct de vertraging. De JavaScript initieert een reeks acties op je pagina. Die acties vertragen de webpagina en inderdaad: daar heb je weinig invloed op.

Daarom moeten we slim zijn en om het probleem heen werken. Er is geen alternatief. We zullen ervoor moeten zorgen dat de chat widget het renderen van de pagina niet hindert. De chat widget moet worden uitgevoerd nadat de 'main thread' van je browser klaar is met het laden en renderen van de pagina.

We bereiken dit door de JavaScript functie setTimeout() en het page load event te gebruiken. Het load event wordt afgevuurd wanneer HTML, CSS en JavaScript zijn geladen en geparset. De setTimeout() functie voert een gegeven commando uit na een aantal milliseconden. Dit voorbeeld: setTimeout(function(){alert('test')},4000) toont een alert in je browser na 4 seconden (of 4000ms).

We kunnen het load event en de setTimeout functie gebruiken om het renderen van de chat widget te vertragen tot 1500ms nadat de HTML, CSS en JavaScripts zijn geparset. Op dit moment zijn we er vrij zeker van dat de main thread van de browser inactief is.

Eerst moeten we de chat widget in een functie verpakken. En vervolgens deze functie 1500ms na het load event aanroepen, wanneer de main thread hoogstwaarschijnlijk inactief is. Wanneer we dit implementeren voor de facebook chat plugin op deze pagina krijg je uiteindelijk deze code

var _x = function(d, s, id) {
    window.fbAsyncInit = function() {
        FB.init({
            xfbml: true,
            version: 'v8.0'
        });
    };
    var js, fjs = d.getElementsByTagName (s) [0];
    if (d.getElementById(id)) return;
    js = d.createElement(s);
    js.id = id;
    js.src = 'https://connect.facebook.net/en_US/sdk/xfbml.customerchat.js';
    fjs.parentNode.insertBefore (js, fjs);
};

setTimeout(function() { _x(document, 'script', 'facebook-jssdk') }, 4000);

Je kunt deze truc toepassen voor elke chat plugin die er is. Het vereist wat handwerk en je kunt bijvoorbeeld geen WordPress plugins gebruiken. Kom je er niet uit? Ik help je graag!

Hebben we nu alle pagespeed problemen opgelost?

Wanneer een chat widget op de bovenstaande manier laadt, krijgen we een 100% Lighthouse score voor onze chat widget. Betekent dit dat we alle pagespeed problemen hebben opgelost?

Ja, gedeeltelijk, maar niet helemaal. We gebruikten progressive rendering om de belangrijkste delen van de pagina vroeg tijdens het laden van de pagina te laden, terwijl we de minder belangrijke delen (de chat widget) naar het einde van de laadcyclus duwden. Belangrijke metrics zoals de LCP (Largest Contentful Paint) en de FCP (First Contentful Paint) verbeterden aanzienlijk omdat we de chat widget uit het 'critical rendering path' hebben verwijderd. Hierdoor kan de browser eerder de 'blocking mode' verlaten, wat de initiële blocking time aanzienlijk verlaagt.

Daarna wordt het een ander verhaal. Door de chat widget naar het einde van de laadcyclus van de pagina te duwen, valt deze buiten de lighthouse meting. Zodra de chat widget begint te laden, wordt de main thread van de browser geblokkeerd. De pagina is even niet meer interactief. De impact van dit gedrag hangt af van de chat widget. De meeste populaire chat widgets zullen de pagina niet merkbaar blokkeren wanneer ze later worden uitgevoerd.

Chat widgets zijn zo gebouwd dat ze per definitie een pagespeed vertraging veroorzaken. Om een pagina te versnellen moeten we keuzes maken. Die keuzes zijn nooit perfect. Het terugduwen van de chat widget naar het einde van de laadcyclus resulteert in een veel eerdere LCP en FCP, aan de andere kant zijn sommige snelheidswinsten voor interpretatie vatbaar.