Close

Norbergs kriswebb och skogsbranden i Västmanland

Norberg kommuns webbplats under skogsbrandenInnan 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 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.

Boken Webbstrategi för alla tar upp en hel del om webbprestanda och andra exempel på kriser relaterade till stormar och svininfluensa.

Läs mer om skogsbranden i Västmanland

7 thoughts on “Norbergs kriswebb och skogsbranden i Västmanland

  1. Som alltid väldigt välskrivet. Jag tror att många skulle vinna på ett utökat samarbete kring utformning av kriswebbar genom att ta hjälp av andra, som du ju föreslår. Dessutom skulle kunskapen kring prestandakraven behöva öka hos utvecklingspartnern, för att veta vilka krav som ställs på en webb i en krissituation. Grafiktunga, scriptbaserade sajter fungerar som sagt var inte i en krissituation…

    Du får sätta samman ett expertteam. 😉

  2. Mycket välskrivet, som boken. Och framför allt viktigt. Jag och många med mig behöver se över dessa bitar på sajter som kan bli mycket viktiga vid oönskade händelser. Är gärna med och diskuterar frågan vidare, för att lyfta fram den ännu mer bland kollegor i “branschen”.

  3. Intressant inlägg Markus! Jag hoppas hinna fördjupa mig själv i ett eget blogginlägg inom kort. Några förtydliganden bara, i fallet med Norberg som är ett exempel i inlägget.

    SiteVision donerade en kriswebb till Norberg eftersom något på deras skarpa webb verkligen gick i kras. De använder inte SiteVIsion annars, och det blev något av ett hastverk som bara skulle fungera. De kunder som redan ligger i vår cloud-lösning är inte i något behov av en kriswebb, åtminstone inte av tekniska skäl. Det skalar egentligen obegränsat.

    För att vara en enkel webbplats så är den kanske något tung eftersom den inte är optimerad (se ovan), men den är inte riktigt så tung som du skriver. I ditt räkneexempel är det 1,7 MB som total sidladdning. I själva verket är det 466 kB som överförs eftersom data komprimeras av SiteVision (kolla t.ex. med Chrome). SiteVision gzippar resurser som skickas, vilket i praktiken stöds av alla webbläsare som används i dag. Dina siffror är för uppackad data. Du får gärna justera om du vill.

    Vi har redan dragit igång tankesnurrorna på hur vi hade kunnat hjälpa våra kunder ännu mer. Och jag har själv en bakgrund som webbstrateg och kriskommunikatör i Halmstads kommun. Jag skulle gärna vara med i en kriswebb-diskussion!

    Disclaimer (som om det skulle behövas ;)): Jag arbetar med marknad och kommunikation på SiteVision AB.

  4. Är det inte bara att gräva fram “WAP for Dummies” ur garderoben och börja koda som om varje bit kostar?
    För det kan det göra vid en krissituation, varje onödig bit är då en bit information som en annan drabbad inte kan ta del av.

    Har MSB eller annan myndighet några riktlinjer vad gäller kriswebbar?

    1. Ja, för oss som faktiskt kodade WAP-sajter för 10-15 år sedan så framstår ju dagens mobila/responsiva webbplatser som oerhört tunga kolosser.
      Mer om WAP – Wireless Application Protocol:
      http://sv.wikipedia.org/wiki/Wireless_Application_Protocol

      Jag har iaf inte snubblat över någon rekommendation från någon statlig part där de oroat sig över ett överbelastat nät och rekommenderat att fokusera enbart på innehåll utan finurligheter som anpassade teckensnitt, Google-kartor och sånt tjafs.
      Vore ju fint med en dokumenterad lägsta-nivå för alla att följa. En som tog höjd för innehållsproducenternas frågor ner till IT-teknikernas funderingar kring komprimerad sändning över mobilnätet…

Leave a Reply

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

Denna webbplats använder Akismet för att minska skräppost. Lär dig hur din kommentardata bearbetas.