Gestire le prestazioni di un solo sito è fattibile. Gestire le prestazioni di dieci siti, cinque app mobili e più microservizi è complesso.
Un solo sito: la dashboard mostra LCP, CLS, INP. Il team si concentra su una pagina alla volta.
Un'azienda grande: la dashboard mostra centinaia di pagine, più prodotti, più piattaforme. Il team deve stabilire le priorità.
Scalare l'analisi delle prestazioni significa: scegliere cosa misurare, scegliere cosa ottimizzare, distribuire la responsabilità tra i team.
Esempio: un'azienda ha cinque prodotti (piattaforma web, app mobile, dashboard, strumento di analisi, API). Ogni prodotto ha un profilo di prestazioni diverso. Ogni prodotto è curato da un team diverso. Un team centrale non può ottimizzare tutto. Soluzione: fissa gli standard di prestazioni, ogni team è responsabile delle prestazioni del proprio prodotto, il team centrale monitora le prestazioni complessive.
Scegliere cosa misurare su scala aziendale
Misura solo i percorsi critici. Piattaforma di e-commerce: home page, pagina prodotto, pagamento (critici). Blog, pagina chi siamo (non critici). Concentrati sui percorsi critici.
Misura per linea di prodotto. Piattaforma SaaS: pagina di iscrizione, dashboard, pagina impostazioni. Ogni team è responsabile delle proprie pagine. Ogni team monitora le proprie prestazioni.
Misura in base all'impatto sul business. Le pagine che generano ricavi contano di più. Le pagine con poco traffico contano meno. Concentrati sulle pagine che generano ricavi.
Esempio reale: un'azienda con tre linee di prodotto:
- Prodotto A (e-commerce): home page, prodotto, pagamento, ricerca
- Prodotto B (SaaS): iscrizione, dashboard, impostazioni, integrazioni
- Prodotto C (contenuti): home page del blog, articolo, commenti, articoli correlati
Priorità di misurazione:
- Prodotto A (più traffico, più ricavi): misura tutte le pagine
- Prodotto B (molto traffico, molti ricavi): misura le pagine critiche (iscrizione, dashboard)
- Prodotto C (poco traffico, pochi ricavi): misura solo la home page
Distribuire la responsabilità sulle prestazioni
Il team centrale fissa gli standard. Ogni team è responsabile delle prestazioni del proprio prodotto.
Standard: tutte le pagine devono avere un LCP sotto i due virgola cinque secondi, un CLS sotto zero virgola uno, un INP sotto i duecento millisecondi.
Modello di responsabilità:
- Team del prodotto A: responsabile delle prestazioni di home page, prodotto, pagamento, ricerca
- Team del prodotto B: responsabile delle prestazioni di iscrizione, dashboard, impostazioni
- Team del prodotto C: responsabile delle prestazioni della home page del blog
- Team centrale per le prestazioni: controlla il rispetto delle regole, avvisa sulle regressioni, fornisce gli strumenti
Esempio reale: un'azienda SaaS con tre team tecnici.
Standard (fissati dal team centrale per le prestazioni):
- Obiettivo LCP: due secondi (gli obiettivi dei singoli prodotti possono variare, ma la base è due secondi)
- Obiettivo CLS: zero virgola zero cinque
- Obiettivo INP: centocinquanta millisecondi
Responsabilità dei team di prodotto:
- Team della piattaforma: la dashboard deve mantenere un LCP sotto i due secondi
- Team delle integrazioni: la pagina delle integrazioni deve mantenere un LCP sotto i due virgola cinque secondi
- Team dell'analisi: la pagina di analisi deve mantenere un LCP sotto i due secondi
Ogni team misura le proprie pagine. La dashboard avvisa se le pagine di un team superano gli standard. Il team ne risponde.
Aggregare le prestazioni tra i prodotti
La dashboard aggregata mostra: tutti i prodotti, tutte le pagine, il rispetto degli standard.
La dashboard mostra la percentuale di prodotti che rispettano lo standard: il novanta per cento delle pagine ha un LCP sotto i due virgola cinque secondi. Zona verde.
La dashboard mostra quali prodotti non rispettano lo standard: il prodotto B è all'ottanta per cento di conformità (due pagine superano lo standard). Zona gialla.
Report alla direzione: le prestazioni complessive sono solide (novanta per cento delle pagine in regola). Un prodotto richiede attenzione (prodotto B).
Azione: il team del prodotto B riceve l'avviso. Il team indaga. Il team ottimizza le pagine fuori standard.
Esempio reale: prestazioni aggregate di un'azienda con tre prodotti.
Prodotto A (e-commerce):
- Home page: LCP 1,2 s (in regola)
- Pagina prodotto: LCP 1,8 s (in regola)
- Pagamento: LCP 2,1 s (in regola)
- Ricerca: LCP 2,4 s (in regola)
- Conformità: 100 per cento
Prodotto B (SaaS):
- Iscrizione: LCP 1,9 s (in regola)
- Dashboard: LCP 2,6 s (fuori standard)
- Impostazioni: LCP 2,5 s (fuori standard)
- Conformità: 66 per cento
Prodotto C (contenuti):
- Home page del blog: LCP 2,3 s (in regola)
- Conformità: 100 per cento
Totale: 88 per cento di conformità su tutti i prodotti.
Report alla direzione: due prodotti su tre sono pienamente in regola. Il prodotto B richiede attenzione. Il team lavora per migliorare le prestazioni di dashboard e impostazioni.
Standard di prestazioni per tipo di dispositivo e area geografica
Gli standard possono cambiare in base al contesto. Gli standard per il desktop sono diversi da quelli per il mobile. Quelli degli USA sono diversi da quelli internazionali.
Obiettivo LCP su desktop: due secondi (internet veloce, CPU veloce).
Obiettivo LCP su mobile: tre secondi (internet più lento, CPU più lenta).
Obiettivo LCP negli USA: due secondi (internet veloce in generale).
Obiettivo LCP a livello internazionale: tre secondi (velocità di internet varie).
Esempio reale: un'azienda SaaS globale con servizi in più regioni.
Standard LCP per area geografica:
- USA: 1,8 secondi (obiettivo)
- UE: 2,2 secondi (obiettivo, internet più lento che negli USA)
- Asia-Pacifico: 2,5 secondi (obiettivo, internet più variabile)
Prestazioni per regione (situazione attuale):
- USA: 1,5 secondi (buono, supera l'obiettivo)
- UE: 2,3 secondi (in linea con l'obiettivo, serve un piccolo miglioramento)
- Asia-Pacifico: 3,0 secondi (sotto l'obiettivo, va migliorato)
Azione: il team dell'Asia-Pacifico (o il team centrale per le prestazioni, se non c'è un team regionale) ottimizza le prestazioni in Asia-Pacifico. Priorità: ottimizzazione della CDN per le regioni dell'Asia-Pacifico, ottimizzazione delle immagini per la banda più ridotta.
Domande frequenti
Come fissiamo standard di prestazioni diversi per prodotti diversi?
In base all'importanza per il business e alle aspettative degli utenti. Il prodotto che genera più ricavi: l'obiettivo più ambizioso. Il prodotto che genera meno ricavi: un obiettivo più morbido. Esempio: il pagamento di un negozio online è il più critico (genera ricavi). Obiettivo: 1,5 secondi. I contenuti del blog sono meno critici. Obiettivo: 2,5 secondi. Con il creatore di siti di WEMASY puoi impostarlo direttamente sul tuo sito.
Il team centrale per le prestazioni deve ottimizzare tutti i prodotti o solo fissare gli standard?
Fissare gli standard e monitorare. Lascia che siano i team di prodotto a occuparsi dell'ottimizzazione. Il team centrale fornisce strumenti, affiancamento e un livello di escalation. Se un team di prodotto non riesce a rispettare lo standard, il team centrale aiuta. Ma l'ottimizzazione di tutti i giorni spetta al team di prodotto.
Come gestiamo i conflitti tra sviluppo del prodotto e requisiti di prestazioni?
Le prestazioni fanno parte dei requisiti del prodotto. Una nuova funzione deve rispettare gli standard di prestazioni. Se la funzione aggiunge codice che peggiora le prestazioni, non viene approvata finché non è ottimizzata. Le prestazioni non sono negoziabili (a meno che la direzione non le metta esplicitamente in secondo piano per un motivo di business).
Dobbiamo misurare le prestazioni delle pagine con poco traffico?
No. Concentrati sulle pagine con molto traffico e molto impatto. Le pagine con poco traffico non meritano lo sforzo di ottimizzazione. Il traffico moltiplicato per l'impatto sul business determina la priorità. Misura dove l'impatto è maggiore.
Come teniamo conto delle differenze di velocità di rete tra le regioni?
Fissa obiettivi diversi per regione. Gli USA hanno reti veloci. Fissa un obiettivo ambizioso (1,5 secondi). Le regioni internazionali hanno reti variabili. Fissa obiettivi realistici (2-3 secondi). Misura le prestazioni per regione. Avvisa se una regione rende meno del proprio obiettivo (non dell'obiettivo assoluto).
Dobbiamo inserire i budget di prestazioni nella pipeline di rilascio per tutti i team?
Sì. Controllo del budget di prestazioni prima del rilascio. Se il codice di un team supera il budget, il rilascio viene bloccato. Previene le regressioni. Garantisce anche la responsabilità (il team è costretto a ottimizzare prima di rilasciare).