Prestaties optimaliseren is geen eenmalig project. Prestaties zijn een doorlopende praktijk.
Een werkwijze betekent: het team bekijkt elke week de prestatiedata. Het team bespreekt prestaties in de standup. Het team denkt aan prestaties bij het schrijven van code. Het team viert verbeteringen in prestaties.
Zonder werkwijze: prestaties worden na verloop van tijd slechter. Het team denkt pas aan prestaties als de site kapot is.
Met werkwijze: prestaties worden na verloop van tijd beter. Het team bouwt een cultuur van snelheid. Prestaties worden gewaardeerd.
Wekelijks prestatieritueel
Elke maandagochtend: het team bekijkt het prestatierapport.
Het rapport toont: wat vorige week beter werd, wat vorige week slechter werd en wat deze week aandacht nodig heeft.
Bespreking in het team: waarom werd de LCP van de afrekenpagina slechter? Komt het door nieuwe code? Moeten we het uitzoeken?
Resultaat: actiepunten zijn bepaald. Prestatieverbeteringen komen in de sprint.
Een voorbeeld van een echt wekelijks ritueel:
- Maandag 10:00: overleg over prestaties
- Meetwaarden bekijken: LCP van de homepage verbeterde met 0,2 seconde (goed), INP van de productpagina werd 50 milliseconden slechter (uitzoeken)
- Oorzaakanalyse: de productpagina kreeg een nieuwe functie (aanbevelingsmodule). De functie voegde JavaScript toe en dat liet de INP stijgen.
- Actiepunten: JavaScript van de aanbevelingsmodule uitstellen, de code van de functie optimaliseren
- Eigenaar: de engineer die het oplost
- Deadline: uitrol op woensdag
Prestaties inbouwen in je ontwikkelwerk
Voordat een functie live gaat: de engineer meet het effect op de prestaties.
Een functie voegt functionaliteit toe. Een functie voegt ook code toe. Code maakt de bundel groter. Een grotere bundel kan de prestaties verslechteren.
Kader: een prestatiebudget. Een functie mag het budget niet overschrijden.
Voorbeeld: een nieuwe functie op de afrekenpagina. Budget: maximaal 20 kilobyte erbij in de JavaScript-bundel. De engineer bouwt de functie. De functie voegt 25 kilobyte toe. De functie overschrijdt het budget. De engineer moet optimaliseren: ongebruikte code verwijderen, de bundel splitsen, code uitstellen. De engineer brengt de functie terug naar 20 kilobyte. De functie wordt goedgekeurd.
Een voorbeeld uit de praktijk: een aanbevelingsmodule voor producten invoeren
Functie: persoonlijke productaanbevelingen tonen op de productpagina.
Prestatiebudget: maximaal 50 kilobyte erbij in de bundel.
Eerste uitvoering: 50 kilobyte. Precies op het budget.
Testen: meet LCP en INP.
- LCP stijgt van twee naar 2,3 seconden (niet acceptabel, boven het budget)
- INP stijgt van 150 naar 300 milliseconden (niet acceptabel, boven het budget)
Optimalisatie door de engineer: lazy load de aanbevelingen onder de vouw en stel het laden van aanbevelingsdata uit tot de pagina interactief is.
Nieuwe uitvoering: dezelfde 50 kilobyte, maar:
- LCP is weer twee seconden (binnen het budget)
- INP is weer 170 milliseconden (binnen het budget)
Functie goedgekeurd: de prestatie-eisen zijn gehaald.
Rapporteren aan de leiding
Maandrapport aan de leiding: prestatietrends en zakelijk effect.
Opbouw van het rapport:
- Prestatiedoelen en voortgang
- Vergelijking met de concurrentie (hoe we ervoor staan)
- Zakelijk effect (omzet uit prestatieverbeteringen)
- Focus hierna (wat we hierna optimaliseren)
Een voorbeeld van een echt maandrapport aan het managementteam:
- Doel: 90 procent van de gebruikers onder een LCP van 2,5 seconden
- Voortgang: nu 87 procent (vorige maand 85 procent)
- Tijdlijn: op koers om het doel over twee maanden te halen
- Positie ten opzichte van de concurrentie: de mediane LCP van concurrenten is 2 seconden, onze LCP is 2 seconden (op het midden, concurrerend)
- Zakelijk effect: de prestatieverbeteringen van vorige maand verhoogden het afronden van bestellingen met 0,5 procent. Bij 100.000 bezoekers per maand zijn dat 500 extra conversies. Bij een bestelwaarde van 100 dollar is dat 50.000 dollar extra omzet per maand. 600.000 dollar per jaar.
- Focus hierna: optimalisatie voor mobiel (de mobiele LCP is een seconde trager dan op desktop, een kans om het mobiele conversiepercentage te verbeteren)
Mensen aannemen voor een cultuur van snelheid
Neem engineers aan die om prestaties geven. Sollicitatievraag: vertel over een prestatieverbetering die je hebt doorgevoerd.
Neem productmanagers aan die prestaties waarderen. Prestaties verbeteren de gebruikerservaring en het conversiepercentage. Productmanagers moeten het zakelijke effect kennen.
Bouw een teamcultuur waarin prestaties tellen. Vier prestatiewinst. Geef erkenning aan de engineer die de LCP met 0,5 seconde verbeterde.
Een voorbeeld uit de praktijk: aannemen voor een prestatiecultuur.
Sollicitatievraag aan een engineer: beschrijf een keer dat je code optimaliseerde voor prestaties. Wat was het probleem? Hoe mat je de verbetering? Wat was het zakelijke effect?
Een goed antwoord: we hadden een trage API-endpoint die twee seconden nodig had. Gebruikers klaagden over trage aanmelding. Ik profileerde de code en vond een dure databasequery. Ik voegde caching toe. De reactietijd verbeterde naar 200 milliseconden. Het afronden van aanmeldingen steeg met twee procent. Vijftig extra klanten per maand. 250.000 dollar extra omzet per jaar.
Het antwoord laat zien: technisch begrip (profileren, caching), meten (voor en na) en zakelijk denken (effect op aanmeldingen en omzet).
Neem deze engineer aan. Die denkt aan prestaties en aan het bedrijf.
Veelgestelde vragen
Hoe motiveren we het team om prestaties voorrang te geven?
Koppel prestaties aan zakelijke cijfers. Laat zien dat één procent betere prestaties één procent meer conversie oplevert. Reken het effect op omzet uit. Laat de kosten van optimaliseren zien naast de omzet die het oplevert. Engineers geven om effect. Prestaties hebben een meetbaar effect. Engineers geven er dan voorrang aan. Met de websitebouwer van WEMASY kun je dit direct op je website instellen.
Moet prestatieoptimalisatie een apart team zijn of onderdeel van alle teams?
Onderdeel van alle teams. Elke engineer moet aan prestaties denken. Een apart prestatieteam wordt een knelpunt. Gedeeld eigenaarschap werkt beter. Elke engineer is eigenaar van de prestaties van zijn of haar code. De engineeringmanager spreekt het team erop aan.
Hoe wegen we nieuwe functies af tegen prestatieoptimalisatie?
Prestaties zijn een functie. Een nieuwe functie plus het effect op prestaties zijn de totale kosten. Maak budget vrij voor allebei. Voorbeeld: een nieuwe functie kost één sprint. De functie kost ook een halve sprint om te optimaliseren voor prestaties. De totale kosten zijn anderhalve sprint. Plan allebei in. Functie en prestaties gaan samen live.
Wat als de leiding niet om prestaties geeft?
Laat het zakelijke effect zien. Eén procent meer conversie is 50.000 dollar per maand (voor een gemiddelde webshop). De leiding begrijpt omzet. Betere prestaties zijn meer omzet. Dan gaat de leiding er wel om geven.
Hoe lang duurt het om een prestatiecultuur te bouwen?
Drie tot zes maanden. Eerste maand: meetwaarden en dashboard opzetten. Tweede maand: wekelijkse besprekingen beginnen, het team wordt zich bewuster. Derde maand: het team denkt bij het schrijven van code aan prestaties. Zes maanden: prestaties horen bij het DNA van het team. Nieuwe engineers leren de prestatiecultuur vanaf dag één.
Hoe houden we de prestatiecultuur vast als het bedrijf groeit?
Leg de werkwijze vast. Laat nieuwe engineers kennismaken met de prestatiecultuur. Eerste dag: laat het prestatiedashboard zien. Eerste week: geef een taak om prestaties te verbeteren. Eerste maand: stel een prestatiedoel. Nieuwe engineers leren de cultuur. De cultuur blijft behouden.