1. Definisci l'obiettivo e i confini
Assegna un unico responsabile e scrivi l'obiettivo prima di aprire uno strumento di audit. Indica il pubblico, il percorso, le pagine o le route, la finestra temporale e la decisione che il lavoro deve supportare. Un obiettivo utile descrive un compito, come completare un flusso mobile da prodotto a carrello, non un generico desiderio di rendere il sito più veloce.
Elenca i non negoziabili: flusso di acquisto o richiesta funzionante, accesso account, comportamento di consenso, accessibilità, reperibilità per i motori di ricerca e contenuti approvati. Un guadagno sintetico di punteggio non è una vittoria se un modulo fallisce, il contenuto viene nascosto alla ricerca o l'uso da tastiera diventa più difficile.
Scrivi pagina di partenza, azione utente e stato finale di successo in una frase.
Scegli un risultato che non deve peggiorare, come l'invio riuscito o l'assenza di nuovi blocchi critici di accessibilità.
2. Definisci un valore di riferimento comparabile
Prima di modificare codice, contenuto, configurazione o tag, salva la lista di URL, la data, le condizioni di test, la versione di rilascio, i report o le tracce e il risultato della verifica manuale. web.dev raccomanda di registrare lo stato del sito prima delle modifiche e di testare più tipologie di pagina; per le single-page application includi route, componenti e flussi invece che solo il primo caricamento.
Usa più di una lente. Lighthouse fornisce audit automatici su performance, accessibilità, SEO e altro. Testa il primo caricamento con storage cancellato o profilo pulito, quindi completa il compito target. Dove esistono dati reali sufficienti, confronta gruppi di pagine e classi di dispositivo importanti. Core Web Vitals sono misure di campo: LCP riguarda il caricamento, INP l'interattività e CLS la stabilità visiva.
I dati di campo riflettono visite reali; i test in laboratorio rendono il problema più riproducibile. Usa entrambi quando disponibili.
Un caricamento simulato non può misurare INP perché manca l'input utente; il laboratorio fornisce Total Blocking Time solo come proxy.
3. Esegui l'audit del percorso end-to-end
Raggruppa le evidenze per percorso e meccanismo. Controlla dimensioni delle richieste, tempi e dipendenze per asset di pagina e terze parti. Verifica viewport mobile, percorso da tastiera, focus visibile, etichette, messaggi di errore, intestazioni, scopo dei link, zoom e cosa accade se un'immagine, uno script o un servizio condizionato al consenso è lento o non disponibile.
Tratta l'output di accessibilità automatizzato come triage. W3C dice che nessuno strumento da solo può determinare se un sito soddisfa gli standard di accessibilità; è necessaria una valutazione umana competente. Per la ricerca, assicurati che le risorse renderizzate importanti restino disponibili sia ai crawler che agli utenti. Includi redirect, canonical, link interni, direttive robots, sitemap e dati strutturati quando la modifica li coinvolge.
Elenca tag manager, analytics, chat, pagamento, font, CDN, API e strumenti di consenso da cui il compito dipende.
Per pagamento, autenticazione, dati utente, header o controlli di sicurezza, ottieni una revisione qualificata in ambito sicurezza e pagamenti.
4. Costruisci un backlog classificato
Scrivi una piccola ipotesi per ogni voce: su questa pagina o flusso, cambia questo meccanismo perché l'evidenza suggerisce che causa questo problema; misura il risultato atteso e proteggi i vincoli nominati. Mantieni distinta l'osservazione dalla diagnosi. Una traccia salvata può mostrare un'immagine grande che ritarda il contenuto, ma la soluzione richiede comunque revisione di design e contenuto.
Classifica le voci per Impatto, Confidenza, Sforzo e Rischio. L'impatto è il percorso prioritario interessato. La confidenza indica se laboratorio, campo e verifiche manuali concordano. Lo sforzo include il coordinamento, non solo il codice. Il rischio comprende dipendenze, sicurezza, complessità di rilascio e reversibilità. Un problema critico di funzionalità o sicurezza può avere la precedenza su questo modello e richiede un triage specialistico.
Tieni owner, link all'evidenza, ipotesi, pagine, misura, vincoli, dipendenze, metodo di rilascio e trigger di rollback.
Non aggregare refactor non correlati in una modifica misurata a meno che la sicurezza non lo richieda.
5. Rilascia in sicurezza e conserva una via di ritorno
Prima del deployment, registra cosa cambia, l'approvatore, la finestra di rilascio, il verificatore, la condizione di successo, il trigger di rollback e il metodo di ripristino. Testa in un ambiente non di produzione rappresentativo quando possibile, inclusi contenuti, permessi, integrazioni, redirect, scelte di consenso e percorsi di errore comuni. La produzione può comunque differire per dati, cache, configurazione e terze parti.
Usa un rollout ridotto, feature flag, asset versionati o una configurazione reversibile quando la piattaforma lo supporta. Conferma il comportamento di cache e CDN prima di confrontare i risultati. OWASP considera la gestione di configurazione e deployment un'area di testing per la sicurezza; header, permessi, esposizione di file e impostazioni di dominio o cloud non dovrebbero essere modifiche di ottimizzazione fatte alla leggera.
Definisci un trigger osservabile, come checkout fallito, navigazione rotta, errore client inatteso o regressione di accessibilità.
Un piano di ripristino può ridurre il tempo di recovery ma non eliminare tutti i rischi; testa il ripristino prima di farvi affidamento.
6. Verifica, decidi e ripeti
Dopo il rilascio, ripeti i controlli funzionali di riferimento e i test di laboratorio comparabili. Ricontrolla dispositivi, browser, stati e integrazioni rilevanti. Confronta elementi omogenei: URL, stato della cache, classe di dispositivo, regione quando possibile e finestra di misurazione. Conferma i vincoli oltre alla metrica target.
Lascia all’evidenza il tempo di maturare. Google nota che i cambiamenti nella ricerca possono richiedere da ore a mesi per manifestarsi e suggerisce di attendere settimane prima di valutare il risultato. I dati reali sulle prestazioni sono evidenza aggregata, non un verdetto istantaneo sul rilascio. Registra se mantenere, modificare, indagare o ripristinare, quindi definisci un nuovo valore di riferimento dopo modifiche significative a template, piattaforma, tag, contenuti o dipendenze.
L'esito del percorso atteso migliora e i vincoli concordati restano intatti.
Agisci quando l'evidenza di campo o del compito confligge con il risultato di laboratorio, o quando un vincolo critico regredisce.