Prestandaoptimering är inte ett engångsprojekt. Prestanda är en löpande rutin.
Ett arbetsflöde betyder: teamet går igenom prestandadata varje vecka. Teamet pratar om prestanda på stand-ups. Teamet tänker på prestanda när det skriver kod. Teamet firar förbättringar.
Utan arbetsflöde: prestandan försämras över tid. Teamet tänker inte på prestanda förrän sajten är trasig.
Med arbetsflöde: prestandan förbättras över tid. Teamet bygger en prestandakultur. Prestanda värderas.
Veckorutin för prestanda
Varje måndagsmorgon: teamet går igenom prestandarapporten.
Rapporten visar: vad som förbättrades förra veckan, vad som försämrades förra veckan och vad som behöver uppmärksamhet den här veckan.
Diskussion i teamet: varför försämrades LCP på kassasidan? Beror det på ny kod? Behöver vi undersöka?
Resultat: åtgärder identifieras. Prestandaförbättringar läggs in i sprinten.
Exempel på en verklig veckorutin:
- Måndag kl. 10: genomgångsmöte om prestanda
- Genomgång av mått: LCP på startsidan förbättrades med noll komma två sekunder (bra), INP på produktsidan försämrades med femtio millisekunder (undersök)
- Orsaksanalys: produktsidan fick en ny funktion (rekommendationsmotor). Funktionen lade till JavaScript som ökade INP.
- Åtgärder: skjut upp JavaScript för rekommendationsmotorn, optimera funktionens kod
- Ansvarig: ingenjör som får uppdraget att åtgärda
- Deadline: release på onsdagen
Gör prestanda till en del av utvecklingsflödet
Innan en funktion släpps: ingenjören mäter effekten på prestandan.
Funktionen ger ny funktionalitet. Funktionen ger också mer kod. Mer kod ger ett större paket. Ett större paket kan försämra prestandan.
Ramverk: prestandabudget. Funktionen får inte överskrida budgeten.
Exempel: en ny funktion på kassasidan. Budget: högst tjugo kilobyte till JavaScript-paketet. Ingenjören bygger funktionen. Funktionen lägger till tjugofem kilobyte. Funktionen överskrider budgeten. Ingenjören måste optimera: ta bort oanvänd kod, dela upp paketet, skjut upp kod. Ingenjören minskar funktionen till tjugo kilobyte. Funktionen godkänns.
Verkligt exempel: införande av en rekommendationsmotor för produkter
Funktion: visa personliga produktrekommendationer på produktsidan.
Prestandabudget: högst femtio kilobyte till paketet.
Första versionen: femtio kilobyte. På budgeten.
Test: mät LCP och INP.
- LCP ökar från två till två komma tre sekunder (oacceptabelt, överskrider budgeten)
- INP ökar från hundrafemtio till trehundra millisekunder (oacceptabelt, överskrider budgeten)
Ingenjörens optimering: använd lazy loading för rekommendationerna under vikningen, skjut upp inladdningen av rekommendationsdata tills sidan är interaktiv.
Ny version: samma storlek på femtio kilobyte, men:
- LCP går tillbaka till två sekunder (under budget)
- INP går tillbaka till hundrasjuttio millisekunder (under budget)
Funktionen godkänns: prestandakraven är uppfyllda.
Rapportering till ledningen
Månadsrapport till ledningen: prestandatrender och affärseffekt.
Rapportens struktur:
- Prestandamål och framsteg
- Jämförelse med andra aktörer (hur vi ligger till)
- Affärseffekt (intäkter från prestandaförbättringar)
- Fokus framöver (vad vi optimerar härnäst)
Exempel på en verklig månadsrapport till ledningsgruppen:
- Mål: nittio procent av användarna under en LCP på två komma fem sekunder
- Framsteg: just nu åttiosju procent (upp från åttiofem procent förra månaden)
- Tidslinje: på rätt spår att nå målet om två månader
- Konkurrensläge: medianvärdet för LCP hos andra aktörer är två sekunder, vår LCP är två sekunder (på medianen, konkurrenskraftigt)
- Affärseffekt: prestandaförbättringarna från förra månaden ökade andelen genomförda köp med noll komma fem procent. På hundratusen besökare i månaden är det femhundra extra konverteringar. Med ett ordervärde på hundra dollar är det femtiotusen dollar i extra intäkter varje månad. Sexhundratusen dollar per år.
- Fokus framöver: mobiloptimering (LCP på mobil är en sekund långsammare än på dator, chans att förbättra konverteringsgraden på mobil)
Rekrytera för en prestandakultur
Anställ ingenjörer som bryr sig om prestanda. Intervjufråga: berätta om en prestandaoptimering du genomförde.
Anställ produktchefer som värderar prestanda. Prestanda förbättrar användarupplevelsen och konverteringsgraden. Produktchefer bör känna till affärseffekten.
Bygg en teamkultur där prestanda värderas. Fira prestandavinster. Uppmärksamma ingenjören som förbättrade LCP med noll komma fem sekunder.
Verkligt exempel: rekrytera för en prestandakultur.
Intervjufråga till en ingenjörskandidat: beskriv ett tillfälle då du optimerade kod för prestanda. Vad var problemet? Hur mätte du förbättringen? Vad blev affärseffekten?
Bra svar: vi hade en långsam API-slutpunkt som tog två sekunder. Användare klagade på långsam registrering. Jag profilerade koden och hittade en dyr databasfråga. Jag lade till cachning. Svarstiden förbättrades till tvåhundra millisekunder. Andelen genomförda registreringar ökade med två procent. Femtio extra kunder per månad. Tvåhundrafemtiotusen dollar i extra årliga intäkter.
Svaret visar: teknisk förståelse (profilering, cachning), mätning (före och efter) och affärstänkande (effekt på registreringar och intäkter).
Anställ den här ingenjören. Hen tänker på både prestanda och affär.
Vanliga frågor
Hur motiverar vi teamet att prioritera prestanda?
Koppla prestanda till affärsmått. Visa att en procents bättre prestanda ger en procents högre konvertering. Räkna ut intäktseffekten. Visa kostnaden för optimering mot intäkterna. Ingenjörer bryr sig om effekt. Prestanda har mätbar effekt. Ingenjörerna prioriterar den. Med WEMASY webbplatsbyggare kan du ställa in det direkt på din webbplats.
Ska prestandaoptimering vara ett eget team eller en del av alla team?
En del av alla team. Varje ingenjör bör tänka på prestanda. Ett separat prestandateam blir en flaskhals. Fördelat ansvar är bättre. Varje ingenjör äger prestandan i sin kod. Utvecklingschefen håller teamet ansvarigt.
Hur balanserar vi nya funktioner mot prestandaoptimering?
Prestanda är en funktion. Ny funktion plus effekt på prestanda är den totala kostnaden. Budgetera för båda. Exempel: en ny funktion kostar en sprint. Funktionen kostar också en halv sprint att optimera för prestanda. Totalkostnaden är en och en halv sprint. Avsätt tid för båda. Funktion och prestanda släpps tillsammans.
Vad gör vi om ledningen inte bryr sig om prestanda?
Visa affärseffekten. En procents bättre konvertering ger femtiotusen dollar i månaden (för en typisk webbutik). Ledningen förstår intäkter. Bättre prestanda är bättre intäkter. Då börjar ledningen bry sig.
Hur lång tid tar det att bygga en prestandakultur?
Tre till sex månader. Första månaden: ta fram mått och dashboard. Andra månaden: veckogenomgångar startar, teamets medvetenhet ökar. Tredje månaden: teamet börjar tänka på prestanda i koden. Efter sex månader: prestanda är en del av teamets DNA. Nya ingenjörer lär sig prestandakulturen från dag ett.
Hur behåller vi prestandakulturen när företaget växer?
Dokumentera arbetssätten. Introducera nya ingenjörer i prestandakulturen. Första dagen: visa prestandadashboarden. Första veckan: ge en uppgift om prestandaförbättring. Första månaden: sätt ett prestandamål. Nya ingenjörer lär sig kulturen. Kulturen består.