Prestandakollen 2017

Offentlig sektors prestanda på webben

Författare: Marcus Österberg
Licens: CC-BY-SA 4.0
Släppt: 2017-11-21

Korrekturläsare:

• Peter Hedenskog, arbetar med webbprestanda för Wikimedia Foundation
• David Fleischhacker, samordnare digitala kanaler på Universitets- och högskolerådet
• Jonas Runesson, produktägare på Phoniro Systems

---

Innehållsförteckning

• tl;dr - sammanfattning
• Intro till prestandatestet
• Spelar webbprestanda någon roll?
  • Spelar det roll för offentlig sektor?
  • Offentlig sektors “kunder”
  • Långsamhet utmanar användarens koncentrationsförmåga
• Praxis för offentlig sektor - Vägledning för webbutveckling
• Vilka webbplatser är med i utvärderingen 2017?
  • Detaljer om testet
• Jämförelse mellan 2016 och 2017
• Slutsatser kring offentlig sektors prestation
• Vilka tjugofem webbplatser var snabbast?
• Hur stor är variationen på prestanda, användbarhet och webbplatsernas statistik?
  • Hastighet
  • Förklaring till förbättringstabellerna
  • Användbarhet
  • Mängd HTML-, CSS- och Javascript-kod
  • Bilders tyngd
  • Andra teknikaliteter
• Förbättringspotential för offentlig sektor
  • Några slutsatser kring det som kan förbättras
  • Undvik krav om plugin
• Slutsatser av offentlig sektors potential
• Resultat för nedladdning
• Appendix
  • Metod för mätning – teknikaliteter
  • Ett genomsnitt per webbplats
  • Tips på verktyg
  • Tips på fördjupande läsning/tittande

---

tl;dr - sammanfattning

Svensk offentlig sektor presterar sämre 2017 jämfört med året innan när det gäller Googles riktlinjer för hastighet, men något bättre gällande användbarhet.

En skillnad mot när utvärderingen gjordes 2016 är att det nu finns webbriktlinje 54^[1] från Post- och telestyrelsen (uppdaterad i september 2017) som förklarar hur offentlig sektor bör jobba med att optimera sina webbplatser när det gäller prestanda. Riktlinje 54 rekommenderar att med hjälp av en intern prestandabudget dokumentera organisationens ambition och att börja utvärdera sina webbplatsers prestation.

Årets fynd i all korthet:

1. Adobe Flash har praktiskt taget försvunnit.
2. Användbarheten har ökat med knappt två procentenheter.
3. Dessvärre är offentlig sektor två procentenheter sämre än föregående år när det gäller efterlevnad av Googles hastighetsriktlinjer.
4. Varken antalet filer eller filernas storlek har ändrats nämnvärt sedan 2016, om man bortser från att den genomsnittliga webbsidans bilder är drygt en fjärdedel tyngre. Troligen på grund av att fler webbplatser är responsiva.
5. Den största enskilda försämringen är att bildernas negativa påverkan på prestandabetyget har mer än fördubblats, det vill säga bilderna är sämre optimerade 2017.
6. Användningen av webbläsarens cache och textstorlekarna har förbättrats en hel del.
7. Snabbast 2017 är Västra Götalandsregionen (VGR), vars satsning på webbprestanda verkar ha burit frukt. VGR är hela 12 procentenheter bättre utformad än den näst snabbaste webbplatsen, enligt Googles hastighetsriktlinje.

Intro till prestandatestet

Detta test har körts sedan 2010 dock med varierande mätobjekt och mätpunkter. Till en början kontrollerades alla 290 kommuner, men sedan 2016 har även myndigheter, landsting och flera andra inom offentlig sektor tagits med. Sedan 2015 är det enbart mobilanvändarnas behov som utvärderas. Detta bland annat för att de användarna började bli i majoritet på de flesta webbplatserna, samt att Google ändrade perspektiv för hur de rankade material. Att mäta enbart från mobilt perspektiv skiljer agnarna från vetet gällande prestanda, samt att Google inom en snar framtid har ett mobile-first index^[2] för rankning av sökresultaten.

Sedan 2010 har totalt cirka en halv miljon webbsidor från tiotusentals webbplatser utvärderats, det finns följaktligen rätt mycket data bakom jämförelserna. Analysen för 2017 har gjorts på drygt 60 000 sidor från 573 webbplatser.

Spelar webbprestanda någon roll?

Bland kommersiella aktörer, och särskilt de som bedriver ehandel, har prestanda seglat upp som en av de viktigaste faktorerna till framgång de senaste åren. Även fast historien om webbprestandas betydelse började tidigare så finns en tydlig start 2010. Då berättade nämligen sökgiganten Google att en webbplats hastighet påverkade dess rankning i sökresultaten. Bland annat framhöll man 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. We use a variety of sources to determine the speed of a site relative to other sites.”

– Google Webmaster Central Blog^[3] (2010)

Men det är inte bara Google som menar att prestanda påverkar en webbplats nyttighet. Flera andra organisationer har undersökt vilken påverkan god webbprestanda har:

1. Yahoo: 0,4 sekunder snabbare sidvisning gav 9% mer trafik.
2. AOL: Snabbare sidor = fler sidvisningar.
3. Amazon: 0,1 sekunder snabbare = 1% mer omsättning.
4. Shopzilla: 5 sekunder snabbare = 25% fler sidvisningar, samt 7 till 12% mer omsättning.
5. Aberdeen Group i rapporten ”The performance of web applications”: 1 sekund långsammare = 11% färre sidvisningar, samt 7% färre konverteringar.

Ta och reflektera över den sista punkten. Har man råd med att ignorera sju procent sämre konverteringsgrad? Vill du läsa mer av rapporterna finns de dels diskuterade i webbanalysboken^[4], men också på bokens webbsida med referenser ^[5].

Spelar det roll för offentlig sektor?

Men hur relevant är det för offentlig sektor? Man kan oftast inte mäta nyttigheten i reda pengar och det gör det hela lite svårare. Ett annat perspektiv är därför att se det som den serviceplikt offentlig sektor har och att man har det gentemot hela samhället, där medborgarna har högst varierande förmågor. Till skillnad från privat sektor har många i offentlig sektor någon form av monopol. Gillar du inte det din kommun gör på webben är det för de flesta ett rätt stort steg att flytta till grannkommunen.

Offentlig sektors användare har både behov och rättigheter, men ganska liten valmöjlighet. Rättigheterna regleras i ett antal lagar. Kanske är diskrimineringslagen tydligast då man fokuserar på kulturella, språkliga och funktionella ting, bland annat. Vi som jobbat med digitalt innehåll har länge använt blinda som grupp när vi exemplifierar behov av tillgänglighet på webben. Men den gruppen är försvinnande liten jämfört med alla andra som också behöver vår omtanke.

