Uppsala.se under prestanda-luppen

Idag, 18 år senare, hörs vi mest av över Twitter, samt att jag avundsjukt kollar in alla vettiga grejer han och kollegorna på Uppsala kommun får till (och berättar om på sin utvecklingsblogg). Att min arbetsgivares utvecklingsblogg har likheter är rena slumpen, tro mig :)

Så när Sebastian föreslog att jag skulle inspektera deras webbplats prestanda var det enkelt att tacka ja. Kanske mest för att jag var nyfiken på vad jag skulle hitta.

Okulärbesiktning

Vid en titt så kommer man snabbt fram till att de gör många rätt. Bland annat att de använder det där magiska S:et i HTTP-protokollet, det som gör att man kan vara trygg med att fylla i formulär och ingen snokare på samma datornätverk enkelt kan fånga upp vad jag skrivit.

Dessutom, hur lyckades man bli av med alla nyheter och annat nonsens som alla vi andra inte haft viljestyrka att stå emot när intressenter, chefer och andra dignitärer krävt att även de måste få vara med på startsidan. Vill man ironisera något så saknas det två-tre varianter av nyhetsspalter, en sån där karusell, du vet de där som mest irriterar om man för en gångs skull faktiskt försöker läsa vad där står. Om du tvekar kring att använda en sån där förbenad karusell så kolla in shouldiuseacarousel.com först :P

Uppsala tycks vara befriade från nonsens. Flera med mig lär ju vilja veta vad hemligheten är, hur man lyckats.

Responsiv webb istället för 100 sidor PDF!

En annan sak man lyckats med är att publicera årets mål och budget-dokument som en responsiv webbplats. Detta istället för ett hundrasidigt PDF-dokument, något som skulle ha varit direkt användarfientligt för de som fått för sig idén om att läsa innehållet på sin mobil.

Det många nog inte tänkt på är att när ens webbplats är mobile first egentligen handlar om att värna allas rätt till att delta i vårt demokratiska samhälle. Vilka är vi i offentlig sektor att kräva att man ska vara tvungen att skaffa en apparat med stor skärm, och kanske en extra internetuppkoppling, för att ta del av var ens skattepengar går?

Men om jag ska växla till en mer konstruktiv sida och inte köra fast i hyllandet, då kan man konstatera att det inom Uppsalas domän ryms hela 16 600 PDF-filer. Många av dem tycks tillhöra de kommunala skolorna, så per definition är de inte en del av samma webbplats, men ändock en teknisk skuld någon kommer få reda ut förr eller senare.

För att kolla hur mycket PDFer man har som ligger och hotfullt lurar på ens mobila användare kan man googla enligt följande syntax:

site:uppsala.se filetype:pdf

Vilket språk pratas det bakom kulisserna?

Något som nästan alla webbplatser inom offentlig sektor låtit bli är det som SEO-folk kallar för RDFa, eller vad vi informationsarkitekter kallar för semantiskt berikat innehåll. Poängen är att man följer en standard så att den text och kod man publicerar på en webbplats inte bara har ett utseende och innehåll - utan också att man gör tydligt vad något är.

En tidig standard för detta var nu ganska inaktiva Microformats, numera är nog Schema.org mer känt. Det är ett sätt att beskriva kontaktuppgifter, recensioner och mycket mer. Uppsala har visserligen lite grann av detta, problemet är att det inte validerar ännu, åtminstone inte enligt Googles sätt att se på saken. Detta kan man nämligen kolla med Googles Structured Data Testing Tool, där följande klagomål ges just nu:

Du måste bifoga en ContactPoint till en överordnad med en angiven typ.

Men som sagt, de flesta webbplatser jag inspekterat har inte ens försökt sig på detta ännu. Ska det vara lönt så är det bra om man bestämt för vems skull man gör detta. De flesta kommer nog att komma fram till att de primärt vänder sig till Google, att man vill ge Google data i ett strukturerat format för att förhoppnignsvis vinna lite mer utrymme i sökresultatet. I så fall är det hos Google man får besked om de tycker man har bra nog med strukturerad data.

