Nyhetsbrev #11: om prestandabudget

“An ounce of performance is worth pounds of promises.”
– Mae West

Inledande jidder

Om du inte märkt mitt omåttliga intresse för optimering och mätning av webbplatser har du inte läst särskilt mycket av vad jag skrivit de senaste fem åren. Det finns de som skulle kalla mig för prestandataliban, tidigare kollegor på webbyråer exempelvis 🙂
Månadens nyhetsbrev gör en djupdykning i hur man dokumenterar sin tekniska ambition med webbplatsen, detta i något som kallas för en prestandabudget. Denna dokumentation kan mycket väl vara en bilaga till ens levande stilguide, men med fokus på mätbara ting och vilken teknisk ambitionsnivå man tänker sig.

Jag är omåttligt nöjd över att få göra dessa inspel i min arbetsgivares webbarbete. Att bidra till att göra våra investeringar i webben mätbara och möjliga att följa upp dess tekniska kvalitet.

Månadens erbjudande är 20 % rabatt på alla böcker som säljs av Intranätverk. Kolla in slutet på nyhetsbrevet för att hitta koden. Intranätverk säljer även den tredje uppdateringen av e-boken Webbstrategi för alla, uppdaterad förra veckan, där pratas det också en del om prestanda.

/Marcus

Vad är en prestandabudget?

Ja, det är kanske inte helt uppenbart. Först och främst bör man läsa prestanda ur bred bemärkelse, exempelvis skulle en översättning av engelskans “performance budget” mycket väl kunna avse även prestation. Inte enbart prestanda som i antalet hästkrafter i en motor med andra ord.

Även ordet budget kan man behöva fundera lite kring, innebörden bör ses som i ekonomi att man håller sig inom budgeten, men att den exakta fördelningen kanske inte är helt avgörande. Tolka gärna också in att budgeten ska minska lite varje år (att man höjer ribban löpande) och att man över tid ska försöka bli bättre och bättre på att driva en effektiv webbplats.

Prestandabudgetens innehåll är ett klargörande över vilka kvalitetskrav man ställer på sin webbplats, allra helst mätbara krav. Sådana krav kan ha med tillgänglighet att göra, hur snabbt sidan ska ladda in, och andra lite mer tekniska ting.

Du använder prestandabudgeten som ett styrdokument både internt och externt. Internt är det en målsättning att försöka leva upp till. Externt är det däremot en kravställning gentemot leverantörer.

För att man ska kunna vara tydlig och rättvis gentemot sina leverantörer behöver man vara tydlig med exakt hur man kommer följa upp mätvärden. Krav man formulerar i sin prestandabudget bör mätas med representativt innehåll på testsidor. Dessa testsidor kan utvecklarna stämma av kraven mot inför avstämning med webbplatsens utsedda webbanalytiker. För att inte hamna i onödiga bekymmer bör inte testsidorna kunna påverkas nämnvärt av ens egna webbredaktörer mellan testtillfällena, de ska vara jämförbara över en längre tid.

Om man inte lever upp till prestandabudgeten?

En leverans som misslyckas med att leva upp till dessa krav ska inte sättas i produktion och bör inte accepteras av beställaren. Sen om man väljer att göra ett avtal eller inte av denna överenskommelse har jag ingen åsikt om. Själv skulle jag mer hålla leverantören moraliskt ansvarig om det är någon man jobbar med på löpande räkning eller sedan tidigare. Är det ett mindre uppdrag, eller en ny leverantör, kanske en prestandabudget är bra i beställningsunderlaget, så man har något att peka på om leveranskvaliteten inte är bra nog.

Om jag själv skulle ge mig i kast med att bygga webbplatser igen så skulle en på förhand uppgjord måttstock som en prestandabudget vara uppskattat. Då vet jag vilken hygiennivå beställaren förväntar sig och jag skulle överprestera lite lagom på det som prioriterats. Om något krav tillkommer så sätts det upp på prestandabudgeten inför nästa produktionssättning.

Denna typ av “testprotokoll” har ju funnits inom övrig systemutveckling länge för kvalitetskontroll, det är på tiden att webbutveckling följer efter.

Exempel på en prestandabudget

