Performanceoptimering er ikke et engangsprojekt. Performance er noget, du arbejder med hele tiden.
En arbejdsgang betyder: Teamet gennemgår performancetal hver uge. Teamet taler om performance på standupmøder. Teamet tænker på performance, når det skriver kode. Teamet fejrer forbedringer.
Uden en arbejdsgang bliver performance dårligere med tiden. Teamet tænker ikke på det, før hjemmesiden er gået i stykker.
Med en arbejdsgang bliver performance bedre med tiden. Teamet bygger en kultur, hvor performance tæller.
Ugentligt performanceritual
Hver mandag morgen gennemgår teamet en performancerapport.
Rapporten viser, hvad der blev bedre i sidste uge, hvad der blev dårligere, og hvad der kræver opmærksomhed i denne uge.
Teamet drøfter: Hvorfor blev LCP på betalingssiden dårligere? Skyldes det ny kode? Skal vi undersøge det?
Resultatet er en liste med opgaver. Performanceforbedringer kommer med i sprintet.
Eksempel på et ugentligt ritual:
- Mandag kl. 10: møde om performance
- Gennemgå tallene: LCP på forsiden blev 0,2 sekunder bedre (godt), INP på produktsiden blev 50 millisekunder dårligere (undersøg)
- Årsag: Produktsiden fik en ny funktion (anbefalingsmotor). Funktionen tilføjede JavaScript, som øgede INP.
- Opgaver: udskyd JavaScript til anbefalingsmotoren, optimér funktionens kode
- Ansvarlig: udvikleren, der får opgaven
- Frist: udgivelse onsdag
Performance i udviklingsarbejdet
Før en funktion lanceres, måler udvikleren effekten på performance.
En funktion giver ny funktionalitet. Den giver også mere kode. Mere kode gør pakken større. En større pakke kan gøre performance dårligere.
Rammen er et performancebudget. Funktionen må ikke overskride budgettet.
Eksempel: en ny funktion på betalingssiden. Budget: højst 20 kilobyte ekstra i JavaScript-pakken. Udvikleren bygger funktionen. Den fylder 25 kilobyte. Den overskrider budgettet. Udvikleren må optimere: fjerne ubrugt kode, opdele pakken, udskyde kode. Udvikleren får funktionen ned på 20 kilobyte. Funktionen bliver godkendt.
Eksempel: implementering af en anbefalingsmotor til produkter
Funktion: vis personlige produktanbefalinger på produktsiden.
Performancebudget: højst 50 kilobyte ekstra i pakken.
Første version: 50 kilobyte. Lige på budgettet.
Test: mål LCP og INP.
- LCP stiger fra 2 til 2,3 sekunder (uacceptabelt, over budgettet)
- INP stiger fra 150 til 300 millisekunder (uacceptabelt, over budgettet)
Udviklerens optimering: indlæs anbefalinger sent under skærmens synlige del, og vent med at hente anbefalingsdata, til siden kan bruges.
Ny version: stadig 50 kilobyte, men:
- LCP er tilbage på 2 sekunder (inden for budgettet)
- INP er tilbage på 170 millisekunder (inden for budgettet)
Funktionen bliver godkendt: kravene til performance er opfyldt.
Rapportering til ledelsen
Månedlig rapport til ledelsen: udvikling i performance og betydning for forretningen.
Rapportens opbygning:
- Mål for performance og fremdrift
- Sammenligning med konkurrenterne (hvordan vi ligger i forhold til dem)
- Betydning for forretningen (omsætning fra performanceforbedringer)
- Næste fokus (hvad vi optimerer som det næste)
Eksempel på en månedlig rapport til direktionen:
- Mål: 90 procent af brugerne har LCP under 2,5 sekunder
- Fremdrift: lige nu 87 procent (op fra 85 procent sidste måned)
- Tidsplan: vi når målet om to måneder
- Konkurrenceposition: konkurrenternes median for LCP er 2 sekunder, vores LCP er 2 sekunder (på medianen, konkurrencedygtigt)
- Betydning for forretningen: Forbedringerne fra sidste måned øgede antallet af gennemførte køb med 0,5 procent. Med 100.000 besøgende om måneden er det 500 ekstra salg. Med en ordreværdi på 100 dollar er det 50.000 dollar ekstra i omsætning om måneden. 600.000 dollar om året.
- Næste fokus: optimering til mobil (LCP på mobil er 1 sekund langsommere end på computer, så der er mulighed for at få flere køb på mobil)
Ansæt til en performancekultur
Ansæt udviklere, der går op i performance. Spørg i samtalen: Fortæl om en performanceoptimering, du har lavet.
Ansæt produktchefer, der værdsætter performance. Performance giver en bedre brugeroplevelse og flere salg. Produktchefer bør kende betydningen for forretningen.
Byg en teamkultur, hvor performance tæller. Fejr sejrene. Anerkend den udvikler, der gjorde LCP 0,5 sekunder bedre.
Eksempel: ansættelse til en performancekultur.
Spørgsmål til en udviklerkandidat: Beskriv en gang, du optimerede kode for at få bedre performance. Hvad var problemet? Hvordan målte du forbedringen? Hvad betød det for forretningen?
Godt svar: Vi havde et langsomt API-endepunkt, der tog 2 sekunder. Brugerne klagede over langsom tilmelding. Jeg profilerede koden og fandt en tung databaseforespørgsel. Jeg tilføjede caching. Svartiden blev 200 millisekunder. Flere gennemførte tilmeldinger, plus 2 procent. 50 ekstra kunder om måneden. 250.000 dollar ekstra i omsætning om året.
Svaret viser teknisk forståelse (profilering, caching), måling (før og efter) og forretningsforståelse (betydning for tilmeldinger og omsætning).
Ansæt den udvikler. Hun eller han tænker på både performance og forretning.
Ofte stillede spørgsmål
Hvordan motiverer vi teamet til at prioritere performance?
Knyt performance til forretningstal. Vis, at 1 procent bedre performance giver 1 procent flere salg. Regn effekten på omsætningen ud. Vis, hvad det koster at optimere, og hvad det indbringer. Udviklere interesserer sig for effekt. Performance har en målbar effekt. Så prioriterer de det. Med WEMASY's hjemmesidebygger kan du sætte det op direkte på din hjemmeside.
Skal performanceoptimering være et eget team eller en del af alle teams?
En del af alle teams. Alle udviklere bør tænke på performance. Et separat performanceteam bliver en flaskehals. Det er bedre at fordele ansvaret. Hver udvikler har ansvar for performance i sin egen kode. Lederen holder teamet ansvarligt.
Hvordan afvejer vi nye funktioner mod performanceoptimering?
Performance er en funktion. En ny funktion plus effekten på performance er den samlede pris. Sæt budget af til begge dele. Eksempel: en ny funktion koster ét sprint. Den koster også et halvt sprint at optimere. Samlet pris er halvandet sprint. Afsæt tid til begge. Funktion og performance leveres sammen.
Hvad hvis ledelsen ikke går op i performance?
Vis betydningen for forretningen. 1 procent bedre konvertering svarer til 50.000 dollar om måneden (for en typisk webshop). Ledelsen forstår omsætning. Bedre performance er mere omsætning. Så går ledelsen op i det.
Hvor lang tid tager det at bygge en performancekultur?
Tre til seks måneder. Første måned: sæt tal og dashboard op. Anden måned: de ugentlige gennemgange starter, og teamet bliver mere opmærksomt. Tredje måned: teamet begynder at tænke på performance i koden. Efter seks måneder er performance en del af teamets DNA. Nye udviklere lærer kulturen fra første dag.
Hvordan bevarer vi performancekulturen, når virksomheden vokser?
Skriv arbejdsmåderne ned. Introducer nye udviklere til performancekulturen. Første dag: vis performance-dashboardet. Første uge: giv en opgave om at forbedre performance. Første måned: sæt et performancemål. Nye udviklere lærer kulturen. Kulturen består.