Checklist di ottimizzazione dei Core Web Vitals

Checklist: Ottimizzazione dei Core Web Vitals. Timebox: un giorno lavorativo per confermare ambito e diagnosi; da uno a dieci giorni lavorativi per una correzione e rilascio tipici, a seconda che la causa risieda in un asset, un template condiviso, uno script di terze parti, l’origine o il CDN. La verifica sul campo segue la finestra dati mobile di 28 giorni e viene programmata separatamente. Proprietario: un ingegnere delle performance o un ingegnere front-end senior è responsabile. Il responsabile SEO tecnico possiede i criteri di accettazione sul campo; i proprietari di piattaforma, design, analytics e prodotto approvano le modifiche nei loro sistemi.

Questa checklist trasforma un riscontro di performance diagnosticato in una correzione rilasciata e verificata sul campo. I Core Web Vitals sono le misure di Google dell’utente reale per caricamento, reattività e stabilità visiva: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). Time to First Byte (TTFB) e First Contentful Paint (FCP) sono metriche diagnostiche di supporto. Sono incluse perché una risposta lenta o una schermata vuota consumano il tempo disponibile per ottenere un buon LCP.

Perché questa checklist, e perché qui

Questa checklist consuma il registro delle ottimizzazioni derivante dall’audit delle performance e dei Core Web Vitals . La fase precedente identifica la metrica che fallisce, l’URL e il template interessati, la baseline dell’utente reale, la condizione di laboratorio ripetibile, la causa sospetta, la priorità e il proprietario. L’ottimizzazione inizia solo dopo che questi campi esistono. Altrimenti, a uno sviluppatore viene chiesto di “rendere il sito più veloce” e modificherà naturalmente ciò che uno strumento evidenzia per primo, che sia o meno la causa del fallimento sul campo.

La diagnosi deve restringere tre livelli prima di agire: quale metrica, quale template e quale elemento o operazione. Un fallimento TTFB a livello di origine necessita di una correzione sulla piattaforma; un LCP che fallisce solo sulle pagine articolo potrebbe provenire dal loro componente hero; un INP dopo l’apertura di un filtro prodotto potrebbe derivare da un singolo gestore di eventi; un CLS sulle pagine promozionali potrebbe provenire da un banner senza riserva di spazio. Trattarli come un unico problema produce modifiche generiche e una proprietà poco chiara.

L’ordine è importante all’interno della correzione. TTFB è a monte: finché non arriva il primo byte di risposta, il browser non può scoprire le risorse HTML normali né visualizzare il contenuto della pagina. Se TTFB è scarso, correggi la generazione della risposta, la memorizzazione nella cache, i reindirizzamenti e la consegna edge prima di comprimere l’immagine LCP. Dopo che il tempo di risposta è rientrato nel budget, procedi attraverso la scoperta delle risorse, il download delle risorse, il rendering, le interazioni e la stabilità del layout.

Saltare questa checklist lascia l’audit come un semplice rapporto. Eseguirla prima della diagnosi invita a inseguire i sintomi: comprimere un’immagine quando domina una scoperta tardiva o posticipare script quando l’origine è lenta.

Input e output

Gli output consentono a un futuro proprietario di riprodurre il fallimento, identificare cosa è stato distribuito e distinguere l’accettazione in laboratorio dalla conferma sul campo.

La checklist

Completa gli elementi 1–4 prima di modificare la produzione. Gli elementi 5–8 implementano la correzione ordinata per dipendenza. Gli elementi 9–11 separano l’accettazione immediata del rilascio dalla verifica sul campo.

1. Blocca la metrica, il template e l’elemento che falliscono

Cosa: riduci il riscontro a una metrica, un insieme di template interessati e un elemento, richiesta, operazione o intervallo server nominato. Perché: un punteggio a livello di sito non identifica il lavoro distribuibile e due URL possono fallire per ragioni diverse. Come: unisci il fallimento p75 alle tracce e confronta i template interessati e non interessati; nomina l’elemento LCP e il ritardo, l’interazione INP e l’operazione, l’elemento CLS e il fattore scatenante, o il percorso di richiesta TTFB e lo stato della cache. Strumento: evidenze CrUX, traccia browser, waterfall, server timing, inventario template e tracker dei problemi. Completato quando: le evidenze supportano “la metrica X fallisce sul template Y perché Z crea ritardo o movimento nella condizione C.”

