WebperfInnan jag börjar förklara vad man skulle kunna göra bättre vill jag poängtera att så gott som varje webbplats jag sett (inklusive de jag själv byggt) har haft saker som kunde varit bättre ur prestandasynpunkt.
Dock blir det i krissituationer extra viktigt att vara extremt aktiv med hur ens webbnärvaro fungerar. Är det ett överbelastat nät så försöker man fixa det, går webbservern på knäna får man försöka lösa det, ansluter besökarna primärt via mobila enheter… ja, du fattar poängen.
Jag tänkte med detta inlägg gå igenom de mest grundläggande sakerna jag på förhand är medveten om att titta på om jag själv blev inkallad för kriskommunikation hos min arbetsgivare.
Finns det ett problem?
Först och främst är det viktigt att skaffa sig en bild av vad problemet egentligen är och om det ens finns något. Nu kanske det låter som att jag är en expert på detta och det bör påpekas att det är jag inte. Däremot har jag under många år tampats med att få en populär, och ytterst säsongsbetonad, webbplats att fungera över huvud taget på ett allt för billigt webbhotell. Under de åren har jag fått utså rätt många varianter av problem med hur en webbplats presterar och fått lite av ett intresse för prestandaoptimering på köpet.
För att lista ut vad prestandaproblem kan vara, bortom de anekdoter man hör rapporteras av sin omgivning, är webbanalys det bästa du kan göra. Då menar jag inte enbart att granska webbstatistiken utan hela verktygslådan som står till ditt förfogande.
Segmentera din webbstatistik och gör en snabb webbanalys
För att få reda på vilka dina besökare är under krissituationen behöver du förstås välja det tidsspann krisen existerar i, finns det dessutom någon form av realtidsvy är det också värt att titta i. Det du är ute efter är att lära känna det troligtvis förändrade besökarmönstret din webbplats får utså under krisen. Kanske finns det tekniska lösningar (som en inaktiv cache-lösning) du kan aktivera för att avhjälpa många samtidiga besökare på relativt få sidor?
Kanske kan du med hjälp av segmentering (att skärskåda vissa grupper av besökare alltså) se illavarslande saker du faktiskt kan avhjälpa.
Utöver att granska Google Analytics eller motsvarande skulle jag också kollat hur de tekniska förutsättningarna är på webbplatsen. Detta för att vara välinformerad när jag troligtvis behöver ta proaktiva beslut kring driften av webbplatsen. Först skulle jag kollat Google PageSpeed som ger en snabb överblick över teknikaliteter som påverkar besökarnas möjlighet att använda webbplatsen. Tänk på att ovanligt många av dem kanske för stunden använder en mobil uppkoppling, eller att det är på liv och död för de som använder en mobil uppkoppling.
Tips från PageSpeed har en ganska stor bredd men det kan exempelvis vara att webbplatsen inte skickar textmaterial komprimerat - vilket leder till upp till tio gånger segare överföring. Eller att bilder inte är optimerade för webben och därmed gör det så långsamt att besökarna ger upp. Det PageSpeed inte säger är att din webbserver har begränsat antal samtidiga besökare den kan hantera. Ju längre tid varje sidladdning tar desto färre besökare kan din webbserver hantera per tidsenhet. Med andra ord är en webbplats som är seg i normala fall ett ganska säkert sätt att överbelasta sig själv när krisen väl slår till.
Lite andra tips kan man få från YSlow för att få tips på allt från innehållsnätverk till statistik över vad sidan utgörs av för sorts material. Det jag gillar mest från YSlow är den tydliga grafen för hur ett återbesök kommer att te sig, om mycket onödig info laddas in på nytt eller ej.
Om du är tekniskt lagd så kan en snabb titt i webbläsarens utvecklarläge vara värt ansträngningen, i Chrome finns Network att titta på exempelvis. Där kan du finna mönster att jobba vidare med, som att det är den initiala svarstiden som är bekymret (tyder på behov av cache).
Studie i vad som kunde varit bättre i Norbergs kriswebb
Jag tänkte exemplifiera med den tillfälliga kriswebb Norbergs kommun (norberg.sitevision.se) fick upp på CMS-företaget Sitevisions molnlösning. Det vore bättre om man inte behövde växla till en kriswebb över huvud taget, men då jag inte kan se deras vanliga webb tänkte jag att vi kan lära lite av vad som kan göras bättre med en kriswebb. Några snabba siffror om Norbergs kriswebb hittar du på Webbfunktions optimeringstest och hos Google PageSpeed Insights.
Norbergs kriswebb i siffror 5:e augusti:
- Google PageSpeed-betyg: 65 av 100 från ett mobilt perspektiv, 83 av 100 från en skrivbordsdator.
- Sidladdning totalt: 1,7 Mb (≈ 500 Kb att föra över i komprimerad form, notera att nedan siffror är i okomprimerad form)
- Information/HTML: 0,016 Mb (≈1 % av totalen)
- Bilder/logo: 0,05 Mb (≈3 % av totalen)
- Stilmallar/presentation: 0,46 Mb (≈27 % av totalen)
- Javascript: 1,2 Mb (≈69 % av totalen)
- Antal stilmallar: 6 stycken.
- Antal Javascript: 3 stycken.
- Totalt antal filer: 16 st.
Det blir rätt tydligt med siffrorna ovan att man slösar med folks bandbredd då aktuell webbplats inte behöver använda Javascript alls vad jag kan se. Bandbredd kan vara en väldigt begränsad resurs i en krissituation, särskilt för de på mobil uppkoppling. Är inte själv i krisområdet men på min 3G-uppkoppling just nu ger Bredbandskollen mig det dystra beskedet att jag för stunden har 0,07 Mbit/s i nedströms hastighet och ingen uppströms alls. Slarvigt omräknat till Norbergs exempel ovan är det 0,007 Mb per sekund (vilket förklarar varför nästan inget på nätet tycks fungera) och Norbergs kriswebb skulle då ta 67 sekunder att ladda in. Utan Javascript, stilmallar och loggan i toppen däremot skulle det ta 1,5 sekund…
Nu tänkte jag gå in i detalj på den förbättringspotential Norberg och andras kriswebbar kan hämta hem under de beräknade, smått ofattbara, 2–4 veckorna av släckningsarbete de har framför sig.
Storleken på en sidladdning
För alla oss som sitter på kontor är trög uppkoppling något vi inte ens förstår. Inte innan vi befinner oss i radioskugga under semestern, försöker mobilsurfa under en biltur i ödemarken eller dela ett foto på en idyllisk utsikt på Facebook.
Försök visualisera att det kan vara ett enormt antal personer tillfälligtvis på en enda mobilmast så kan det vara lättare att avstå alla utsmyckningsbilder och att den grafiska profilens krav kring logotyp och organisationens färgschema kanske får stå tillbaka för en stund om kriswebben måste aktiveras.
Försök att hushålla med resurserna även på den vanliga webbplatsen på alla sidor där krisinformation ges. På en mer renodlad kriswebb går det säkert att argumentera för en logotyps användbarhet men se då till att den åtminstone är (hårt) optimerad för visning på webben.
Länka gärna till nyttiga bilder på en kriswebb, men om du bäddar in dem kommer den filen att tynga ned samtliga besökares försök att nå det allra viktigaste.
Skickas onödig information?
Ja, herregud. Idag är vi så bortskämda med bra uppkoppling att det mesta vi tar emot inte är meningsbärande innehåll såsom text eller bilder. Många webbplatser är konstruerade för att vara enkla att framställa för ett fåtal webbutvecklare snarare än effektiva hos mängder av besökare.
Norbergs kriswebb är dessvärre även den ett exempel på detta med sina 4 procent av sidans tyngd som är bilder, läsbart innehåll och dess struktur.
Du som sitter med en “responsiv” webbplats av idag kan ha dragit på dig en onödigt brant uppförsbacke vid en krissituation då många tidiga responsiva webbplatser innehåller massor av riktigt stora bilder. Inte sällan massor med stilmallskod för att tala om hur designen ska se ut och Javascript för att få det att fungera i äldre webbläsare m.m.
I Norbergs fall skickar man 0,463 Mb stilmallskod för att beskriva att logotypen ska vara proportionerlig och vilka färger texten ska ha, dvs svart. Det är alltså mer text än min bok på 240 sidor. För dig som inte kan koda CSS så är det rejält i överkant för att uttrycka det milt.
Hur skickas filerna till besökaren?
Det är inte särskilt långsökt att tänka sig att många av besökarna på dessa kriswebbar är återkommande besökare under en kortare tidsperiod. Därför blir det extra viktigt att planera hur man hanterar utgångsdatum på filer så att besökarna får aktuell information men samtidigt inte laddar hem material som inte förändrats sedan dennes senaste besök.
För att sköta detta finns instruktioner att skicka med respektive fil så besökarens webbläsare vet om filen förändrats eller inte. En oförändrad fil som inte laddas ner besparar både besökaren, dennes med andra delade uppkoppling, och din server onödigt arbete.
Norbergs kriswebb använder dessvärre inte detta bäst-före-datum på alla filer. Det vill säga de talar inte om filernas förväntade livslängd. Det gör att filer som loader.white.png, drop-shadow.png med flera riskerar att skickas på nytt till besökarna vid varje besök - helt i onödan.
Är bilderna optimerade?
Jämfört med text är bilder och annan media väldigt tungt material. I många fall är det säkert så att en bild säger mer än tusen ord, men om innebörden är att alla bör utrymma sina hus är text troligtvis mer effektivt per överförd etta och nolla till besökarna.
Norbergs kriswebb har en logga i toppen. Den kan optimeras för webben med 9,8 Kb vilket nästan motsvarar all meningsbärande text på sidan. Så glöm för guds skull inte bilderna om de behöver få vara med.
Sammanfattningsvis skulle jag säga att om Norberg bara gjorde sig av med onödig Javascript och stilmallskod så skulle det vara en rätt bra kriswebb.
Ta hjälp av oss andra…
Om du sitter i situationen att det är du som ska fixa med en kriswebb lär du kunna finna folk som hjälper dig på traven genom att använda ditt sociala nätverk. Åtminstone jag bjuder gärna på lite distanshjälp om någon branschkollega sitter i trångmål och jag har svårt att tro att jag är ensam. Mitt nummer finns uppenbarligen att hitta via nätet om just jag kan hjälpa till med något.
