Tool gezocht om laadtijd te tonen (webapplicatie)

[NIMIC]

Mijn situatie
Ik ben business analist. Namens en met gebruikers doe ik acceptatietesten.
Hier hebben we een probleem met performance.

Graag wil ik op een duidelijke manier de performance duiden.
het gaat om een web applicatie.

Mijn vraag
Hoe kan ik tijdens een test makkelijk een timer laten lopen en weergeven?
Hebben jullie daar tooltjes voor?

Ik denk dan aan een timer die de tijd laat zien tussen muisklikken.
En dus niet aan technische informatie en analyse over wat er gebeurt, maar echt over gebruikerservaring.
Het gaat er dus om dat alle json calls ook afgehandeld zijn dan ook als binnen een pagina iets nieuws geladen moet worden.

Wat ik al gevonden of geprobeerd heb
Ik gebruik nu al een tool om mijn scherm op te nemen, maar om daarin het probleem te duiden is lastig.
Misschien zelf spreken en de secondes uitspreken.

Via de performance tab in de ontwikkelaarsmodus van de browser kun je natuurlijk al iets zien, maar dat is nogal bewerkelijk, en lastig te zien als het gaat om 20 stappen in een proces.

[BCC]

Filmpje met je telefoon maken?

[Masvic]

Type webapplicatie is nogal relevant; PWA?

Waar wil je de snelheid tonen, in de pagina of in een extern tooltje?

https://pagespeed.web.dev/

https://gtmetrix.com/

Etc...

[FuaZe]

Devtools in elk modern browser laat ook nog eens zien welke resource zo lang duurt om te laden.

[rnark]

Wellicht dev tools in combinatie met een schermopname? Je kan dan van begin tot eind het proces laten zien.

[NIMIC]

rnark schreef op woensdag 16 februari 2022 @ 16:20:
Wellicht dev tools in combinatie met een schermopname? Je kan dan van begin tot eind het proces laten zien.

Dat dacht ik ook, maar als een proces 10 keer klik is het met devtools vrij lastig te zien hoe lang ik als gebruiker van een applicatie moet wachten tot de volgende stap.
Als ik dan de volgende stap uitvoer wordt de tijd opgeteld, en is lastig te zien wat de tijd van de onderlinge acties waren.
Of heb ik het verkeerd gezien?

[loewie1984]

Je kunt met OSB Studio een screen capture maken van je test. Daarna eventueel zelf een timeline erin plakken met Shotcut opensource video editor. Mogelijk wat veel werk, maar tis maar een idee.

[NIMIC]

@loewie1984, daar heb ik idd ook aan zitten denken, maar dat vind ik inderdaad veel werk

Een screen capture maken doe ik regelmatig, dat is het probleem niet.
Ik ga nog eens een poging doen devtools, dat misschien in combinatie met een screencapture.

[SiErRa]

NIMIC schreef op woensdag 16 februari 2022 @ 16:22:
[...]


Dat dacht ik ook, maar als een proces 10 keer klik is het met devtools vrij lastig te zien hoe lang ik als gebruiker van een applicatie moet wachten tot de volgende stap.
Als ik dan de volgende stap uitvoer wordt de tijd opgeteld, en is lastig te zien wat de tijd van de onderlinge acties waren.
Of heb ik het verkeerd gezien?

Je kan in de meeste devtools ook pauzeren of alles verwijderen, zodat je iedere stap weer een zuivere meting hebt.

Maar als je een performance probleem hebt, dan zit dat meestal op specifieke punten in het proces, dat zie je in dev tools toch al snel aan lange balkjes. Of is het de optelsom van alles? Dat is namelijk een stuk lastiger aan te pakken.

[NIMIC]

SiErRa schreef op woensdag 16 februari 2022 @ 16:38:
[...]


Je kan in de meeste devtools ook pauzeren of alles verwijderen, zodat je iedere stap weer een zuivere meting hebt.

Maar als je een performance probleem hebt, dan zit dat meestal op specifieke punten in het proces, dat zie je in dev tools toch al snel aan lange balkjes. Of is het de optelsom van alles? Dat is namelijk een stuk lastiger aan te pakken.

Ik ben niet echt op zoek naar het probleem, dat is aan IT .
Het is inderdaad een optelsom van 100 js aanroepen bij het laden van een pagina, of het doen van een actie op een pagina wat oploopt tot 7 seconden van muisklik, tot het volgende scherm compleet geladen is.

Bedankt tot nu toe allemaal, ik ga nog even experimenteren morgen.

