Utkast till ny version av riktlinje 54 om prestanda

20 maj, 2017
Här följer ett tidigare utkast till ny version av riktlinjen R54. Optimera webbplatsen för bästa prestanda. OBS! Riktlinjen är nu uppdaterad så denna version finns endast kvar som dokumentation av diskussionen kring utkastet.

Diskussioner skedde i kommentarsfunktionen sist på sidan och i Facebookgruppen webbriktlinjer samt genom epost till info@webbriktlinjer.se.

Optimera tjänsten så att den laddar snabbt, svarar snabbt på interaktion och kräver så lite som möjligt av användarens utrustning och uppkoppling. Dålig prestanda leder till negativa användarupplevelser, hinder för användning, försämrat genomslag (till exempel genom sämre rankning i sökmotorer) och slöseri med resurser. Bra prestanda kan till exempel uppnås genom att inte överföra mer data än nödvändigt.

Rekommendationer för god prestanda

  • Acceptera inte långa väntetider
  • Kartlägg utgångsläget och skapa en prestandabudget
  • Identifiera och åtgärda prestandaproblem
  • Gå igenom ”Fem sätt att förbättra prestandan”

Acceptera inte långa väntetider

Ingen skulle köpa en bil som alltid skapar köer bakom sig, men många webbplatser och appar låter användare vänta i onödan. Du själv har kanske bra uppkoppling till din nya snygga sajt och är motiverad nog att vänta när den laddas, men andra besökare är ofta otåliga och på väg någon annanstans. Det kan även gälla personer med vissa funktionsnedsättningar, till exempel koncentrationsstörningar och kort arbetsminne.

Användare med mobil uppkoppling har extra stor anledning att undvika dåligt optimerade webbplatser eftersom de ofta har begränsad bandbredd och ibland måste betala extra för varje megabyte data.

Eftersom sökmotorer premierar webbplatser med en god användarupplevelse leder ökad prestanda även till bättre sökmotoroptimering.

Optimering innebär också minskad belastning på servrarna, vilket kan ge lägre kostnader för hårdvara och bandbredd eftersom befintlig infrastruktur kan ta hand om fler användare.

Godtagbar prestanda är alltså ingen lyx, utan nödvändigt för att uppnå syftet med sajten.

Kartlägg utgångsläget och välj ambitionsnivå

Om det redan finns ett system:

  • Kartlägg nuläget och identifiera vilka brister i prestandan som ni behöver åtgärda.
  • Ta reda på vilka prestandabrister som användarna upplever som mest besvärande och åtgärda de problemen först.
  • Gör en nollmätning, det vill säga mät prestanda innan förbättringarna gjorts och upprepa mätningarna efteråt så blir det enkelt att utvärdera era insatser.

Oavsett om det gäller förvaltning eller nyutveckling kan det vara bra att ta fram en prestandabudget som dokumenterar organisationens ambition kring prestandaoptimering, mätvärden med mera. Ett exempel på prestandabudget finns hos Västra Götalandsregionen.

Vad är tillräckligt bra prestanda?

Forskning har visat att användare av datorsystem tappar koncentrationen om de får vänta för länge. Nielsen-Norman har redovisat följande konsekvenser av väntetider på webben:

  • 0,1 sekunders svarstid slutar uppleva att svaret är omedelbart.
  • 1 sekunds svarstid börjar tankeflödet hindras av en upplevd väntan.
  • 10 sekunders svarstid har användaren svårt att vara uppmärksam och vill göra något annat under tiden.

Behovet av snabba svarstider beror på användarens förväntan och exakt vad hen försöker åstadkomma. För användare med muspekare är den första tidsgränsen om 0,1 sekunder avgörande för om responsen uppfattas som omedelbar, exempelvis om musmarkören placeras över något och det orsakar en mouseover-effekt. Om användaren istället klickar på en länk är det troligt att den andra tidsgränsen om en sekund är mer relevant. Tio sekunder är någon form av bortre gräns för en användare att kunna behålla fokus.

