Audit delle Performance e Core Web Vitals

Fase P3 · Stadio A — Comprendere
Timebox: 4–8 ore per un audit rappresentativo; 2–5 giorni lavorativi per un’indagine su interi template con tracce di engineering. La validazione sul campo su 28 giorni avviene dopo le correzioni e non estende il timebox iniziale dell’audit.
Responsabile: il technical SEO lead possiede l’ambito e l’accettazione. Un performance engineer o un senior front-end engineer possiede la diagnosi; i responsabili di piattaforma, CDN, analytics, design e prodotto contribuiscono dove i loro sistemi generano ritardi o instabilità.

Questa fase converte le evidenze sul campo degli utenti reali e i test di laboratorio ripetibili in un registro di remediation collegato a URL, template, metriche, responsabili e test di completamento, non in un punteggio di velocità generico.

Perché questa fase, e perché qui

Le performance appartengono allo Stadio A perché una pagina che va in timeout è un problema di crawl prima ancora di essere un problema di esperienza utente. Un crawler o un agente di recupero ha un budget limitato di richieste. Se l’origine si blocca, reindirizza ripetutamente o restituisce una risposta incompleta, il client potrebbe abbandonare la pagina prima ancora di poterne valutare il contenuto. Intestazioni più veloci, testi migliori e schema più robusto non possono aiutare contenuti che non vengono recuperati in modo affidabile.

P3 consuma gli host canonici, i template indesizzati previsti, i percorsi prioritari, le evidenze sui codici di stato e i risultati infrastrutturali irrisolti provenienti dall’audit tecnico di base . Quest’ordine previene diagnosi errate. Ad esempio, un “caricamento pagina” di cinque secondi causato da un loop di reindirizzamento non è un compito di ottimizzazione delle immagini, e un test veloce di una pagina di errore in cache non è un superamento. P2 stabilisce che l’URL corretto può essere richiesto e selezionato; P3 stabilisce che può essere consegnato e utilizzato entro limiti di tempo e stabilità accettabili.

Eseguire questa fase in ritardo genera rilavorazioni. Un team di contenuti potrebbe pubblicare in un template il cui hero è sempre l’elemento più lento, o approvare uno slot promozionale che sposta ogni scheda prodotto. Il difetto si moltiplica quindi su tutte le nuove pagine.

Input e output

Gli input rendono il campione rappresentativo. Gli output costituiscono il contratto con la fase successiva: esattamente quali pagine sono disponibili in modo affidabile, quali condizioni rimangono deboli e quali limitazioni di performance devono qualificare le misurazioni future.

Dati sul campo e dati di laboratorio sono evidenze diverse

I dati sul campo descrivono ciò che gli utenti Chrome idonei hanno effettivamente sperimentato. Il Chrome User Experience Report, solitamente abbreviato in CrUX, aggrega le misurazioni di visite reali e riporta il 75° percentile: il valore al di sotto del quale cade il 75% delle esperienze registrate. Include l’eterogeneità di dispositivi reali, reti, posizioni, cache, strumenti di consenso, sessioni e interazioni. Usalo per decidere se gli utenti superano le soglie pubblicate e se una modifica implementata ha effettivamente migliorato la popolazione.

I dati di laboratorio descrivono un singolo caricamento o interazione di pagina controllati in condizioni dichiarate. Lighthouse è un test di laboratorio che applica simulazioni di dispositivo e rete, cattura una traccia e spiega le cause probabili. Usalo per riprodurre un problema, confrontare due build nella stessa configurazione, ispezionare catene di richieste e identificare il lavoro da fare. Un punteggio di laboratorio è un’evidenza utile, ma non prova che gli utenti reali superino la soglia.

Le due fonti possono discordare senza che nessuna delle due sia errata. Un’esecuzione di laboratorio veloce può utilizzare una posizione vicina, una CDN calda e nessuna interazione significativa, mentre i visitatori sul campo includono telefoni più vecchi e reti distant. Registra il disaccordo e indaga le sue condizioni; non fare mai la media dei valori né scegliere quello che sembra più sano.

La checklist

Completa questi controlli in ordine. Ogni elemento specifica l’azione, il motivo, il metodo, lo strumento e la condizione di accettazione in modo da poter essere assegnato e ritestato.