2. Conferma l’ambito con pagine rappresentative

Cosa: testa il riscontro su un URL tipico e uno nel caso peggiore per ogni template implicato, più un controllo non interessato. Perché: una correzione su una singola pagina può nascondere un difetto condiviso, mentre una modifica globale può essere superflua quando una variante di contenuto causa il problema. Come: mantieni costanti dispositivo, rete, località, consenso, login e condizioni della cache; confronta l’uso dei componenti, il peso degli asset, i tempi di risposta, l’attività di terze parti e la lunghezza dei contenuti. Strumento: analytics, inventario template, strumenti di performance del browser, monitor delle richieste e una matrice di test. Completato quando: ogni template in ambito è marcato come interessato o di controllo, ciascuno ha evidenze riproducibili e l’ambito di rilascio nomina il componente, il percorso, la famiglia di asset o il livello di piattaforma che deve cambiare.

3. Imposta il budget e proteggi il comportamento richiesto

Cosa: definisci l’obiettivo numerico, i guardrail di regressione e le funzioni che devono sopravvivere. Perché: “più veloce” non ha un confine di accettazione, e cancellare un gestore di consenso, un tag analytics, un comportamento di focus accessibile o una funzionalità di prodotto può creare un superamento ingannevole. Come: imposta l’obiettivo dalla tabella decisionale sottostante, aggiungi un buffer interno più rigoroso dove i test ripetuti variano, ed elenca i percorsi critici e le metriche non target da ritestare. Strumento: registro dei riscontri, requisiti di prodotto, piano analytics, controlli di accessibilità e budget di performance. Completato quando: il ticket indica la metrica target e il valore, il metodo di accettazione in laboratorio, il metodo di accettazione sul campo, i comportamenti protetti, i compromessi consentiti, la condizione di rollback e gli approvatori nominati.

4. Controlla TTFB prima del lavoro front-end

Cosa: misura TTFB in condizioni di cache fredda e calda da località rilevanti per il pubblico. Perché: TTFB è incluso in ogni tempo di visualizzazione successivo; il lavoro front-end non può recuperare il tempo già speso attendendo l’HTML. Come: suddividi la richiesta in DNS, connessione, reindirizzamenti, attesa CDN, elaborazione sull’origine, tempo di database o API upstream e comportamento di streaming dove la strumentazione lo consente. Confronta le risposte con cache hit e miss e conferma che personalizzazione o cookie non disabilitino inaspettatamente la cache. Strumento: waterfall delle richieste, server timing, log CDN e origine, profiling dell’applicazione e monitoraggio sintetico delle richieste. Completato quando: TTFB è entro il budget concordato oppure esiste un riscontro separato di blocco sulla piattaforma, assegnato e programmato. Non iniziare la rifinitura di LCP mentre un TTFB scarso rimane inspiegato.

5. Rimuovi prima il ritardo del server e della consegna

Cosa: correggi la risposta lenta dell’origine, i cache miss, i reindirizzamenti o la consegna distante. Perché: queste cause ritardano ogni elemento e spesso influenzano più template. Come: rimuovi i reindirizzamenti evitabili; memorizza nella cache HTML e dati sicuri; riduci il lavoro lento su database o API; sposta il lavoro fuori dal percorso critico; ottimizza il routing CDN e le chiavi di cache. Non memorizzare mai nella cache risposte private senza un design approvato. Strumento: profiler dell’applicazione, tracce delle query, configurazione CDN, intestazioni di risposta, monitoraggio e test di carico. Completato quando: i test ripetuti a freddo e a caldo soddisfano il budget, le varianti della cache rimangono corrette, gli errori non regrediscono e gli URL prioritari restituiscono la risposta prevista senza un hop aggiuntivo.

6. Correggi il ritardo di scoperta, trasferimento e rendering di LCP

