Direkt till innehållet

Prestandabudget

Målet med prestandabudgeten är att garantera användarna snabba, korrekt kodade och välfungerande webbplatser. Detta gör vi genom att definiera övergripande principer för utvecklingen samt mätbara gränsvärden och metoder för att mäta dem på ett upprepningsbart sätt. Som stöd för att klara de gränsvärden som är satta definierar vi också underordnade gränsvärden som hjälper till att stötta leveransen av de övergripande gränsvärdena. Även här definierar vi hur dessa skall mätas på ett upprepningsbart sätt.

Övergripande principer

  • Universell design - Vi bygger tillgängligt redan från början istället för att anpassa en otillgänglig lösning i efterhand. Detta är principen om universell utformning som är bärande i svensk funktionshinderspolitik. Se t.ex. https://www.regeringen.se/pressmeddelanden/2017/05/nytt-mal-ska-styra-funktionshinderspolitiken/
  • Progressive enhancement – Vi tar vår utgångspunkt i tekniker som fungerar för alla användare och reserverar smalare tekniker för att erbjuda ytterligare förfining för de som har tillgång till dem. Detta skall ses i kontrast till att utgå från tekniker som alla inte har tillgång till och i efterhand bygga en fallback. Exempelvis basfunktionalitet byggd i javascript där det måste byggas en backend-baserad fallback. Då implementerar vi istället i första hand en lösning i backend och erbjuder en snabbare javascript-baserad lösning för de som kan använda den.
  • Mobile first - Utgångspunkten i vårt arbete är de förutsättningar som mobiler sätter.
  • Offline first - Det skall finnas tolerans för att användare tappar nätverksanslutningen.

Övergripande mätbara gränsvärden

  • Under 1.0 sekund för komplett laddning av sidor på webbplatsen mätt mot produktionsservern via gynnsam anslutning om minst 20Mbit/s (testas med t.ex. bredbandskollen.se). Valet av 1.0 sekund är baserat på Jacob Nielsens rekommendationer kring responstider (som i sin tur bygger på Miller (1968), Card (1991). Se ex. Nielsen (1993) Resonse times: the 3 important limits [https://www.nngroup.com/articles/response-times-3-important-limits/]. Senare artiklar hänvisar till samma forskning där 0.1 sekund betyder att ingen fördröjning upplevs, 1.0 sekund betyder obrutet tankeflöde trots att fördröjningen märks och 10 sekunder gränser ö.h.t. för uppmärksamhet.
  • Under 3.0 sekunder för komplett laddning av sidor på webbplatsen mätt mot produktionsservern via 3G-anslutning. Valet av 3.0 sekunder är inte baserat på forskning utan på en önskan att vara mer ambitiös än andra regioners prestandabudget samtidigt som hänsyn tas till svårigheten att leverera på under 1.0  s via 3G.

Värdena gäller alla sidor på webbplatsen, men vid testning kontrolleras ett antal fördefinierade sidor - minst en av varje sidtyp - för att kunna följa utvecklingen över tid. Avvikelser som identifieras på andra sidor skall följas upp för att identifiera anledningen och åtgärder diskuteras och prioriteras. Testet utförs med sitespeed.io (på lokal maskin till dess att Jenkins är implementerat) och medelvärdet av minst tre hämtningar används. Värdet som läses av är ”pageLoadTime” från ”detailed summary”.

Underordnade mätbara gränsvärden

  • Max 400KB för en sidladdning.

    Vald med utgångspunkt i VG-regionens prestandabudget, men rundad till 400KB eftersom jämna hundratal bättre signalerar ungefärlighet än vad 399KB gör.

  • Max 1500 element i DOM. Detta snabbar upp browserns rendering av sidan och gör DOM-frågor i Javascript snabbare.

    https://yellowlab.tools/result/f8fudoclkc/rule/DOMelementsCount

  • Max 20 nätverksrequest för en enskild sida. https://yellowlab.tools/result/f8fudoclkc/rule/totalRequests
  • Max 3 CSS-filer.

    Lånat av https://webperf.se/articles/prestandabudget-offentlig-sektor/

  • Max 3 javscriptfiler

    Lånat av https://webperf.se/articles/prestandabudget-offentlig-sektor/

  • Maximal väntetid på backend definierad som “time to first byte” (TTFB) för själva sidan är 300ms

    Vi mätningar den 6 februari 2019 mot utvecklingsservern fick vi svarstider för en helt tom template och utan plugins på ca 60ms. När vi aktiverade alla plugins ökade svarstiden till ca 80-90ms. Vi börjar med att lägga på 200ms för nödvändiga databashämtningar, processa data och generera HTML utifrån templates och utvärderar sedan. I skrivande stund ligger vår testserver på betydligt lägre tider och levererar en TTFP med demo-innehåll på ca 60-70ms.

  • Ladda bara ramverk som jQuery m.fl. på sidor där de faktiskt används.
  • Endast A och B-betyg för de aspekter som mäts av https://yellowlab.tools.

Dessa värden är inte hårda värden på samma sätt som det övergripande hastighetsmålet utan stöttar leveransen av det övergripande gränsvärdet. Så länge vi klarar att hålla det övergripande gränsvärdet gör det alltså inte något med enskilda mindre avvikelser som att en sida t.ex. är några kilobyte större.

Dokumentets status

I skrivande stund (14 februari 2019) är detta ett utkast. Lämpligen anpassas särskilt de underordnade mätbara gränsvärdena löpande under dokumentets livstid. De mätvärden som tas upp under denna rubrik bör i första hand vara sådana som antingen är extra viktiga eller där vi har hittat problem som vi vill vara säkra på att inte göra om.

Utökningar

Vissa saker som är intressanta i relation till prestanda är svårare att kvantisera och kan behöva diskuteras innan de beslutas. En sådan är frågan om hur ofta man vill göra mätningar. Med Jenkins får vi förhoppningsvis möjlighet att ha automatiska uppföljningar vid varje enskild sjösättning av ny kod. Utöver detta kan manuella uppföljningar göras av sådant Jenkins inte kan testa och hur ofta det skall göras är en fråga som kan behöva diskuteras.

En annan fråga som kan behöva diskuteras är hur kraven tydliggörs mot verksamheten. Ett sådant system som föreslagits är en form av poängsystem där verksamheten kan får spendera ett visst antal prestandapoäng på enskilda poängsatta funktioner/komponenter.

Senast ändrad: