Blogg

Skapa ramar och mätpunkter för ditt digitala projekt med hjälp av en prestandabudget

  • 16 augusti 2017
  • 0

I en tid när det pratas om bredband och fiber som aldrig förr, så sker merparten av allt surfande via mobilen*. Samtidigt är det modernt med jättestora bilder överst på sidorna för att sätta en känsla. 

Artikelverktyg:

Vi har smidiga ramverk och kodbibliotek som gör att vi med relativ enkelhet kan skapa animationer och interaktivitet som skapar en upplevelse. Men vad händer när man besöker webbplatsen med hjälp av en mobil på ett tåg någonstans i skogen mellan två små orter i vårt avlånga land? Känslan att "jag aldrig kommer få läsa informationen jag söker", och upplevelsen av frustration? Det finns en paradox här.

If less is more; how you're keeping score?

Eddie Vedder

Jag tror de flesta konsulter vill leverera så mycket som möjligt för pengarna (och tilldelad tid), men vad händer om användaren inte alls vill ha mer? Och hur kan man väga värdet av hastighet och relevans mot ett stort utbud av funktioner, information, möjligheter och en polerad yta?

Det är här en prestandabudget kommer in i bilden. I korthet handlar det om att sätta upp ett antal ramar och mätpunkter som varje beslut ska vägas mot. På samma sätt som man gör när man sätter den ekonomiska planen för ett projekt.

När prestandabudgeten är på plats kan man ställa alla beslut mot budgeten. Redan i konceptfasen kan man prioritera vilka tredjepartskopplingar man behöver. I designfasen kan man överväga värdet av stora detaljerade bilder över hela skärmen. Front-end-utvecklare kan prioritera vilka tredjepartsbibliotek som ska användas, backendutvecklare kan ställa begränsad ekonomisk budget mot prestandavinsterna i att bygga upp en avancerad cachning.

Själva prestandabudgeten behöver inte vara alls speciellt avancerad, den skulle till exempel kunna formuleras som:

"Ingen sida ska ta mer än 10 sekunder att ladda ner på en 2G-uppkoppling."

Man kan såklart göra den mer detaljerad och sätta siffror på "tid för första rendering", "tid för tills användaren kan navigera sidan" och så vidare. Vissa lägger även in andra mätpunkter som rör prestanda i den bredare bemärkelsen (inte bara hastighet) som: "Alla sidor ska funka även om alla externt inlänkade resurser inte laddas", "Alla sidor ska få över X värde av tillgänglighetsgransningstjänsten Y".

Jag kommer dock att fokusera på hastighet i detta inlägg då det är det vanligaste användningsområdet.

Mäta, ändra, mäta och utvärdera

För att ha verklig nytta av en prestandabudget måste den vara mätbar. Jobbar man med en befintlig sajt är det viktigt att göra en nollmätning av sina mätpunkter för att ha nåt att jämföra med (annars vet man inte vad ens insatser hade för effekt). Gör man en ny webbplats från scratch så ska man se till att få upp mätdata så fort man har något som alls går att mäta på, om det så är en prototyp, ett API eller vad man har. Men tänk på att även om man bygger en ny webbplats så finns det oftast en webbplats man ersätter. Det vore ju pinsamt om man presterade sämre än kundens webbplats från 2001.

När man sedan lagt till en funktion eller gjort en ändring så gör man en ny mätning och utvärderar om det hade en försvarbar "kostnad" för budgeten. Om det visar sig för kostsamt så får man antingen optimera, eller prioritera om. Kanske det inte var så viktigt med ett flöde med facebookposter trots allt?

Prestandamätningar bör även vara en del av Definition of Done (DoD), med andra ord: Har din funktion övertrasserat prestandabudgeten så är du helt enkelt inte klar ännu. På så vis får man en rutin att hantera prestanda-problemen när de uppstår.

Förvaltning

Prestandabudgeten bör leva vidare även efter leveransen, när projektet går över i förvaltning. Förutom att man brukar man lägga till nya funktioner efter hand, så händer det att företaget byter grafisk profil, eller att man (som vi verkligen får anta) lägger till ny information och nya bilder. Dessutom kanske ens företag blir jättepopulärt så att den rena mängden besökare får webbplatsen att gå långsamt.

Om man har ett automatiserat system för att göra mätningarna så kan man tidigt hitta problem, och enkelt åtgärda dem innan användarna ens märker nåt. Kanske är det en redaktör som har lagt upp en 14-megapixelbild på VD:n på kontaktsidan, kanske gick prenumerationen på tredjeparts-teckensnittet ut?

Man har själv sällan skäl att besöka sin egen externwebb, så det kan bli en väldigt lång period som användarna ger upp medan inte ens VD:ns lugg är inladdad.

Verktyg och tester

Jag ska inte gå in allt för mycket på detta, men det finns ett antal olika verktyg som kan hjälpa en, lite beroende på vilken fas i projektet man är, och vilken roll man har.

Ett enkelt sätt att testa en webbplats är med Google PageSpeed Insights. Även om kanske inte alla deras mätmetoder är helt relevanta ger det en fingervisning

Pingdom är ett annat bra verktyg som man kan använda för kontinuerlig övervakning.

I min roll som gränsnittsutvecklare använder jag ofta Fiddler för att simulera modem-hastighet och testa vad som händer om något blockas eller tar lång tid på sig.

Det finns även en hel del testfunktioner inbyggt i Chrome: Device mode.

Summering

You think you have to want more than you need; Until you have it all you won't be free.

Eddie Vedder, igen

Prestandabudgeten kan vara ett utmärkt verktyg för att värdera det lilla, att motivera återhållsamhet och kvalitet. Med en terminologi som är bekant för de som beställer (och styr projekten). Användaren kommer inte uppleva att de får mindre, snarare mer då de slipper vänta.

Så föreslå gärna en prestandabudget när du ska beställa nästa gång!

Vill du veta mer om hur vi på NetRelations arbetar med den här typen av frågeställningar?

Tveka inte att ta en kontakt med oss via formuläret.

Mobile and tablet internet usage exceeds desktop for first time worldwide

0 kommentarer

Skriv kommentar