Tittar man på den arbetsföra befolkningen i Sverige har drygt 270 procent, ja tvåhundrasjuttio procent, en kognitiv funktionsnedsättning någon gång under sitt liv. Vissa har den hela sitt liv. Detta är siffror från Arbetsmiljöverket^[6] när de gjorde en sammanställning av statistik som har att göra med hur “hjärnvänlig” det svenska arbetslivet är. Med andra ord har vissa människor detta problem vid upprepade tillfällen under livet, delvis på grund av att det finns en mängd sjukdomar som sänker den mentala förmågan. Man har dock inte räknat med att småbarnsföräldrar är utmattade, att folk tenderar att ha sämre mental kapacitet sent på midsommarnatten eller att människor är i affekt när en närstående ligger för döden på ett sjukhus man desperat försöker hitta fram till. Man har helt enkelt inte räknat med de normala livshändelser vi alla genomgår. Trots detta är det 270 procent.

Offentlig sektors “kunder”

Offentlig sektors användare består av ett väldigt brett spektrum av människor och det är viktigt att nå ut till alla. Var tionde svensk har låg eller mycket låg begåvning^[7], och hela en fjärdedel har svårt att läsa. Detta är offentlig sektors användare.

Några som fångat detta och försöker göra något åt det är webbstandardorganisationen W3C som genom sina designriktlinjer Web Content Accessibility Guidelines^[8] (WCAG) i version 2.1 även börjar ta upp den mentala utmaning det kan innebära att använda webben. Ett exempel på de nya framgångskriterierna är att man ska undvika att avbryta användaren (2.2.7 ^[9]). Det kan tyckas uppenbart, men ändå så görs det relativt frekvent, inte minst för att försöka hindra användaren från att lämna webbplatsen.

Långsamhet utmanar användarens koncentrationsförmåga

Nu kanske du undrar hur detta har med diskriminering att göra? Precis som att det är uppenbar diskriminering att kräva att användaren måste ha mycket god syn bör det rimligen krävas att innehåll är utformat så det går att både uppfatta, förstå samt hushålla med sin uppmärksamhet. En del av detta är att skriva Lättläst^[10] (LL), men om innehållet inte dyker upp i rimlig tid spelar det ingen roll hur begripligt innehållet är. Dröjer det för länge sänker man användarens kognitiva förmåga, till exempel genom att det kan vara svårt att bibehålla koncentrationen. Men hur långsamt är för långsamt?

Det finns massor med olika gränser för hur lång tid något får lov att ta. Enligt somliga kan en webbshop som laddar på mindre än två sekunder utnyttja de som saknar impulskontroll, enligt andra är cirka två sekunder en “sweet spot” för när avsändarens och mottagarens intressen sammanfaller. Om man istället kollar på när man börjar göra livet jobbigt för de allra flesta är det mellan sex och trettio sekunder^[11] det handlar om. Inom det spannet kommer vem som helst bli otålig och tappa sitt mentala flöde. Vissa kan rentav glömma bort vad de håller på med, eller vilket ärende de har.

Under optimala förhållanden, som på ditt ergonomiska kontor, är detta ganska sällan ett problem. Men för dina användare på ett skakigt konferensnät mitt i centrum, eller på en konsert med Håkan Hellström bland tiotusentals andra, är det definitivt ett problem.

Praxis för offentlig sektor - Vägledning för webbutveckling

Om man följer de officiella riktlinjerna för hur man bör arbeta med webbplatser i offentlig sektor, populärt kallat webbriktlinjer.se, så finns webbriktlinje nr 54 om att optimera webbplatsen för bästa prestanda. Den sammanfattas 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. Bra prestanda kan till exempel uppnås genom att inte överföra mer data än nödvändigt.”

– Webbriktlinje 54^[12] (september, 2017)

Om du internt behöver motivera varför webbprestanda är viktigt skulle du kunna klippa och klistra ur denna formulering från webbriktlinjen för att väcka empati:

“Du själv har kanske bra uppkoppling till din nya snygga sajt och är motiverad nog att vänta när den laddas, men andra besökare är ofta otåliga och på väg någon annanstans. Det kan även gälla personer med vissa funktionsnedsättningar, till exempel koncentrationsstörningar och kort arbetsminne.

Användare med mobil uppkoppling har extra stor anledning att undvika dåligt optimerade webbplatser eftersom de ofta har begränsad bandbredd och ibland måste betala extra för varje megabyte data.

Eftersom sökmotorer premierar webbplatser med en god användarupplevelse leder ökad prestanda även till bättre sökmotoroptimering.”

Så ja, att en webbplats har en tillfredsställande webbprestanda är viktigt oavsett webbplatsens art eller dess målgrupp.

Vilka webbplatser är med i utvärderingen 2017?

Dels utgår listan från 2016 års test, men de myndigheter som har försvunnit sedan dess är bortplockade. Utöver dem är det några webbplatser som av en eller annan anledning inte var tillgängliga under testtillfället den aktuella kvällen i oktober. Det kan bero på ett flertal saker. Bland annat driftstörningar, men vissa webbplatser vägrar att ge åtkomst till webbplatsen om det inte är antingen Google eller en bekant webbläsare som frågar efter innehåll. Detta är nog ofta ett desperat (och fruktlöst) försök att undvika överbelastningsattacker. Samtliga webbplatser har undersökts med avsikten att kolla minst 50 st undersidor, antingen via respektive webbplats sitemap eller genom att skörda länkar på startsidan. Ibland har färre än 50 adresser hittats. Därmed bör man inte se respektive webbplats värde som en absolut sanning om hur det står till.

Men den webbplats som tycks ha presterat bäst har inspekterats extra noga. Där har 3592 webbsidor undersökts för att se om den faktiskt var så bra som det verkade vid en första anblick.

Detaljer om testet

Du som är nyfiken på metoden kan kolla in rapportens avslutande appendix, likaså du som vill åt källkoden för testet. I korthet kan nämnas att respektive webbplats egna genomsnitt har beräknats först, sedan har det genomsnittet påverkat det totala genomsnittet för alla webbplatser. Denna omväg beror på att det är olika många sidor som inspekterats per webbplats och om inte denna omräkning gjorts skulle webbplatser med många testade sidor påverkat det totala genomsnittet mer än de med få testade sidor.

Jämförelse mellan 2016 och 2017

Så här ser en genomsnittlig webbsida ut hos offentlig sektor i oktober, 2016 kontra 2017 om man ska tro Google Pagespeed API.

Mätvärde	2016	2017
Användbarhet	84.5 av 100	86.3 av 100
Pagespeed	62.1 av 100	60.1 av 100
Javascript	1025 Kb	1067 Kb
Bilder	360 Kb	458 Kb
CSS	316 Kb	338 Kb
Övrig text (textResponseBytes) *	99 Kb	73 Kb
HTML	93 Kb	97 Kb
Andra filer (otherResponseBytes)	30 Kb	43 Kb
HTTP-a nslutningens storlek	5.5 Kb	5.5 Kb
Adobe Flash **	5.2 Kb	-
Antal filer totalt	46.3 st	45 st
Antal statiska filer	37.6 st	35 st
Antal Javascript	16.9 st	16.3 st
Antal CSS-filer	8 st	7.4 st
Antal värdar/domäner	7.8 st	8.2 st