Och när jag ändå är inne på kodkvalitet så körde jag Uppsalas startsida genom Netrelations tjänst Inspector. Det är nog första gången den inte hittat något alls att klaga på! Något som Inspectorn uppenbarligen inte fångade var att sökfältet är helt ur funktion i Firefox, åtminstone 44.0.2. Det händer inget när man klickar på Enter-tangenten, eller klickar på sökknappen. Funkar dock kanon i Safari. Hmm.

Statistik för en sidvisning på uppsala.se

För att gå igenom hur en typisk sidvisning är på uppsala.se så fick jag en lista med 1000 adresser av Sebastian. Nedan siffror är ett genomsnitt av hur Google ser på dessa sidor enligt sin tjänst Pagespeed Insights API och då med mobila inställningar. Jag har alltså frågat Google om tusen undersidor och fått fram följande i storleksordning:

1. Javascript-filerna väger 723 Kb (okomprimerat)
2. Stilmalls-filerna väger 154 Kb (okomprimerat)
3. "Andra" filer, oftast egna teckensnitt 86 Kb
4. Bilder på 86 Kb
5. HTML-kod det vill säga innehållet och dess struktur 57 Kb (okomprimerat)
6. Förfrågansinfo, exempelvis cookies 3 Kb
7. Svarskod 216 (om snittet vore 200 skulle inga Error 404-sidor finnas, eller 502 Server error)
8. Antal filer per sidvisning 31 st
9. Antal statiska filer 21 st
10. Antal Javascript-filer 9.2 st
11. Antal värdar/domäner 8.9 st
12. Antal stilmalls-filer 3.9 st

Kommentarer på detta är att det är ganska vanliga siffror. Kanske att 154 Kb i stilmallar är ovanligt lite. Angående punkt sju så noterar du som läst min bok Webbstrategi för alla - och särskilt delen om URL-strategi - att jag envisas med att man ska vårda och behålla inarbetade adresser. I mycket stor utsträckning gör Uppsala det, men det finns bevisligen fortfarande en outnyttjad potential i att få sin svarskod ännu närmre 200 :)

Konstruktionskvalitetet kan alltid bli bättre

Om jag ska bitcha lite kring konstruktionskvaliteten så är de 9 st Javascript-filerna i alla fall 6-7 st för många, på en riktigt trög 3G-uppkoppling kan det handla om 10 sekunder i extra väntan. Men samtidigt, sprider man ut sina filer på nästan 9 olika domäner/värdar så kör man low-tech-optimering à la HTTP 1.1 då man i många fall kan skicka fler filer parallellt på det sättet. Även när det gäller stilmallar klarar man sig gott på en endaste, frågan är mer om man ens ids ta den diskussionen med sina webbutvecklare eller om det kommer kosta mer än det smakar om man råkar vara först (och således få betala för att de lär sig hur man optimerar ordentligt).

Användbarhet och sidornas pagespeed

Orkar man inte fokusera på många siffror så kokar Google ner helheten rätt bra till nedan siffror. Genomsnittet på uppsala.se är alltså:

• Usability - 98.5 av 100
• Pagespeed mobile - 68.9 av 100

Att man inte får full pott i användbarhet beror nästan uteslutande på att några träffytor är för små eller placerade för tätt inpå varandra. Risken är alltså att man klickar/duttar på fel länk eller knapp.

Oj då, Episerver klantar till det :/

Pagespeed-betyget är rätt bra. Men, för första gången har jag hittat en sida som fått noll i betyg. Den har en mix av många misstag, kanske främst irriterar sig Google på att det är 7 Mb med bilder som kan förminskas med 82 %. Sånt är lätt hänt, inte helt enkelt att upptäcka enormt stora bildfiler som redaktör om man sitter på jobbets snabba uppkoppling, detta är ju något som ens webbpubliceringssystem måste hjälpa en att undvika.

Episerver Find

