EU:s webbdirektiv & webbprestanda à la Västra Götalandsregionen

“What gets measured, gets improved”
– Peter F. Drucker

Som managementgurun Peter Drucker konstaterade är det verkligen svårt att förbättra något om man inte ständigt utvärderar.

Föreläsningarna i videoformat

Nedan följer videoklipp från föreläsningar om webbdirektivet och webbprestanda, videoklippen erbjuder även textning. Marcus Österbergs talmanus är nedan bloggpost (vilket täcker in mer än videoklippet), kolla Marcus presentationsbilder, samt kolla in Pär Lannerös presentationsbilder.

Om VGR och webbprestanda

En tydlig startpunkt för att börja fokusera på webbprestanda är 2010. Då gick Google ut och förklarade att webbprestanda var väldigt viktigt för hur en webbplats rankades i deras sökresultat. Man sade att:

“Like us, our users place a lot of value in speed — that’s why we’ve decided to take site speed into account in our search rankings.”
– Google Webmaster Central Blog (2010)

För VGRs del började den här typen av arbete med webbprestanda våren 2011. Då jobbade jag själv på webbyrå och hade VGR som kund. Då utgick vi dels från Google Pagespeed (precis som idag) men också Yahoos Yslow, som numera till viss del är utdaterad.

Sedan dess har många aktiviteter behövts för att hålla intresset för webbprestanda “top of mind”.

Aktiviteter

Kortversionen av VGRs resa från medelmåtta till ledande inom webbprestanda kan sammanfattas på följande vis:

  • 2011 = utreda och ge förslag till interna riktlinjer
  • 2012 = bearbeta kollegor som har IT-perspektiv på prestanda
  • 2013 = kravställning av responsivt webbprojekt
  • 2014 = utvärdering av responsiv webbplats,  👍 & 👎
  • 2015 = Googles “mobilegeddon”, internt beslut om prestandabudget
  • 2016 / 2017 = nya webbplatser utvecklas och sjösätts

2011

Men mer i detalj så började vi under 2011 att jobba med våra riktlinjer. Det är en sak att ta fram riktlinjer, en annan att de faktiskt kommer till användning. Därför började vi direkt med förankringsarbetet och la extra mycket energi på att vår IT-organisation skulle bli intresserade. De flesta blev intresserade och vi fick in riktlinjerna i vår IT-projektdokumentation som vi släppte öppet på nätet, det som kallas för öppna program och idag ligger på alla utvecklares älsklingssajt Github.

2012

Under 2012 fortsatte vi att bearbeta vår IT-organisation. Inte alla inom IT var förtjusta, bland annat kom kommentarer som:

”Vi har andra siffror än du och tycker det fungerar bra som det är”

När det visade sig att vi mätte med samma verktyg blev det lite dålig stämning. För hur skulle man då hävda sig? Detta har dock löst sig till ett mycket gynnsamt samarbete när vi väl började förstå varandra!

2013

2013 började vi förbereda för att göra vår befintliga webbplats responsiv till nytta för den växande andel som använde mobila pryttlar.

I utredningen bakom uppgraderingen av vår befintliga webbplats konstaterades det att vi:

”endast i undantagsfall ha lägre än 90 av 100 enligt PageSpeed”

Nu blev det inte riktigt så bra i praktiken, men helt klart bättre än föregångaren. De utmaningar vi stötte på var detsamma som alla andra som uppgraderade sina befintliga webbplatser – det är svårt att lösa ut frågan om webbprestanda i efterhand.

2014

Under 2014 stod VGR där, som många andra, med en responsiv webbplats, men som egentligen var långsammare på en mobil pryl än den webbplats vi just ersatt. Tiden var kanske inte mogen för att skapa snabba mobila upplevelser?

2015 – mobilegeddon