* fanns på 81 av 557 webbplatser 2016 och 65 av 573 webbplatser under 2017. Det som anges är genomsnittet för de webbplatserna, alltså genomsnitt för där det förekom (så kallad prevalens ^[13]).
** fanns bara på en av webbplatserna 2016, detta är genomsnittet för den enskilda webbplatsen. 2017 hittades tack och lov inget Adobe Flash-material någonstans bland de undersökta webbsidorna.

Slutsatser kring offentlig sektors prestation

Det här med jämförelser är komplicerat. Google är inte öppna med bedömningskriterierna, så de kan ha ändrats mellan olika års testtillfällen. Men också, i vilken takt förväntar man sig att något förbättras. Förutsättningarna förändras emellanåt. 2015 var första året det var meningsfullt att jämföra offentlig sektor från en mobilanvändares preferenser, då körde vi en test på alla kommuners webbplatser^[14]. Delvis för att Google hotade med vad som kallades “mobilegeddon”, alltså att låta mobilanvändarnas upplevelse påverka hur bra en webbplats rankades på Google. Då, 2015, fick Sveriges kommuner ynkliga 69,8 av 100 i användbarhetsbetyg. Det skuttade upp till 84,5 förra året och marginellt upp till 86,3 i år när testet körts på dubbelt så många sajter inom offentlig sektor.

2015 var kommunernas allmänna prestandabetyg 52,3 av 100, något som gick upp till 62,1 förra året för offentlig sektor för att backa till 60,1 under 2017.

Ovanstående siffror som beskriver de testade webbplatserna tyder på att de flesta webbplatserna numera är byggda enligt tekniken responsiv webbdesign, men att man slarvat med att optimera för god prestanda. Att offentlig sektor är mer responsiv idag kan man läsa ut av att användbarhetsbetyget ökat. Det innebär bland annat att man valt storlek på text som är läsbart på andra prylar än en skrivbordsdator. Samtidigt är det ett flertal av de snabbare webbplatserna som inte är responsiva, det vill säga relativt oanvändbara på en mobil.

Vilka tjugofem webbplatser var snabbast?

Den kompletta listan över snabbhet hittar du i appendix, men nedan presenteras de som gjort bäst ifrån sig. Det är inte läge att sparka sina utvecklare för hur man placerat sig i denna lista. Se listan som hur det såg ut under ett dygn i oktober när testet kördes. Kanske hade just din webbplats både otur och bekymmer precis när det var dags att inspektera er webbplats? Men kanske behöver ni kämpa er upp och förbi Googles rekommenderade 85 av 100 i prestandabetyg?

Den enda webbplatsen som levde upp till Googles nivå är Västra Götalandsregionens (där rapportförfattaren råkar jobba med webbanalys och som skapare av prestandabudgeten).

Inte alla webbplatser på topplistan över snabbhet är responsiva, så bedöm själv om det är rimligt att idag inte stödja olika skärmstorlekar.

Webbplats:	Pagespeed-betyg:
www.vgregion.se	96,2
www.svff.se	83,5
www.epn.se	82,0
www.forsvarsmakten.se	81,3
www.domstol.se	80,3
www.orebrotingsratt.domstol.se	79,8
www.angermanlandstingsratt.domstol.se	79,8
www.vanersborgstingsratt.domstol.se	79,7
www.varmlandstingsratt.domstol.se	79,6
www.karlsborg.se	79,5
www.ostersundstingsratt.domstol.se	79,5
www.vaxjotingsratt.domstol.se	79,3
www.skelleftea.se	79,0
www.moratingsratt.domstol.se	79,0
www.smus.se	79,0
www.nykopingstingsratt.domstol.se	78,9
www.kristianstadstingsratt.domstol.se	78,9
www.jonkopingstingsratt.domstol.se	78,9
www.skaraborgstingsratt.domstol.se	78,9
www.kammarrattenistockholm.domstol.se	78,9
www.svea.se	78,9
www.skellefteatingsratt.domstol.se	78,9
www.kammarratten.goteborg.se	78,9
www.sodertaljetingsratt.domstol.se	78,9
www.linkopingstingsratt.domstol.se	78,8

När det gäller användbarhetsbetyget så är det inte meningsfullt att rapportera i någon topplista. Detta beror på att nästan alla är grupperade runt 98 av totalt 100 i betyg, eller runt 60 av 100. Det är nämligen där man hamnar om man har en hyggligt välbyggd responsiv webbplats, eller inte har det. Däremot är respektive användbarhetsbetyg, dess potential, intressant, men det kommer vi in på lite senare.

Det som däremot kan vara av intresse är hur kombinationen av hastighet och användbarhet föll ut. Problemet är nämligen att många äldre webbplatser har en rätt bra hastighet tack vare sin enkelhet, medan de samtidigt är hopplösa att använda på en mobil. Nedan tabell har adderat betygen för hastighet och användbarhet, vilket kan vara en mer rättvisande topplista.

Webbplats:	Hastighet + användbarhet:
www.vgregion.se	195,26
www.karlsborg.se	178,65
www.skelleftea.se	178,45
www.habokommun.se	178,42
www.forsvarsmakten.se	177,78
www.epn.se	177,72
www.lu.se	176,74
www.sodertalje.se	176,30
www.nacka.se	174,92
www.namndenmotdiskriminering.se	174,75
www.mia.eu	174,60
www.overkalix.se	174,12
www.arbetsgivarverket.se	174,00
www.amal.se	172,96
www.kommun.kiruna.se	171,80
www.fi.se	171,47
trafa.se	171,42
www.av.se	170,38
www.hoor.se	169,54
www.konstfack.se	169,41
www.gislaved.se	169,23
www.ekn.se	169,12
www.hedemora.se	169,04
www.fas.se	169,00
www.do.se	168,84

Hur stor är variationen på prestanda, användbarhet och webbplatsernas statistik?

Ett genomsnitt är för all del intressant, men det ger inte jättemycket insikt eller gör det enkelt att jämföra sig i konkurrensen. Därför kommer här alla kriterier och siffror i en visuell form och med förklaring.

Staplarna är grupperade. Exakt gruppering beror lite på vilken data som presenteras. För den första visualisering, om hastighet, är stapeln ovanför noll det som samlar alla sajter som har mellan 0 och 9 i betyg, vilket var två stycken. Nästa stapel de som fått 10 till 19 i betyg, och så vidare.

Respektive undersökt mätvärde kan säkert upplevas diffust. Dels förklaras respektive visualisering nedan, men blir du inte klok på vad mätvärdet handlar om så kolla in Google Pagespeed APIs dokumentation^[15].

Även fast årets SPEED på 60 av 100 inte är i närheten av de 85 Google anger som en bra nivå så hade det väl varit logiskt med åtminstone en förbättring? Med en hårsmån är svensk offentlig sektor numera sämre än de 10 000 största webbplatserna (enligt Alexa, nedladdat från httparchive) under föregående år^[16], från att ha varit en hårsmån bättre. Dessa stora webbplatser hade 2016 i snitt 61,2 av 100 i Pagespeed (baserat på en undersökning av 330 000 undersidor).

Hastighet