Ett annat riktigt magplask (som Episerver får ta på sig som sinkar varje sidvisning) är att man hämtar en fil från Episervers "moln" via adressen https://dl.episerver.net/11.1.1/epi-util/find.js vilket jag tror är för att man använder Episervers sökmotor Find. Kolla in den adressen noga. Den innehåller något som tycks vara en versionsnumrering, nämligen 11.1.1, och grejen med versionsnumrering i filer är att filens innehåll består under hela filens levnad. Om något behöver ändras räknas versionsnumret upp, säg till 11.2, vilket ger en helt annan adress.

Men istället för att följa god praxis fullt ut så sätter man den där filens förväntade livslängd till "expiration not specified", det innebär att den behöver laddas ner på nytt vid varje besök på webbplatsen. Helt i onödan! Som före detta Episerver-utvecklare har jag många gånger haft anledning att ondgöra mig över deras okunnighet om webbstandard, eller hur halvhjärtat de slängt ihop exempelmallar (minns du deras RSS-filers description?) och det här är vatten på en sedan länge översvämmad kvarn... Lär er använda browserns cache för jösse namn!1!

Något Uppsala själva kan bättra sig på är att se över varför bilder i mappen ~/contentassets/ har en förväntad livslängd på endast 12 timmar. Jag tippar på att de är hyggligt statiska och att man kan öka denna inställning till minst 30 dagar. Då kommer en medborgare som gör ett återbesök på en undersida inte behöva ladda ner samma oförändrade fil redan efter 13 timmar :)

Men de sidor som har större prestandaproblem än genomsnittet tycks handla om att man har dåligt optimerade bilder, det är tacksamt nog ganska enkelt att åtgärda. Dessutom är de inte så många, kolla in dessa:

• https://www.uppsala.se/organisation-och-styrning/publikationer/strategisk-forsorjning-av-utbildningslokaler-2016-2020/strategisk-forsorjning-av-utbildningslokaler-2016-2020/
• https://www.uppsala.se/kampanjsidor/undersokning-av-gamla-lertakter/
• https://www.uppsala.se/organisation-och-styrning/sa-fungerar-kommunen/fortroendevalda/

Sen är det uppenbarligen så att SKL (Sveriges Kommuner och Landsting) får ta på sig skulden för att med sitt Javascript-baserade öppna data-tänk skickar okomprimerat innehåll. Så samma problem lär vi ha även på min arbetsplats med vår egen PSI-datasida, precis som uppsala.se/psidata

Vad tycker Google är mest angeläget att fixa?

Dessa siffror tycker jag nog är de mest intressanta från Googles Pagespeed. Jag har tyvärr inte hittat något bra sätt att få fram samma typ av data, alltså viktade faktorer, utan att gå rakt mot deras API.

1. Minska blockering av rendering - 30.7
2. Använd webbläsarens cache - 9.1
3. Använd GZip-komprimering 3.2
4. Optimera bilder för webben - 2.1
5. Prioritera synligt innehåll - 0.6
6. Minifiera stilmallar - 0.5
7. Använd läsbar textstorlek - 0.3
8. Långsam svarstid på webbservern - 0.26
9. Gör träffytor på länkar & knappar stora nog - 0.2
10. Justera innehålls storlek i relation till viewport - 0.17
11. Konfigurera viewport - 0.07
12. Minifiera Javascript-filer - 0.02
13. Minifiera HTML - 0.02
14. Undvik plugin - 0
15. Undvik omdirigeringar på landningssidor - 0

Här hamnar man dessvärre om en sida kastats.

Den första punkten är ett systematiskt och stort problem, inget man löser genom något annat än redesign eller ganska omfattande utgifter. Det handlar om att man genom sin struktur av CSS och Javascript blockerar sidan från att snabbt visa upp sig. Vill man experimentera lite och hoppas på en rimlig lösning så kan man kolla vilka Javascript som kan köras asynkront eller placeras i slutet på HTML-koden, detsamma med CSS, samt att man kan bädda in strukturell CSS-kod direkt i HTML-koden. Troligen är det värt att vänta till nästa gång.