I ETSI-standarden för kognitiv mobil tillgänglighet (pdf, se avsnitt 12.4.6) rekommenderas att applikationen ska ge någon sorts respons efter max 0,1 sekunder.

Identifiera och åtgärda prestandaproblem

Det finns ett flertal möjliga anledningar till att en webbplats upplevs som långsam. Mest uppenbart är att antingen webbplatsen i sig, eller användaren, har en långsam uppkoppling till internet. Det kan också bero på att servern eller uppkopplingen har en hög belastning, till exempel på grund av en överbelastningsattack eller för att för många användare efterfrågar ett visst innehåll.

En webbplats kan också uppfattas som långsam på grund av tekniska brister, bland annat:

  • Underdimensionerade servrar. De flesta webbplatser består av flera olika sorters servrar, bland annat för databas, bakomliggande system och webbredaktörernas publiceringssystem.
  • Inte tillräcklig bandbredd mellan servrarna och internet. Jämför med tjockleken på en vattenslang vid vattnande av en gräsmatta: en tjockare slang kan potentiellt bära mer vatten.
  • Programmeringsfel till exempel vid sökningar i databaser kan göra att servern tvingas arbeta onödigt mycket för att leverera efterfrågat innehåll.
  • Inte optimal konfiguration, till exempel brister på hur en cache är inställd, att databasers index inte återspeglar efterfrågat material eller att behoven varierar på ett sådant sätt att det ändå inte fungerar optimalt.

Fem sätt att förbättra prestandan

Begränsa antalet anrop

Att hämta en webbsida på en webbplats innebär i princip alltid att klienten behöver hämta flera olika resurser från servern: själva html-dokumentet, stilmallar, script, bilder, videofilmer med mera. Kom ihåg att varje http-anrop tar tid. Om anropen sker till olika domännamn kan även fler dns-uppslagningar behövas.

Prestanda kan alltså förbättras genom att minska antal anslutningar. Detta sker med automatik om ni använder http-versionen HTTP/2. Gör gärna det om ni har möjlighet, men eftersom inte riktigt alla besökare ännu har stöd för HTTP/2 så behöver ni också stödja någon annan http-version. Då kan antal anslutningar minskas genom att till exempel slå ihop flera resurser i en och samma fil.

Kombinera flera separata stilmallar till en enda istället för att leverera flera separata stilmallar: en för färger, en för teckensnitt, en för övergripande layout och så vidare.

Detsamma gäller script. Även bilder kan kombineras till så kallade CSS image sprites. Det passar dock inte för alla typer av bilder, och kräver särskild eftertanke för att inte orsaka tillgänglighetsproblem.

Läs mer om olika http-versioner i R7. Använd en krypterad anslutning för e-tjänster.

Välj rätt format för bilder och multimedia

Bilder, videofilmer, ljudklipp och liknande står ofta för större delen av datatrafiken från en modern webbplats. Här finns stora prestandavinster att göra, ofta med ganska enkla medel:

  • Välj rätt filformat för bilder, exempelvis JPEG för fotografier eller PNG för bilder som innehåller färre färger eller är transparenta.
  • Använd inte högre bildkvalitet än nödvändigt; ju högre kvalitet desto större blir filerna.
  • Använd inte bilder eller videofilmer i större dimensioner/upplösning än nödvändigt.

Komprimera bilderna för att minska storleken. Använd en bildkomprimerare för att ta bort onödig bildinformation som många bildhanteringsprogram sparar. Exempel på verktyg är Tiny PNG och SVGOMG.

Minska datamängden genom att komprimera filer och minifiera eller städa i kod

Ett effektivt sätt att minska datamängden mellan servern och klienten är att komprimera den. Ställ in webbservern på att använda gzip-komprimering (via content negotiation, eftersom inte alla klienter har stöd för tekniken) för textbaserade filtyper (HTML-dokument, stilmallar, script).

