Inizia dai percorsi, non da una media su tutto il sito
Elenca tre-cinque percorsi in cui il ritardo ha un chiaro costo per il cliente o per l'operatività: atterrare su una pagina di campagna, trovare un prodotto, inviare un form di lead, effettuare il login o completare una richiesta di supporto. Per ognuno, scrivi l'inizio, l'esito utile, la classe di dispositivo principale e la pagina o l'interazione che deve funzionare bene.
Dai a ogni percorso la propria riga di budget. Una dashboard può includere più codice di una pagina pubblica, ma la sua azione di filtro ha bisogno di un obiettivo di reattività. Una pagina prodotto ricca di media può accettare immagini più grandi, ma necessita di un limite per l'immagine visibile principale. Questo evita che un percorso critico debole scompaia nella media origin-wide.
Denomina ciò che il visitatore può vedere o fare, come leggere l'offerta, vedere un risultato o ricevere la conferma di un form.
La cache può cambiare in modo significativo il costo degli asset, quindi registra se il budget copre la prima visita, la visita ripetuta o entrambe.
Scegli esiti e input controllabili
Usa sia metriche di esito che limiti sugli input. Google descrive Largest Contentful Paint (LCP) come prestazione di caricamento; Interaction to Next Paint (INP) come reattività all'interazione; e Cumulative Layout Shift (CLS) come stabilità visiva. Le soglie consigliate sono LCP a 2,5 secondi o meno, INP a 200 millisecondi o meno e CLS a 0,1 o meno al 75° percentile, considerate separatamente per mobile e desktop.
Aggiungi limiti che espongano una causa presto: JavaScript iniziale, immagini necessarie prima del contenuto principale, trasferimento totale per il percorso, richieste di terze parti e un widget noto per essere costoso. Monitora sempre le dimensioni trasferite compresse. Una diagnostica come Time to First Byte può aiutare a indagare un caricamento lento, ma non è di per sé l'esito che conta per il cliente.
Usa LCP quando il percorso dipende dal rendering del contenuto principale.
Usa INP dal field per ricerca, filtraggio, menu e checkout; usa un proxy di laboratorio solo prima che esistano dati di campo.
Limita la route iniziale e i maggiori contributori in modo che i proprietari sappiano cosa modificare dopo una violazione.
Fissa i numeri a partire dalla tua baseline
Cattura una baseline per ogni percorso. In PageSpeed Insights, distingui i dati di campo del Chrome User Experience Report (CrUX), che aggrega esperienze reali degli utenti Chrome, dai dati di laboratorio di Lighthouse, che sono un test controllato. I dati di campo verificano l'esperienza effettiva degli utenti; i test di laboratorio rendono ripetibile una modifica prima del rilascio.
Segmenta almeno per mobile e desktop e, dove possibile, per template critico o URL. PageSpeed Insights può ricadere dai dati a livello di URL ai dati a livello di origin, e alcune pagine non hanno dati CrUX. Etichetta quel caso come baseline di laboratorio e aggiungi misurazione real-user per i percorsi importanti. Conserva URL di test, profilo dispositivo e rete, stato della cache, data e versione dello strumento con ogni baseline.
Scegli un obiettivo che migliori la baseline con un passo pianificato, poi testalo in condizioni rappresentative. Un budget che blocca release normali viene aggirato; uno al di sopra dell'esperienza attuale non protegge nessuno.
Il 75° percentile è il valore al di sotto del quale ricadono il 75% delle esperienze osservate; non è una media.
Rendi il budget una regola di rilascio
Conserva il budget in un posto versionato e revisionabile accanto al codice o alla checklist di rilascio. Ogni riga necessita del percorso, della metrica, del profilo o della popolazione di test, della soglia di avviso, della soglia di errore, del proprietario, del metodo di misurazione e della via per l'eccezione. MDN raccomanda livelli di avviso e di errore: l'avviso supporta la pianificazione proattiva, mentre l'errore è un limite superiore con effetto negativo evidente.
Automatizza controlli affidabili. Un bundler può rifiutare un asset troppo grande o un entry point iniziale; webpack supporta limiti massimi per asset e entry-point e hint di errore a livello di produzione. Esegui test di laboratorio ripetibili per il percorso interessato nelle pull request o nei release candidate. Mantieni metriche di campo per la verifica post-rilascio e la prioritizzazione, piuttosto che usarle come gate di build inaffidabili.
Quando un limite fallisce, riduci un asset, rimanda codice non essenziale, modifica l'esperienza, separa il rilascio o approva un'eccezione. Non aumentare silenziosamente la soglia per far passare la build.
Registra un owner prodotto e tecnico, l'impatto sul cliente, la data di scadenza e il task di rimedio prima del rilascio.
Blocca una soglia di errore riproducibile su un percorso protetto; notifica e indaga le soglie di avviso.
Verifica e rimedia dopo il lancio
Il peso della pagina non predice l'esperienza completa. L'ordine delle richieste, il lavoro che blocca il rendering, la capacità del dispositivo, le condizioni di rete, la cache e le terze parti contano anche. Mantieni limiti sugli input per catturare la crescita e misure di esito per testare se il percorso è utilizzabile. L'interfaccia W3C Resource Timing espone i tempi delle risorse e le dimensioni transferite, codificate e decodificate per diagnosi più profonde. Il dettaglio dei timing cross-origin può essere limitato dai permessi, quindi un waterfall incompleto non dimostra assenza di costo da terze parti.
Rivedi i risultati di campo dopo cambiamenti significativi di template, piattaforma, tag di marketing o traffico. Se LCP peggiora, ispeziona la risposta del server, la risorsa LCP e il lavoro che blocca il render. Se INP peggiora, ispeziona le interazioni effettive; Lighthouse non può misurare INP perché non ha input utente, sebbene Total Blocking Time sia un proxy di laboratorio. Usa il workflow proattivo di ottimizzazione di SIU per triagare una violazione, stabilizzare il percorso critico e verificare la correzione nello stesso contesto di misurazione.
Le eccezioni scadute rivelano rapidamente debito di prestazioni temporaneo diventato permanente.