1. Congela la matrice di URL e condizioni rappresentativa

Cosa: definisci gli URL, i template, i profili dispositivo, le aree geografiche, gli stati di consenso e gli stati della cache da testare. Perché: un audit solo sulla homepage può essere superato mentre il template del prodotto, dell’articolo o del checkout fallisce. Come: combina l’inventario P2 con i dati di traffico e priorità aziendale; seleziona esempi tipici, pesanti e critici per la conversione. Strumento: analytics, inventario crawl, registro dei rilasci e un foglio di test condiviso. Completato quando: ogni template prioritario ha un campione di produzione approvato dal responsabile e ogni test registra le ipotesi su dispositivo, rete, posizione, login, consenso e cache.

2. Cattura la baseline sul campo CrUX

Cosa: registra le metriche sul campo p75 disponibili a livello di URL e, separatamente, a livello di origine. Perché: l’origine può nascondere un template debole, mentre un singolo URL a basso traffico potrebbe non avere dati pubblicabili. Come: usa la stessa data di osservazione e la finestra di 28 giorni, etichetta esplicitamente URL vs origine e registra i valori vuoti come “dati insufficienti”. Strumento: AmICited Web Vitals e CrUX. Completato quando: ogni URL campionato ha valori LCP, INP, CLS, FCP e TTFB o uno stato sconosciuto documentato; il livello della fonte e la finestra sono univoci.

3. Verifica l’affidabilità della risposta prima di valutare i pixel

Cosa: ripeti le richieste e registra stato, reindirizzamenti, Time to First Byte (TTFB), timeout e risposte inconsistenti. TTFB è l’intervallo dall’inizio della richiesta all’arrivo del primo byte di risposta. Perché: una pagina non può visualizzare nulla prima che il suo HTML inizi ad arrivare, e un fallimento intermittente è più grave di un rallentamento estetico. Come: testa il comportamento della cache a freddo e a caldo da regioni pertinenti, ispeziona i tempi del server e correla le anomalie con i log CDN e di origine. Strumento: monitor delle richieste, pannello di rete del browser, osservabilità CDN/origine e waterfall Lighthouse. Completato quando: gli URL prioritari restituiscono la risposta 200 prevista senza salti imprevisti o timeout, e ogni risposta lenta o fallita ha un risultato registrato con un responsabile.

4. Diagnostica il Largest Contentful Paint

Cosa: identifica l’elemento Largest Contentful Paint (LCP) e suddividi il suo tempo in ritardo del server, scoperta della risorsa, download della risorsa e ritardo di rendering. LCP misura quando l’immagine visibile più grande o il blocco di testo termina il rendering. Perché: comprimere un’immagine serve a poco quando il browser la scopre tardi, e le modifiche front-end non possono cancellare un’attesa lenta dall’origine. Come: ispeziona la traccia e il waterfall, confronta esecuzioni in cache e senza cache, verifica la priorità di preload, il dimensionamento reattivo delle immagini, le risorse che bloccano il rendering, il comportamento dei font e il rendering lato client. Strumento: Lighthouse, strumenti di performance del browser, waterfall delle richieste e ispezione delle immagini. Completato quando: l’effettivo elemento LCP e la sottoparte dominante sono nominati per ogni template con esito negativo, con una misurazione prima riproducibile e un’ipotesi di correzione specifica.

5. Diagnostica Interaction to Next Paint

Cosa: testa il percorso Interaction to Next Paint (INP) per azioni reali come apertura menu, filtraggio, aggiunta al carrello, input in moduli e chiusura dei consensi. INP misura il ritardo da un’interazione utente fino a quando il browser mostra il successivo aggiornamento visivo, utilizzando un’interazione ad alta latenza dalla visita. Perché: una pagina può apparire completa ma ignorare comunque l’utente mentre JavaScript occupa il thread principale. Come: riproduci le azioni importanti, ispeziona i long task e i gestori di eventi, testa script di terze parti e separa il ritardo di input, il tempo di elaborazione e il ritardo di presentazione. Strumento: CrUX, traccia di performance del browser, profilazione delle interazioni e un dispositivo realistico. Completato quando: ogni interazione importante è stata esercitata, l’interazione lenta e il task responsabile sono identificati per i template con esito negativo, e la correzione ha un test di interazione ripetibile.