Inom Västra Götalandsregionen, där jag jobbar med webbanalys, har en prestandabudget beslutats som ett styrande dokument för extern webbkommunikation. VGRs prestandabudget finns att läsa på tjänsten Github.

Nedan tre rubriker är från första versionen av VGRs prestandabudget och med licensformen vi valt får du göra en kopia om du vill ha på ditt jobb. Kommentarer följer i kursiv text.

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

  1. Följa designkonventionerna 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.
  2. Funktion före form, och upplevelsen framför 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.

Vi inleder med ganska subjektiva mål, detta för att klargöra hur vi ser på webbplatser i största allmänhet. Dessa är inte särskilt mätbara men hjälper till när man ska resonera och prioritera.

Att följa progressive enhancement är en markering om att inte av tekniska skäl utesluta någon med äldre utrustning, eller prylar vi inte känner till. Det garanterar inte att man får en likvärdig upplevelse med jättegammal webbläsare, men det ska fungera så som webbplatser gjorde när den webbläsaren var modern.

Andra punkten förklara värderingen att webbplatser bör vara till för användaren och vad hen vill utföra, snarare än att vara en snygg testyta för ej beprövad teknik.

Mätbar prestandabudget

  1. Max 399kb för en sidvisning.
  2. Under 3 sekunder för komplett laddning av sida, mätt från gynnsam trådad uppkoppling.
  3. Under 10 sekunder för komplett laddning av sida mätt på 3G-uppkoppling.

Av de 399 Kb måste man sätta en gräns för webbplatsen som ramverk. I vårt fall har vi initialt tänkt oss att en redaktör ska få bidra med som mest 140Kb för ett högupplöst foto, exempelvis. Med andra ord har webbutvecklarna 259Kb att hushålla med.

Angående laddningstid kan man vara mer precis i hur man mäter, men i denna första version är idén att mäta från en kontorsdator med nätverkssladd. 3G-uppkopplingen har vi tänkt att simulera via Google Chromes utvecklarverktyg.

Lägstanivå på webb

Alla mallar/vyer/komponenter i webbplatsen skall som allra minst:

  1. Vara testade och säkrade mot WCAG 2 nivå AA.
  2. Anses vara mobilvänliga enligt Googles mobilvänlighetstest.
  3. Med exempelinnehåll uppvisa minst 85 av 100 i Google Pagespeed med mobila inställningar, och minst 90 för dator.
  4. Max 2 CSS-filer laddas in.
  5. Max 3 Javascript-filer laddas in.
  6. Använda CSS Sprites (eller motsvarande teknik) för att minska antalet bildfiler att ladda ner.
  7. Strukturell CSS-kod inkluderas i HTML-koden enligt god prestanda-praxis för snabb initial visning av innehållet.

Här kommer mätbara kvalitetskrav in i en längre lista. Först förklaras exakt vilken nivå av tillgänglighet som gäller. Denna nivå valde vi för att den omnämnts i utkast till EU-direktiv kring tillgänglighet, den svenska diskrimineringslagen är ju teknikneutral och nämner inte något mätbart.

Punkt sju är där av en enda anledning, att försöka adressera det för stunden stora problemet med att Javascript och CSS blockerar en sida från att visa sig, det vill säga den upplevda prestandan. Den punkten kommer säkerligen behöva revideras eller kompletteras. För att veta om din sajt är drabbad så kör Google Pagespeed så kommer den i så fall klaga på “above the fold”, prioritera synligt innehåll eller liknande.

– /slut citering från prestandabudgeten

Det är troligt att värderingar kommer få en ytterligare punkt i framtiden. När Post- och Telestyrelsen släpper sin vägledning för hur cookie-lagen ska hanteras finns det anledning att i sin prestandabudget klargöra hur man ser på cookies, besökarens integritet och när man tycker sig ha anledning att blanda in tredjepartstjänster.

Vilka tidiga lärdomar finns inom Västra Götalandsregionen?

