En av utmaningarna med prestandatester av webbsidor är bland mycket annat att korrekt simulera besökarnas beteenden. Inom prestandatest kallar man detta för scenarion och skript, men det är egentligen en anpassad form av testautomatisering. Ett verktyg som utför ett (eller ofta flera) fördefinierat test används för att med automatik enligt ett visst mönster och beteende besöka en webbsida eller en webbapplikation och utföra ett antal moment, som valideras för dess funktionalitet, samt för syftet av prestandatester, mäter vi svarstiden för hur lång tid det tar att utföra dessa moment.
Men till skillnad mot testautomatisering med syfte att validera funktionerna på webbplatsen är syftet under prestandatester att på något sätt simulera riktiga besökare, och här blir det ofta lite klurigt. För vad gör de riktiga besökarna på webbsidan egentligen?
Här kan man nyttja dels de analysverktyg som finns tillgängliga, som tex genom att analysera webbserverns access loggar. I dessa loggas vad varje användare har hämtat ner för resurser från vår webbserver. Men för att få ut nånting vettigt av dessa, som svarstider eller i vilken ordning vilka sidor besöks oftast, måste vi slå på ganska mycket extra loggning vilket i sin tur kan slöa ner webbservern, då det kostar en del CPU och disk IO att logga allt detta. Som alternativ finns då några gratis tjänster på nätet man kan använda, som via ett enkelt litet javascipt loggar besökarnas trender till ett separat webbsystem. Google Analytics är ett exempel på dessa.
Men prestandatester vill man ju göra innan man går live med en ny sajt, så vad får man ut av detta då? Man kan ju önska att alla som redan är i drift med sina sajter kunde dela med sig lite av sin statistik. Just detta försöker Google åstadkomma. Jag fick nyligen en första rapport av Google, där de även hade jämfört trenderna för 2010 och 2011, vilket pekar på några intressanta resultat;
| 2010 | 2011 | Diff | |
| Pages/Visit | 4,9 | 4,5 | -0,4 |
| Bounce Rate | 48.2% | 47.0% | -1,20% |
| Avg. Time on Site | 05:49 | 05:23 | -0:26 |
| Think Time (s) | 71,22 | 71,77 | 0,55 |
Tabellen visar några intressanta mätvärden som vi har nytta av under prestandatester av en sajt vilka vi får från statistikverktyget. En första anblick säger att skillnaden mellan just 2010 och 2011 inte är så stora, och det ger lite mera tyngd för att kunna använda dessa data som en form av baseline för andra sajter. Värdena ovan är genomsnitt för alla sajter på Google Analytics vilka deltar i Shared Data programmet (ett antal hundra tusen i dagsläget).
De första 3 värderna kommer direkt från Google Analytics och det fjärde, Think Time har vi räknat fram genom att dela totala tiden på sajten med antalet sidor som har besökts.
Det första värdet Pages per visit visar i snitt hur många sidbesök vi bör genomföra per iteration av ett skript under våra tester. Det andra, Bounce Rate visar hur ofta en besökare endast laddar ner en enda sida (oftast en artikel eller startsidan) och sedan lämnar sajten. Detta inträffar mer frekvent på sajter som låter sig indexeras, och är oftast ett besök på endast startsidan, men kan även vara en besökare som hittat en sida som sökresultat på tex Google eller Bing och läser endast den hittade sidan. En bounce är mycket tyngre i det avseendet att det ofta leder till en så kallad complete page download (inget är cachat i webbläsaren) samt att det i vissa fall kan vara en slumpmässig vald sida eller artikel på sajten (dvs webservern har den troligen inte i sin cache heller utan måste läsa från disk). Detta mäts såklart också under så kallad ”Referrer statistics” där vi ser hur besökare hittar till sajten. ”Direct” innebär att de mer eller mindre knappade in adressen i webbläsaren eller har ett bokmärke och därmed hamnar troligen på startsidan. Kommer de däremot från Google eller Bing är det via en sökning.
Dessa olika beteenden simulerar man enklast med 2 olika skript, det ena som simulerar bounce rate (tex startsidan och/eller 1 slumpmässig sida) och det andra som simulerar i snitt 4,5 sidbesök. Enligt statistiken ovan för 2011 ska då alltså cirka 47% köra vårt bounce rate skript och resterande vårt klicka runt skript (med i snitt 4,5 sidor). Hur besöker man då 0,5 sidor? Jo, varannan gång. Alternativt gör vi två skript av detta med, ett med 3 sidor och ett med 6 sidor som körs av lika många användare (3+6)/2 = 4,5.
Average Time on site samt framför allt Think Time är viktiga parametrar då dessa är nödvändiga att specifiera i ett prestandatest, då detta återspeglar den simulerade betänketiden som vi ska ha mellan klick eller sidbyten i ett skript. Självklart varierar detta rejält från besökare till besökare, och därför kan de flesta verktyg utföra en normalfördelning eller en slumpmässig variation på denna betänketid för att på så sätt även simulera spikar/toppar och dalar under testet.
Vi kan även använda denna betänketid för att transformera andra mätvärden som ett prestandatestverktyg samlar in. Tex mäter man ofta lasten som genereras under ett test i form av Sidor per sekund som laddas ner av virtuella användare. Om vi tex under ett test påvisar att en webbapplikation klarar som max 160 sidor per sekund innan tex nätverket eller CPU blir en flaskhals, kan vi alltså räkna fram ett besökarantal som skulle krävas för att generera denna last, nämligen 160 * betänketiden (vilket med snittvärdet för 2011 ovan innebär 11 483 samtidiga besökare).
72 sekunder betänketid kan tyckas vara en hög siffra, och denna varierar så klart från användare till användare (första gångs besökare, ovana och vana besökare mm) samt även sajtens struktur och design. Ju mer det finns att läsa och begrunda på en sida, ju högre blir betänketiden. En webbapplikation för aktiehandel eller en internetbank kommer tex att ha ett annat mönster (tex neråt 45-50 sekunder) än tex ett digitalt magasin eller en tidning.
Slutligen, nu när vi vet ungefär hur många besökare och hur ofta de gör något på en sajt, återstår att spegla vad de faktiskt tittar på eller gör på en sajt. Är sajten redan i drift eller kanske en äldre version av sajten är det, kan verktyg som Google Analytics såklart även visa hur ofta besökare gör vad på sajten. Det var det ursprungliga syftet med dessa verktyg. Har man inte tillgång till detta, kan man ändå använda genomsnitts statistik, som bounce rate ovan, för att bygga ett rimligt mönster. Det är inte ovanligt att startsidan på en sajt står för över hälften av alla sidbesök. För att sedan fylla på med ytterligare 3,5 klick (för att komma upp i 4,5) så får man leka lite beteendevetare, och titta på startsidan och bedömma vad som kan vara rimligt.
Avslutningsvist listar jag några alternativa produkter till Google Analytics;
WebTrends (http://webtrends.com/) är en av de marknadsledande produkterna som man kör helt och hållet själv, antingen direkt på webbservern eller på en separat server. Allt insamlat data behålls därmed in den egna infrastrukturen. Banker, försäkringsbolag och statliga myndigheter använder ofta en sådan lösning då den även har mycket kraftfulla funktioner för att kunna anpassas till sin egna webbapplikation, för att tex mäta User Stories eller Användningsfall istället för endast sidorna.
Ett opensource alternativ till WebTrends och Google Analytics är Piwik (http://piwik.org/) vilken man liksom WebTrends driftar själv och har därmed full tillgång till datat och integrationer men även källkoden för att kunna göra anpassningar.
Slutligen finns det även produkter som inte kräver en javascript kod på websidan (vilket de ovannämnda gör) utan ger sig på webbloggarna på servern istället. Några sådana är tex opensource baserade webalizer (http://www.mrunix.net/webalizer/) samt Windows programmet Web Log Expert (http://www.weblogexpert.com/) vilken även har bra stöd för att skapa egna filter och analyser av beteenden och de vanligaste flöden som besökare genomför.
Förutom dessa finns det en uppsjö av liknande produkter och färdiga tjänster på internet och många CMS leveratörer tillhandahåller även en egen anpassad sådan till sina produkter.
En av nyheterna i de nya webbläsarna (IE9 och FF9) är att javascript numera även kan komma åt svarstider, både DNS tid, nätverk, server svarstider samt renderingstider på ett standardiserat sätt. Några av de större analysverktygen som Google Analytics och WebTuna har redan börjat använda dessa mätvärden i sina tjänster. Men det förtjänar en egen artikel som kommer snart!
Uppdatering: Artikeln är nu skriven och heter Samla in svarstider från användarens webbläsare.