Punkt 2-4 är däremot något man borde ta tag i. Dels för att man har systematiska problem (vilket gör att en förbättring slår igenom på många sidor) men också för att de i min erfarenhet inte är jättesvåra att lösa. Jag bifogar datakällan bakom analysen nedan, om man läser in CSV-filen i Excel kan man sortera fram vilka adresser som har högt 'ruleresult', sedan kör man dem manuellt genom Pagespeed Insights för att bekräfta problemet och sedan pånytt för att se förbättringen.

Vill man ha en lista över de "värsta" sidorna att beta av en efter en så finns här de 250 med aggregerad förbättringspotential (PDF) ›

Angående datakvalitet

Man behöver komma ihåg att till viss del smutsas dessa data ner av hur Episerver hanterar felsidor. Exempelvis beklagar sig Google Pagespeed enormt över sidor som sedan visar sig vara kastade eller fortfarande ligger i papperskorgen. Varför en besökare på en vanlig webbplats bemöts av ett inloggningsdialog till Episerver övergår mitt förstånd, men samma problem har vi ju inom VGR. Det gör ju ens URL-strategi ännu viktigare, det är inte självklart att man ska kunna få kasta sidor - om man nu inte tycker det är ok att medborgare hamnar på inloggningsfönster stup i kvarten.

Jag har märkt att många inte riktigt förstår problemet med att vara slösaktig med sina adresser. Utöver att upprepa argumenten jag skrev ned i Webbstrategi för alla så har jag märkt att det finns en övertro på att folk navigerar sig fram på en webbsida. Nu är det inte riktigt så vanligt som somliga tror att varje besök börjar på sajtens startsida och att användaren lydigt klickar på länkar för att nå fram. Användare har gamla/befintliga adresser i sin adresshistorik i webbläsaren, de kan ha fått dem i mejlen, det kan finnas i ett dokument, man kan hitta dem på ett intranät vilket är komplett osynligt för dig som skapar en publik webbsida, de kan försöka hitta tillbaka via ett bokmärke, med mera. Med andra ord, att få sätta en ny URL till världen förpliktigar. Den behöver omvårdnad och det är inte schysst att slänga en etablerad URL i papperskorgen - den ska som allra minst hänvisas till något motsvarande!

Tro inte att Uppsala är sämre på denna fronten än någon annan. Anledningen, tror jag, till att det på många webbplatser är så pass eländigt är att vi som avsändare inte själva drabbas av våra egna beslut. Vi är usla på att vara representativa som användare av våra egna webbplatser!

Personligen skulle jag hävda att de gjort bra ifrån sig. Men jag vet att Sebastian skulle vara lite besviken om jag inte la manken till att hitta grejer de kan göra ännu bättre. Så se denna post för vad den är, ett sätt för Uppsala att överprestera på de punkter mitt hjärta bultar för.

Passus: Apica och MKSE utser prestandavinnare 2016

Jo, jag förstår att somliga tycker att jag är oldman av prestanda (andra skulle kanske kalla mig prestandataliban). Men jag tycker faktiskt att det är lite smickrande att jag får mejl av folk som ber mig "klä av MKSE" och deras prestandapris. Javisst, MKSE:s pris är något godtyckligt i sitt urval, men jag själv är inte direkt vetenskaplig. Möjligen i den där kommunjämförelsen då alla är med.

Sen tycker jag att det är smickrande att Apicas PR-maskineri skickar mig ett pressmeddelande via den här sajtens kontaktformulär för att göra mig medveten om att de redan testat IDG:s topp-100-lista för 2016. Bra och snabbt jobbat!

Ladda ner datakällan (och läs mer om webbprestanda i min bok)

Vill du själv leka med dessa 31 000 datapunkter? Den finns att ladda hem som zippad CSV-fil. Den funkar att importera i Excel, eller Tableau Public.

Blev du sugen på att lära dig mer om webbprestanda? Då kan jag rekommendera min bok Webbstrategi för alla som har ett avsnitt om prestandaoptimering i bred bemärkelse - allt från det alla behöver veta om index i databaser till hur man hushåller med resurser.