Det dyker nu och då upp nya komprimeringsformat som är bättre än tidigare, till exempel på grund av högre komprimeringsgrad, snabbare komprimering eller mer öppet format. Ett exempel på detta är WebP som kan användas för komprimering av bilder. Även HTTP/2 komprimerar (header-)data. Nya format tar dock en stund innan de fungerar i all utrustning. Utnyttja gärna de bättre formaten om ni har kapacitet att samtidigt erbjuda äldre format så länge det behövs för att inte utestänga användare.

Även om det tar tid att komprimera och dekomprimera filer tjänar både server och klient på tekniken eftersom det blir mindre data att föra över, vilket vanligen är det som utgör flaskhalsen.
Kod på webben (html, css, javascript) kan i många fall ”minifieras”, det vill säga bearbetas på ett sätt som gör att onödiga mellanslag och annat innehåll som inte påverkar presentationen rensas bort eller ersätts av kompaktare alternativ. Det finns verktyg som minifierar kod automatiskt. Nackdelen är att koden brukar bli svårare att läsa, men det är inte alltid ett problem. Dessutom finns verktyg som kan indentera och göra minifierad kod någorlunda läsbar igen.

Det är tyvärr fortfarande vanligt att såväl publiceringsverktyg som utvecklarramverk genererar mycket onödig kod, och även manuellt skapad kod kan ha innehåll som inte behövs. Ofta kan en städning av koden minska filstorleken och dessutom göra den lättare att underhålla.

Utnyttja cache-funktioner på rätt sätt

Principen för cache-funktioner är enkel: se till att klienten inte behöver hämta samma resurs flera gånger, om det inte behövs! Det finns många olika typer av cachning: i webbpubliceringsverktyget (CMS-system), på webbservern, framför webbservern, i så kallade Content Delivery Network (CDN), i användarens webbläsare och så vidare.

Använd cacheminnet i användarens webbläsare genom att sätta bäst före-datum på samtliga av webbplatsens filer. Då behöver inte en återvändande användare ladda ner oförändrade filer på nytt om återbesöket är inom tidsspannet för filens bäst före-datum.

Tänk på att olika typer av resurser kan behöva olika cache-inställningar. Eftersom stilmallar och skript bara uppdateras ibland är de lämpliga att hantera som små paket, vars filnamn kan numreras. När en ny fil dyker upp på webbplatsen förbigår den tidigare cachade filer, vilket gör att dessa filer kan ha riktigt lång giltighet. En sida som genereras dynamiskt (till exempel utifrån innehåll i en databas) kan bara vara giltig så länge som alla beståndsdelar är oförändrade. Helt statiskt innehåll kan vara giltig mycket längre (månader).

Skicka korrekta statuskoder enligt HTTP-standarden. Exempelvis HTTP-kod 304 som berättar för webbläsaren att filen på servern har ett identiskt innehåll som den fil användaren redan har tagit emot och som därmed inte behöver skickas igen.

Generella resurser går ofta att hämta från centrala lagringsplatser. Exempelvis finns Javascript-biblioteket jQuery att hämta från Google Libraries API, Microsoft AJAX CDN och jQuery CDN. Genom att hänvisa till sådana ökar sannolikheten något för att klienten redan har resursen i sin cache, och därmed inte behöver hämta den på nytt. Dessutom minskar det datatrafiken över era servrar.

För webbplatser med höga krav på robusthet, säkerhet och integritetsskydd (till exempel många myndigheters webbplatser) bör sådana lösningar användas med försiktighet, eftersom de skapar beroende av externa parter, ofta i andra länder. Att istället själv drifta ett CDN kan eventuellt vara ett alternativ.

Observera att det finns olika grader av beroende: I vissa sammanhang kan sidan besökas även om den externa resursen inte går att hämta (eller är förändrad), medan det i andra sammanhang bara påverkar en del av sidans funktionalitet.

Läs mer om tredjepartsinnehåll i R67 Se till att infogade externa tjänster följer webbriktlinjerna.

Tänk på hur sidan laddas

