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 opeens… 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. Nou, laten we dit ticket samen ontcijferen.
Trouwens, voordat ik verder ga. Ik heb een geautomatiseerd testproject gemaakt in webdriverio voor demodoeleinden, maar ik zou aanraden om de hele blog te lezen om de metingen correct te interpreteren. https://gitlab.com/learnautomatedtesting/devtoolsperformancereporter
Kijk voor meer informatie over webdriverio (WDIO) op hun website https://webdriver.io/
Wat is Lighthouse
Lighthouse is een open-source, geautomatiseerde tool ontwikkeld door Google om de kwaliteit van webpagina’s te verbeteren. Het biedt prestatiestatistieken en audits voor toegankelijkheid, progressieve webapps, SEO en meer. Gebruikers gebruiken het op elke webpagina, openbaar of waarvoor authenticatie vereist is. 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, ik ben tot een subset gekomen waarin ik denk dat het nuttig kan zijn voor organisaties om tests op te zetten in cicd icw selenium
1. Eerste Contentful Paint (FCP)
Dit is het moment waarop uw 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 telt mee?)
- Rood licht: >3000 ms (tijd voor een motorcheck, mijn vriend!)
2. Grootste 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
3. Interactief
Op het moment dat 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
4. Cumulatieve lay-outverschuiving (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
5. MaxPotentialFID (eerste invoervertraging)
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
Integratie van XHR met vuurtorenmetingen
XHR staat voor XMLHttpRequest. Het is een web-API die beschikbaar is in webbrowsers waarmee webpagina’s asynchrone aanvragen kunnen doen aan servers zonder de pagina opnieuw te hoeven laden. Deze mogelijkheid is een fundamenteel onderdeel geweest van het creëren van dynamische, responsieve webapplicaties.
Waarom XHR-prestaties meten?
Gebruikerservaring: Langzame reacties kunnen leiden tot een frustrerende gebruikerservaring. Als een gebruiker na een actie lang moet wachten op feedback (zoals het klikken op een knop), kan hij of zij denken dat de site kapot of onbetrouwbaar is. Het meten van XHR-prestaties helpt bij het identificeren van knelpunten die de interactie met gebruikers kunnen belemmeren.
Efficiëntie van gegevensuitwisseling: Sommige XHR’s kunnen grote hoeveelheden gegevens ophalen of verzenden. Door deze te monitoren kan worden vastgesteld of er te veel gegevens worden uitgewisseld of dat optimalisatie nodig is om de payload te verminderen.
Afhankelijkheid van externe services: veel moderne toepassingen zijn afhankelijk van API’s en services. Als een van deze externe services traag of niet werkt, kan dit invloed hebben op de prestaties van de toepassing. Door XHR’s te monitoren, kunnen ontwikkelaars problemen met services van derden identificeren.
Serverprestaties optimaliseren: Als specifieke XHR-aanvragen constant lang duren, kan dit wijzen op problemen aan de serverzijde, zoals inefficiënte databasequery’s of problemen met de serverconfiguratie.
Nu we dit een beetje weten, hoe kunnen we dit allemaal meten in combinatie met CI/CD en testautomation, om een constante controle van uw auto te krijgen en te controleren of de hobbelige weg (XHR) nog steeds soepel rijdt
Laten we eens kijken naar het orangehrmlive-voorbeeld https://opensource-demo.orangehrmlive.com om via code te zien hoe dit kan worden gedaan. Allereerst gebruik ik webdriverio. Ik ben dol op wdio, het is voor mij het beste raamwerk 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, python
Voor de techneuten: wat heb je nodig!
Deze code gaat over het testen van de prestaties 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 - wat in feite webverzoeken zijn), en worden ook enkele andere statistieken met betrekking tot de prestaties opgehaald.
De belangrijkste functie is: CaptureandAggregatePerformanceData
Het legt verschillende prestatiestatistieken vast van de momenteel geladen webpagina en structureert deze. De stappen omvatten:
Een schermafbeelding maken. Navigatietijden ophalen, zoals wanneer de inhoud is geladen en de totale tijd die nodig is om de webpagina te laden. Andere statistieken met betrekking tot prestaties ophalen. Het structureren van deze gegevens om te worden opgeslagen.
Controleer alstublieft mijn gitlab-project om dit voor uw eigen doeleinden te gebruiken. De details worden daar uitgebreid uitgelegd en 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 vleugje knowhow ben je weer op weg naar groene lichten en soepel cruisen op de digitale snelweg.