När Google definierar vad de tycker en välbyggd webbplats har för betyg i hastighet anger de 85 av 100 möjliga. I detta test är det mindre än en procent som är i närheten av detta. Strikt sett är det bara Västra Götalandsregionen (VGR) som överträffar det målet (notera att VGR är rapportskrivarens arbetsgivare). VGR släppte våren 2017 en ny webbplats där man kravställt 85 i Pagespeed som lägsta acceptabla resultat. Det verkar ha burit frukt.

“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

Förklaring till förbättringstabellerna

För varje kriterium kommer de som har störst möjlighet till förbättring att listas. Att hamna i den änden av skalan kan mycket väl ha en rimlig förklaring. De siffror som anges beskriver den genomsnittliga webbsidan på webbplatsen. Vissa webbplatser har av olika anledningar inte fått massor av undersidor undersökta, så ta enskilda siffror med en nypa salt.

Om ens webbplats eller enskilda sidor får under 50 av 100 i Pagespeed är det definitivt orsak att undersöka vad som står på.

Webbplats:	Pagespeed:
www.overtornea.se	0
www.pajala.se	6.125
www.avesta.se	10.94
www.skovde.se	11.84
www.tranemo.se	16.67

Användbarhet

När det gäller användbarhet är det väldigt många som hamnar i spannet om 90-99 av 100 i betyg. Att dessa webbplatser inte får fullt betyg beror oftast på att man placerat länkar eller knappar för tätt inpå varandra, att träffytorna är för små eller att textstorleken inte är helt optimal. De som ligger under 90 har däremot ganska allvarliga problem utifrån dagens mobila verklighet. Inte minst att många inte har en läsbar textstorlek, eller en responsiv webbplats i största allmänhet.

De som hade lägst användbarhet är nedan webbplatser. Det är väldigt trångt i botten såväl som toppen när det gäller användbarhet, så denna bottenlista är mer en indikation på spridningen av betyg på de fem i botten. Som du ser på ovanstående visualisering är det egentligen 165 webbplatser som gjort mindre bra ifrån sig gällande detta kriterium.

Webbplats:	Usability:
www.lakemedelsverket.se	58.91
www.tjorn.se	58.06
www.valdemarsvik.se	58.45
www.ab.lst.se	59.0
www.ac.lst.se	59.0

Mängd HTML-, CSS- och Javascript-kod

De allra flesta webbsidors HTML-kod håller sig under 100 Kb (textfilers tyngd anges okomprimerat). Det går egentligen inte att säga vad som är ett bra värde då HTML-koden förhoppningsvis bär med sig en bra mängd med innehåll. Dessutom ska man komma ihåg att detta material kan komprimeras innan det skickas till mottagaren, därmed blir överföringstiden över nätet cirka en tiondel jämfört med en likvärdigt tung bild. Dock blir det för väldigt svaga maskiner en utmaning att packa upp en komprimerad fil för att skyndsamt visa upp innehållet. Den exakta gränsen är oklar, men allt över 500 Kb bör man betrakta som en avvikelse värd att undersöka.

De webbplatser som skickar de största HTML-filerna ser du nedan.

Webbplats:	HTML:
www.boras.se	1,45 Mb
www.leksand.se	1,37 Mb
www.kristianstad.se	0,85 Mb
ale.se	0,69 Mb
www.hofors.se	0,61 Mb

CSS är ett formgivningsspråk för webben och är bland annat där färger och responsiviteten är kodat. Mängden CSS-kod som skickas håller sig under 400 Kb för de flesta (även här anges det i okomprimerad form). Någonstans vid 600 börjar man ana att avsändaren dragit nytta av diverse CSS-ramverk för att förenkla utvecklingen av webbplatsen. Dock är det ytterst tveksamt om någon normal webbplats faktiskt använder all den kod som varje besökare tvingas att ladda ner.

De som skickar mest CSS-kod till sina användare anges nedan.

Webbplats:	CSS-kod:
www.upplandsvasby.se	1,25 Mb
www.ornskoldsvik.se	1,08 Mb
www.skatteverket.se	1,04 Mb
www.orebro.se	1,02 Mb
www.eskilstuna.se	1,01 Mb

Javascript var ursprungligen ett språk för att styra interaktioner på webben, att animera saker och kolla att formulärfält var korrekt ifyllda. Numera gör man så mycket mer. Inte minst tekniker som AJAX för att dynamiskt ladda in innehåll, eller bistå med responsiv design och att få en webbplats att mer bete sig som en app eller datorapplikation.

Att skicka 1000 Kb (okomprimerat) Javascript är nog sällsynt att det kommer till nytta, vilket nästan hälften gör. Ofta får man ta emot Javascript som används på sidor man aldrig kommer besöka. Exempelvis är det vanligt att man laddar ner koden för de förbenade^[17] bildkarusellerna som ofta finns på startsidor - även om du aldrig tittat på sidor som drar nytta av koden.

De webbplatser som skickar mest Javascript följer i nedan tabell.

Webbplats:	Javascript:
www.fba.se	4,37 Mb
www.norrkoping.se	3,60 Mb
www.hultsfred.se	3,51 Mb
www.grums.se	3,42 Mb
www.borlange.se	3,38 Mb

Avser andra textbaserade filer i okomprimerat skick. Alltså varken HTML, CSS eller Javascript. Detta görs endast av 65 av webbplatserna. Vad går att utläsa kring dokumentation handlar detta oftast om egna teckensnitt, kanske också bilder som kodats om med tekniken base64 och möjligen också bilder i SVG-format. Just när det gäller teckensnitt brukar de väga in på 60 Kb för att man ska få vanlig, fet och kursiv. Vissa använder dessutom flera teckensnitt på sin webbplats. Som du säkert listat ut så blir dessa teckensnitt några extra filer att ladda ner.

Det här med mer udda teckensnitt påverkar ibland även antalet CSS-filer, åtminstone för de som hyr sitt teckensnitt. Något man ofta gör på en licens vars kostnad beräknas för antalet besökare på webbplatsen. Detta försöker uthyraren ha koll på genom att ha med en CSS-fil för övervakning (*host* GDPR^[18], *host*).

De som skickar mest är de i nedan tabell.

Webbplats:	Övrig textdata:
www.hammaro.se	1,23 Mb
www.vastmanlandstingsratt.domstol.se	0,31 Mb
www.alvkarleby.se	0,31 Mb
www.havochvatten.se	0,25 Mb
www.hoor.se	0,24 Mb

Ur Googles dokumentation: “Number of response bytes for other resources on the page.”

De allra flesta har inget eller väldigt lite av andra sorters filer/innehåll än de som redan angetts.

De webbplatser som skickar mest är angivna nedan.

Webbplats:	Övrigt innehåll:
www.miun.se	752 Kb
www.kungsbacka.se	303 Kb
www.regiongavleborg.se	296 Kb
www.ekn.se	295 Kb
www.norrtalje.se	279 Kb

RequestBytes låter svårare än vad det egentligen är. Att HTTP är ett protokoll känner du säkert till, och protokoll är precis som blanketter ett gäng förutbestämda uppgifter som ska anges. I fallet med webbprotokollet HTTP är det saker som vad adressen är, vilken avsändaradressen är och lite annat som gör att du kan navigera. Dessa saker tar nästan inget utrymme. Det som återstår och kan ta plats är cookies.

