193 views

Webbprestanda à la Västra Götalandsregionen

Presentation om VGRs resa från medelmåttig webbprestanda till att bli snabbast i offentlig sektor enligt Googles prestandariktlinjer Pagespeed.

Internet◦

Webbprestanda à la Västra Götalandsregionen

1.
“What gets measured,gets improved” – Peter Drucker
2.
Agenda ≈ 25minuter 1. Intro till Marcus & VGR 2. VGRs resa från långsam till (antagligen) snabbast i offentlig sektor 3. Vad vi kunnat göra ännu bättre 4. Lästips och referenser 5. Frågor och reflektioner 2017-12-07 Webbprestanda à la Västra Götalandsregionen
3.
Marcus Österberg ❤️VGR Utvecklingsledarnörd på VGR. Gör bl.a: ‒ Webbanalys, externt via webbriktlinjer.se ‒ Innovation, utredningar och rådgivning Om VGR: ‒ 53k anställda ‒ 2/3 handlar om vård, 1/3 om kultur, skola, m.m. ‒ 1,7 miljoner invånare som potentiella användare 2017-12-07 Webbprestanda à la Västra Götalandsregionen
4.
2017-12-07 Webbprestanda àla Västra Götalandsregionen “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)
5.
Händelser och aktiviteter 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 2017-12-07 Webbprestanda à la Västra Götalandsregionen
6.
En prestandabudget ärett mätbart sätt att… ”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 2017-12-07 Webbprestanda à la Västra Götalandsregionen
7.
Google Pagespeed ärvår måttstock 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 2017-12-07 Webbprestanda à la Västra Götalandsregionen
8.
Så hur gickdet då? 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 Hastighet + användbarhet: 1. VGR 195 av 200 2. Karlsborg 178,7 3. Skellefteå 178,5 2017-12-07 Webbprestanda à la Västra Götalandsregionen
9.
”A typical CMSis like a digestive system with no capacity to poop” – Gerry McGovern 2017-12-07 Webbprestanda à la Västra Götalandsregionen
10.
Första större uppdateringenav er nya webbplats 2017-12-07 Webbprestanda à la Västra Götalandsregionen
11.
Vad vi kundegjort annorlunda Designbudget först - sedan en prestandabudget Innehållsbudget - styrd av användbarhet, tillgänglighet, SEO och CRO 2017-12-07 Webbprestanda à la Västra Götalandsregionen
12.
Val av verktygoch mätvärden Google Pagespeed Insights/API via projektet verifierad.nu Google Search Console och Google Analytics Pingdom för svarstider och deras Real User Monitoring (RUM) Siteimprove Sitespeed.io funkar även med intranät Webpagetest.org för visuell jämförelse och skillnad full/tom cache 2017-12-07 Webbprestanda à la Västra Götalandsregionen
13.
Sammanfattning Välj ett mätvärdedu tror du kan få acceptans för Börja mäta, kontinuerligt! Dokumentera er ambition i en prestandabudget Det är användarens upplevelse av prestanda som spelar roll 2017-12-07 Webbprestanda à la Västra Götalandsregionen
14.
Lästips Designing For Performanceav Lara Hogan (gratis på nätet) Lean Websites av Barbara Bermes Time Is Money: The Business Value of Web Performance av Tammy Everts High Performance Browser Networking av Ilya Grigorik (gratis på nätet) 2017-12-07 Webbprestanda à la Västra Götalandsregionen
15.
Tack för mig!Frågor eller reflektioner?

Editor's Notes