Cosa: riduci il Largest Contentful Paint , quando viene renderizzato il blocco di immagine o testo visibile più grande. Perché: hero di dimensioni eccessive sono comuni, ma la scoperta tardiva, la bassa priorità, il CSS bloccante, JavaScript o i font possono dominare. Come: servi un’immagine responsive correttamente dimensionata; non caricare in lazy-load l’asset LCP above-the-fold; esponilo nell’HTML iniziale; dai priorità o pre-carica solo con evidenze; rimuovi il blocco del rendering; e usa font subsettati e memorizzabili nella cache con un fallback adatto. Strumento: scomposizione LCP, waterfall, ispezione delle immagini, report di copertura, traccia e confronto visivo. Completato quando: l’elemento LCP previsto è coerente, il suo ritardo dominante diminuisce, le pagine rappresentative soddisfano il budget e larghezza di banda, visibilità del testo e rendering non regrediscono.

7. Correggi INP all’interazione responsabile

Cosa: riduci l’interazione responsabile per uno scarso Interaction to Next Paint , la metrica di reattività. Perché: eliminare JavaScript arbitrario potrebbe non toccare l’evento lento. Come: separa il ritardo di input, elaborazione e presentazione; suddividi le operazioni lunghe; rimuovi il lavoro sincrono; posticipa le terze parti non essenziali; evita layout ripetuti; riduci i re-render; e cedi il controllo per la pittura. Testa su hardware realistico con terze parti in produzione. Strumento: traccia delle interazioni, profilo del thread principale, voci delle operazioni lunghe, profiler del framework e dispositivo realistico. Completato quando: le interazioni critiche funzionano, l’operazione responsabile soddisfa il budget sui test ripetuti, il proxy sul campo è documentato e il comportamento di analytics, consenso, tastiera e screen reader non regredisce.

8. Correggi CLS riservando il layout finale

Cosa: previeni il movimento che contribuisce al Cumulative Layout Shift , il punteggio di instabilità visiva. Perché: immagini, font, annunci, banner, embed e componenti asincroni possono tutti spostare l’interfaccia. Come: imposta dimensioni intrinseche o aspect-ratio; riserva slot per moduli dinamici; usa fallback di font compatibili; e anima con trasformazioni. Strumento: regioni di layout-shift, traccia, filmstrip, test di regressione visiva e browser throttled. Completato quando: ogni gruppo di spostamento significativo ha una fonte nominata, le pagine soddisfano il budget CLS durante il caricamento e le interazioni critiche, e lo spazio riservato non oscura alcun controllo.

9. Ritesta l’intero insieme di metriche e i percorsi protetti

Cosa: confronta il candidato al rilascio con la baseline congelata in condizioni identiche, poi testa in produzione. Perché: migliorare una metrica può danneggiarne un’altra: posticipare JavaScript può migliorare LCP ma peggiorare la prima interazione, mentre un cambio di font aggressivo può migliorare i tempi di pittura ma creare spostamenti di layout. Come: esegui diversi campioni controllati, confronta una statistica dichiarata anziché la migliore esecuzione, ispeziona le tracce, esercita i percorsi protetti, verifica la correttezza della risposta e testa i template interessati e di controllo. Strumento: Lighthouse o equivalente runner di laboratorio, strumenti di performance del browser, monitor delle richieste, test visivi e funzionali e checklist di rilascio. Completato quando: la metrica target soddisfa il suo budget di laboratorio secondo il metodo di esecuzione ripetuta dichiarato, TTFB/FCP/LCP/INP/CLS non mostrano regressioni critiche, il comportamento protetto è superato, la produzione serve la modifica prevista e il rollback non è attivato.

10. Annota il rilascio e programma la revisione sul campo

Cosa: registra il timestamp di distribuzione, l’ambito modificato, la metrica target, la direzione prevista e le date di revisione sul campo. Perché: CrUX utilizza una finestra mobile di 28 giorni, quindi le esperienze pre-rilascio rimangono nel p75 riportato dopo la distribuzione. Senza un’annotazione, il team potrebbe ritenere una buona correzione inefficace troppo presto o attribuire movimenti successivi al rilascio sbagliato. Come: allega la versione di produzione al riscontro, controlla immediatamente gli errori, registra le prime letture sul campo senza trattarle come definitive e programma un proprietario per revisionare una finestra sufficientemente aggiornata. Strumento: log di distribuzione, tracker dei problemi, CrUX, AmICited Web Vitals e monitoraggio. Completato quando: il ticket è marcato Accettato in laboratorio, l’annotazione di rilascio e le evidenze immediate sono allegate e un proprietario nominato e una data di calendario esistono per la verifica sul campo.

11. Verifica con i dati sul campo e chiudi o riapri

