‘Perceived’, het woord betekent waargenomen. De term perceived performance is de waarneming, de eigen ervaring/interpretatie van performance. Wanneer we dan denken aan de performance van een applicatie, kan de vraag worden gesteld: Hoe wordt de performance van een (web)applicatie ervaren door een gebruiker? Maar hoe weten we eigenlijk wat een gebruiker ervaart, is dat niet subjectief?
Enige tijd geleden hield een collega een presentatie over dit onderwerp en dit heeft mij aan het denken gezet. Als perceived performance gaat over de beleving van een gebruiker, en dan met name van iedere individuele gebruiker, is dit dan wel iets meetbaars? Iedereen beleeft dingen immers op zijn eigen manier. Dat geldt niet anders voor performance, het kan voor iedereen iets anders betekenen. Zo kan ik me voorstellen dat wat oudere mensen misschien minder moeite hebben met iets tragere webpagina’s dan jongeren, die zijn opgegroeid met veel snellere hard- en software. Daarnaast gaat het niet alleen zo zeer over hoe snel een applicatie technisch gezien is, maar hoe de gebruiker de snelheid ervaart. Hoe snel de gebruiker denkt dat de applicatie is. Zit daar een verschil in? Wellicht zou dat niet zo moeten zijn, maar toch is het zo.
In het boek ‘High Performance Browser Networking’ (1) geeft Ilya Grigorik in 5 fases weer hoe men over het algemeen denkt over de snelheid van een applicatie, ongeacht het type applicatie of medium waarop hij gebruikt wordt. Een responstijd tot 100 milliseconden voelt als direct. Tot 300 milliseconden ervaart men als een kleine vertraging en tot ongeveer een seconde krijgt men het gevoel dat een machine echt iets aan het doen is. Nog langer begint men vervelend te vinden en bij zo’n 10 seconden heeft men het gevoel dat er iets verkeerd is gegaan. Zelf denk ik dat het de 5e fase de laatste jaren steeds korter op de vorige is gaan zitten, daar we gewend zijn geraakt aan steeds snellere computers en daarmee ook snellere software. De bekende F5 knop wordt al snel ingedrukt, of vensters worden zelfs al gesloten, als men een paar seconden moet wachten op een pagina. Wat er dus eigenlijk moet gebeuren is zorgen dat iedere gebruikersactie binnen een seconde of liefst binnen 300 milliseconden resulteert in de gewenste uitkomst. Maar sommige roundtrips hebben nou eenmaal meer tijd nodig. Denk aan backendcalls die allerlei informatie uit verschillende systemen moeten halen en daar vervolgens nog mee moeten rekenen of andere verwerkingen uit moeten voeren, voordat het in leesbaar formaat teruggestuurd kan worden naar het scherm van de gebruiker.
Hoe zorgen we er dan toch voor dat de gebruikerservaring goed is, ondanks het feit dat sommige acties trager zijn dan we zouden willen? In ieder geval is het duidelijk dat een gebruiker altijd zo snel mogelijk feedback wil hebben. Men moet het gevoel krijgen dat een systeem bezig is met de actie die geïnitieerd is, en dat het gewenste antwoord op de uitgevoerde actie spoedig komt. Een aantal simpele voorbeelden hiervan zijn:
- Voortgangsbalken die laten zien hoelang het nog duurt voordat er resultaat komt;
- Klikbare knoppen die de gebruiker het gevoel geven dat er daadwerkelijk een actie wordt uitgevoerd, wat anders overkomt dan klikken op platte tekst waarbij men eigenlijk niet weet of het verzoek wel verstuurd is;
- Het separaat tonen van bruikbare en minder bruikbare informatie, waarbij de bruikbare informatie dan natuurlijk ‘snel’ getoond moet kunnen worden;
- Het gebruik van progressive image rendering waardoor de gebruiker direct een plaatje van iets mindere kwaliteit in beeld ziet, welke steeds scherper wordt, in plaats van te moeten wachten tot deze volledig is geladen.
Bovenstaande punten kunnen ervoor zorgen dat de gebruiker het gevoel krijgt dat de applicatie sneller is dan in de tegengestelde gevallen, waar dat technisch gezien misschien helemaal niet zo is. Nog een mogelijkheid is om de gebruiker bezig te houden, zijn aandacht op iets anders te laten vestigen dan de actie waarmee hij bezig is. Een voorbeeld hiervan is het gebruik van zogenaamde ‘dummy content’. Tijdelijke content ter vervanging van de daadwerkelijke content die gepresenteerd moet worden. Zo gebruikt Facebook witte en grijze blokken en regels om te laten zien waar de afbeeldingen en teksten komen te staan als ze zijn geladen. Omdat het de gebruiker toch bezig houdt, al zijn het misschien slechts milliseconden, is de content in de beleving sneller geladen (2).
Wat ook nuttig kan zijn, zeker wanneer een gebruiker een bepaalde flow doorloopt, is om alvast informatie van een volgende pagina te laden, voordat een gebruiker daar naartoe navigeert. Vaak is men toch bezig met lezen of anderzijds opnemen van informatie. Als er geen afhankelijkheden zijn met een volgende pagina, kan deze informatie alvast worden opgehaald, om zo tijd te besparen in de beleving van de gebruiker.
De vraag of de impact van dergelijke oplossingen ook meetbaar is, is lastig te beantwoorden, want dat is per situatie verschillend. Het op de achtergrond laden van informatie die op andere pagina’s pas getoond wordt, zal zichtbaar zijn in de resultaten van een loadtest. Maar hoe het gebruik van klikbare knoppen ten opzichte van ‘gewone’ linkjes geïnterpreteerd wordt door een gebruiker is niet te meten. Wat wel van belang is, is om dergelijke inzichten en gedachtes mee te nemen in bijvoorbeeld frontend performance tests, waar collega Jeffrey al eerder over heeft geschreven (3). Ook kan het van toegevoegde waarde zijn om een groep eindgebruikers alvast hun mening te laten geven over de performance door gerichte vragen te stellen wanneer zij een GAT (= Gebruikers Acceptatie Test) uitvoeren.
Concluderend is het belangrijk om je ervan bewust te zijn dat er ook meerdere manieren zijn om de gebruikersbeleving te verbeteren dan alleen de verwerkingssnelheden te verhogen. Die zijn niet meer zo meetbaar als de tijd die het duurt om een response te ontvangen nadat een request is verstuurd, maar meerdere subjectieve metingen bij elkaar kunnen wellicht als objectieve meting worden beschouwd?