På min arbetsplats har vi under hösten för första gången ett projekt som behövt förhålla sig till prestandabudgeten, nämligen vår uppgradering av Episerver CMS. Det är ett rätt omfattande och komplext projekt. Det finns massor av intressenter högt och lågt i organisationen eftersom det som tas fram är en gemensam grundstomme för alla olika förvaltningar inom denna mycket stora organisation med många vitt skilda verksamhetsinriktningar.

Nu är jag förstås något partisk, men jag upplever att kollegor och konsulter efter ett tag börjat uppskatta den konkretisering som prestandabudgeten bidragit till i vissa frågor. Våra webbkonsulter har till och med uttryckt att de är entusiastiska kring detta. Det gläder mig enormt.

En webbutvecklande vän, på en ej inblandad webbyrå, kommenterade varför han skulle gilla att leverera i enlighet med en prestandabudget så här:

“När någon ställer krav betyder det att de bryr sig och värnar om resultatet.”
–  Filip Andersson, @FrontendFilip

1. Bör vi använda mindre vanliga teckensnitt?

Frågan om det är lämpligt att ha rubriker med ett visst teckensnitt blev mer konkret än designfrågor enligt min erfarenhet normalt är. Konsekvensen av att välja ett “eget” teckensnitt, alltså att det rimligen inte finns i normala besökares prylar, var nämligen att:

  1. En visserligen liten, men ändå, risk för användbarhetsproblem identifierades i och med att ovanliga teckensnitt “blinkar in”, eftersom de måste laddas ner innan de kan påverka textens utseende. En effekt känd som FOUT – Flash of Unstyled Text. Alltså prioritering av form framför funktion, potentiellt i strid med värderingarna i somliga fall.
  2. Totalt skulle teckensnittsfilerna väga in på upp till 80 Kb, det vill säga cirka 20% av all trafik för en sidvisning.
  3. I och med licensvillkoren behövde en extra CSS-fil läsas in, detta så säljaren av teckensnittet kunde kontrollera att vi betalade rätt nivå, att vi har så många besökare som vi betalar för (och inte fler). En extra fil, och särskilt som i detta fall då den inte skulle hämtats från en svensk webbserver, tar extra tid vid nedladdning. Utan att tillföra något meningsfullt för besökaren. Vid ett flertal tillfällen har jag själv dokumenterat fördröjningar på över en sekund, vilket skulle kunna orsaka övertrasseringar mot budgetens mål om laddningstid på under 3 sekunder.

Frågan designgruppen ställde sig var om detta var värt det, gick det att motivera? Med andra ord blev det inte enbart en fråga om design, typografi och ifall kostnaden var ok. Diskussionen fick högst påtaglig konsekvens gentemot prestandabudgeten. I en framtida värld om/när Post- och Telestyrelsen rekommenderat oss att vara noga med besökarnas integritet är det inte givet att tredjepartsinblandningen ens skulle fungera.
Svaret på frågan var att åtminstone tills vidare låta bli udda teckensnitt. Hittar man en lösning som har mindre inverkan på prestandan så kanske beslutet blir annorlunda.

2. Sidhuvudsbakgrund vs kontrastförhållande

Högst grundläggande för god tillgänglighet är att man har ett kontrastförhållande mellan förgrund och bakgrund. Det märker man inte minst själv när man försöker använda sin mobiltelefonen i starkt solljus utomhus.

Att kombinera bakgrundsbilder i ett responsivt sidhuvud och garantera god kontrast visade sig vara en svår nöt att knäcka. Eftersom vi inte kände oss övertygade om att detta kunde bli både snyggt och tillgängligt försvann sidhuvudets bakgrundsbild med hänvisning till efterlevnad av tillgänglighetsriktlinjen WCAG.

De här subtila nyansskillnaderna som många designer är beroende av fungerar inte så bra längre i en mobil verklighet, och de har aldrig fungerat särskilt bra för de med nedsatt syn, först nu upptäcker även vi andra det.

3. Hur hämta in externa nyhetskällor?

Jag har många gånger irriterat utbrustit “hur svårt kan det vara?” när något känts självklart och simpelt. En sådan fråga som tycks vara simpelt löst framstod lite i annan dager på grund av prestandabudgetens mål om sidladdningstid.

