Örebro slott (fotokredd: paul frankenstein on-flickr-cc-by-nc)

Webbanalys-rapport av Länsstyrelsen i Örebro län

Jag lovade under förra året att köra lite extern webbanalys på några sajter inom offentlig sektor. Först ut av dem är Länsstyrelsen i Örebro län. Kommer senare att följa upp med Malmö Stad, Trelleborg och Varberg. Hör gärna av dig med frågor och kommentarer, antingen här i kommentarerna eller på Twitter.

Tillvägagångssätt

Jag har plockat alla adresser som länkas från i första hand webbplatsens sajtkarta, detta för att få en bred bild över hur sidan fungerar i praktiken. Totalt sett har 288 sidor, inklusive startsidan, analyserats genom automatiserade kontroller via Google Pagespeeds API men också en del dataanalys och stickprov vid behov.

Google Pagespeeds bedömningar går att få antingen med en skrivbordsdators inställningar, preferenser och behov, eller så väljer man en “mobil strategi”. I detta test har jag kört med mobila inställningar. Med tanke på dagens användare är det nog osmart att blunda för mobilanvändarens behov, dessutom kommer vissa tveksamma designbeslut tydligare fram i dagen om man kör med dessa inställningar.

Det finns förstås mycket mer man kan analysera, detta är endast ett skrapande på ytan. All insamlad data finns att ladda ner som kommaseparerad textfil (CSV). Det lämpar sig utmärkt för den som är bra på Excel, den som vill importera till en databas eller om man vill leka visualisering med exempelvis Tableau Public.

Ladda hem webbanalys-lst-orebro.csv som ZIP-fil ›

Koden bakom testet finns på Github. Du som inte är rädd för lite kodning i Python kan utgå från default.py så ser du snabbt vad jag gjort.

Statistik

I denna statistik finns två dimensioner. Dels den statistik som beskriver webbplatsens sidor och ger genomsnittsvärden. Den andra delen är den förbättringspotential Google ser utifrån webbprestanda, användbarhet och därigenom sökmotoroptimering.

Genomsnittliga värden för en sidvisning hos Länsstyrelsen i Örebro län:

  1. Pagespeed mobile: 45.17 av 100
  2. Användbarhet: 61.1 av 100
  3. CSS per sidvisning: 234 Kb
  4. HTML per sidvisning: 123 Kb
  5. Bilder per sidvisning: 171 Kb
  6. Javascript per sidvisning: 1,34 Mb
  7. Antal CSS-filer: 12 st
  8. Antalet inblandade domäner: 7.7 st
  9. Antal Javascript-filer: 25 st
  10. Antal filer totalt: 60.4 st
  11. Antal statiska filer: 48 st
  12. Responsdata/cookies: 3,3 Kb
  13. Längd på sidtitel: 50.3 tecken
  14. HTTP-data mellan klient och server: 11,5 Kb

Kommentar: Som vanligt en jäkla massa Javascript. Utan att ens läsa koden kan man dra slutsatser om att man troligen valt ett icke-optimerat ramverk där allt, fan och hans moster ingår oavsett om man har användning för det på sin webbplats. Detta är väldigt vanligt på responsiva webbplatser, men förhoppningsvis något som försvinner när man mognat inom modern webbdesign och håller igen lite. I övrigt är inte siffrorna särskilt ovanliga, men nog är webbplatsen tyngre än nödvändigt och kan optimeras en hel del.

Förbättringspotential enligt Google

Dessa förbättringar (se relativt värde enligt Google) kan vara värt att ta tag i uppifrån:

  1. Inte låta Javascript & CSS blockera sidans visning: 57.7
  2. Aktivera komprimering/GZip: 56.8
  3. Använd läsbar textstorlek: 40
  4. Låt knappar och länkar ha tillräckligt stor träffyta: 14.1
  5. Webbserverns svarstid är långsam: 11.4
  6. Innehåll passar inte in på skärmen (en mobils viewport): 10
  7. Minifiera Javascript-filers innehåll: 6.8
  8. Optimera bilder för webben: 4.5
  9. Använd webbläsarens cache (livslängd på filer, TTL): 4.3
  10. Minifiera CSS-filers innehåll: 3.6
  11. Omforma innehåll efter skärmens storlek: 2.8
  12. Minifiera HTML-filen: 0.37
  13. Prioritera synligt innehåll: 0.08
  14. Undvik att kräva tillägg i webbläsaren (som Adobe Flash): 0.08
  15. Undvik hänvisningar: 0.033

Hur ska man läsa denna lista då? Jo, kolla in siffran som avslutar raden. Den förklarar hur allvarligt Google tycker att den punkten påverkar webbplatsens kvalitet. Med andra ord finns det egentligen tre väldigt viktiga grejer att ta tag i med denna webbplats.

Sen måste man som webbplatsansvarig ta reda på hur komplicerad respektive lösning är. Punkt 2 råkar vara en fullträff i detta sammanhanget, den är skitenkel att fixa och har stor påverkan på resultatet. Ofta är även punkt 9 enkel att ordna för de flesta filer, men har inte riktigt samma hävstång.

Innehållsanalys

Långa sidtitlar är ett problem då man inte vet hur mycket som syns i besökarens flikar i webbläsaren, hur mycket sökmotorerna visar upp, m.m.