#2 Ok, då var det dags för mitt pass. Jag kommer prata om uppföljning på webben, närmare bestämt webbprestanda. Som managementgurun Peter Drucker konstaterade så är det verkligen svårt att förbättra något om man inte ständigt mäter. >> Upplägget ser ut så här
#3 Jag tänkte berätta om VGRs resa från tveksam men genomsnittlig prestanda till att bli bland de absolut bästa i offentlig sektor. Men jag tror att det vi gjorde inte är värt att följa till punkt och pricka, så jag tänkte ge tips på vad vi kunnat göra ännu bättre, vad vi inte visste skulle nog göra nytta hos andra. Och jag har en del tips på vad man kan läsa för att ta inspiration, det finns riktigt bra böcker som hunnit bli gratis, bland annat av auktoriteter som Ilya Grigorik (prestandaguru hos Google) och Lara Hogan som undersökt ifall designfirman Etsy haft nytta av snabbare sidvisningar.. Inte minst, det finns plats för frågor och reflektioner. (i rummet ser jag ett flertal som varit med och fått nya vgregion.se att bli snabbare, så passa på att fråga så kanske det finns fler perspektiv än mitt). >> Först tänkte jag berätta lite om mig och min arbetsgivare
#4 Jag är en stolt anställd inom VGR. Mina sysslor är allt som rör olika former av analys, vilket bland annat inkluderar webbanalys och webbprestanda i Post- och Telestyrelsens utmärkta projekt webbriktlinjer.se – något jag varit en beundrare av sedan start. Jag jobbar primärt med medarbetarnas innovationskraft, skriver utredningar och agerar rådgivare kring allt möjligt som har med digitalisering att göra. Men för att gå över till VGR så är det landstinget mellan Halland och Värmland, ända in till Mariestad. Vi är drygt 50 000 anställda. Tvåtredjedelar jobbar i vården, men många är inom utbildning, kultur eller kollektivtrafiken. Vi har 1,7 miljoner invånare och många webbplatser. Bland annat har vi 1,2 miljoner besök (dock inte unika besökare) på vår del av 1177.se varje månad. >> VGRs resa mot att få en snabb webbplats har tagit några år
#5 En tydlig milstolpe för att börja fokusera på webbprestanda är 2010. Då gick Google ut och förklarade att (LÄS CITATET). För VGRs del började den här typen av arbete med webbprestanda våren 2011. Då jobbade jag på webbyrå och hade VGR som kund. Kristian Norling, idag chef på enheten Digitala medier inom regionens kommunikationsavdelning, hörde av sig och ville få research utförd kring hur man kunde förhålla sig till webbprestanda. Då utgick vi dels från Google Pagespeed precis som idag, men också Yslow som numera till stor del utdaterad. >> Sedan dess har många aktiviteter behövts
#6 2011: Det är en sak att ta fram riktlinjer, en annan att de 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 nappa. Det gjorde de flesta och vi fick in riktlinjerna i vår IT-projektsdokumentation som vi släppte öppet på nätet. 2012: Fortsatte bearbeta inom 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” – och när det visade sig att vi mätte med samma verktyg blev det lite dålig stämning. 2013 började vi förbereda för att göra befintlig webbplats responsiv: 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. 2014: Under 2014 stod vi där som många andra med en responsiv webbplats, men som egentligen var trögare på en mobil än den webbplats vi just ersatt… Tiden var kanske inte mogen? 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 svår att använda på en mobil, och prestanda var en del av detta. Sen blev det inte fullt så dramatiskt som många befarade. Men jag passade på, dels genom en föreläsning hos vår egen IT-avdelning och deras konsulter, men också att vara så pass byråkratisk att jag 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. 2016 - Nu verkade tiden vara mogen: Något som underlättade massor var att vi ändå skulle bygga om vår externwebb. Vi tog inte med oss gammalt material och att vi bytte samtidigt bildsystem. En ny webbplats där prestandakrav var en del av projektplanen, samt att vi följde upp prestandan kontinuerligt. 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 våra större webbplatser skulle prestera. Våren 2017 lanseras 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. >> Men innan vi går in på hur resultatet blev tänkte jag orientera oss lite kring prestandabudget som begrepp
#7 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: [--läs upp citatet--] 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, den är bra men har några nackdelar
#8 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
#9 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 statistikt underlag till siffran. 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. >>
#10 Jag tycker Gerry McGovern uttryckt utmaningen med förvaltning bra: ”A typical CMS is like a digestive system with no capacity to poop” Webbplatser tenderar att bli förstoppade över tid. Det är nog inte troligt att webbplatsen blir mindre komplex eller snabbare på något magiskt sätt. Åtminstone om man inte aktivt ser till att det blir så. Ett tydligt beslut och någon som har uppdraget att bevaka utvecklingen var så vi försökt rigga organisationen. Jag tror att det är en enorm utmaning är hur ens prestanda förvaltas över tid. >> Jag har nog lite tips på detta, men det är också svårt att veta när det är dags att saga ifrån på skarpen
#11 Och jag tror att de flesta listat ut att aspekten med webbprestanda är inte ett projekt, lika lite som innehållet på en webbplats är statiskt. En uppenbar risk är att man börjar glida iväg från ambitionen allt eftersom tiden går. Ett tag efter lansering brukar verksamhetsföreträdare ha önskemål om tillägg. Det gäller att balansera de avvägningarna så inte varje insats gör användarupplevelsen långsammare och därmed mindre effektiv. Om du kollar på grafen här från Pingdom kan du visserligen se när sajten troligen uppdaterades genom de röda markeringarna, men att det skedde en större förändring i andra halvan av mars syns om inte annat på att webbplatsens bästa svarstider stabiliserade sig på en klart sämre nivå. Den nya nivån är i genomsnitt 0,3 sekunder långsammare än innan. Här övervakade jag alltså vår miljö för acceptanstest. Det är lite sent om man dagen efter lansering konstaterar att man inte är i närheten av sina mål för prestanda. Åtminstone finns det många som märkt hur svårt och kostsamt det är att fixa sina prestandaproblem i efterhand. Jag tror att Pär håller med om att även tillgänglighet kostar mer som en reaktiv insats snarare än att man ser till att fixa det från början. Även jag kan leva med att en webbplats blir några tiondels sekunder långsammare, trots att vissa gett mig epitet som en extremist eller prestanda-taliban. Frågan är väl mer hur många gånger man kan acceptera att webbplatsen blir 0,3 sekunder långsammare? Vad tycker du? Vill man sätta 0,3 sekunder i perspektiv så är det tre gånger så mycket som Google har satt som mål för en sökning på deras webbplats. Detta om man ska tro deras prestandaguru Ilya Grigorik. I och med en uppdatering av vår webbplats gick den alltså från att vara 8 gånger långsammare än Googles mål, till att bli 11 gånger så långsam. Jag påtalade denna illavarslande trend för vår interna leverantör. Till svar fick jag att de hade andra siffror som inte alls var så illa. Nu råkar jag veta att de har en stor skärm med exakt samma siffror från Pingdom på en vägg för att ha koll på hur webbplatserna mår. Nej, detta är inte dåliga siffror. Google är extremt fokuserade på detta jämfört med de flesta. Frågan är mer när man säger stopp till sin IT-leverantör när det sakta men säkert blir sämre? Jag ska poängtera att jag bjudit vår leverantör på tårta för ett väl utfört arbete. De har verkligen jobbat hårt, men vi som beställare har varit extremt tydliga med att denna gång ska det banne mig bli snabbt. >> Det är en av få fördelar att jobba med mig, jag bjuder gärna på tårta när jag blir glatt överraskad :)
#12 Jag tänkte vara lite efterklok kring aktiviteterna vi gjort på VGR. Först och främst är jag nöjd med vårt arbete med en 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. (Hand upp alla som har bilder som bläddrar runt som en karusell på någon sida?) 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… 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 om det behöver förbättras. Den typen av stöd hjälper nog till att ambitioner kring innehåll faktiskt inträffar. >> Tänkte tipsa om lite verktyg…
#13 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 och 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 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 ä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 ä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 är ett öppet projekt skapat av några sköna prestandanördar. 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 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. >> Nu är det dags att sammanfatta
#14 Jag inser att webbprestanda är ännu ett smått diffust krav på hur man bygger webbplatser. Min rekommendation är dock enkel. Se till att komma igång i det lilla, dokumentera er ambition och jobba mätbart. Hos oss tyckte jag att Googles mätvärde Pagespeed var enklast att sälja in, men det finns många fler varianter. Bland annat siffror som berättar hur lång tid det tar innan sidan kan interageras med, andra siffror är tiden det tar för sidan att börja visa upp sig på ett meningsfullt sätt. 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… >> Avslutningsvis tänkte jag tipsa om lite böcker för den som vill gräva vidare
#15 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. 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. 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? Vill man verkligen djupdyka i tekniska aspekter är ilya Grigoriks bok High Performance Browser Networking utmärkt. Ilya jobbar som prestandaguru på Google. Hans 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 var tjugonde sidvisning inte leder till ett användbart resultat. >> Med detta avrundar jag denna intro till VGRs prestandaarbete och intro till webbprestanda

Webbprestanda à la Västra Götalandsregionen

More Related Content

Similar to Webbprestanda à la Västra Götalandsregionen

More from Marcus Österberg

Webbprestanda à la Västra Götalandsregionen

Editor's Notes