Nu finns det en andra version av HTTP och den stödjer komprimering av HTTP-headers inklusive cookies. I och med att Google inte är direkt transparenta med alla kriterier finns det anledning att inte jämföra sig just på dessa siffror.

Ett riktvärde för RequestBytes är 3 Kb, det bör nämligen rymma alla rimliga mängder med kakor. Allt över det är antingen märkligt eller suspekt. Att det finns en webbplats som har 18 Kb får en att tro att de skickar en textversion av någon roman fram och tillbaka bland cookies.

De som skickar mest finns i nedan tabell.

Webbplats:	Request-storlek:
www.formas.se	18,3 Kb
www.hultsfred.se	17,8 Kb
www.uddevalla.se	17,7 Kb
kil.se	16,3 Kb
www.kramfors.se	16,2 Kb

Bilders tyngd

Om det inte finns stöd i webbpubliceringssystemet tenderar missöden kring bilder att inträffa. Alla redaktörer och andra som bidrar med innehåll tycks inte känna till att bildfilers storlek kan påverka hur länge någon annan får vänta. Eller så tar man sig inte tiden att skapa en snabb upplevelse för alla de som använder webbplatsen.

Om du tar den mest extremt högupplösta skärmen av idag, en 8K-skärm, så kan den i fullskärm som mest visa upp bilder med upplösningen 7680 x 4320. Samtidigt som de flesta webbplatser har en majoritet med mobilanvändare som är vana vid bilder på 320 bildpunkters bredd. Testet är kört med de senares behov, det innebär att vissa sajter skickat bilder som är på tok för högupplösta.

Om man inte kan motivera sitt avsteg är det logiskt att undvika mer än 100 Kb med bilder. Undantag är bland annat bildgallerier, fotowebbplatser och bilder som är avsedda för nedladdning och vidareanvändning.

Webbplats:	Bilders tyngd:
www.overtornea.se	17,9 Mb
www.pajala.se	7,9 Mb
www.skovde.se	7,7 Mb
www.avesta.se	4,9 Mb
www.tranemo.se	4,6 Mb

Andra teknikaliteter

Nedan kommer ett gäng visualiseringar av det antal filer som en webbplats vill skicka till varje användare. Att skicka onödigt många filer kan innebära problem och lång väntan för användaren. Ibland kan det dröja en eller annan sekund innan en fil börjar skickas till användaren, men det kan också bli problem med att vissa filer inte hinner skickas och webbplatsen blir oanvändbar när den ser ut att ha laddat färdigt.

Endast 26 webbplatser har som mest en CSS-fil. En enda CSS-fil är fullt tillräckligt enligt de som fokuserar på webbprestanda. Samtidigt, allt över tio stycken CSS-filer tyder på ett fokus på webbutvecklarens behov att sortera saker i olika filer framför den mängd användare som drabbas varje dag när de besöker webbplatserna.

De som gått över till version 2.0 av HTTP kan ha resonerat annorlunda när det gäller antalet filer. Åtminstone initialt verkade det som att det fanns en prestandafördel att dela upp på några filer, men det är inte helt utan kontrovers.

De som skickar flest CSS-filer anges i nedan tabell.

Webbplats:	Antal CSS-filer:
www.norrkoping.se	36 st
www.torsas.se	25 st
www.grums.se	24,2 st
polar.se	22,1 st
www.gotland.se	22 st

Två eller maximalt tre Javascript-filer är nog inget anmärkningsvärt ens för de som fokuserat på webbprestanda (och oroat sig för svajig mobil uppkoppling hos användarna). Men att över hundra webbplatser inom offentlig sektor har 24 eller fler Javascript är illa.
Under sämre uppkopplingsförhållanden, som i tunnlar eller överbelastade konferensnät, kommer bara detta designbeslut att göra första sidvisningen ibland trettio sekunder långsammare, om nu webbplatsen fungerar över huvud taget när den är klar ^[19].

“All your users are non-JS while they're downloading your JS”

– Jake Archibald

De fem med flest skickade Javascript-filer finns i nedan tabell.

Webbplats:	Antal Javascript:
www.eksjo.se	71,8 st
www.norrkoping.se	63,1 st
www.hultsfred.se	61,3 st
kil.se	45,2 st
www.borlange.se	44,7 st

I den högra extremen finns en webbplats som i genomsnitt skickar 133 filer per sidvisning. Det är förstås helt normalt att ha minst fyra filer, du har innehåll i form av HTML, CSS, Javascript och säkert en logga. Men bara detta kommer under suboptimala förhållanden att ta fyra sekunder att ladda in. Vi bör sikta på att ladda in på halva den tiden (för det mesta), så försök hålla de flesta sidvisningarna under 30 resurser/filer som laddas in. Om du nu inte har en väl genomtänkt strategi kring HTTP 2.0.

De som skickar flest filer består av nedan uppställning.

Webbplats:	Antal filer:
kil.se	132,8 st
www.grums.se	124,1 st
www.norrkoping.se	122,2 st
www.hultsfred.se	120,1 st
www.eksjo.se	115,2 st

Antalet statiska resurser är extra intressant när det gäller prestanda. Till att börja med är det Googles bedömning att filerna är statiska, men förutsatt att man accepterar detta är det antalet filer vars innehåll inte uppdateras ofta, eller någonsin. Här kommer diskussionen om cache^[20] in. Cache kan av icke-tekniker kännas mer komplicerat än det är, känner du dig osäker så kolla in Caching Explained ^[21]. När det gäller ovanstående kriterium kan detta beskrivas som vilken livslängd en fil anses ha. Om en besökare återkommer till en webbplats och några filer inte förändrats sen det senaste besöket kommer de inte laddas ner, istället hämtas de från webbläsarens cacheminne då det går mycket snabbare.

Exempelvis logotyper tenderar att vara oförändrade under en ganska lång tid. Exakt hur länge beror på verksamheten, men om du sätter den förväntade livslängden på “logo.png” till 180 dagar kan du alltid vid behov av justering versionshantera filnamnet till “logo-2.png” för att överlista din cacheinställning. På så sätt är din webbplats snabb en vanlig dag och du är redo för det oväntade under en dålig dag.

De med flest statiska filer anges nedan. Detta värde är mer av en bedömningsfråga än att en viss siffra är bra. Möjligen strävar man efter att ha så hög andel statiska filer som möjligt, då behöver bara filer som uppdateras skickas till återkommande användare.

Webbplats:	Antal statiska filer:
kil.se	117,7 st
www.eksjo.se	110,1 st
www.grums.se	108,8 st
www.norrkoping.se	107,7 st
www.skovde.se	89,8 st

Minns du Dagens Nyheters^[22] granskning 2015 av hur offentlig sektor bjöd in tredjeparter till mer eller mindre varje sidvisning? 2016 hade 75% färre än tio olika “värdar” per webbplats, 2017 ser det inte ut som en radikal förändring.

Värdar kan kännas abstrakt, men det handlar ofta om maximalt tre-fyra stycken. En för organisationens egen webbplats/domän, resten är ofta (dessvärre) tredjeparter vars överlevnad hänger på att övervaka användarnas beteende på webben. Just för offentlig sektor handlar dessa sällan om annonsnätverk, men desto oftare om att man bland annat:

• Hämtar udda teckensnitt från någon leverantör.
• Bäddat in Facebook-sidans flöde på webbplatsen.
• Använder Google Analytics för webbstatistik, Google Translate, Google Maps eller Youtube-klipp.
• Uppläsningstjänster som Readspeaker.
• Använder JQuery som Javascript-ramverk och hämtar det från något externt innehållsnätverk.

Men de som har tio eller fler värdar inblandade är helt klart avvikelser. Är din webbplats en av dem så är det läge att prata med utvecklarna. Vill du förbereda dig för den dialogen är nog Pingdoms verktyg^[23] enklast att använda för att få en överblick.

De fem webbplatser som har flest värdar kan du se nedan.

Webbplats:	Antal värdar:
www.hultsfred.se	32,7 st
www.formas.se	32,1 st
www.nassjo.se	29,6 st
kil.se	24,1 st
www.prv.se	21,9 st

Förbättringspotential för offentlig sektor

Det finns förstås många tips på hur man kan göra sin webbplats bättre, och Google Pagespeed ger via sitt API väldigt konkreta siffror på detta. Ä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.

Betrakta nedan som den potential till förbättring så som Google ser på saken när det gäller hastighet och användbarhet.

Med tanke på att Google är den dominerande sökmotorn samt att de sedan många år förklarat att hög prestanda ger en skjuts upp i sökresultatet är det väl bäst att göra ett bra jobb. Vi kan väl kalla det för SEO om vi inte är bekväma med att kalla det webbanalys. Utöver det är det också ett mätbart sätt att jämföra en sida mot en annan på samma webbplats, eller att verifiera om nästa version av webbplatsen faktiskt presterar bättre än föregående.

Nedan mätvärden är hyggligt självförklarande för oss som jobbar mycket med webben, men tvekar du på vad de betyder så kolla in dokumentationen för Google Pagespeed API^[24], och vi kommer strax gå igenom dem en och en . De är underlag nog för att fråga dina utvecklare hur det kommer sig att ni har ett visst resultat (se appendix för möjlighet att ladda ner testets data).

Nedan listas den gemensamma förbättringspotentialen för offentlig sektor i oktober 2016 och 2017, enligt Google Pagespeed API. Det är sorterat efter största problemen 2016 överst, med dess värde för 2017 strax till höger för jämförelse om hur offentlig sektor utvecklats ett år senare. Till skillnad från SPEED och USABILITY är det låga siffror man eftersträvar i dessa tester.

Mätvärde	2016	2017
MinimizeRenderBlockingResources	39.7	39.99
UseLegibleFontSizes	13.0	10.2
LeverageBrowserCaching	11.6	8.8
EnableGzipCompression	8.9	8.2
OptimizeImages	8.2	20.4
SizeTapTargetsAppropriately	5.0	3.8
ConfigureViewport	3.6	2.9
PrioritizeVisibleContent	2.2	1.6
MinifyJavaScript	2.0	1.1
SizeContentToViewport	1.7	1.2
MainResourceServerResponseTime	1.6	1.2
MinifyCss	0.5	0.2
MinifyHTML	0.4	0.2
AvoidLandingPageRedirects	0.1	0.8
AvoidPlugins	0.03	0.02
AvoidInterstitials	0.0	0.0

Några slutsatser kring det som kan förbättras

Under 2017 blockerar man ännu mer att sidor kan visa upp sig snabbt, samt att bilder är ännu sämre optimer ade jämfört med 2016.

De tjugofem webbplatser som enligt Googles riktlinjer har mest att ta tag i kan du se i nedan tabell. Siffran är en summering av webbplatsernas samtliga omdömen inom förbättring.

Webbplats:	Summerad potential:
www.overtornea.se	1189,00
www.pajala.se	819,75
www.avesta.se	495,20
www.skovde.se	478,96
www.tranemo.se	402,67
www.horby.se	355,14
www.jokkmokk.se	350,57
markaryd.se	350,28
www.tibro.se	349,33
www.vastervik.se	291,98
www.hallstahammar.se	282,38
www.sieps.se	282,25
www.munkfors.se	273,16
www.maritima.se	267,90
www.kungalv.se	260,98
www.sigtuna.se	247,93
www.kau.se	240,57
www.gellivare.se	234,58
www.historiska.se	227,50
www.polisen.se	220,25
www.hb.se	209,98
www.hogstadomstolen.se	209,71
www.ulricehamn.se	209,40
www.lessebo.se	209,07
www.statenskonstrad.se	205,33

Men för att kolla på vad Google tycker man kan fokusera på som förbättringspotential finns nedan visualiseringar av hur stor variationen är 2017 inom respektive kriterium. Dessa är uttryckta som respektive webbplats förbättringspotential. Ett lågt resultat innebär att man redan har gjort ett bra jobb. Även här visualiseras resultaten så man kan nå mer insikt än tidigare genomsnittliga siffror.

Kom ihåg: Låg siffra är ett bra resultat. Det som tycks vara den största utmaningen för alla webbplatser handlar om att inte blockera sidvisningen. Det innebär att sidan är blank och tar en stund innan det märks att det går framåt.

Ett sätt att misslyckas är att ladda in en massa CSS-filer och Javascript som hindrar sidan från att visa upp sig tidigt. Men det är inte helt trivialt att bättra på sin webbplats utifrån detta kriterium. En fallgrop kan vara att webbplatsen ser ut att ladda snabbt men att den inte är redo att interagera med trots att den ser ut att vara det.

De webbplatser som har störst problem med att blockera webbsidors visning finns i nedan tabell.

Webbplats:	Blockering:
www.lomma.se	107,9
www.habo.se	89,5
www.avesta.se	87,4
www.varberg.se	86,2
www.tranas.se	85,8

Undvik krav om plugin

Numera kräver få webbplatser att du har några skumma plugin i din webbläsare. Totalt hittades material som behöver plugin på tjugo webbplatser. Plugin som äntligen tillhör forntiden är bland annat Adobe Flash, Microsofts efterapande lösning med namnet Silverlight, Oracles Java-applets och annat sattyg från förr som inte ens leverantörerna tycks vara stolta över numera. De flesta plugins verkar snarare vara en huvudvärk då de ständigt behöver uppdateras för att nya säkerhetshål upptäcks mest hela tiden.

De webbplatser där mest pluginmaterial hittades redovisas nedan.

Webbplats:	Plugin:
www.hudiksvallstingsratt.domstol.se	6,6
www.sjobo.se	3,5
www.csn.se	1,8
www.forvaltningsrattenivaxjo.domstol.se	0,2
www.fmi.se	0,2

Anledningen till att du bör undvika att hänvisa dina användare vidare beror på att det då uppstår en ny förfrågan. Det kan ta en eller i värsta fall några sekunder innan den nya sidan börjar ladda in (på HTTP 1.1 åtminstone). Ibland blir det en kedja av hänvisningar innan användaren når målet. Detta drar ner betyget även enligt praxis inom sökmotoroptimering (SEO).

De webbplatser som Google bedömer har mest utrymme till bättring är listade nedan.