Cosa: confronta i dati sul campo p75 comparabili dopo che la finestra mobile si è sufficientemente aggiornata. Perché: i dispositivi reali degli utenti, le reti, la geografia, il comportamento della cache, gli stati di consenso e le interazioni non possono essere rappresentati da una singola esecuzione di laboratorio. Come: usa lo stesso livello CrUX — URL o origine — la stessa metrica e un ambito di pubblico comparabile; considera il rollout parziale e altri rilasci; ispeziona i rappresentanti dei template invece di affidarti solo a un aggregato di origine. Se il risultato non raggiunge l’obiettivo, confronta la traccia corrente con la dichiarazione della causa originale e riapri la diagnosi invece di accumulare modifiche non correlate. Strumento: AmICited Web Vitals, cronologia CrUX, annotazioni di rilascio, segmenti analytics e il pacchetto di evidenze. Completato quando: l’obiettivo soddisfa la soglia p75 concordata e l’ambito con le limitazioni registrate, a quel punto lo stato diventa Verificato sul campo; oppure il ticket è esplicitamente riaperto con nuove evidenze, proprietario e prossima ipotesi.

Strumenti in AmICited

Apri AmICited Web Vitals per visualizzare LCP, INP, CLS, FCP e TTFB da CrUX per il tuo dominio e i concorrenti tracciati. Usalo in fase di diagnosi per catturare la baseline sul campo e dopo la distribuzione per verificare il risultato progressivo sul campo. Un valore vuoto significa dati sul campo idonei insufficienti, non zero e non un superamento. La vista prodotto supporta il verdetto; tracce, server timing e profili browser identificano ancora la causa.

Usa Performance Impact per collegare le evidenze di performance a livello di pagina con la posizione nelle citazioni e identificare pagine lente di valore. Questa associazione aiuta a prioritizzare l’ottimizzazione ma non dimostra che la performance da sola abbia causato un risultato di citazione. Preserva pertinenza, contenuto, autorità e contesto di rilascio quando interpreti i movimenti.

Per il flusso di lavoro del prodotto, segui Come controllare i tuoi Core Web Vitals in AmICited . Il tutorial spiega dove appaiono le metriche e come funzionano i confronti con i concorrenti; questa checklist governa la diagnosi, l’implementazione e l’accettazione.

Regole decisionali: cosa significa “scarso”

Usa il 75° percentile, abbreviato p75, per le decisioni sul campo: il 75% delle esperienze registrate idonee è pari o inferiore a quel valore. Un valore al confine appartiene alla fascia migliore. LCP, INP e CLS determinano lo stato dei Core Web Vitals; TTFB e FCP sono misure di supporto utilizzate per sequenziare e diagnosticare il lavoro.

Applica queste regole in ordine:

1. Un timeout, errore del server, risposta errata o percorso critico interrotto blocca il rilascio indipendentemente dal punteggio della metrica.
2. Un TTFB scarso è a monte di LCP e viene ottimizzato per primo. Non dichiarare una soluzione basata solo sulle immagini mentre il server ha già consumato la maggior parte del budget di pittura.
3. Le metriche scarse sul campo hanno la precedenza sulle metriche che necessitano miglioramento. All’interno di una fascia, dai priorità alle cause condivise tra template, al traffico e ai percorsi critici per il business.
4. Un valore sul campo a livello di URL vuoto è sconosciuto. Usa evidenze di laboratorio e un proxy documentato, ma non ridefinire sconosciuto come buono.
5. Una singola esecuzione di laboratorio superata non è sufficiente. Dichiara il profilo dispositivo/rete e il metodo di esecuzione ripetuta prima del test.
6. Una correzione è Accettata in laboratorio quando il comportamento distribuito e i test controllati sono superati. È Verificata sul campo solo dopo che dati comparabili progressivi sul campo soddisfano la soglia concordata.
7. Se i dati dell’origine sono positivi ma un template ad alto traffico fallisce, il risultato del template prevale per quell’ambito. L’aggregazione non deve cancellare un problema concentrato per gli utenti.

Risultato finale: il pacchetto di ottimizzazione e verifica

Consegna un ticket o una voce di registro per causa principale, con ambiti secondari dove una causa riguarda più template. Usa un foglio di calcolo, un tracker dei problemi o un documento tecnico, ma preserva questi campi:

Finding ID and primary metric:
Field source: URL | Origin
Field p75, band, and 28-day window:
Affected templates and representative URLs:
Control template and URL:
Element, interaction, request, or server span:
Cause statement and evidence links:
Lab profile and repeated-run baseline:
Target, guardrails, and protected journeys:
Chosen remediation and rejected alternatives:
Engineering owner, approvers, and dependencies:
Release/version ID and deployment timestamp:
Immediate production and lab results:
CrUX field-review owner and date:
Comparable field result and limitations:
Monitoring threshold and reopen rule:
Status: Open | Implementing | Lab accepted | Field verified | Reopened | Accepted risk

Allega tracce, waterfall, intervalli server, registrazioni di spostamenti, profili di interazione, output dei test e annotazioni di rilascio. Rischio accettato necessita di ambito, motivo, approvatore, scadenza e trigger di monitoraggio; non è un superamento.

Il pacchetto è accettato quando un altro ingegnere può riprodurre il problema originale, identificare perché questa modifica lo affronta, confermare cosa è arrivato in produzione e ripetere il confronto sul campo senza chiedere all’investigatore originale di ricostruire il lavoro.

Cosa può andare storto

Ottimizzare prima di isolare la causa. Compressione generica ed eliminazione di script sostituiscono la diagnosi. Richiedi prima evidenze di metrica-template-elemento.

Comprimere l’hero mentre l’origine è lenta. Un’immagine più piccola non può essere renderizzata prima che arrivi l’HTML. Misura e ottimizza TTFB per primo quando è fuori budget.

Correggere lo spostamento sbagliato. CLS può provenire da un annuncio, banner di consenso, font, embed o componente idratato. Nomina la fonte dello spostamento.

Posticipare ogni script. La posticipazione indiscriminata può rompere l’ordinamento dei consensi, l’analytics, la navigazione, i moduli o la prima interazione. Modifica il percorso di esecuzione responsabile e testa in regressione il comportamento richiesto.

Verificare un URL dopo un rilascio su template condiviso. L’esempio selezionato può essere superato mentre una variante di contenuto più pesante o un’altra configurazione del componente fallisce ancora. Testa pagine tipiche, pesanti e di controllo.

Leggere i dati a livello di origine come un superamento del template. Pagine sane ad alto volume possono mascherare un template debole per categoria, articolo o prodotto. Mantieni la diagnosi e l’accettazione all’ambito affidabile più ristretto.

Chiudere il giorno della distribuzione. I test immediati stabiliscono l’accettazione in laboratorio. Non sostituiscono la finestra dati progressiva sul campo.

Aspettare 28 giorni per scoprire un rilascio difettoso. La conferma sul campo richiede tempo, ma i codici di stato, errori, percorsi, stabilità visiva e metriche controllate vengono controllati immediatamente. I dati progressivi non sono una scusa per saltare il QA di rilascio.

Fase successiva: monitoraggio e iterazione continui

Consegna il registro di verifica sul campo, l’annotazione di rilascio, i template interessati, le limitazioni e le soglie all’aggiornamento continuo e iterazione . Necessita di una baseline stabile in modo che successive modifiche di contenuti, media, template, campagne e terze parti possano essere confrontate anziché riscoperte come movimenti inspiegati.

Il prossimo proprietario registra chi monitora ogni soglia, dove risiedono le evidenze, con quale frequenza vengono revisionate e cosa riapre l’ottimizzazione. Una metrica di nuovo scarsa, una tendenza ripetuta di necessità di miglioramento attraverso l’intera finestra aggiornata, un elemento LCP cambiato, una nuova interazione lenta o un rilascio di template che altera il percorso diagnosticato dovrebbero riaprire la checklist all’elemento 1. Non ripetere automaticamente la correzione precedente: la stessa metrica può fallire per un elemento diverso dopo una riprogettazione.

Il passaggio di consegne è completo quando lo stato sul campo è esplicito, ogni limitazione accettata ha un proprietario e una data di revisione, e il monitoraggio può collegare una regressione a un template e un rilascio. Se la verifica sul campo rimane in sospeso, il prossimo proprietario riceve la data di revisione programmata e il ticket rimane Accettato in laboratorio, non chiuso.

FAQ

FAQ sull'ottimizzazione dei Core Web Vitals