Att hantera prestanda för en webbplats går bra. Att hantera prestanda över tio webbplatser, fem mobilappar och flera mikrotjänster är komplext.
En sajt: dashboarden visar LCP, CLS och INP. Teamet fokuserar på en sida i taget.
Stor organisation: dashboarden visar hundratals sidor, flera produkter och flera plattformar. Teamet måste prioritera.
Att skala prestandaanalys betyder: välja vad som ska mätas, välja vad som ska optimeras och fördela ansvaret mellan teamen.
Exempel: ett stort företag har fem produkter (webbplattform, mobilapp, dashboard, analysverktyg, API). Varje produkt har en egen prestandaprofil. Varje produkt förvaltas av ett eget team. Ett centralt prestandateam kan inte optimera allt. Lösning: sätt prestandastandarder, låt varje team äga prestandan för sin produkt och låt det centrala teamet följa upp den samlade prestandan.
Välja vad som ska mätas i stor skala
Mät bara kritiska flöden. Webbutiksplattform: startsida, produktsida, kassa (kritiskt). Blogg, om oss-sida (inte kritiskt). Fokusera på de kritiska flödena.
Mät per produktlinje. SaaS-plattform: registreringssida, dashboard, inställningssida. Varje team äger sina sidor. Varje team följer sin prestanda.
Mät efter affärseffekt. Sidor som ger intäkter spelar störst roll. Sidor med lite trafik spelar mindre roll. Fokusera på sidor som ger intäkter.
Verkligt exempel: ett företag med tre produktlinjer:
- Produkt A (webbutik): startsida, produkt, kassa, sök
- Produkt B (SaaS): registrering, dashboard, inställningar, integration
- Produkt C (innehåll): bloggens startsida, artikel, kommentarer, relaterade artiklar
Prioritering av mätningen:
- Produkt A (mest trafik, störst intäkter): mät alla sidor
- Produkt B (hög trafik, höga intäkter): mät kritiska sidor (registrering, dashboard)
- Produkt C (lite trafik, låga intäkter): mät bara startsidan
Fördela ansvaret för prestanda
Det centrala teamet sätter standarder. Varje team äger prestandan för sin produkt.
Standarder: alla sidor ska ha LCP under två komma fem sekunder, CLS under noll komma ett och INP under tvåhundra millisekunder.
Ansvarsmodell:
- Team för produkt A: äger prestandan för startsida, produkt, kassa och sök
- Team för produkt B: äger prestandan för registrering, dashboard och inställningar
- Team för produkt C: äger prestandan för bloggens startsida
- Centralt prestandateam: följer efterlevnaden, varnar vid försämring och tillhandahåller verktyg
Verkligt exempel: SaaS-företag med tre utvecklingsteam.
Standarder (satta av det centrala prestandateamet):
- Mål för LCP: två sekunder (produktspecifika mål kan variera, men grunden är två sekunder)
- Mål för CLS: noll komma noll fem
- Mål för INP: hundrafemtio millisekunder
Ansvar i produktteamen:
- Plattformsteamet: dashboarden ska hålla LCP under två sekunder
- Integrationsteamet: integrationssidan ska hålla LCP under två komma fem sekunder
- Analysteamet: analyssidan ska hålla LCP under två sekunder
Varje team mäter sina egna sidor. Dashboarden varnar om ett teams sidor överskrider standarderna. Teamet är ansvarigt.
Samla prestanda över produkter
Den samlade dashboarden visar: alla produkter, alla sidor och efterlevnad av standarderna.
Dashboarden visar andelen produkter som uppfyller standarden: nittio procent av sidorna har LCP under två komma fem sekunder. Grön zon.
Dashboarden visar vilka produkter som inte uppfyller standarden: produkt B har åttio procents efterlevnad (två sidor överskrider standarden). Gul zon.
Rapportering till ledningen: den samlade prestandan är stark (nittio procent av sidorna uppfyller standarden). En produkt behöver uppmärksamhet (produkt B).
Åtgärd: teamet för produkt B får en avisering. Teamet undersöker. Teamet optimerar sidorna som inte uppfyller standarden.
Verkligt exempel: samlad prestanda i ett företag med tre produkter.
Produkt A (webbutik):
- Startsida: LCP 1,2 s (uppfyller)
- Produktsida: LCP 1,8 s (uppfyller)
- Kassa: LCP 2,1 s (uppfyller)
- Sök: LCP 2,4 s (uppfyller)
- Efterlevnad: 100 procent
Produkt B (SaaS):
- Registrering: LCP 1,9 s (uppfyller)
- Dashboard: LCP 2,6 s (uppfyller inte)
- Inställningar: LCP 2,5 s (uppfyller inte)
- Efterlevnad: 66 procent
Produkt C (innehåll):
- Bloggens startsida: LCP 2,3 s (uppfyller)
- Efterlevnad: 100 procent
Sammanlagt: 88 procents efterlevnad över alla produkter.
Rapport till ledningen: två av tre produkter uppfyller standarden fullt ut. Produkt B behöver uppmärksamhet. Teamet arbetar med att förbättra prestandan för dashboard och inställningar.
Prestandastandarder för olika enheter och regioner
Standarder kan variera efter sammanhang. Standarderna för dator skiljer sig från mobil. Standarderna för USA skiljer sig från andra länder.
Mål för LCP på dator: två sekunder (snabbt internet, snabb processor).
Mål för LCP på mobil: tre sekunder (långsammare internet, långsammare processor).
Mål för LCP i USA: två sekunder (snabbt internet överlag).
Mål för LCP internationellt: tre sekunder (varierande internethastighet).
Verkligt exempel: globalt SaaS-företag med drift i flera regioner.
Standard för LCP per region:
- USA: 1,8 sekunder (mål)
- EU: 2,2 sekunder (mål, långsammare internet än i USA)
- Asien och Stillahavsregionen: 2,5 sekunder (mål, mer varierande internet)
Prestanda per region (nuläge):
- USA: 1,5 sekunder (bra, bättre än målet)
- EU: 2,3 sekunder (på målet, liten förbättring behövs)
- Asien och Stillahavsregionen: 3,0 sekunder (under målet, behöver förbättras)
Åtgärd: teamet för Asien och Stillahavsregionen (eller det centrala prestandateamet om det saknas regionalt team) optimerar prestandan där. Fokus: CDN-optimering för regionerna i Asien och Stillahavsområdet, bildoptimering för lägre bandbredd.
Vanliga frågor
Hur sätter vi olika prestandastandarder för olika produkter?
Utgå från affärskritikalitet och användarnas förväntningar. Produkten som ger mest intäkter: det mest ambitiösa målet. Produkten som ger mindre intäkter: ett mer avslappnat mål. Exempel: kassan i en webbutik är mest kritisk (ger intäkter). Mål: 1,5 sekunder. Bloggens innehåll är mindre kritiskt. Mål: 2,5 sekunder. Med WEMASY webbplatsbyggare kan du ställa in det direkt på din webbplats.
Ska det centrala prestandateamet optimera alla produkter eller bara sätta standarder?
Sätta standarder och följa upp. Låt produktteamen äga optimeringen. Det centrala teamet ger verktyg, coachning och eskalering. Om ett produktteam inte klarar standarden hjälper det centrala teamet till. Men den dagliga optimeringen är produktteamets ansvar.
Hur hanterar vi konflikter mellan produktutveckling och prestandakrav?
Prestanda är en del av produktkraven. En ny funktion måste uppfylla prestandastandarderna. Om funktionen lägger till kod som försämrar prestandan godkänns den inte förrän den är optimerad. Prestanda är inte förhandlingsbart (om inte ledningen uttryckligen nedprioriterar det av affärsskäl).
Ska vi mäta prestanda för sidor med lite trafik?
Nej. Fokusera på sidor med mycket trafik och stor effekt. Sidor med lite trafik är inte värda optimeringsarbetet. Trafik gånger affärseffekt avgör prioriteten. Mät där effekten är störst.
Hur tar vi hänsyn till skillnader i nätverkshastighet mellan regioner?
Sätt olika mål per region. USA har snabba nätverk. Sätt ett ambitiöst mål (1,5 sekunder). Andra regioner har varierande nätverk. Sätt realistiska mål (2 till 3 sekunder). Mät prestanda per region. Varna om en region når sämre än sitt eget mål (inte det absoluta målet).
Ska vi bygga in prestandabudgetar i releaseflödet för alla team?
Ja. Kontrollera prestandabudgeten före release. Om ett teams kod överskrider budgeten blockeras releasen. Det förhindrar försämringar. Det skapar också ansvar (teamet tvingas optimera innan det släpper).