Det finns nämligen ett behov att samla ihop en eller flera externa nyhetskällor (RSS) och visa upp dem som en nyhetsspalt på sin egen webbplats. Det slitna uttrycket att ingen kedja är starkare än den svagaste länken är tydlig när man blandar in fler parter för att kunna visa upp sin webbsida. Exempelvis, hur hanterar man om någon av de där externa nyhetskällorna inte är uppe, eller svarar först efter 10 sekunder? Sånt händer, inte minst under en samhällskris kan dessa problem börja visa upp sig men det räcker ju med att antingen din eller deras webbplatser får en ökad belastning för att din sajt ska gå ner.

Om webbplatsen ska visa upp sig på under 3 sekunder så är det bara att börja addera ihop svarstiderna på det antal externa källor man gör sig beroende av. Är man säker på att alla tillsammans garanterat svarar på mindre än 3 sekunder så har man ändå spenderat nästan hela sin budget för sidinladdning.

Vi har inte kommit fram till en klockren lösning ännu som är en lagom stor utgift. Ett alternativ som IT utreder är om man kan använda någon teknisk lösning som part webbplatserna och de nyhetskällor som ska bevakas. Då kan man exempelvis försöka isolera väntan och felhantering till en programvara som är bra på den uppgiften, eller åtminstone bättre än publiceringssystemet.

“Det här kommer bli dyrare!”

Ja, det lär en och annan få höra av sin leverantör när man introducerar en prestandabudget. Att kvalitet kostar är nog de flesta överens om. Fördelen här är att man börjar dokumentera de kvalitetsfaktorer man är medveten om vilken nivå man vill hålla.

En anledning jag misstänker (som numera något ringrostig webbutvecklare) till att man kan få detta bemötande är nog att det ännu inte är så vanligt att man har så här tydliga krav, eller att man är så pass högtidlig med dem. Det är här du läser mellan raderna att några av kraven säkert är sånt du skulle fått ändå, men att andra är lite ovant för utvecklarna.

När offentlig sektor beställer webbplatser har man ofta (av det jag läst) med krav som att det ska vara tillgängligt, ibland specat exakt vilken nivå. Frågan är hur många som följer upp att det fick vad de beställde.

Att ställa tydliga krav via sin prestandabudget förpliktigar att man löpande följer upp resultatet. Antingen om man, som vi på mitt jobb, har en utsedd webbanalytiker, eller om man har det som en del av leverantörens rapport vid varje nya produktionssättning.

Mer om prestandabudget och gränssnittskvalitet

Om du inte ids räkna på sidladdningstider själv så kan tjänsten performancebudget.io göra det åt dig. Tala om hur många sekunders laddningstid du accepterar, välj typ av uppkoppling du avser och klicka på knappen.

Jag föreläste för egna IT-avdelningen och några av våra konsulter i våras. Den inspelningen med presentationsbilder finns på Youtube. Det är att jämföra med en checklista över prestanda och webbkvalitet där jag introducerar och argumenterar för respektive punkt. Min föreläsning från konferensen Webbstrategidagarna offentlig sektor finns också på Youtube, tyvärr med lite dåligt ljud. Ämnet där är webbanalys ur vinklarna från stilguide, prestandabudget och outnyttjad SEO-potential sett från Googles måttstock.

På tal om Google så har deras prestandaevangelist en kanal på Youtube, något för dig som inte räds ofta väldigt tekniska tips.

Rabattkod för alla böcker från Intranätverk

För att få aktuella rabattkoder behöver du vara med på mejllistan för nyhetsbrevet - anmäl dig till nyhetsbrevet

Webbstrategi för alla tar upp det du behöver veta för att jobba mer strategiskt med en webbplats. Köp boken och få e-boken på köpet! Boken finns att köpa hos Intranätverk

E-boken är nedladdningsbar i formaten PDF, Epub & Mobi

Webbanalys - förstå och förbättra användarnas upplevelse hjälper till med verksamhetsmål och föreslår en process för att göra verklighet av de uppsatta målen. Webbanalys-boken finns att köpa dels hos förlaget Intranätverk, hos Adlibris men också på Bokus

Har du kommentarer på nyhetsbrevet, förslag eller tips är du varmt välkommen att höra av dig via kontaktsidan.