6. Diagnostica Cumulative Layout Shift

Cosa: individua i movimenti imprevisti che contribuiscono al Cumulative Layout Shift (CLS). CLS è un punteggio adimensionale che rappresenta il movimento visivo imprevisto durante la vita della pagina. Perché: un banner tardivo, un’immagine senza dimensioni, un font sostituito, un annuncio o un componente idratato possono spostare il link che l’utente sta per cliccare e possono modificare il punto in cui l’estrazione automatizzata trova i contenuti. Come: usa le regioni di layout-shift e un filmstrip, testa asset ritardati e stati di consenso, e ispeziona gli elementi senza dimensioni riservate. Strumento: CrUX, traccia Lighthouse, diagnostica di rendering del browser e cattura di regressioni visive. Completato quando: ogni spostamento significativo ha un elemento sorgente, un trigger e una correzione di spazio riservato o di rendering; il movimento previsto causato immediatamente da un’azione dell’utente è documentato separatamente.

7. Usa FCP per separare il ritardo dello schermo vuoto

Cosa: misura il First Contentful Paint (FCP), il tempo fino a quando il browser renderizza il primo contenuto di testo, immagine, canvas o SVG. Perché: FCP distingue un segnale precoce di progresso da una pagina che rimane vuota, anche se non prova che il contenuto principale sia pronto. Come: confronta FCP con TTFB e LCP, poi ispeziona CSS, font, script che bloccano il rendering, markup renderizzato lato server e comportamento di streaming. Strumento: CrUX, Lighthouse e la traccia di rete/performance. Completato quando: ogni FCP lento è assegnato a ritardo del server, blocco del rendering, rendering solo client o un’altra causa dimostrata, anziché essere descritto semplicemente come “la pagina è lenta.”

8. Classifica i risultati per gravità, portata e dipendenza

Cosa: ordina il backlog per fascia di fallimento, traffico e template interessati, criticità aziendale e dipendenza upstream. Perché: correggere cinque punteggi gialli può consumare lo sprint mentre un singolo fallimento rosso di TTFB ritarda ogni pagina sull’origine. Come: metti prima i fallimenti di affidabilità, poi le metriche scarse prima di quelle da migliorare; all’interno della stessa gravità, correggi le cause condivise di piattaforma e TTFB prima del lavoro downstream su LCP. Strumento: registro risultati, analytics, inventario template e stima engineering. Completato quando: ogni risultato ha una gravità, un conteggio di URL interessati o ambito template, evidenze, responsabile, sforzo, dipendenza e priorità esplicita.

9. Convalida l’implementazione in laboratorio

Cosa: confronta la build modificata con la baseline registrata in condizioni identiche. Perché: i dati sul campo non possono fornire un feedback immediato sul rilascio, e un’esecuzione “dopo” non ripetibile non può stabilire che la modifica al codice abbia causato la differenza. Come: esegui più campioni controllati, confronta le mediane anziché la singola esecuzione migliore, ispeziona la traccia per regressioni e testa interazioni e layout critici. Strumento: Lighthouse, strumenti di performance del browser, staging o rilascio di produzione controllato e monitoraggio delle richieste. Completato quando: la causa prevista è rimossa, la metrica target supera il budget di laboratorio concordato in esecuzioni ripetute, nessun’altra metrica critica regredisce e le evidenze sono allegate al risultato.

10. Annota il rilascio e attendi la conferma sul campo

Cosa: registra il momento del deploy, l’ambito, la metrica prevista e le date di validazione. Perché: CrUX è una finestra mobile di 28 giorni, quindi le visite pre-rilascio rimangono nel percentile riportato dopo che la correzione viene pubblicata. Come: monitora immediatamente gli errori, verifica il movimento direzionale sul campo man mano che arrivano nuovi dati ed effettua il confronto finale solo quando ci sono abbastanza giorni post-rilascio per rappresentare la finestra. Strumento: log di deploy, AmICited Web Vitals, CrUX e monitoraggio. Completato quando: i controlli tecnici immediati sono superati, l’annotazione del rilascio è visibile e un responsabile nominato con una data esiste per la conferma sul campo; il risultato non è contrassegnato come “verificato” dalla sola evidenza di laboratorio.