67 av 288 sidor hade sidtitlar längre än 60 tecken. Den genomsnittliga längden är 50,3 tecken. Rekommendationen är lite varierande, men för SEO nämns ofta att man bör ha 50–70 tecken för att nå ut i träfflistan, men samtidigt måste allt väsentligt rymmas inom de första 50 tecknen.

Anledningen till längden på denna webbplats är att man har en sidtitel-syntax som avslutar alla sidtitlar med “ – Länsstyrelsen i Örebro län”. Det finns mig veterligen ingen riktlinje för utformning av sidtitlar, åtminstone inte mer än att de gamla vanliga kommunikativa riktlinjerna om viktigast först och hålla sig kort.

Nedan är de tio längsta sidtitlarna, fast jag har kapat av dem så endast de 50 första tecknen syns. Som du ser är de flesta rätt tydliga om vad sidan innehåller så längden till trots är de klart godkända.

  • “Länsstyrelsens arbete inom alkohol, narkotika, dop”
  • “Bestämmelser om kräftfiske på allmänt vatten i Vät”
  • “Flyktingsituationen och mottagandet av asylsökande”
  • “UTCED – femlänssamverkan för kvinnors företagande”
  • “Personligt ombud för personer med psykisk funktion”
  • “Naturliga möjligheter – företagens guide till natu”
  • “Anmälan och ansökan om tillstånd – miljöfarlig ver”
  • “Information tillgänglig för vidareutnyttjande – Öp”
  • “Invasiva arter – främmande djur och växter i vår n”
  • “Ramdirektivet för vatten och svensk vattenförvaltn”

Sen tror jag att jag är ganska ensam om att iakkta hur adresserna ser ut. Nu har man både systemstandarden med avslutande .aspx från Microsoft samt att man använder stora bokstäver. Har nästan ett helt kapitel om URL-strategi i boken om webbstrategi.

Länkar till sidor användaren inte har behörighet till

Sexton av 288 sidor som samlats in är behörighetsskyddade. Då HTTP-kod 401 anges som felmeddelande antar jag att de endast är åtkomliga för personer sittandes på Länsstyrelsens interna nätverk.

Såna här grejer kan vara luriga. Som ansvarig, eller testare av en webbplats, är man inte särskilt representativ som användare. Exempelvis kanske man inte på jobbet upptäcker att man länkar till material som inte är publikt åtkomlig, som inte ens ger användaren chansen till inloggning eller ett bra svar på varför en sådan länk finns på publika webben.

Kommentar och rekommendation

Länsstyrelsen i Örebro läns webbplats ser ur denna synvinkel ut som majoriteten av webbplatser jag testat. Man har ett antal saker man kan ta tag i för att göra den bättre ur en mobilanvändares perspektiv och på köpet också bättre för alla andra – inklusive sökmotorerna.

Rekommendation kring webbprestanda

Som alla andra webbplatser av idag är det en god idé att bevaka frågan om övergång till HTTP/2. Då kommer flera av de praxis kring webbprestanda man ännu inte tagit till sig bli onödiga att åtgärda. Snarare är det så att de 25 st olika Javascript-filerna man har idag med HTTP/2 nästan är att betrakta som klokt. Fast med dagens HTTP 1.1 kan det orsaka en halv minuts extra väntan på att börja överföra filerna om användaren är på en skakig mobiluppkoppling.

Av de punkter från Googles viktade lista finns det tre uppenbara grejer man kan kolla omgående ifall de är lätta att lösa, nämligen:

  1. Aktivera komprimering. Detta gör att statiska textfiler som skickas blir cirka en tiondel så tunga, det går helt enkelt mycket snabbare. I de miljöer jag jobbat med, WordPress och Episerver CMS, har detta varit så simpelt som en kryssryta/konfigurationsändring och sedan är det klart.
  2. Utvärdera textstorleken. Anlita en grafisk formgivare med specialitet inom typografi på webben. Låt denne kolla hur det står till med webbplatsens typografi ur en mobilanvändares perspektiv (utan att sumpa det för skrivbordsdatorer).
  3. Använd webbläsarens cache. Det snabbaste av allt är att inte skicka filer till en användare om de inte har ändrats sedan förra besöket. Sätt gärna filers förväntade livslängd (TTL – Time To Live) till 30 dagar. Om en fil förväntas ändras inom 30 dagar så kringgår man detta genom att ge den ett nytt namn när den ladas upp, svårare än så är det inte.

Rekommendation kring användbarhet

På denna punkt fanns det lite mer att ta tag i än vad jag är van vid. Att utreda textstorleken är grundläggande, men också kolla i detalj hur ofta länkar/knappar är placerade varandra. Ofta beror det problemet på att man har punktlistor med länkar och det inte är givet att en mobilanvändare med motorisk funktionsnedsättning (eller bara är lite äldre) träffar rätt länk.

Jag tycker nog att man ska sträva efter att väsentligt höja sitt användbarhetsvärde (usability hos Google Pagespeed). Egentligen borde man betrakta allt under 100 (av 100 totalt) i betyg som en innehållsbugg man rättar omgående.

Avslutningsvis…

Jag rekommenderar alla att sätta upp en prestandabudget. I den så börjar man sätta vilka lägsta-nivåer man tolererar på sin webbplats. Siffrorna ovan är ett bra ingångsvärde för att veta att man inte budgeterar något komplett omöjligt, att man gör utmaningen lite lagom svår vid en redesign, osv.

Mer om webbanalys

Leave a Reply

Your email address will not be published. Required fields are marked *