Många webbplatser är uppbyggda så att användaren inte kan börja interagera med en sida förrän hela sidan har laddats in och renderats. Ofta beror det på Javascript och CSS-selektorer som gör att webbläsaren måste rita om sidan flera gånger. Tänk därför igenom hur användaren påverkas av renderingen och om en del av beräkningarna istället kan göras på servern istället för i webbläsaren. Se även R93. Använd Javascript för att öka tillgängligheten – inte tvärtom.

Mätbarhet

De flesta moderna webbläsare har inbyggda utvecklarverktyg som kan visa hur lång tid det tar att hämta olika resurser som ingår i en webbsida. Ofta finns en tidslinje som visar vilka filer som tar lång tid att ta emot.

Exempel på hur verktyg för prestandaoptimering på webben kan se ut.
Schematisk bild av tidslinje-visning som finns i många utvecklarverktyg. En brant lutning bör eftersträvas eftersom det innebär kort väntetid.

Exempel på gratisverktyg som kan ge en bild av hur välbyggd en webbplats är utifrån prestandasynvinkel:

Som underlag för jämförelse kan nämnas att en undersökning av drygt 500 webbplatser inom svensk offentlig sektor gjordes i oktober 2016 med utgångspunkt i Google Pagespeed 2.0. Mätt med en mobilanvändares behov var genomsnittet 62 poäng av 100 möjliga. Googles riktlinje för bra webbprestanda är 85 av 100.

Fler tips på mätverktyg och kommentarer om prestandamätning.

Fördjupning

Terminologi

Robusthet i webbsammanhang har två olika betydelser. Dels är det en av principerna i WCAG 2.0 (som handlar om kompatibilitet med största tänkbara variation av user agents), dels handlar det i prestandasammanhang om den infrastruktur som behövs för att en webbplats varken ska bli långsam eller gå ner.

Resilient innebär att konstruera en webbplats som är motståndskraftigt mot en hög belastning.

Cache är det som på svenska kallas buffer. Det är ett sätt att mellanlagra information på strategiska platser. När det gäller webben brukar cache ofta exemplifieras genom det cacheminne som finns i besökarens egen dator, den så kallade webbläsarcachen. Det gör upplevelsen snabbare om material som inte uppdaterats istället återanvänds från den egna datorns minne istället för att hämta på nytt över internet.

CDN står för Content Delivery Network, ibland Content Distribution Network. CDN används ibland för att öka prestanda genom att bygga upp en cache-funktion i nätet så att flera webbplatser kan hänvisa till samma filer. Om besökaren varit på webbplats A och laddat ner den senaste Jquery-filen behöver den inte laddas ner på nytt vid besök på webbplats B – förutsatt att webbplatserna använder samma CDN. Ytterligare en fördel med CDN är att resurser kan hämtas från servrar som geografiskt befinner sig närmare användaren, vilket också påverkar svarstiden.

CMS står för Content Management System, det vill säga publiceringssystem. Vissa publiceringssystem har omfattande funktioner för till exempel automatisk anpassning av bildfilers upplösning till mottagarens skärm eller uppkoppling, avancerad cachning och så vidare.

WebP är ett exempel på bildformat som är skräddarsytt för webben. Brotli är ett exempel på generellt komprimeringsformat.

AMP står för Accelerated Mobile Pages och är ett Googleprojekt som tagit fram en sorts begränsade webbsidor (där bara delar av html, css och javascript används) som kan laddas mycket snabbt i mobilen. AMP ger god prestanda, men nackdelen är att det inte är en standardlösning. Dessutom fungerar AMP i dagsläget bara i omedelbar anslutning till Googlesökning.

TTL betyder Time To Live och används i olika tekniska sammanhang för att ange hur länge en viss resurs (till exempel en fil, en uppkoppling eller ett datapaket) ska anses vara giltig. När tiden passerat byter systemen strategi, oftast genom att ”börja från början”.