Strumenti in AmICited

Apri https://app.amicited.com/audit/web-vitals per confrontare il tuo dominio con i concorrenti monitorati utilizzando i dati CrUX degli utenti reali. L’audit colloca LCP, INP, CLS, FCP e TTFB in un’unica tabella, evidenzia il tuo dominio e rende visibili i dati mancanti sul campo anziché trasformarli in uno zero fuorviante. Usa il confronto per rispondere a due domande: se il dominio supera le soglie pubblicate e se un concorrente che serve lo stesso pubblico ha dimostrato un risultato sul campo materialmente migliore.

La funzione Performance Impact collega le performance a livello di pagina con la posizione e la probabilità di citazione. Considera questa relazione come evidenza di priorità, non come prova che la sola velocità abbia causato un cambiamento nelle citazioni. Se una pagina lenta citata e una pagina veloce non citata differiscono in autorità, pertinenza o contenuto, la performance è solo una variabile. Il segnale utile è che una pagina interessata ha abbastanza valore da essere corretta e monitorata.

Per il funzionamento del prodotto, segui Come Controllare i Tuoi Core Web Vitals in AmICited . Questo playbook definisce l’ambito dell’audit, le decisioni e il passaggio di consegne; il tutorial copre i clic e le letture, quindi duplicarlo qui creerebbe due istruzioni che potrebbero divergere.

Regole decisionali: che aspetto ha un risultato negativo

Valuta i Core Web Vitals dai dati sul campo al 75° percentile. “Buono” significa che il valore p75 è uguale o inferiore alla soglia del buono. Un valore su una soglia appartiene alla fascia migliore; ad esempio, un LCP esattamente di 2,5 secondi è buono. Le soglie di supporto FCP e TTFB guidano la diagnosi e l’accettazione, ma non fanno parte della valutazione di superamento dei tre Core Web Vitals.

Usa queste regole di priorità:

1. Richieste fallite, timeout e risposte non valide hanno la precedenza sui punteggi. L’affidabilità è il cancello di consegna.
2. Correggi le fasce scarse prima di quelle da migliorare. Il rosso è un’esperienza negativa dimostrata, non un’opportunità di lucidatura.
3. Correggi TTFB prima di LCP quando TTFB è insufficiente. LCP non può verificarsi prima che la risposta inizi, quindi il ritardo del backend consuma il budget LCP prima che il browser possa renderizzare qualsiasi cosa.
4. Preferisci cause condivise a sintomi isolati. Una singola riparazione della politica di cache su quattro template ha la precedenza su quattro modifiche separate alle immagini con portata minore.
5. Usa il valore del traffico e del percorso all’interno della stessa gravità. Un INP scarso sul checkout o un LPC di un articolo ad alto traffico hanno la precedenza su un archivio a basso traffico nella stessa fascia.
6. Non considerare buono un valore CrUX vuoto. È sconosciuto. Usa evidenze di laboratorio ripetibili e un template comparabile fino a quando non esiste volume sul campo.
7. Non promettere un miglioramento immediato sul campo. Convalida il deploy ora, poi lascia che la finestra mobile sostituisca le esperienze precedenti prima di accettare o rifiutare il risultato sul campo.

Deliverable: il registro di remediation delle performance

Consegna al team di engineering un registro più la relativa cartella di evidenze. Un foglio di calcolo, un issue tracker o una tabella di progetto strutturata è accettabile se preserva questi campi e consente il filtraggio per template, gravità, responsabile e stato:

ID e risultato:
URL e template interessati:
Percorso prioritario e contesto di traffico:
Metrica e fascia sul campo:
Livello CrUX, valore p75 e finestra di 28 giorni:
Configurazione di laboratorio e baseline ripetuta:
Causa osservata e riferimento alle evidenze:
Condizione prevista e obiettivo:
Modifica raccomandata:
Gravità e motivazione della priorità:
Responsabile, dipendenza e sforzo:
Data di rilascio e annotazione:
Risultato di accettazione immediata in laboratorio:
Data e risultato della conferma sul campo:
Stato: Aperto | Pianificato | Accettato in laboratorio | Verificato sul campo | Rischio accettato

