Riktlinje nr 54 Prio 2

Optimera webbplatsen för bästa prestanda

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.


Acceptera inte långa väntetiderLänk hit

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åLänk hit

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. Medvetenhet om betydelsen av prestanda får gärna finnas med redan i UX- och design-fasen när webbplatsen tas fram.

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 prestandaproblemLänk hit

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 prestandanLänk hit

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. Eftersom inte riktigt all mjukvara ännu har stöd för HTTP/2 så är det lämpligt att tills vidare säkerställa godtagbar prestanda även för användare med äldre http-versioner. För äldre http-versioner 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


TerminologiLänk hit

Robust
I webbsammanhang har robusthet 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
En resilient webbplats är motståndskraftig mot hög belastning.
Last
Så många användare med genomsnittligt beteende som webbplatsen kan hantera.
Cache
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. Cache kan kallas för buffert på svenska, men det engelska ordet är nog vanligare än det svenska i tekniska sammanhang.
CDN
CDN står för Content Delivery Network, eller 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
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
Ett exempel på bildformat som är skräddarsytt för webben. Brotli är ett exempel på generellt komprimeringsformat.
AMP
Accelerated Mobile Pages ä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. (Se R80. Följ standarder.) Dessutom fungerar AMP i dagsläget bara i omedelbar anslutning till Googlesökning.
Stress
Hur väl fungerar systemet när man belastar det så mycket att det inte längre kan hantera mängden anrop. (Det man främst kontrollerar vid stresstest är att systemet inte levererar felaktiga data alternativt öppnar upp för intrång.)
TTL
Time To Live. 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. I webbsammanhang motsvaras detta ibland av max-age. När tiden passerat byter systemen strategi, oftast genom att ”börja från början”.


Kommentarer (2)