Webbplats:	Hänvisningspotential:
www.polisen.se	51
www.statenskonstrad.se	34,6667
www.nybro.se	33
www.ltv.se	28
www.fba.se	25

Viewport handlar om ifall man löst presentationen för alla de olika stora skärmar som är vanliga idag. Detta är ett mått på hur responsiv designen är.

Nu är det många webbplatser som inte fått ett så värst bra omdöme enligt Googles bedömning, så nedan är några exempel bland de 155 som inte riktigt lyckats.

Webbplats:	Viewport:
www.alingsas.se	10
www.alingsastingsratt.domstol.se	10
www.alvdalen.se	10
www.angermanlandstingsratt.domstol.se	10
www.ap1.se	10

Till skillnad från föregående potential kring viewport handlar denna om ifall innehållet får plats inom den yta som finns till förfogande. Det kan handla om att man glömt att göra sin bildhantering responsiv, att tabeller är för breda och därmed orsakar horisontell skroll, etc.

De som tycks ha en del problematiskt innehåll är bland annat de listade nedan.

Webbplats:	Innehåll vs viewport:
www.nordanstig.se	48,2
www.soderhamn.se	45,2
www.uppvidinge.se	42,9
www.fmv.se	42,5
www.osby.se	34,9

Gzip är en teknik för att komprimera textfiler, detta gör att de går fortare att överföra. Ibland blir filer endast en tiondel så stora. Som du ser i ovanstående visualisering finns det webbplatser med enormt stor potential. Det är ganska tacksamt då det inte är mycket svårare än att konfigurera sin webbplats korrekt, det tar några minuter att fixa till om man vet vad man gör och var man ska leta.

De i den högra extremen är bland annat de nedan.

Webbplats:	Gzip-potential:
www.kau.se	200,1
www.horby.se	173,7
www.kungalv.se	160,8
www.statenssc.se	130,5
www.maritima.se	112,5

Att dra nytta av användarens webbläsarcache gör att när användaren återkommer vid ett senare tillfälle så laddas inte oförändrade filer ner i onödan. Det här är en av de viktigaste aspekterna om ens användare tenderar att återkomma lite då och då. Också detta är enkelt åtgärdat genom att konfigurera webbplatsen.

De som enligt Google nog bör ta en ordentlig titt på detta listas i nedan tabell.

Webbplats:	Cachepotential:
www.eksjo.se	76,5
www.norrkoping.se	65,8
www.skovde.se	43,6
www.inspsf.se	42
www.uu.se	37,2

Denna potential handlar om att den huvudsakliga webbplatsen/domänen har en trög svarstid. Exakt vad det innebär är inte klart, men utgår man från Googles publika version av Pagespeed, Pagespeed Insights, brukar den börja varna vid en svarstid på mer än 0,6 sekunder. Det finns många tänkbara lösningar på detta problem, men det beror lite på hur stor webbplats man driver. Ett ambitiöst sätt är att kolla in webbacceleratorer som Varnish, ett sätt att börja utforska området är att kolla in CDN-tjänster som Cloudflare, MaxCDN, med flera.

De med störst problem vid testtillfället följer i nedan tabell.

Webbplats:	Trög server:
www.kulturanalys.se	61
www.historiska.se	49
www.landskrona.se	27,2
www.sala.se	24
www.hsan.se	22,5

Endast i extremfall behöver man bry sig om att minifiera som HTML-kod. Att minifiera handlar om att det inte finns överflödiga mellanslag, tabbar och radbryt. I de fall man önskar minifiera kod kan man få mothugg av sina webbutvecklare, koden blir nämligen jobbigare att läsa. Det finns dock lösningar på detta.

Trots att det är ovanligt att detta blir ett problem bör nog de i nedan lista ta sig en titt på ifall de har absurda mängder kommentarer och tomrum i sin HTML-kod.

Webbplats:	Minifiera HTML:
www.gellivare.se	19,1
www.energimyndigheten.se	16,7
www.ltu.se	9,5
www.alvesta.se	8,1
www.avesta.se	8

Inte heller när det gäller CSS brukar det vara ett problem med överflödiga mellanrum. Dessutom brukar de CSS-ramverk man lånar av andra erbjuda en minifierad version och det är ofta där lejonparten av en webbplats CSS-kod ligger.

Trots detta finns det en handfull webbplatser som nog kan behöva inspektera sina CSS-filer i jakt på prestandaoptimering.

Webbplats:	Minifiera CSS:
www.horby.se	13,7
www.hoor.se	9
www.maritima.se	6
www.gotland.se	6
www.soderkoping.se	5

Precis som för HTML och CSS kan man slösa med tomrum i Javascript-filer. Javascript som språk skrivs med en hel del korta uttryck per rad, massor med indrag eller mellanslag.

Här bedömer Google att offentlig sektor har större problem. De som har mest att vinna på att kolla sina Javascript-filer listas nedan.

Webbplats:	Minifiera Javascript:
www.hoganas.se	36,1
www.bra.se	31
www.sjofartsverket.se	16,8
www.arvsfonden.se	14,3
www.regiongavleborg.se	14,1

När det gäller hur väl anpassade bilder är för webben finns de största extremerna i detta test. Visualiseringen är grupperad om den relativa potentialen 30 för att visa på variationen, men den webbplats som har mer än 10 i detta kriterium har inte anledning att luta sig tillbaka. Lösningen är ofta att anpassa storleken på bilder och välja mer lämpliga bildformat. Konkreta tips kring bildbehandling för webben finns på webbstrategiforalla.se ^[25]

De fem mest extrema webbplatserna listas nedan. Övertorneå skickar nästan 18 Mb med bilder vilket är minst sagt mer än nödvändigt.

Webbplats:	Bildoptimering:
www.overtornea.se	1033,7
www.pajala.se	758,6
www.tranemo.se	365,3
www.skovde.se	325,6
www.avesta.se	301,3

De flesta webbplatserna inom offentlig sektor tycks inte ha problem med att prioritera att synligt innehåll visas upp innan annat material bearbetas.

Ligger man över 10 i denna bedömning är det nog ändå smart att kolla om det går att åtgärda eller ställa specifika krav på vidareutvecklingen.

Webbplats:	Prioritera synligt:
www.kungalv.se	33,9
www.tyreso.se	31,8
www.alvesta.se	23,8
www.avesta.se	22,6
www.energimyndigheten.se	22,4

Att träffytor på knappar och länkar är tillräckligt stora är en fråga om empati för användarna. Vill man vara hård kan ett tillräckligt dåligt resultat ses som diskriminering mot de med motorisk funktionsnedsättning, alltså att man kan ha svårt med precisionen med muspekare eller var man duttar med fingret.

Nu ska man komma ihåg att detta är ett automatiserat test och just tillgänglighet behöver ofta granskas av experter. Så se detta kriterium som ett potentiellt problemområde, men inget du sparkar dina utvecklare eller designers för. De som kan behöva kolla detta är fler än hundra stycken, men nedan listas de sex där Google bedömde problemet som störst.

Webbplats:	Små träffytor:
www.ab.lst.se	30
www.ac.lst.se	30
www.bd.lst.se	30
www.d.lst.se	30
www.w.lst.se	30
www.y.lst.se	30

