De verkeerslichten van de digitale snelweg: een duik in Google Lighthouse en WDIO

webdriver io learn automated testing

Stel je voor dat je met je gloednieuwe virtuele auto (lees: ontwikkelde website) over de digitale snelweg rijdt. Je bent er vrij zeker van dat je motor geoptimaliseerd is en dat je banden de perfecte luchtdruk hebben. Maar plotseling… BAM! Je wordt aangehouden door de verkeersagent van Google Lighthouse.

“Wat heb ik verkeerd gedaan?”, vraag je je af, terwijl je in de achteruitkijkspiegel kijkt. Laten we dit ticket samen ontcijferen.

Voordat ik verder ga: ik heb een geautomatiseerd testproject gemaakt in WebDriverIO voor demonstratiedoeleinden, maar ik raad aan om de hele blog te lezen om de metingen correct te interpreteren. https://gitlab.com/learnautomatedtesting/devtoolsperformancereporter

Voor meer informatie over WebDriverIO (WDIO), kijk op hun website https://webdriver.io/

Wat is Lighthouse?

Lighthouse is een open-source, geautomatiseerde tool die door Google is ontwikkeld om de kwaliteit van webpagina’s te verbeteren. Het biedt performance statistieken en audits voor accessibility, Progressive Web Apps, SEO en meer. Gebruikers kunnen het inzetten op elke webpagina, of deze nu publiek toegankelijk is of authenticatie vereist. Lighthouse stelt een rapport op met bruikbare richtlijnen voor het verbeteren van de pagina. Het is toegankelijk via Chrome DevTools, een CLI of als een Node module. Er zijn zoveel statistieken die moeten worden gevalideerd dat ik tot een subset ben gekomen waarvan ik denk dat het nuttig kan zijn voor organisaties om tests op te zetten in CI/CD samen met Selenium.

1. First Contentful Paint (FCP)

Dit is het moment waarop je auto (website) de eerste tekenen van leven vertoont. In een perfecte wereld zou dit zijn alsof je auto binnen een nanoseconde opstart.

Groen licht: 0 - 1000 ms (je bent al weg voordat het licht groen wordt!)
Geel licht: 1000 - 3000 ms (misschien een paar seconden te laat, maar wie houdt dat bij?)
Rood licht: >3000 ms (tijd voor een motorcheck, mijn vriend!)

first contentfull paint learn automated testing

2. Largest Contentful Paint (LCP)

Dit is wanneer de hoofdinhoud van je website volledig zichtbaar is. Als je auto een film was, zou dit het moment zijn waarop de hoofdrolspeler zijn grote entree maakt.

Groen licht: 0 - 2500 ms
Geel licht: 2500 - 4000 ms
Rood licht: >4000 ms

largest contentfull paint learn automated testing

3. Interactive

Het moment waarop je website volledig interactief wordt. Vergelijkbaar met wanneer je auto soepel door alle versnellingen kan schakelen.

Groen licht: 0 - 3800 ms
Geel licht: 3800 - 7300 ms
Rood licht: >7300 ms

interactive learn automated testing

4. Cumulative Layout Shift (CLS)

Niemand houdt van een auto die onverwachts naar links of rechts uitwijkt. Dit meet de visuele stabiliteit van je site.

Groen licht: 0 - 0,1
Geel licht: 0,1 - 0,25
Rood licht: >0,25

cumulative layout shift learn automated testing

5. Max Potential FID (First Input Delay)

Hoe snel reageert je site op de eerste interactie van de gebruiker? Het is alsof je auto reageert op het moment dat je het gaspedaal aanraakt.

Groen licht: 0 - 100 ms
Geel licht: 100 - 300 ms
Rood licht: >300 ms

first input delay learn automated testing

Integratie van XHR en Fetch API met Lighthouse metingen

XHR staat voor XMLHttpRequest. Het is een web-API die beschikbaar is in webbrowsers waarmee webpagina’s asynchrone requests kunnen maken naar servers zonder dat de pagina opnieuw geladen hoeft te worden.

Naast XHR bestaat er tegenwoordig ook de modernere Fetch API, die een meer intuïtieve en promise-gebaseerde benadering biedt voor het maken van HTTP requests. Fetch heeft grotendeels XHR vervangen in moderne webdevelopment vanwege zijn eenvoudigere syntax en betere error handling.

Beide technologieën zijn fundamentele onderdelen van het creëren van dynamische, responsieve webapplicaties.

Waarom XHR en Fetch API performance meten?

User Experience: Langzame responses kunnen leiden tot een frustrerende gebruikerservaring. Als een gebruiker na een actie lang moet wachten op feedback (zoals het klikken op een button), kan hij of zij denken dat de site kapot of onbetrouwbaar is. Het meten van XHR performance helpt bij het identificeren van bottlenecks die de user interaction kunnen belemmeren.

Efficiëntie van data uitwisseling: Sommige XHR’s kunnen grote hoeveelheden data fetchen of verzenden. Door deze te monitoren kan worden vastgesteld of er te veel data wordt uitgewisseld of dat optimalisatie nodig is om de payload te verminderen.

Afhankelijkheid van externe services: Veel moderne applicaties zijn afhankelijk van API’s en services. Als een van deze externe services traag of niet beschikbaar is, kan dit invloed hebben op de performance van de applicatie. Door XHR’s en Fetch requests te monitoren kunnen developers problemen met third-party services identificeren.

Server performance optimaliseren: Als specifieke XHR of Fetch requests constant lang duren, kan dit wijzen op problemen aan de server-side, zoals inefficiënte database queries of problemen met de server configuratie.

Nu we dit weten, hoe kunnen we dit allemaal meten in combinatie met CI/CD en test automation, om een constante controle van je auto te krijgen en te controleren of de hobbelige weg (XHR/Fetch) nog steeds soepel rijdt?

Laten we eens kijken naar het OrangeHRM Live voorbeeld https://opensource-demo.orangehrmlive.com om via code te zien hoe dit kan worden gedaan. Ik gebruik WebDriverIO. Ik ben dol op WDIO - het is voor mij het beste framework als het gaat om het ondersteunen van betrouwbare geautomatiseerde UI tests in combinatie met Selenium en DevTools. Maar voel je natuurlijk vrij om hetzelfde te implementeren in Java, .NET of Python.

Voor de developers: wat heb je nodig!

Deze code gaat over het testen van de performance van een webapplicatie tijdens de interactie ermee. Het gebruikt WebDriverIO om met de browser te communiceren en het inlogproces te testen. Tijdens de tests wordt vastgelegd en geregistreerd hoe lang bepaalde acties duren (zoals XHR’s en Fetch requests - wat in feite web requests zijn), en worden ook enkele andere performance gerelateerde statistieken opgehaald.

De belangrijkste functie is: CaptureandAggregatePerformanceData

Het legt verschillende performance metrics vast van de momenteel geladen webpagina en structureert deze. De stappen omvatten:

Een screenshot maken
Navigation timings fetchen, zoals wanneer de content is geladen en de totale tijd die nodig is om de webpagina te laden
Andere performance gerelateerde statistieken fetchen
Het structureren van deze data om te worden opgeslagen

Controleer alsjeblieft mijn GitLab project om dit voor je eigen doeleinden te gebruiken. De details worden daar uitgebreid uitgelegd - vraag het gerust!

https://gitlab.com/learnautomatedtesting/devtoolsperformancereporter

Als je merkt dat je veel “rode lichten” hebt, wees dan niet bang! Onthoud dat elke weg (of website) zijn hobbels heeft. Met de juiste tools en een beetje know-how ben je weer op weg naar groene lichten en soepel cruisen op de digitale snelweg.