[BernardV]

Je zou eens kunnen kijken naar session recording, daar is commercieel genoeg over te vinden en ook wel self hosted.
Enige is of dat haalbaar is ivm gevoelige informatie.

//EDIT: Eerste hit die ik tegenkwam https://uxlens.com/
Geen idee of het wat is (heb er ook geen aandelen of wat dan ook )

[Voor 27% gewijzigd door BernardV op 16-02-2022 16:47]

[Turismo]

My 2 cents, als je reproduceerbaar en exacte/meetbare resultaten wil.
Run een tool als Jmeter ertussen https://jmeter.apache.org/

Wel enigzins verstand van programmeren nodig, maar het is niet hardcore programmeren.
Zijn hier wel wat goede guides te vinden als starting point: https://www.blazemeter.com/jmeter

Dit is ook wel een mooie oplossing, maar vereist wel iemand van redelijke kennis op gebied van test automation.
https://testcon.lt/2019/w...esting-With-WebDriver.pdf
https://hughmccamphill.co...ighthouse-and-webdriverio

Daarnaast raad ik aan om zoveel mogelijk je omgeving te isoleren van externe factoren zoals netwerk performance, andere gebruikers die op dezelfde host testen, caching etc.
Anders blijft het koffiedik kijken, want ene keer kan een klik wel langer duren, maar als er toevallig een netwerk dipje of veel gebruikers op dat moment op zaten zegt het nog niks.
Weet je uberhaupt bij welke load de performance degradeert en wat die host op papier moet aankunnen? want begrijp dat je met meerdere gebruikers er op test.

[Voor 61% gewijzigd door Turismo op 16-02-2022 17:24]

[bonzz.netninja]

Wij maken gebrtuik van debugbear en blazemeter hiervoor. Werkt prima.

[DJMaze]

@NIMIC ik denk dat je je te druk maakt.
Ik ontwikkel een webmail app en de ene keer laad ie in 150ms en de andere keer 3s.

Als ie 150ms kan maak ik mij niet druk. De 3s is dan gewoon de uitschieter bij 1000 simultane requests.

Stresstesting is heel belangrijk, dan weet je gewoon hoeveel bezoekers tegelijk je aan kan, want meer requests = langer wachten.
je moet even omdenken en stress tests schrijven voor elk json/websocket request.

(Nog maar te zwijgen over session (dead)locks)

[Voor 5% gewijzigd door DJMaze op 16-02-2022 18:49]

[DHH]

Je post in de devschuur dus ik wilde je ook Selenium als mogelijke oplossing meegeven. Selenium is een Python package die gebruikt kan worden om websites geautomatiseerd te bedienen, dus een pagina openen, navigeren naar een volgende pagina, een formulier invullen en verzenden etc. is allemaal mogelijk. Voor andere talen zijn er ongetwijfeld de nodige alternatieven te vinden.

Het automatiseren heeft als voordeel dat je meerdere keren dezelfde tests kan uitvoeren, bijv. op verschillende momenten om te zien of je op piekuren dezelfde performance haalt als tijdens daluren en je voorkomt (grotendeels) dat de eerste keer dat de (test)gebruiker de website test, hij/zij een tijdje moet zoeken om te zien op welke knop(pen) er gedrukt moet worden en de vervolgtests die veel sneller gaan omdat de gebruiker weet waar hij of zij moet kijken. Daarnaast is een voordeel dat je de tests ook later kan draaien om te zien of performance verandert als er aanpassingen zijn gemaakt.

Het nadeel is dat je het zal moeten programmeren en ook je programma zal moeten aanpassen als er (grote) wijzigingen in de webapplicatie plaatsvinden.

[mbaltus]

Op Enterprise (tool) niveau kom je dan terecht bij APM (application performance monitoring) of RUM (real user monitoring). Tools die dan tijdens de ontwikkeling en ook in productie kunnen helpen zijn onder meer NewRelic, Dynatrace, ...

[NIMIC]

Ik heb uiteindelijk een stopwatch gevonden die ik met een toetsencombinatie kan triggeren, en die bovenop applicaties weergegeven kan blijven worden.

Daar heb ik dan een screen capture van gemaakt.
Dankjewel voor jullie input.

[wvell]

Mooi om te horen dat je geholpen bent. Ik wil je toch nog even hierop wijzen: https://developer.chrome.com/docs/devtools/recorder/

Hiermee kun je gelijk een performance profiel maken welke je weer kunt exporteren voor je developers.