Le prestazioni peggiorano. Una pagina che si caricava in due secondi ora ne impiega quattro. Qualcosa è cambiato.
La diagnosi risponde a due domande: cosa è cambiato e perché le prestazioni sono peggiorate.
Cause tipiche: una nuova funzione ha aggiunto un pacchetto JavaScript pesante. Una query al database è diventata lenta. È stato aggiunto uno script di terze parti. Le immagini sono diventate più pesanti. Il server si è sovraccaricato.
Una diagnosi sistematica trova la causa. Una correzione sistematica la elimina.
Il metodo di diagnosi
Passo uno: individua il sintomo. L'LCP è passato da due a quattro secondi. Il CLS è passato da zero virgola zero cinque a zero virgola due. L'INP è passato da cento a quattrocento millisecondi.
Passo due: la cronologia. Quando è iniziato il peggioramento? La settimana scorsa. Ieri. Un'ora fa. La cronologia restringe la ricerca.
Passo tre: collega ai cambiamenti. Quale codice è cambiato? Quali funzioni sono state rilasciate? Quale infrastruttura è cambiata? La correlazione indica la causa.
Passo quattro: isola la causa. Le prestazioni sono peggiorate. Ipotesi: il nuovo pacchetto JavaScript. Prova: misura l'LCP con il nuovo pacchetto disattivato. L'LCP torna a due secondi. Ipotesi confermata.
Passo cinque: correggi o torna indietro. Correggi la causa (ottimizza il pacchetto) oppure torna indietro (annulla la modifica). La scelta dipende dalla gravità.
Esempio reale: peggioramento delle prestazioni di un negozio online
Sintomo: l'LCP è passato da due secondi a tre virgola cinque secondi. Rilevato da un avviso del monitoraggio.
Cronologia: il peggioramento è avvenuto martedì mattina. Il team aveva rilasciato un nuovo motore di raccomandazioni lunedì sera.
Correlazione: la coincidenza suggerisce che la causa sia il motore di raccomandazioni.
Prova di isolamento: disattiva il motore di raccomandazioni. L'LCP torna a due secondi. Il motore di raccomandazioni è confermato come causa.
Indagine: il motore di raccomandazioni carica le immagini dei prodotti consigliati. Le immagini non sono ottimizzate (dimensione originale, nessuna compressione). Caricare cinquanta immagini di prodotto aggiunge due megabyte alla pagina.
Correzione: ottimizza le immagini del motore di raccomandazioni. Comprimi le immagini, usa il caricamento differito per quelle sotto la parte visibile. Il peso delle immagini scende a cinquecento kilobyte. L'LCP migliora fino a due virgola due secondi.
Rilascio: annulla il motore di raccomandazioni, pubblica la versione ottimizzata. L'LCP torna a due virgola due secondi.
Problemi di prestazioni comuni e soluzioni
Problema uno: pacchetto JavaScript pesante
- Sintomo: LCP lento, INP lento
- Causa: una nuova funzione aggiunge codice e il pacchetto cresce
- Soluzione: dividi il codice della funzione, caricala in modo differito
- Miglioramento atteso: l'LCP migliora di zero virgola cinque secondi
Problema due: query lente al database
- Sintomo: TTFB lento
- Causa: una query al database diventa lenta (indice mancante, query che unisce molte tabelle)
- Soluzione: aggiungi un indice al database, ottimizza la query, metti in cache i risultati
- Miglioramento atteso: il TTFB migliora di duecento millisecondi
Problema tre: immagini non ottimizzate
- Sintomo: LCP lento, consumo di banda alto
- Causa: le immagini sono grandi (non compresse, formato sbagliato)
- Soluzione: comprimi le immagini, converti in WebP, usa immagini adattive
- Miglioramento atteso: l'LCP migliora di un secondo
Problema quattro: script di terze parti
- Sintomo: LCP lento, la pagina non risponde
- Causa: analisi, tracciamento e annunci di terze parti rallentano la pagina
- Soluzione: carica gli script di terze parti in modo differito, usa un web worker, caricali in modo asincrono
- Miglioramento atteso: l'LCP migliora di zero virgola cinque secondi, l'INP migliora di cento millisecondi
Problema cinque: CLS causato da annunci o embed
- Sintomo: il layout si sposta mentre si legge
- Causa: gli annunci si caricano e occupano spazio, il contenuto si sposta
- Soluzione: riserva lo spazio per gli annunci, carica in modo differito gli annunci sotto la parte visibile
- Miglioramento atteso: il CLS migliora da zero virgola due a zero virgola zero cinque
Monitoraggio per accorgersi in anticipo
Avviso sul peggioramento: se l'LCP supera i due virgola cinque secondi, avvisa il team.
Avviso sulla regressione: se l'LCP aumenta di più di zero virgola cinque secondi rispetto alla base di partenza, avvisa il team.
Avviso sull'impatto di business: se il completamento delle iscrizioni cala dell'uno per cento, avvisa il team (può indicare un problema di prestazioni).
Esempio reale: gli avvisi in un'azienda SaaS
- Avviso uno: se l'LCP supera i due virgola cinque secondi
- Avviso due: se viene rilevata una regressione delle prestazioni (l'LCP aumenta del cinquanta per cento in un giorno)
- Avviso tre: se i Core Web Vitals passano da buono a da migliorare per più del cinque per cento degli utenti
- Avviso quattro: se il completamento delle iscrizioni scende sotto l'obiettivo (può indicare un problema di prestazioni della pagina di pagamento)
Quando scatta un avviso: il team tecnico indaga entro un'ora. Si individua la causa. La correzione viene pubblicata lo stesso giorno.
Esempio reale: problema di prestazioni nell'elaborazione dei pagamenti
Sintomo: il tasso di abbandono del pagamento è passato dal quindici al venticinque per cento. È iniziato giovedì.
Indagine: le prestazioni della pagina di pagamento sono peggiorate. Il tempo di interazione del pulsante di pagamento è passato da duecento millisecondi a un secondo.
Cronologia: il fornitore dei pagamenti ha cambiato l'infrastruttura giovedì mattina.
Causa: il fornitore dei pagamenti si è spostato dalla California all'Europa. La latenza di rete dall'utente al fornitore è aumentata di duecento millisecondi. Il tempo totale di elaborazione del pagamento è salito a un secondo.
Soluzione: usa un punto di accesso CDN vicino all'utente. Fai passare la richiesta di pagamento da un punto di accesso CDN locale. Il punto di accesso CDN la inoltra al fornitore europeo. La latenza di rete si riduce. Il tempo di elaborazione del pagamento torna a duecento millisecondi.
Risultato: il tasso di abbandono del pagamento torna al quindici per cento.
Impatto sul business: cinquemila pagamenti al mese con il quindici per cento di abbandono sono settecentocinquanta conversioni perse. Con un valore d'ordine di cento dollari, sono settantacinquemila dollari persi al mese. Risolvere il problema di latenza ha fatto risparmiare all'azienda settantacinquemila dollari al mese.
Domande frequenti
Come capiamo se un problema di prestazioni è causato dal codice o dall'infrastruttura?
Prova entrambi. Disattiva il nuovo codice (torna indietro). Se le prestazioni tornano normali, la causa è il codice. Se restano lente, la causa è l'infrastruttura. Isola in modo sistematico. Non dare la colpa all'infrastruttura se la causa è il codice (e viceversa). Con il creatore di siti di WEMASY puoi impostarlo direttamente sul tuo sito.
Quando le prestazioni peggiorano, conviene tornare indietro o correggere?
La gravità decide. Se il peggioramento è grave (l'LCP passa da due a cinque secondi), torna indietro subito. L'esperienza utente ne soffre. Correggi dopo. Se il peggioramento è lieve (l'LCP passa da due a due virgola tre secondi), correggi sul posto. Il rischio di tornare indietro è inferiore al rischio di pubblicare una correzione incompleta.
Come evitiamo che i problemi di prestazioni arrivino in produzione?
Test delle prestazioni nella pipeline CI/CD. Prima di ogni rilascio, misura le prestazioni. Se il budget di prestazioni viene superato, blocca il rilascio. Previeni le regressioni prima che accadano.
E se il problema di prestazioni è intermittente?
I problemi intermittenti sono più difficili da diagnosticare. Raccogli più dati. Monitora più a lungo. Un problema intermittente può indicare: un problema di rete (succede sulle reti lente), un problema di traffico (succede nei picchi), un problema di browser (succede su browser specifici). Restringi il campo. Verifica l'ipotesi su una rete, un orario, un browser precisi.
Come comunichiamo i problemi di prestazioni agli utenti?
La trasparenza crea fiducia. Se il problema è noto e lo stai risolvendo, dillo agli utenti. Esempio: peggioramento delle prestazioni nella pagina di pagamento per la migrazione del fornitore dei pagamenti. Correzione prevista entro domani. Stiamo indagando. La trasparenza riduce la frustrazione.
Dobbiamo avere un tecnico di reperibilità per le prestazioni?
Per i siti critici (negozi online, SaaS), sì. Il tecnico di reperibilità risponde agli avvisi sulle prestazioni entro trenta minuti. Indaga. Pubblica una correzione o torna indietro. Evita che il problema pesi a lungo sugli utenti.