2015 var året då webbprestanda började bli mainstream, inte minst tack vare det som kallades ”mobilegeddon”. Först nu började folk få upp ögonen för att man faktiskt blev straffad i Googles sökresultat om webbplatsen var långsam eller svår att använda på en mobil, och prestanda var en del av detta.

Nu jäklar = här kommer en prestandabudget

Nu blev det inte fullt så dramatiskt som många befarade. Men vi webbnördar passade på. Dels genom föreläsningar hos vår egen IT-avdelning och deras konsulter, men också genom att vara så pass byråkratiska att vi skickade ett internt förslag till beslut om att börja jobba mätbart med vår webbprestanda – en prestandabudget. Det förslaget föll i god jord och beslutades av vår kommunikationsdirektör Erik Lagersten.

2016 – Nu är tiden vara mogen, till sist!

Något som underlättade massor under 2016 var att vi ändå skulle bygga om vår externwebb. Vi tog inte heller med oss gammalt material och att vi samtidigt bytte bildsystem. Vi skulle bygga en ny webbplats, där prestandakrav var en del av projektplanen, samt att vi följde upp prestandan kontinuerligt.

Under sommaren 2016 dök en av våra mindre sajter upp som baserats på vår nybyggnation. Genomsnittet var lovande nog bättre än vår ambition, men webbplatsens innehåll var kanske inte representativ för hur vi misstänkte att våra större webbplatser skulle se ut. Vi var fortfarande något nervösa.

Våren 2017 lanseras till sist nya vgregion.se och ett gäng av våra verksamheters webbplatser som baseras på samma teknik. Nu kom eldprovet både för innehåll och om den teknik IT hade valt skulle orka med.

Cliffhanger: Men innan vi går in på hur resultatet blev tänkte jag orientera oss lite kring prestandabudget som begrepp.

En prestandabudget är ett mätbart sätt att…

En riktigt bra praxis man kan hänvisa till är webbriktlinjer.se, där tips om just webbprestanda är nummer 54. Där inleds poängen med god webbprestanda så här:

”Optimera tjänsten så att den laddar snabbt, svarar snabbt på interaktion och kräver så lite som möjligt av användarens utrustning och uppkoppling. Dålig prestanda leder till negativa användarupplevelser, hinder för användning, försämrat genomslag (till exempel genom sämre rankning i sökmotorer) och slöseri med resurser.”
Webbriktlinje 54

Prestandabudget, eller ”performance budget” på engelska, är den ambition man valt att dokumentera. Engelskans performance inbegriper också det svenska ordet prestation, så min översättning är inte klockren.

Vi har många olika praxis att förhålla oss till när vi tar fram webbplatser. Dessa praxis är smart att dokumentera på ett sätt att de inte glöms bort under projekts slutskeden, när den ekonomiska budgeten börjar sina.

För att minska risken att VGRs prestandabudget skulle bli en skrivbordsprodukt la vi ut den externt på webben, vi har också bäddat in den i vår designdokumentation, stilguiden alltså. Förhoppningsvis skapar det motivation till att efterleva våra ambition, med risken att någon påminner oss om den ifall vi börjar göra dåligt ifrån oss.

Just nu har vi Googles Pagespeed som måttstock. Det är bra men har några nackdelar

Google Pagespeed är vår måttstock

Google Pagespeed i all korthet:

  • Pagespeed är Googles riktlinjer för snabbhet och användbarhet
  • Kan mätas ur ett mobilt eller datorperspektiv
  • Pagespeed ger två betyg; SPEED och USABILITY
  • Erbjuder också teknisk statistik som antal bilder, filstorlekar, m.m.
  • Ger viktade tips om förbättringspotential, bl.a ifall bilder är optimerade

Pagespeed är inte transparent

Även fast vi inte vet nästan några som helst detaljer om hur Google viktar en kvalitetsfaktor jämfört med en annan är det åtminstone ett sätt att kolla hur en enskild webbplats står sig gentemot konkurrensen, samt att få tips på vad som är värt att förbättra.

