Det finns väldigt mycket att tänka på när man designar en webbplats, och massor med förslag på checklistor för att man inte ska missa något. Ett inte helt ovanligt arbetssätt för att bevisa att det nya är bättre än det gamla kallas för nollmätning. En nollmätning går ut på att göra en utvärdering av nuläge, för att vid ett senare tillfälle förhoppningsvis kunna konstatera att det nya nuläget är ett steg i en positiv riktning.
Just nu pågår diskussioner om hur nästa version av 1177 Vårdguidens webbplats ska se ut. Som ett inspel i den diskussionen har jag gjort en nollmätning från en webbanalytikers synvinkel. Jag har alltså grävt fram statistik om det som hamnar i våra besökares webbläsare, hur snabbt det går, hur användbart det är, osv.
Förutom att en sajt ska vara tillgännglig för alla oavsett eventuell funktionsnedsättning (lagkrav sedan 2015), ska gå att drifta till en försvarbar summa så är det viktigt att inte slösa med besökarens tid och uppmärksamhet.
Är verkligen hastighet på webben ett klokt mål?
Kort svar: JA! Man kan nog förutsätta att man vill nå ut med sin webbplats, att få den använd. Vi i offentlig sektor har ju annars svårigheten med målformulering att vi oftast inte har ett ekonomiskt incitament varken på webben eller bortanför tangentborden. Därför är det lite svårt att sätta ett exakt värde på varje enskilt besök på våra webbplatser.
Det finns organisationer som kollat upp vad en ganska liten skillnad i hastighet på webben gör för skillnad, se nedan lista. Du som vill efterforska kan alltid klicka på länkarna och nörda ner dig ordentligt.
- Google: 2% långsammare = 2% färre sökningar per användare
- Yahoo: 400 millisekunder snabbare = 9% mer trafik
- AOL: Snabbare sidor = fler sidvisningar
- Amazon: 0,1 sekunder snabbare = 1% mer omsättning
- Shopzilla: 5 sekunder snabbare = 25% fler sidvisningar, 7 till 12% mer omsättning
- Aberdeen Groups rapport från november 2008 – ”The performance of web applications”: 1 sekund långsammare = 11% färre sidvisningar, 7% färre konverteringar
- Google har med webbprestanda i sin rankningsalgoritm
Med andra ord är en långsam webbplats mer meningslös jämfört med om den vore snabb. Det gäller även för oss som inte säljer något på webben.
Som om inte det vore nog så har forskning utförts för att kolla vad som händer med en typisk användare under en interaktion med ett datasystem. Om återkoppling sker inom 0,1 sekund upplevs det som omedelbart. Dröjer det mer än en sekund börjar användaren uppleva att hen väntar och tankeflödet är inte längre helt fokuserad på uppgiften. Efter 10 sekunder har man tappat bort sin användare mer eller mindre fullständigt.
Man kan, anser jag, dra det så långt som att en långsam eller icke-optimal webbplats orsakar en kollektiv funktionsnedsättning på användarna, eller gör en befintlig ännu värre!
Så frågan är hur långsam en webbplats får vara under sämsta tänkbara användningsscenario? Jag drar ofta exempel från när jag är i svampskogen i natursköna Dalsland, där man i dessa sammanhang inte uppskattar radioskugga eller dålig täckning på 4G-nätet. Eller för den delen när jag är mitt i smeten bland massor med andra, som på konferens eller festival, när mobilnätet istället är överbelastat.
Hur ser mobilnätet ut i ditt upptagningsområde? Kolla in bredbandskollen.se så kan du få färska siffror. Tänk dock på att kolla efter pessimist-siffrorna, att det går snabbt på en fiberuppkoppling vet vi nog redan 🙂
Nuläge för 1177.se/Vastra-Gotaland/
Först och främst vill jag poängtera att de siffror jag grävt fram på inget sätt är dåliga. Jag har (på min fritid) sedan 2011 granskat 61 000 webbsidor på motsvarande sätt, så jag tycker att jag har data att backa upp det påståendet.
Metoden för denna nollmätning är först och främst att jag plockat fram de tusen mest besökta sidorna under hela 2015 på Västra Götalandsregionens del av 1177.se – detta kan man exportera från webbstatistikverktyget Google Analytics som används nationellt.
Steg för steg för detta finner du i bilderna nedan.
Sedan har jag kört dessa tusen webbadresser mot ett verktyg Google erbjuder, närmare bestämt Pagespeed. Det går att använda det verktyget manuellt, men jag har skrivit ett litet program som gör det åt mig. Du som är tekniskt lagd kan kolla in default.py på mitt Github-konto ›
Pagespeed letar upp förbättringspotential främst för att snabba upp en webbplats, men kollar också efter några vanliga användbarhetsproblem. Anledningen till detta arbetssätt är att inte diskutera personliga anekdoter om vilken sida man har för sig var trög eller snabb. Genom att kolla massor med sidor får man mer trovärdig data och kan lättare identifiera mönster bland de förbättringar man kan göra.
Statistik om en genomsnittlig sida på 1177.se/Vastra-Gotaland/
- 2 Mb CSS, det vill säga kod som styr utseendet.
- 0,6 Mb Javascript, det sköter interaktion mellan webbplatsen och användaren.
- 0,19 Mb bilder.
- 0,1 Mb HTML, vilket är själva innehållet och dess struktur.
- 98 tecken lång sidtitel, alltså texten som syns i flikar i webbläsaren eller som klickbar text i sökmotorer.
- 10 st olika CSS-filer för att styra utseendet.
- 5 st Javascript-filer.
- 30 st filer allt som allt för en sidvisning.
Nördfakta: Dessa siffror återspeglar okomprimerad mängd. Textfiler kan packas mycket effektivt, men inte bra nog för att problemet ska försvinna. Referens till värdena finns hos Google Developers ›
Vill man sätta dessa siffror i relation till en användares upplevelse så kan man kolla in tjänster som webpagetest.org, eller lite mindre nördiga siffror på Pingdoms full page test. En snabb förklaring är att de 30 filerna som ska skickas kan försena hämtningen av sidan med en halv minut om det är en långsam mobiluppkoppling som används, minskar man antalet filer minskar just den långsamheten. Inom den måttstocken kan jag som före detta webbutvecklare tycka att det är lite slappt eller ogenomtänkt att ha 10 st CSS-filer, det räcker utmärkt med en enda.
Tänkte inte gå in på innehållsanalys i detta inlägg, men notera att den genomsnittliga längden på sidtitlarna är 98 tecken. Här kommer en ”ny” utmaning, nämligen att få plats med sin sidtitel inom webbläsarens flik. Som du ser på bilden intill får inte ens 30 tecken plats, då gäller det att hushålla och skriva det viktigaste först. Det gäller att man inte fortsätter att leva efter utdaterad praxis inom sökmotoroptimering, något som är lätt hänt då det ständigt förändras. Praxis just nu är inom sökmotoroptimering (SEO) är att en sidtitel ska ha viktigaste orden så tidigt som möjligt och att längden ska vara mellan 50-70 tecken lång. Här har man alltså anledning till uppföljning med jämna mellanrum och uppdatera sina redaktörshandböcker.
På köpet med Pagespeed får man också ett betyg, en siffra på hur bra Google anser att sidan är. Det är en siffra mellan 0 och 100, där 100 är toppbetyget. De tusen sidorna som kollats hade i genomsnitt följande betyg mätt från en mobilanvändares perspektiv:
- 98.9 av 100 i användbarhet.
- 50.7 av 100 i snabbhet för en mobilanvändare.
Att inte ha toppbetyg i användbarhet på alla sina sidor är förståeligt. Frågan infinner sig dock hur lågt man tycker det är ok att gå? Genom att inte ha toppbetyg lägger man krokben för sina användare – kanske illa nog för att det ska klassas som diskriminering av de med funktionsnedsättning. Ett väldigt vanligt problem även välbyggda sajter har kring användbarhet är att klickbara saker ligger för tätt inpå varandra. Det innebär att det kan vara svårt att träffa rätt sak för de med motoriska svårigheter, samma sak för den på en skakig bussresa.
För att sätta snabbhetssiffran i perspektiv så har VGRs egna prestandabudget satt 85 av 100 som lägsta acceptabla nivå för vår nästkommande externwebb. Att sikta högt på detta område är lättare när man bygger nytt jämfört med att putsa på en befintlig webbplats.
Inte nog med detta, i samma körning får man även en subjektiv bedömning om vad som är bäst och sämst. Här vill man ha en så låg siffra som möjligt då den indikerar vad som sinkar upplevelsen. Högst upp är våra utmaningar, längst ner det vi briljerar på:
- Inte blockera sidvisningen – 63
- Aktivera komprimering (GZip) – 13
- Använda bufferminnet i webbläsaren – 11
- Prioritera synligt innehåll – 9
- Förminska HTML-kod – 4
- Optimera bilder – 3
- Långsamma svarstider på webbservern – 2,5
- Förminska CSS-kod – 2
- Se till att innehåll ryms på mobil skärm – 0,64
- Förminska Javascript-kod – 0,38
- Tillräckligt stor klickyta – 0,28
- Inte kräva webbläsartillägg (som Adobe Flash, Microsofts Silverlight och liknande) – 0,02
- Undvik hänvisningar på landningssidor – 0
- Gör sidan responsiv – 0
- Använd läsbara textstorlekar – 0
Ja, hur använder man denna information tänker du? Börjar man uppifrån kan man fundera på hur svårt det är att lindra eller lösa respektive problem för hela webbplatsen. I vissa fall är insatsen faktiskt ganska liten, punkt två och tre i ovan lista har jag själv fixat på några webbplatser på mindre än en arbetsdag. Punkt ett är däremot väldigt jobbig, och antagligen dumt, att fixa på en befintlig webbplats. Man kan kolla om det går att lindra det med några enkla förbättringar.
Så som jag själv använder datakällan bakom listor som dessa är att sortera fram de värsta syndarna och försöka åtgärda dem. Det kan vara att man råkat ladda upp en extremt högupplöst bild, ja då får man förminska den och ladda upp på nytt. Här kommer kopplingen till webbstatistik in igen – optimera inte innehåll som sällan används, börja med det som är populärast för mest effekt.
När man bestämt sig för att ta bort sina sista Flash-animationer blir de lätta att hitta även på en väldigt stor webbplats, filtrera fram sidorna som fick dåligt betyg på just den punkten.
Nästa steg – en ännu bättre sajt!
Vad ska man göra av dessa siffror? Lättast är att ta ett omtag när man väl bygger om webbplatsen. Man kan (och bör) sätta upp en prestandabudget med de krav man ställer på sin nästkommande webbplats. Dels för att man under designprocessen inte ska bete sig slösaktigt gentemot den prestanda användarna behöver men också för att sätta konkreta siffror på det man beställer. Lämna över ”bevisbördan” till de som utvecklar webbplatsen, låt dem rapportera hur det som byggs lever upp till kraven med ett representativt innehåll.
Ska man inte bygga nytt än på länge kan man ta listan med förbättringspotential och prata med sina utvecklare. Inte sällan finns förbättringar som både har en hel del påverkan men inte tar mer än någon timme att fixa för praktiskt taget hela webbplatsen.
Att formulera sina mål är inte nödvändigtvis enkelt. Ska man någonsin ha under 100 i användbarhetsbetyget? Hur lång tid är ok att vänta för att få fatt på en webbsida under optimala förhållanden kontra eländiga förhållanden?
Inom Västra Götalandsregionen har vi dokumenterat vår första version av en prestandabudget för de webbplatser vi själva ansvarar för. Jag, personligen, ser gärna att arbetssättet med en (publikt åtkomlig) prestandabudget används även på de webbplatser vi delar med andra organisationer. Om det finns något jag kan hjälpa till med är det bara att höra av sig.
”Som du ser på bilden intill får inte ens 30 tecken plats, då gäller det att hushålla och skriva det viktigaste först” – gôrspännande. Sån´t jag älskar. Låt mig mala ner texten och plocka ut de viktigaste beståndsdelarna!
I övrigt bra pedagogisk text tycker jag Marcus samt intressant 🙂