Det er til at styre performance på én hjemmeside. Det er en helt anden opgave at styre den på ti hjemmesider, fem mobilapps og flere mikrotjenester.
Én side: Dashboardet viser LCP, CLS og INP. Teamet kigger på én side ad gangen.
Stor virksomhed: Dashboardet viser hundredvis af sider, flere produkter og flere platforme. Teamet må prioritere.
At skalere performance-analytics betyder: vælge, hvad du måler, vælge, hvad du optimerer, og fordele ansvaret mellem teams.
Eksempel: En virksomhed har fem produkter (webplatform, mobilapp, dashboard, analyseværktøj og API). Hvert produkt har sin egen performanceprofil. Hvert produkt passes af sit eget team. Et centralt performanceteam kan ikke optimere det hele. Løsningen: Sæt standarder, lad hvert team eje performance for sit produkt, og lad det centrale team følge den samlede performance.
Vælg, hvad du måler i stor skala
Mål kun de kritiske forløb. Webshop: forside, produktside og betaling er kritiske. Blog og om-os-side er ikke kritiske. Fokuser på de kritiske forløb.
Mål pr. produktlinje. SaaS-platform: tilmeldingsside, dashboard og indstillinger. Hvert team ejer sine sider. Hvert team følger sin egen performance.
Mål efter betydning for forretningen. Sider, der skaber omsætning, betyder mest. Sider med lidt trafik betyder mindre. Fokuser på de sider, der skaber omsætning.
Eksempel: en virksomhed med tre produktlinjer:
- Produkt A (webshop): forside, produkt, betaling, søgning
- Produkt B (SaaS): tilmelding, dashboard, indstillinger, integration
- Produkt C (indhold): blogforside, artikel, kommentarer, relaterede artikler
Prioritet for målingerne:
- Produkt A (mest trafik, mest omsætning): mål alle sider
- Produkt B (meget trafik, meget omsætning): mål de kritiske sider (tilmelding, dashboard)
- Produkt C (lidt trafik, lidt omsætning): mål kun forsiden
Fordel ansvaret for performance
Det centrale team sætter standarderne. Hvert team ejer performance for sit produkt.
Standarder: Alle sider skal have LCP under 2,5 sekunder, CLS under 0,1 og INP under 200 millisekunder.
Ansvarsfordeling:
- Team for produkt A: ejer performance på forside, produkt, betaling og søgning
- Team for produkt B: ejer performance på tilmelding, dashboard og indstillinger
- Team for produkt C: ejer performance på blogforsiden
- Centralt performanceteam: følger op på standarderne, giver alarm ved forringelser og stiller værktøjer til rådighed
Eksempel: SaaS-virksomhed med tre udviklingsteams.
Standarder (sat af det centrale performanceteam):
- Mål for LCP: 2 sekunder (målene kan være forskellige for hvert produkt, men grundniveauet er 2 sekunder)
- Mål for CLS: 0,05
- Mål for INP: 150 millisekunder
Ansvar i produktteamene:
- Platformteamet: dashboardet skal holde LCP under 2 sekunder
- Integrationsteamet: integrationssiden skal holde LCP under 2,5 sekunder
- Analyseteamet: analysesiden skal holde LCP under 2 sekunder
Hvert team måler sine egne sider. Dashboardet giver alarm, hvis et teams sider overskrider standarderne. Teamet har ansvaret.
Saml performance på tværs af produkter
Det samlede dashboard viser alle produkter, alle sider og om standarderne overholdes.
Dashboardet viser, hvor mange procent der lever op til standarden: 90 procent af siderne har LCP under 2,5 sekunder. Grøn zone.
Dashboardet viser, hvilke produkter der ikke lever op til den: Produkt B har 80 procent (to sider overskrider standarden). Gul zone.
Rapport til ledelsen: Den samlede performance er stærk (90 procent af siderne overholder standarden). Ét produkt kræver opmærksomhed (produkt B).
Handling: Teamet bag produkt B får besked. Teamet undersøger sagen. Teamet optimerer de sider, der ikke overholder standarden.
Eksempel: samlet performance for en virksomhed med tre produkter.
Produkt A (webshop):
- Forside: LCP 1,2 s (overholder)
- Produktside: LCP 1,8 s (overholder)
- Betaling: LCP 2,1 s (overholder)
- Søgning: LCP 2,4 s (overholder)
- Overholdelse: 100 procent
Produkt B (SaaS):
- Tilmelding: LCP 1,9 s (overholder)
- Dashboard: LCP 2,6 s (overholder ikke)
- Indstillinger: LCP 2,5 s (overholder ikke)
- Overholdelse: 66 procent
Produkt C (indhold):
- Blogforside: LCP 2,3 s (overholder)
- Overholdelse: 100 procent
Samlet: 88 procent overholdelse på tværs af alle produkter.
Rapport til ledelsen: To af tre produkter overholder standarden fuldt ud. Produkt B kræver opmærksomhed. Teamet arbejder på at forbedre dashboardet og indstillingerne.
Performancestandarder for forskellige enheder og lande
Standarderne kan variere efter situationen. Computer er ikke det samme som mobil. USA er ikke det samme som resten af verden.
Mål for LCP på computer: 2 sekunder (hurtigt internet, hurtig processor).
Mål for LCP på mobil: 3 sekunder (langsommere internet, langsommere processor).
Mål for LCP i USA: 2 sekunder (generelt hurtigt internet).
Mål for LCP i resten af verden: 3 sekunder (internethastigheden varierer).
Eksempel: global SaaS-virksomhed med drift i flere regioner.
Standard for LCP pr. region:
- USA: 1,8 sekunder (mål)
- EU: 2,2 sekunder (mål, langsommere internet end i USA)
- APAC: 2,5 sekunder (mål, mere varierende internet)
Performance pr. region (nuværende status):
- USA: 1,5 sekunder (godt, bedre end målet)
- EU: 2,3 sekunder (ved målet, lidt forbedring nødvendig)
- APAC: 3,0 sekunder (under målet, skal forbedres)
Handling: APAC-teamet (eller det centrale performanceteam, hvis der ikke er et regionalt team) optimerer performance i APAC. Fokus: optimering af CDN for APAC-regionerne og optimering af billeder til lavere båndbredde.
Ofte stillede spørgsmål
Hvordan sætter vi forskellige performancestandarder for forskellige produkter?
Tag udgangspunkt i, hvor kritisk produktet er for forretningen, og hvad brugerne forventer. Det produkt, der giver mest omsætning, får det mest ambitiøse mål. Et produkt med mindre omsætning får et mere afslappet mål. Eksempel: Betaling i webshoppen er mest kritisk (skaber omsætning). Mål: 1,5 sekunder. Blogindhold er mindre kritisk. Mål: 2,5 sekunder. Med WEMASY's hjemmesidebygger kan du sætte det op direkte på din hjemmeside.
Skal det centrale performanceteam optimere alle produkter eller bare sætte standarder?
Sæt standarder og følg op. Lad produktteamene eje optimeringen. Det centrale team stiller værktøjer, sparring og eskalering til rådighed. Hvis et produktteam ikke kan nå standarden, hjælper det centrale team. Men den daglige optimering er produktteamets ansvar.
Hvordan håndterer vi konflikter mellem produktudvikling og krav til performance?
Performance er en del af kravene til produktet. En ny funktion skal overholde performancestandarderne. Hvis en funktion tilføjer kode, der forringer performance, bliver den ikke godkendt, før den er optimeret. Performance er ikke til forhandling (medmindre ledelsen bevidst fravælger det af forretningsmæssige grunde).
Skal vi måle performance på sider med lidt trafik?
Nej. Fokuser på sider med meget trafik og stor effekt. Det er ikke værd at bruge kræfter på at optimere sider med lidt trafik. Trafik gange betydning for forretningen afgør prioriteten. Mål dér, hvor effekten er størst.
Hvordan tager vi højde for forskelle i nethastighed mellem regioner?
Sæt forskellige mål for hver region. USA har hurtige net. Sæt et ambitiøst mål (1,5 sekunder). Andre regioner har forskellige net. Sæt realistiske mål (2 til 3 sekunder). Mål performance pr. region. Giv alarm, hvis en region ligger under sit eget mål (ikke det absolutte mål).
Skal vi bygge performancebudgetter ind i udgivelsesforløbet for alle teams?
Ja. Tjek performancebudgettet før udgivelse. Hvis et teams kode overskrider budgettet, bliver udgivelsen stoppet. Det forhindrer forringelser. Det sikrer også ansvar, fordi teamet er nødt til at optimere, før det lancerer.