Dock är det oklart om de bedömningar Google gör står sig över tid. Jag tycker man ska vara lite försiktig med att använda dessa siffror som en absolut och statisk sanning över en längre tid.

“Perhaps what you measure is what you get. More likely, what you measure is all you’ll get. What you don’t (or can’t) measure is lost”
– H. Thomas Johnson

Så hur gick det då för VGR?

Jo det gick bra för VGR. De flesta webbplatserna i testet fick lite drygt 100 sidor inspekterade. Så för att inte förhasta mig kollade jag in några tusen sidor på VGRs webbplats för att få ett mer statistiskt säkerställt underlag till siffran.

  • VGR har 96 av 100, medan tvåan har 83,5
  • Google anger 85 som nivå för välbyggd webbplats
  • Snittet för offentlig sektor är 60,1 av 100

VGRs betyg blev 96 av 100 möjliga. Den näst snabbaste webbplatsen låg rent utav under den gräns Google satt (antagligen något godtyckligt) för vad en välbyggd webbplats bör ha. Genomsnittet för de nästan 600 webbplatserna inom offentlig sektor blev 60 av 100.

I testet var det många äldre webbplatser som placerade sig högt. Det går nämligen ofta snabbare om webbplatsen är mer sparsamt konstruerad som de ofta var förr. Dessa webbplatser är oftast inte responsiva. Så ett sätt att straffa dem lite om man nu vill ha en mer rättvis topplista är att räkna vad användbarheten ur en mobilanvändares perspektiv är och addera hastighetsbetyget. Även från den vinkeln placerade sig VGR högst upp.

Topp tre inom användbarhet + webbprestanda:

  • VGR 195 av 200
  • Karlsborgs kommun 178,7
  • Skellefteå kommun 178,5

Undertecknad är för övrigt producerad i Skellefteå och anställd i VGR 🙂

Vad vi kunde gjort annorlunda (ännu bättre?)

Designbudget först – sedan en prestandabudget

För att vara lite efterklok kring aktiviteterna vi gjort på VGR. Först och främst är vi både nöjda och stolta med vårt arbete med vår prestandabudget. Men om vi fått chansen att göra om alltihop med det vi känner till idag tror jag på att jobba med en designbudget först, och sedan koka ner det till en mer teknisk prestandabudget.

Designbudget är något du får lästips om strax. Lara Hogan har en bok som blev gratis i år och Barbara Bermes skrev om det i sin utmärkta bok Lean Websites. Poängen är att man vid design av webbplatsen har en begränsad mängd med prylar att placera. Med andra ord ett mätbart sätt att förhålla sig till användarupplevelsen redan innan man börjar konstruera webbplatsen.

Tror ingen av oss är stolta över att vi gett efter för påtryckningar och lagt till bildkaruseller på våra webbplatser. Men ett sätt där en beslutad designbudget kan hjälpa till är att man då kan börja diskutera vad en bildkarusell innebär, att den har en kostnad. Eller när ens ”inom citationstecken digitala” reklambyrå föreslår att man förstås måste ha en stor jäkla så kallad hero-bild på en startsida.

En designbudget avfärdar inte dessa (ibland dåliga) idéer, snarare hjälper designbudgeten till med att göra prioriteringen mer tydlig. ”Ok, om vi ska ha en hero-bild kan vi inte också ha en bildkarusell, inte heller 8 högupplösta utsmyckningsbilder för våra strategiska projekt”.

En designbudget är inte direkt komplicerad. Det går ut på att man har satt siffror på hur stor påverkan olika designelement har på användarens upplevelse av hur rapp och användbar en webbplats är.

Om du behöver argument kanske motargumentet att ”allt kan inte vara av högsta prioritet” fungerar? Det finns bara en förstaplats eller above-the-fold på dagens webbplats. Så vad ska vara först och varför?