Att textstorleken ska vara anpassad för läsning kan tyckas självklart. Då detta test körts med mobilanvändarnas preferenser blir detta kriterium lite av en indikation på vilka webbplatser som har gjort ett bra jobb med responsiv typografi, vilka som har lite kvar och att somliga har mycket kvar att åtgärda.

Nedan listas några av de med mest att vinna på att se över textstorleken.

Webbplats:	Läsbarhet:
markaryd.se	40
www.asele.se	40
www.finanspolitiskaradet.se	40
www.hsan.se	40
www.karnavfallsfonden.se	40

Slutsatser av offentlig sektors potential

Klart negativt är att offentlig sektor som kollektiv verkligen missat många enkla grejer. Som att den näst största förbättringspotentialen är att se till att text är läsbar i en mobil enhet. Kom igen, det är ju 4-5 år sedan nästan varenda offentlig organisation genomförde sina webbprojekt för det vissa kallade mobile first och andra kallade responsiv webbdesign . Att fixa textstorleken är väldigt grundläggande.

Är problemet att offentlig sektor publicerar webbplatser och sedan överger dem? De webbplatser som inte är responsiva tyder på det.

En klart enkel grej är att aktivera Gzip-komprimering. Det är några textrader i filen .htaccess för dig med WordPress, eller web.config för den som kör webbplatsen på en Microsoft-plattform. Det tar kanske en timme att fixa.

En annan enkel sak är att använda webbläsarens cacheminne. Det är lika okomplicerat som Gzip. En återkommande användare kommer inte behöva ta emot oförändrade filer på nytt. Ingenting är snabbare än att låta bli att skicka en fil.

Detta kanske många inom offentlig sektor kan sälja in på hemmaplan med att det handlar om digital krisberedskap. Under den flaggan kan många andra nyttigheter segla som kommer göra webbplatsen bättre alla dagar när det inte är kris. Dessutom blir webbplatsen bättre på att stå emot när väl krisen inträffar.

Resultat för nedladdning

Data för alla utvärderade webbplatsers prestanda, användbarhet, statistik samt förbättringspotential finns att ladda ner nedan.

Ladda ner alla data?

• Excel-fil med filtrering och enkel jämförelse mellan webbplatserna - tba.nu/webperf2017

Denna utvärdering var strikt utförd med Googles Pagespeed API. Vill du ha fler exempel på nyttiga verktyg, såväl kvalitativa metoder som kvantitativa, kan du kolla in webbanalys-boken. Den tredje delen har en fördjupning i webbanalys. Bland annat logganalys med open source-verktyget Kibana, övervakning med Pingdom, belastningsanalys med Apica och mycket mer. Kolla in boken om webbanalys hos förlaget Intranätverk^[26] (se rabattkod nedan) , Adlibris , CDON eller Bokus.

Köper du böcker via Intranätverk kan du ange kupongkoden 'friendsofintranatverk' vid utcheckningen så får du 20% rabatt.

Appendix

Metod för mätning – teknikaliteter

Med utgångspunkt från PSIdatakollen^[27] hämtades adresser till 573 webbplatser för offentlig sektor. Det bör fungera som ett bra prestandaindex för alla som jobbar med offentlig sektors webbplatser. Bland dessa webbplatser finns utöver kommuner också alla landsting och regioner. Några domstolar, myndigheter och lite övrigt följde också med.

Totalt utvärderades 60 045 sidor, alltså lite drygt hundra sidor per webbplats i genomsnitt. Ett egenhändigt kodat Python-skript (som du kan hitta på verifierad.nu^[28] ) tittade först om den hittade en sitemap.xml i webbplatsens rot. Om en sådan saknades skördades det länkar från startsidorna med hjälp av Beautiful Soup^[29] och de första 50 adresserna valdes ut för att testas. Det innebär att de webbplatser som erbjöd en sitemap.xml har testats mer grundligt än de där skriptet tvingades leta länkar på startsidan, och detta betyder även att inte alla webbplatser har exakt samma nivå av statistiskt säkerställt genomsnitt. Med andra ord behöver man undersöka en enskild webbplats lite närmare innan man drar långtgående slutsatser om vad man vill åtgärda.

Anledningen till att samla in adresser till webbplatsers undersidor är för att inte bara utgå från startsidornas prestation. Startsidor är ofta tyngre, har fler bilder, men det är också en sida man lägger mer krut på än många av undersidorna. Därför samlades även undersidor in för analys.

De ovan nämnda 60 045 sidor na kördes sedan mot Google Pagespeed API v 2.0^[30], och då med måttstocken att sätta en mobilanvändares behov först. Det är en lite tuffare nivå jämfört med desktop. Bland annat för att mobiler lever på batterier, ofta har sämre uppkoppling till nätet, används utomhus i dagsljus samt att den lilla skärmen ställer krav på designen.

Det är värt att komma ihåg att vissa webbplatser kan ha haft driftstörningar eller problem av annan art när det var deras tur att utvärderas. Några av webbplatserna har lite märkliga värden, vilket fått stor påverkan på den webbplatsens genomsnitt om det endast fanns ett fåtal webbsidor att testa inom webbplatsen. För att dra långtgående slutsatser för en enskild webbplats bör man som sagt göra en mer fokuserad undersökning på den specifika webbplatsen.

Ett genomsnitt per webbplats

Eftersom inte alla webbplatser har lika många sidor undersökta har det först gjorts ett genomsnitt för respektive webbplats. Så huruvida en enskild webbplats fick 2, 50 eller 402 sidor undersökta snedvrider inte den övergripande statistiken. Efter att varje webbplats egna genomsnitt beräknats har dessa genomsnitt beräknats för alla 5 73 webbplatsers gemensamma prestation och statistik.

Om det verkar ha gjorts något statistiskt misstag så hör gärna av dig, inte mer prestige än att det blir justerat då all grunddata finns kvar. Förhoppningsvis är detta tillräckligt grundligt för att vara nyttigt för de flesta som undrar hur det gått till. Om inte annat är det fritt fram att ställa frågor på Twitter till @webbstrategiskt

Tips på verktyg

1. Google Pagespeed API/Insights
2. Sitespeed.io
3. Webpagetest.org
4. Pingdom, dock endast för svarstider

Tips på fördjupande läsning/tittande

1. Webbanalys - förstå och förbättra användarnas upplevelse^[31], av Marcus Österberg (2016)
2. Webbstrategi för alla, kapitlet om webbprestanda^[32], av Marcus Österberg (2014)
3. Design for performance^[33], av Lara Hogan (2014)
4. Time is money - The business value of web performance^[34], av Tammy Everts (2016)
5. Ilya Grigoriks föreläsning^[35] på Google i/o om att webbplatser inte är så pålitliga som vi tror (2016)

---

Referenser

5 senaste rapporterna

• Webperf #58
• Ha din Plan B att flytta från amerikanska molntjänster - hälsar dataskyddsmyndigheter i Europa
• Webperf #57
• Inventera kakor på din webbplats med Screaming Frog - de flesta kakor är olagliga utan samtycke!
• Webperf #56