Gå direkt till sidans huvudinnehåll

En prestandabudget för offentlig sektor

Offentlig sektor står för det mesta utan konkurrenter. Om ens kommuns webbplats är trög och otillgänglig är det inte bara att välja grann­kommunen istället. Därför är det extra viktigt att offentlig sektor inte ställer för låga krav när de beställer webbplatser.

Här kommer ett mätbart förhållningssätt till hur en bra webbplats presterar - ett förslag på prestandabudget för svensk offentlig sektor.

Intro till prestandabudget

En prestandabudget är dels ett dokument och dels en överenskommelse om vilken nivå en webbplats ska överträffa. Man kan ha den som en del i sin upphandling för att klargöra hur man förväntar sig att webbplatsen ska prestera på en mätbar teknisk nivå. Det går också att ha som en bilaga till ett avtal.

Nedan prestandabudget är inspirerad av den Västra Götalandsregionen släppte 2016, men något uppdaterad, och utgår från att man har lite ambition kring prestanda och användarupplevelse. En mindre ambitiös variant är att nollmäta hur befintlig webbplats presterar och sedan följa upp att det åtminstone inte blir sämre över tid.

Diskutera gärna på Twitter under taggen #prestandabudget eller i vår Slack-kanal.

Själva prestandabudgeten

Läs nedan krav som att de mäts med representativt innehåll på testsidor utvecklarna tar fram inför avstämning med av kunden utsedda personer. Dessa testsidor ska inte kunna påverkas nämnvärt av webbredaktörer mellan testtillfällena, de ska vara jämförbara över tid. Var och en ansvarar för det den tar fram, drift för svarstider, utvecklare för övergripande kod och webbredaktörer för redaktionellt innehåll, exempelvis.

En leverans som misslyckas med dessa krav ska inte sättas i produktion och ska inte accepteras. Samtidigt förväntas de som står för innehållet hålla koll så inte innehållet är slösaktigt utformat.

Värderingar, prioriteringar och prestation för hela webbplatsen

Så här resonerar vi när det gäller utformning av webbplatsen och våra digitala tjänster:

  1. Följa designkonventionerna universell design, progressive enhancement samt mobile first. Det vill säga fokusera på tillgänglighet först och finess sen, samt att det är det mobila scenariot som sätter behoven kring design och funktion. Det innebär att stödja att användaren ibland tappar anslutning till nätet (så kallad offline first).
  2. Form följer funktion, och upplevelsen är viktigare än teknikaliteter. Det vill säga inkluderande design, både för funktionsnedsattas möjlighet att delta men också för att nå så många sorters utrustning som möjligt.
  3. Vid design- eller arkitekturella beslut trumfar W3C:s rekommendation, praxis och framgångskriterier, samt DIGG:s webbriktlinjer.se, samtliga av kundens och leverantörernas överväganden och förslag. Nationell och internationell konvention ska agera standard.

Mätbar prestandabudget

Följande punkter ska mätas kontinuerligt.

  1. Max 399kb för en sidvisning. Mäts exempelvis genom Pingdom Tools.
  2. Under 3 sekunder för komplett laddning av sida, mätt från Stockholm genom WebPageTest med inställningen Native Connection.
  3. Under 10 sekunder för komplett laddning av sida mätt på 3G-uppkoppling. Mäts från Stockholm genom WebPageTest med inställningen 3G Fast, 0,8-1,6 Mbps, 150ms RTT.
  4. Svarstid på under 0,3 sekunder. Mäts med Sitespeed.io genom serverResponseTime.
  5. Speed Index under 1500 för first view enligt WebPageTest eller Sitespeed.io, samt under 1000 vid repeat view.
  6. Inga tillgänglighetsfel enligt Axe eller Pa11y.
  7. Bara A och B i betyg på Yellow Lab Tools.
  8. HTTP/2 samt HTTPS på allt. Testa med HTTP/2 Test och SSL Checker, exempelvis.
  9. Anses vara mobilvänlig enligt Googles mobilvänlighetstest.
  10. Minst betyg 80 av 100 i Google Pagespeed med mobila inställningar, och minst 85 för dator.

Årsvis uppföljning

Dessa krav skall följas upp av lämplig expertis minst årligen.

Alla designkomponenter och redaktionellt innehåll på webbplatsen skall som allra minst:

  1. Vara testade och säkrade årligen mot WCAG 2.1 minst nivå AA.
  2. Max 3 st CSS-filer laddas in.
  3. Max 3 st Javascript-filer laddas in.
  4. Inte ladda in ramverk (som Jquery) på sidor där de inte används.
  5. Använda CSS/SVG-sprites (eller motsvarande teknik) för att minska antalet bildfiler att ladda ner.
  6. Strukturell CSS-kod inkluderas i HTML-koden enligt god prestanda-praxis för snabb initial visning av innehållet.
  7. Fungera utan antagandet att all Javascript nådde fram till användaren. Se värdering om progressive enhancement. Allt väsentligt ska fungera utan Javascript, men inte nödvändigtvis på ett identiskt sätt.