Som vi på VGR gjorde nu var det ett beslut från vår kommunikationsdirektör som vi hänvisade till vid behov. När vi kunnat jobbat med empati för den blivande användarens upplevelse. Men visst, kanske hade det inte räckt hela vägen att jobba enbart med morot, ibland behövs piskan.

Innehållsbudget – styrd av användbarhet, tillgänglighet, SEO och CRO

När det gäller innehållsbudget är även det en form av riktlinjer eller ambition om hur ens webbplats ska fungera, men då med fokus på hur innehållet ska konsumeras. Som så ofta kan man ta inspiration från Gov.uk, de har samlat på sig undersökningar om vad som fungerar bäst. Det innebär att sidtitlar ska ha en viss längd, texters längd är inte upp till skribentens personliga stil, och så vidare.

Denna typ av riktlinjer är säkert ni som använt WordPress vana med, men då kallas det istället för SEO. Vanligast på WordPress är nog tillägget Yoast SEO, då får man rödljus om man totalt misslyckas med dessa aspekter, brandgul för det som behöver förbättras. Den typen av stöd hjälper nog till att ambitioner kring innehåll faktiskt inträffar.

Val av verktyg för utvärdering

Dessa verktyg har vi använt för att utvärdera webbprestanda:

Google Pagespeed

Google Pagespeed finns i två olika utgåvor. Den enkla är den som kallas Insights, där får man lättbegripliga tips om vad som är bra eller mindre bra. Denna version kan man använda utan några förkunskaper eller särskild IT-behörighet.

API-versionen är den man kan använda om man står ut med lite programmering eller gärna automatiserar sin utvärdering i stor skala. Det är denna jag brukar använda och vill man se exakt hur jag gör detta finns all källkod på adressen verifierad.nu

Med APIet kan man gratis kontrollera 25 000 sidor per dygn, så det går att ha koll på hela sin webbplats i realtid om man så önskar.

Google Search Console (fd Webmaster Tools) & Google Analytics

Search Console har en vy för mobil användbarhet. Den listar bland annat de sidor som misslyckas med användbarhetskriterierna i Pagespeed.

Google Analytics har vyer för att se vilka sidor som behöver ses över kring prestandan och ger tips om mer exakt vad som behöver åtgärdas. Här stöds också de användarsegment man redan specat.

Pingdom

Pingdom är intressant främst för att kolla en webbplats generella välmående. Exempelvis kunde vi på VGR spåra att en uppdatering av vårt publiceringssystem gjorde webbplatsen 0,3 sekunder långsammare. Man har inte riktigt råd med den nivån av försämring för varje uppdatering.

Siteimprove

Siteimprove är intressant för att kunna göra många (men inte alla) tillgänglighetstester i större skala. De har en del annat också.

Sitespeed.io

Sitespeed.io är ett öppet projekt skapat av några sköna prestandanördar, bland annat Peter Hedenskog. Sitespeed.io kan man tipsa sina utvecklare om för att köra på intranät eller andra interna webbsystem som inte nås av de andra.

Webpagetest.org

Webpagetest.org har en visuell jämförelse. Likt två stycken filmer kan man jämföra sin webbplats med en annan. Kanske att vara sämre än någon man gärna jämför sig med gör att man får loss lite pengar till att börja åtgärda sin prestanda? Jag tror att Webpagetest med en viss ansträngning kan köras även på intranät.

Sammanfattning

Kortversion av sammanfattningen:

  1. Välj ett mätvärde du tror du kan få acceptans för
  2. Börja mäta, kontinuerligt!
  3. Dokumentera er ambition i en prestandabudget
  4. Det är användarens upplevelse av prestanda som spelar roll

Det är viktigt att mäta kontinuerligt! Att webbplatsen var fantastisk under lanseringsveckan gör ju ingen större nytta.

Det du avser att mäta bör skrivas ner i en prestandabudget så du vet vilken nivå du förväntar dig.

Och självklart är det användarnas världsbild som är spelar roll. Varken du, din chef eller IT-avdelningen är representativa användare.

Därför ska man nog utgå från mobilanvändarens behov först, åtminstone om man inte kan bevisa att samtliga i ens målgrupp enbart behöver en när de råkar sitta på ett ergonomiskt kontor, med fiberuppkoppling, är utsövda, perfekt syn och så vidare…

Lästips om webbprestanda

Nedan författare brukar också föreläsa, så kolla gärna på videotjänsterna efter aktuella presentationer, även fast böckerna är läsvärda något år till:

Designing For Performance av Lara Hogan

Ska man bara läsa en bok är det Lara Hogans bok om hur man designar och genomför webbprojekt där man inte fumlar bort webbprestanda på vägen. Laras CV på området är imponerande. Under hennes tid på design- och hantverkswebbplatsen Etsy har hon i stor skala kunnat utvärdera om det spelar roll att ta bort några tiotals kilobyte på bilder, dessutom har hon kunnat öva på sin process för att låta prestanda genomsyra designprocessen.

Laras bok är numera gratis och kan läsas direkt på webben.

Lean Websites – Barbara Bermes

Står man ut med mer teknik (eller kan tänka sig att bläddra förbi sådant) är Barbara Bermes bok Lean Websites också riktigt bra. Skillnaden är som sagt att Barbara går djupare i praktisk webbteknik. Här finns kodexempel som kan hjälpa till om man behöver övertyga mer tekniska personer, hon går också in på frågor som hur komplex DOMen kan vara innan det blir svårt att använda Javascript för bra interaktion. Exempelvis kan visuella designelement börja hacka i sina animeringar och det mår nog ingen seende bra av.

Time Is Money: The Business Value of Web Performance av Tammy Everts

Vill man fokusera på vilka bevis det finns för att webbprestanda spelar roll så är boken Time Is Money utmärkt. Min erfarenhet är att man har svårt att sätta ett mätbart värde på det användaren gör på webbplatser inom offentlig sektor, men det går också att tänka på pengar i form av:

  • hur mycket driften av webbplatsen kostar?
  • hur stor investering i extrateknik behövs för att vara redo för kriskommunikation?
  • hur mycket kostar det användarna att vi slentrianmässigt skickar några megabyte extra som egentligen inte behövs?

Webbprestanda och webbstrategi enligt Marcus Österberg

För dig som föredrar att läsa på svenska så har jag skrivit ett och annat om webbprestanda. Dels i (numera gratisboken) Webbstrategi för alla, men också på VGRs utvecklingsblogg under etiketten prestandabudget, samt att jag på fritiden skrivit en webbanalysbok (Webbanalys – Förstå och förbättra användarnas upplevelse) som släpptes för drygt ett år sedan.

High Performance Browser Networking av Ilya Grigorik

Vill man verkligen djupdyka i tekniska aspekter är Ilya Grigoriks bok High Performance Browser Networking utmärkt. Ilya jobbar som prestandaguru på Google. Ilyas bok ligger gratis ute på nätet så kolla in den om du står ut med att läsa om varför HTTPs statuskod 304 är din bästa kompis och hur man drar maximal nytta av den tekniska webbstandard som redan finns.

Ilya har också en del intressanta föreläsningar ute på Youtube, bland annat från Googles konferens I/O. Genom all sin insikt i hur Googles webbläsare Chrome fungerar så har de lyckats utmana många saker folk tar för sanning. En sådan sanning som sågades jämns med fotknölarna förra året var att det är ovanligt att sidvisningar misslyckas ladda klart. De kom fram till att det även i bebyggda områden i Europa handlar om att upp till var tjugonde sidvisning inte leder till ett användbart resultat.

Kolla gärna in prestandafolkets julkalender för 2017. Där publiceras initierade tips ›

Vad ska vår nästa Meetup handla om?

Nominera gärna inspirerande föreläsare (inklusive dig själv?) och ämnen du vill lära dig mer om.

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *