Prestaties van één website beheren is te doen. Prestaties beheren over tien websites, vijf mobiele apps en meerdere microservices is complex.
Eén site: het dashboard toont LCP, CLS, INP. Het team richt zich op één pagina tegelijk.
Grote organisatie: het dashboard toont honderden pagina's, meerdere producten en meerdere platforms. Het team moet kiezen.
Prestatieanalyse opschalen betekent: kiezen wat je meet, kiezen wat je optimaliseert en de verantwoordelijkheid over teams verdelen.
Voorbeeld: een grote organisatie heeft vijf producten (webplatform, mobiele app, dashboard, analyticstool, API). Elk product heeft een ander prestatieprofiel. Elk product wordt onderhouden door een ander team. Een centraal prestatieteam kan niet alles optimaliseren. Oplossing: normen vaststellen, elk team is eigenaar van de prestaties van zijn product en het centrale team volgt de prestaties als geheel.
Kiezen wat je meet op grote schaal
Meet alleen kritieke routes. Webshopplatform: homepage, productpagina, afrekenen (kritiek). Blog, overpagina (niet kritiek). Richt je op kritieke routes.
Meet per productlijn. SaaS-platform: aanmeldpagina, dashboard, instellingenpagina. Elk team is eigenaar van zijn pagina's. Elk team volgt zijn prestaties.
Meet op zakelijk effect. Pagina's die omzet opleveren tellen het zwaarst. Pagina's met weinig verkeer tellen minder. Richt je op pagina's die omzet opleveren.
Een voorbeeld uit de praktijk: een organisatie met drie productlijnen:
- Product A (webshop): homepage, product, afrekenen, zoeken
- Product B (SaaS): aanmelden, dashboard, instellingen, integraties
- Product C (content): bloghomepage, artikel, reacties, gerelateerde artikelen
Prioriteit voor meting:
- Product A (meeste verkeer, meeste omzet): meet alle pagina's
- Product B (veel verkeer, veel omzet): meet kritieke pagina's (aanmelden, dashboard)
- Product C (weinig verkeer, weinig omzet): meet alleen de homepage
Eigenaarschap voor prestaties verdelen
Het centrale team stelt normen vast. Elk team is eigenaar van de prestaties van zijn product.
Normen: alle pagina's moeten een LCP onder 2,5 seconden hebben, een CLS onder 0,1 en een INP onder 200 milliseconden.
Model voor eigenaarschap:
- Team van product A: eigenaar van de prestaties van homepage, product, afrekenen, zoeken
- Team van product B: eigenaar van de prestaties van aanmelden, dashboard, instellingen
- Team van product C: eigenaar van de prestaties van de bloghomepage
- Centraal prestatieteam: controleert naleving, meldt achteruitgang en levert tools
Een voorbeeld uit de praktijk: een SaaS-bedrijf met drie engineeringteams.
Normen (vastgesteld door het centrale prestatieteam):
- LCP-doel: 2 seconden (doelen per product kunnen verschillen, maar de basis is 2 seconden)
- CLS-doel: 0,05
- INP-doel: 150 milliseconden
Verantwoordelijkheid van de productteams:
- Platformteam: het dashboard moet een LCP onder 2 seconden houden
- Integratieteam: de integratiepagina moet een LCP onder 2,5 seconden houden
- Analyticsteam: de analyticspagina moet een LCP onder 2 seconden houden
Elk team meet zijn eigen pagina's. Het dashboard geeft een melding als de pagina's van een team de normen overschrijden. Het team is verantwoordelijk.
Prestaties over producten heen samenvoegen
Het samengevoegde dashboard toont: alle producten, alle pagina's, naleving van de normen.
Het dashboard toont het percentage producten dat aan de norm voldoet: 90 procent van de pagina's heeft een LCP onder 2,5 seconden. Groene zone.
Het dashboard toont welke producten niet voldoen: product B komt op 80 procent naleving (twee pagina's overschrijden de norm). Gele zone.
Rapportage aan de leiding: de totale prestaties zijn sterk (90 procent van de pagina's voldoet). Eén product heeft aandacht nodig (product B).
Actie: het team van product B krijgt een melding. Het team zoekt het uit. Het team optimaliseert de pagina's die niet voldoen.
Een voorbeeld uit de praktijk: samengevoegde prestaties van een bedrijf met drie producten.
Product A (webshop):
- Homepage: LCP 1,2 s (voldoet)
- Productpagina: LCP 1,8 s (voldoet)
- Afrekenen: LCP 2,1 s (voldoet)
- Zoeken: LCP 2,4 s (voldoet)
- Naleving: 100 procent
Product B (SaaS):
- Aanmelden: LCP 1,9 s (voldoet)
- Dashboard: LCP 2,6 s (voldoet niet)
- Instellingen: LCP 2,5 s (voldoet niet)
- Naleving: 66 procent
Product C (content):
- Bloghomepage: LCP 2,3 s (voldoet)
- Naleving: 100 procent
Totaal: 88 procent naleving over alle producten.
Rapport aan de leiding: twee van de drie producten voldoen volledig. Product B heeft aandacht nodig. Het team werkt aan betere prestaties van het dashboard en de instellingen.
Prestatienormen per apparaattype en regio
Normen kunnen per situatie verschillen. Desktopnormen verschillen van mobiele normen. Normen voor de VS verschillen van internationale normen.
LCP-doel op desktop: 2 seconden (snel internet, snelle processor).
LCP-doel op mobiel: 3 seconden (trager internet, tragere processor).
LCP-doel in de VS: 2 seconden (over het algemeen snel internet).
LCP-doel internationaal: 3 seconden (wisselende internetsnelheden).
Een voorbeeld uit de praktijk: een wereldwijd SaaS-bedrijf met uitrol in meerdere regio's.
LCP-norm per regio:
- VS: 1,8 seconden (doel)
- EU: 2,2 seconden (doel, trager internet dan in de VS)
- APAC: 2,5 seconden (doel, wisselender internet)
Prestaties per regio (huidige stand):
- VS: 1,5 seconden (goed, beter dan het doel)
- EU: 2,3 seconden (op het doel, kleine verbetering nodig)
- APAC: 3,0 seconden (onder het doel, moet beter)
Actie: het APAC-team (of het centrale prestatieteam als er geen regionaal team is) optimaliseert de prestaties in APAC. Focus: CDN-optimalisatie voor APAC-regio's, beeldoptimalisatie voor lagere bandbreedte.
Veelgestelde vragen
Hoe stellen we verschillende prestatienormen in voor verschillende producten?
Baseer ze op zakelijk belang en wat gebruikers verwachten. Het product met de meeste omzet: het scherpste doel. Een product met minder omzet: een soepeler doel. Voorbeeld: afrekenen in de webshop is het meest kritiek (levert omzet op). Doel: 1,5 seconden. Blogcontent is minder kritiek. Doel: 2,5 seconden. Met de websitebouwer van WEMASY kun je dit direct op je website instellen.
Moet het centrale prestatieteam alle producten optimaliseren of alleen normen stellen?
Normen stellen en controleren. Laat de productteams zelf optimaliseren. Het centrale team levert tools, coaching en escalatie. Kan een productteam de norm niet halen, dan helpt het centrale team. Maar het dagelijkse optimaliseren is de verantwoordelijkheid van het productteam.
Hoe gaan we om met conflicten tussen productontwikkeling en prestatie-eisen?
Prestaties horen bij de eisen aan het product. Een nieuwe functie moet aan de prestatienormen voldoen. Voegt een functie code toe die de prestaties verslechtert, dan wordt de functie pas goedgekeurd na optimalisatie. Prestaties zijn niet onderhandelbaar (tenzij de leiding om zakelijke redenen bewust een lagere prioriteit kiest).
Moeten we prestaties meten voor pagina's met weinig verkeer?
Nee. Richt je op pagina's met veel verkeer en veel effect. Pagina's met weinig verkeer zijn de moeite van optimaliseren niet waard. Verkeer maal zakelijk effect bepaalt de prioriteit. Meet waar het effect het grootst is.
Hoe houden we rekening met verschillen in netwerksnelheid tussen regio's?
Stel per regio andere doelen in. De VS heeft snelle netwerken. Stel een scherp doel (1,5 seconden). Internationale regio's hebben wisselende netwerken. Stel realistische doelen (2 tot 3 seconden). Meet prestaties per regio. Geef een melding als een regio onder het eigen doel presteert (niet onder het algemene doel).
Moeten we prestatiebudgetten voor alle teams in de uitrolpipeline opnemen?
Ja. Controleer het prestatiebudget vóór de uitrol. Overschrijdt de code van een team het budget, dan wordt de uitrol geblokkeerd. Zo voorkom je terugval. Het zorgt ook voor verantwoordelijkheid (het team moet optimaliseren voordat het live gaat).