Allega la matrice degli URL, l’esportazione CrUX, le tracce di laboratorio, i waterfall, i filmstrip, le registrazioni delle interazioni, le evidenze di layout-shift e le annotazioni di rilascio. Deduplica per causa: se la stessa query di origine non in cache crea un TTFB scarso su tre template, crea un unico risultato padre con tre ambiti interessati anziché tre diagnosi concorrenti.

“Rischio accettato” necessita di un approvatore nominato, un motivo, l’ambito interessato, una data di scadenza o revisione e una condizione di monitoraggio. Non è un sostituto di un responsabile. Il passaggio di consegne è completo quando un ingegnere può riprodurre il fallimento e il responsabile della fase successiva può identificare quali risultati rimangono limitati dalle performance.

Cosa va storto

Considerare Lighthouse come verdetto finale. Un punteggio di 100 in un’esecuzione di laboratorio non annulla dati sul campo p75 scadenti. Mantieni Lighthouse come evidenza diagnostica e CrUX come evidenza sulla popolazione.

Testare solo la homepage. Campiona ogni template di alto valore più un esempio pesante, altrimenti i difetti dei template sfuggiranno all’audit.

Ottimizzare l’immagine LCP prima di verificare TTFB. L’asset potrebbe essere piccolo mentre l’origine impiega due secondi per generare HTML. Suddividi LCP nei suoi componenti e correggi prima il tempo upstream.

Usare l’esecuzione più veloce. Il calore della cache, l’attività in background e la variazione di rete possono creare un valore anomalo lusinghiero. Mantieni la configurazione fissa e confronta le mediane di esecuzioni ripetute.

Dichiarare vittoria il giorno dopo il rilascio. Il laboratorio può provare che il codice e la consegna sono cambiati immediatamente; la finestra sul campo di 28 giorni non può. Annota il rilascio e programma l’accettazione sul campo.

Contrassegnare come zero i dati CrUX mancanti. Nessun dato significa che la soglia di idoneità o di traffico non è stata raggiunta. Non dice nulla sulla qualità delle performance.

Inseguire il punteggio composito invece dell’esperienza fallimentare. Un punteggio riassuntivo può migliorare mentre un’interazione sul checkout ancora si blocca o un hero continua a spostarsi. Accetta metriche e percorsi nominati, non movimenti di punteggio estetici.

Rimuovere funzionalità utili per vincere un test. Eliminare consenso, personalizzazione, analytics o comportamento di accessibilità dalla variante di laboratorio produce un risultato che gli utenti non riceveranno mai. Ottimizza il requisito di produzione o prendi una decisione esplicita sul prodotto.

Ignorare regressioni al di fuori della metrica target. Rimandare script può migliorare LCP ma creare un INP scarso alla prima interazione; riservare le dimensioni sbagliate può sostituire un ritardo di caricamento con CLS. Ritesta tutte e cinque le metriche e il percorso critico.

Fase successiva: accessibilità AI e prontezza per gli agenti

La fase Accessibilità AI e prontezza per gli agenti riceve la matrice di URL rappresentativa, le evidenze di affidabilità della risposta, la distribuzione di TTFB, i risultati di performance irrisolti e una dichiarazione su quale contenuto è presente nella risposta iniziale. Il suo responsabile utilizza queste evidenze per distinguere un fallimento della policy di accesso da un fallimento di consegna e per riprodurre le condizioni reali in cui un agente recupera la pagina.

La fase successiva può procedere quando gli URL critici rispondono in modo affidabile e nessun difetto di performance irrisolto rende l’evidenza di recupero non interpretabile. Può procedere con una limitazione scritta quando una metrica da migliorare influisce sugli utenti ma non impedisce un accesso stabile. Dovrebbe mettere in pausa i template interessati quando le richieste vanno in timeout, restituiscono errori intermittenti o la risposta principale supera regolarmente la soglia critica concordata.

Il passaggio di consegne è completo quando il responsabile successivo sa quali URL rappresentano ogni template, le condizioni di test, i fallimenti di consegna rimanenti e se le evidenze P3 già spiegano un recupero lento da parte dell’agente.

FAQ

Domande frequenti