Kommentarer (10)

  • Besökare skriver:

    HTTP/2 är det korrekta namnet på protkollversionen och bör nog användas istället för ”http2” i en officiell text.

    ”För varje http-anrop upprättas en anslutning till servern” är ju inte helt sant. Varje ”anrop” kräver en anslutning ja, men ett antal anrop bör ju kunna göras genom att återanvända en anslutning som redan gjorts.

    HTTP/2 komprimerar inte ”data” som dokumentet säger just nu, mer än vad HTTP/1 gör, utan det h2 införde som inte finns i h1 är header compression.

    Tycker kanske det bör nämnas tydligare att nya funktioner så som HTTP/2 och Brotli enbart fungerar om sajten kör HTTPS.

    Brotli-länken är trasig.

  • Besökare skriver:

    > AMP

    Jag tänker att AMP-delen i terminologi ska bort, finns inget i texten som hämvisar till den? Tänker då att det ska finnas en rekommendation att AMP inte ska användas för offentlig sektor, eftersom dom kan hostas av Google, dvs man förstår ej vem som e avsändaren. Sen är det ju också en massa annat skumt med AMP.

    > Generella resurser … från centrala lagringsplatser, som Google Libraries API

    Jag tycker att rekommendationen ska vara att allting ska hostas av lokalt, inga beroenden till tredjepart för: 1. Offentlig sektor ska inte läcka information om användaren. 2. Risken finns att våra sidor inte fungerar för att ett företags sajt ligger nere.

    > Nielsen-Norman
    Dom siffrorna kommer från början från Robert E. Millers papper från 1968 som det hänvisas i länken, kanske kan vi få in det där också!

    • Pär Lannerö skriver:

      Tack Peter för alla dina konstruktiva bidrag, både här och i andra kanaler!
      Vi tar med dem och gör en ny revidering så snart vi hinner.

      Idag ger vi ingen rekommendation (varken för eller emot) vad gäller AMP. Webbriktlinjerna kan och bör inte ta ställning till alla tekniska möjligheter. Vi får se vad referensgruppen har att säga när det gäller just AMP. Men även om vi inte kommer med någon rekommendation så kan det finnas en poäng att ta upp en sådan relevant term under rubriken terminologi, som orientering.

  • Besökare skriver:

    > Tänk på hur sidan laddas

    Har för mig Marcus hade ett hårdare förslag här från början? Jag kan sakna det: Använd inte JavaScript för att rendrera sidan, ev riktlinjer för mängden JavaScript?

  • Besökare skriver:

    Jo en sista grej om HTTPS-HTTP/2, skrev ju förut om att det inte alltid är säkert att HTTP/2 gör det snabbare. Jag håller på med undersökning på jobbet där vi jämför (vi har sett innan att i vissa lägen är ettan snabbare).

    Just nu har jag bara grafer på testerna som kör just nu: https://dashboard.sitespeed.io/dashboard/db/http1-vs-http2?orgId=1 och en sammanfattning så länge här: https://phabricator.wikimedia.org/T166129 men det kommer en bloggpost framöver.

  • Besökare skriver:

    Dumhatt på för mig: Nielsens studie baseras på ”The information visualizer: An information workspace” av Card Mackinlay, Robertson.

    Håller ej med om AMP, jag tycker genom att ha med det i terminologin legitimerar ni det. AMP är ingen teknisk möjlighet, det gör så att offentlig sektors information serveras från Google istället från våra egna servrar, plus är beroende av att Google servrar fungerar (man behöver inkludera JavaScriptet som är AMP från Google och får ej hosta det själv). Vi ger också all statistik om användarna som läser våra texter till Google och vi låter Google bestämma vilka tredjepartsplugin vi får använda. AMPs primära funktion är inte snabba webbsidor utan ge kontroll till Google.

    • Besökare skriver:

      Ju mer jag läser på om AMP desto större tycks utmaningen kring integritet och gynnande av enskild aktör vara.
      Håller med dig, men får se vad diskussionen i referensgruppen kommer fram till.

  • Besökare skriver:

    > Nielsens studie
    nä det var fel studie det med, skippa det bara 😀