Jag var under torsdagen med på ett “hackathon” i miniatyr med våra webbkonsulter från Precio Fishbone och Filip från vår kommunikationsstab. Som Filip kommenterat är det kul att vi blandar olika bakgrunder och att vi från VGR kommer från olika staber, Filip från kommunikation (KEX) och jag från Hälso- och sjukvårdsstaben. En tanke jag hade varför det är bra att vara med i dessa sammanhang är för att lära mig mer och sedan kunna ta med detta till vårt kravställande på Inera för exempelvis den extremt populära webbplatsen 1177 Vårdguiden och de e-tjänster vi har där för invånarna.
Temat för just denna träff var ganska brett, nämligen; webbprestanda, tillgänglighet och integritet. En utgångspunkt är att vi på VGR har för avsikt att bättra på vår position på Webperf i kategorin Sveriges regioner.
Full disclosure: det är jag, Marcus, som under min föräldraledighet byggt tjänsten Webperf.
VGR varandes min arbetsgivare drar dock lite nytta av detta då jag förstås tar med mig erfarenheter och ett batteri av tester till jobbet när så önskas. Exempelvis denna gång då vi testade om webbplatsen några gånger och körde storskaliga tester med hjälp av samma kod jag tagit fram på fritiden.
Varför ta en ny titt på en befintlig webbplats?
Som med alla webbplatser så tenderar de att efter lansering så sakteliga bli vildvuxna, att saker inte använts som man hade tänkt och att det kommer nya förväntningar på hur saker ska fungera.
Vi tittade efter saker som kan förbättras genom olika sorters tester och funderade ut hypoteser till varför resultatet blir som det blir.
Ett av “fynden” var att det tycks ta för lång tid att hämta sidor som har ett block i sig med externa RSS-prenumerationer. En sida tog mellan 0,3-2,7 sekunder på sig för att visa upp sig. Extremt nyttigt att kunna diskutera hypotesen tillsammans. “Hur funkar det med Varnish?”, “Har vi någon output-cache på RSS-blocket”, “Vilken timeout är det på cache, eller invalideras den dynamiskt?”
Metod för undersökning
Av de delar vi körde; prestanda och automatiserad tillgänglighetstest, innebar att vi körde:
- Alla 246 sidor från vgregion.se som fått 100 eller fler besök under januari genom Sitespeed.io, via Docker på min jobbdator, vilket inkluderade tillgänglighetstest genom Axe.
- De femhundra senast publicerade sidorna vilka testades mot Google Pagespeed API.
- Manuella inspektioner av “misstänkta” sidor genom Axe Developer Tools som kan köras direkt i din webbläsare.
- Vi kollade “vattenfallen” i webbläsarens nätverksdel av utvecklarverktyg.
Personlig integritet
När det gäller besökarnas integritet kommer Content Security Policy förbättras ytterligare och Referrer Policy kommer ändras. När det gäller referrer innebär det att när vi länkar till en tredjepartswebbplats kommer den inte få reda på var besökaren var innan. Det känns bra med tanke på att många av våra webbplatser har länkar till sociala medier i sidfoten, länkar till Google Maps med mera. Vi behöver inte bidra till att de får mer personlig information om de vi skickar till dem. Och vissa av våra webbplatser har information som kan vara avslöjande om ens hälsa.
Så här förklarar föreningen Dataskydd Referrer policy:
”När du klickar på en länk så skickar din webbläsare vanligtvis HTTP-headern referrer till destinationssidans webbserver. Headern innehåller adressen till sidan du kom från, vilket alltså avslöjas för webbservern du kommer till. Headern skickas också när externa resurser (såsom bilder, typsnitt, skript och CSS) laddas.
Referrer-headern är en integritetsmardröm då den låter webbplatser och tjänster spåra dig omkring webben och lära sig om dina surfvanor (och således potentiellt känslig information om dig), speciellt när det sker i kombination med kakor.
Genom att sätta en Referrer Policy är det möjligt för webbplatser att säga webbläsare åt att inte läcka referrers. Det låter dig specificera en policy som tillämpas på såväl alla länkklick som alla andra förfrågningar genererade/orsakade av sidan (bilder, JS, osv).”
– Webbkoll – dataskydd.net
Vad uppnådde vi?
Innan vi satte igång hade VGR:s webbplats 3,4 av 5 på de saker som Webperf mäter. Egentligen är det fel att ta ära för att betyget skuttade upp till 3,6 av 5 under dagen då det till stor del handlar om att CSS-koden gått ifrån cirka 50 st valideringsfel ner till 8 st för närvarande. Alltså ett delbetyg på 3 istället för en 1:a.
Och för att vara helt öppen: jag är småbarnsförälder, hämtar och lämnar på förskolan, jobbar bara halvtid (men kompenserar med att jobba under lunchen), så detta är vad jag hann uppmärksamma under dagen. De andra kan ha mer att bidra med som jag missade och CSS-grejerna var nog påbörjade redan innan…
Pa11y för tillgänglighet
En enkel ändring, trodde vi, var att höja Pa11y-betyget från fyra till fem. Vi gick bet på Pa11y, som ärligt talat inte är helt tillförlitlig. Nästa nivå för att bli mer tillförlitlig var att köra Axe-testet. Sista nivån var att Filip som är en av de främsta jag kan komma på i Sverige inom tillgänglighet granskade koden och undersökte praxis. På så vis kom vi fram till att VGR egentligen förtjänar ett bättre betyg än vad Pa11y var villig att ge oss.
Gå över till http/2 eller http/3 som (nog fortfarande) är draft för att bli webbstandard
Det är inte ett mätbart resultat, men vi diskuterade oss fram till att prioritera att sikta direkt på högsta tänkbara version av webbservern IIS (Internet Information Server) för att i bästa fall få med några av de delar som utgör den blivande webbstandarden http/3. För de flesta innebar http/2 en betydligt snabbare upplevelse av webben och den tredje versionen tar detta ett steg ytterligare vilket redan stöds av webbläsare som Chrome, Firefox, Opera och den nyligen släppta Chromium-baserade versionen av Edge (Microsofts uppföljare till Internet Explorer).
Det är mycket skräp i våra sitemaps
Sitemaps är dolda filer som håller en kronologisk ordning av vilka sidor som publiceras på en webbplats. De postas ofta till tjänster som Google Search Console, egna sökmotorer, mfl, för att berätta vad som är nytt eller uppdaterat på en webbplats.
Well, när vi utgick från denna listning dök det upp sidor som egentligen inte är sidor. Snarare data som vi gissar används i diverse listningar. Eller hur skulle du tolka “sidor” som denna:
Den har extremt lite unikt innehåll. Så det är väl tur att Google anses leva efter “EAT”, alltså: Expertise, Authority, Trustworthiness.
Annars hade sidor som dessa kunnat konkurrera med mer prioriterat innehåll, exempelvis huvudsidan för Kultur i väst. Dags att VGR börjar jobba mer med SEO (sökmotoroptimering)?
SEO kanske borde vara ett tema för ett kommande hackathon? Åtminstone jag har lite att bidra med, tror jag.
Webbprestanda enligt Google Pagespeed API v4 och Sitespeed.io
För ett gäng år sedan skickade jag en tårta till våra webbutvecklare på Precio Fishbones Göteborgskontor. De hade överträffat mina skyhöga krav om att vår webbplats skulle vara snabbast inom svensk offentlig sektor.
Så hur såg det ut nu när webbplatsen råkat ut för några år av förvaltning, tillägg, nya önskemål och annat som brukar vara förödande för den där “nybilsdoften”? Ja, nu kollade jag bara de 246 st mest besökta sidorna under föregående månad enligt vårt webbanalysverktyg Matomo (fd Piwik). Då var det strax över tio stycken webbsidor som inte levde upp till den prestandabudget vi skrev för flera år sedan. Jag har beskrivits, inte bara inom VGR, som en prestandataliban, en som bara ser hastighet som viktigt. Men detta resultat kan inte ens jag se några problem med. Det överträffar mina förväntningar med bred marginal.
Vår hypotes är att även detta fåtal sidor som inte lever upp till våra krav beror på att de inte besöks tillräckligt ofta för att landa i vår cache.
Cache vs. aktuellt innehåll
Här har vi en svår avvägning mellan snabbhet och hur aktuellt innehållet är. Reglerna för detta är extremt “regelstyrda”. Jag som av och till varit med i VGR:s diskussioner kring webbutveckling sedan 2002 känner igen diskussionen sedan länge. Det blir en avvägning om hur snabbt webbredaktören kan se och bekräfta ändringen av webbplatsen, gentemot hur snabbt ändringen behöver slå igenom för de ovetande besökarna som inte vet vad de går miste om.
Automatisera tester
Vi pratade om Grunt och Gulp i änden att kolla om Sitespeed.io tycker att nya versioner av webbplatsens löpande uppdateringar håller måttet. En annan vinkel är det innehåll som webbredaktörer bidrar med.
Vi behöver troligen testa från båda håll. Från utvecklarnas håll med CI – Continuous integration, samt hur webbredaktörerna påverkar slutresultatet vilket kan mätas med så kallade RUM-tester, Real User Monitoring-tester som härmar (eller spelar in exakt, men anekdotiskt) hur det blir i riktiga användares ände.
Framtida tankegångar
Planen för nästa träff tycks vara att gå in på hur en offline-sida kan tänkas designas. Inte helt olikt hur de 404-sidor vi är vana att se. Men offline-sidor är mycket mer komplicerade än man kan tro då det är användarens egen uppkoppling, eller avsändarens, det beror på. Så det behövs en bra mix av förklaring och funktion. Ett icke-alarmistiskt budskap om att det nog är tillfälligt, men funktion om att ladda in den önskade sidan eventuellt innan användaren hann upptäcka att det fanns problem.
Felmeddelande när användaren är offline
Avslutningsvis…
Kanske är detta något vi skulle anamma som koncept inom fler områden inom det vi kallar vardagens digitalisering? Eller även vårdens digitalisering där jag själv jobbar.
Tänk om vi skulle dra nytta av varandras kunskaper innan vi sjösätter ett nytt ekonomisystem, en uppdatering av självservice inom HR som påverkar nära på all personal eller konfigurerar ett nytt journalsystem.
Då kanske vi kunnat leverera bättre kvalitet. Så inte kollegor ser både IT och digitalisering som något ytterligare “någon annan” vill tvinga på en, men som man själv helst sluppit. Snarare att de med användning upptäcker vår proaktiva omtanke emellanåt. En sådan proaktiv omtanke var Filips idé att faviconer ska vara svartvita för de som är inloggade som redaktörer, men i färg för den publika webben. Så det blir enklare att skilja på sina olika flikar i webbläsare om man är webbredaktör.