Profilare un percorso cliente prima di modificare il codice
Scegli una rotta e un’interazione importanti, ad esempio aprire la navigazione, filtrare risultati o inviare un form. Registrala nel pannello Performance di Chrome DevTools in uno stato del browser pulito. Ripeti l'azione e acquisisci sia una registrazione con CPU limitata sia una su una macchina di sviluppo; le tracce desktop possono nascondere lavoro che disturba su un telefono meno potente.
Usa la traccia per verificare un’ipotesi ristretta, non per incolpare un componente da un report di bundle. Nel flame chart Main, le barre più larghe richiedono più tempo e quelle impilate mostrano lo stack di chiamate. Un triangolo rosso su un task identifica un possibile long task; selezionalo e segui il link al codice che lo ha avviato. Salva le tracce prima e dopo per cambiamenti significativi.
Registra poco prima dell’azione e interrompi dopo il risultato visibile.
Mantieni rotta, stato account e sequenza di azione coerenti.
Assegna ogni costo principale al team o fornitore in grado di cambiarlo.
Leggi la traccia come una coda di lavoro
Un long task è una soglia d’indagine, non una diagnosi completa. La specifica W3C Long Tasks segnala task della durata di 50 millisecondi o più. Cerca sotto un task la valutazione JavaScript, un handler di evento, ricalcolo degli stili, layout o paint. Lo stack di chiamate indica dove iniziare; i tempi mostrano se il problema è codice, rendering o un frame di terze parti.
Prioritizza i costi che si ripetono durante un’interazione di valore. Un handler breve può comunque sembrare lento quando innesca layout o è in attesa dietro lavoro precedente. La traccia è una misura di laboratorio, quindi conferma la correzione su dispositivi rappresentativi e, dove disponibile, con telemetria sul campo rispettosa della privacy.
Il parsing all'avvio richiede una soluzione diversa rispetto a un gestore eseguito dopo un tap.
Individua pattern ripetuti di scrittura degli stili e lettura del layout prima del refactoring.
Allega la traccia, lo scenario e i costi principali all’attività di lavoro.
Distribuire meno codice nel momento che conta
Fai l’inventario degli script per rotta e scopo. Rimuovi pacchetti inutilizzati, duplicati, esperimenti ritirati e codice per funzionalità terminate. Poi separa le funzionalità specifiche della rotta o raramente usate affinché si carichino quando necessario anziché nel percorso iniziale. Il caricamento dinamico può ridurre il lavoro di avvio, ma può generare un ritardo visibile quando l’utente ha immediatamente bisogno della funzionalità.
Chiediti se un componente necessita di un intero framework client-side, se un’utility duplica funzionalità esistenti e se HTML statico con un piccolo enhancement può bastare. Testa lo stato di fallback di un modulo caricato in ritardo. La pagina dovrebbe gestire in modo affidabile una funzionalità opzionale rimandata, anziché mostrare un controllo inutilizzabile.
Documenta quali script sono consentiti su una rotta e perché.
Consideralo per editor opzionali, mappe, player o viste di reportistica.
Testa autenticazione, accessibilità, pagamento e completamento form; cerca revisione qualificata quando i controlli sono coinvolti.
Spezzare il lavoro in modo che il browser possa rispondere
Suddividere il lavoro in funzioni più piccole non crea task del browser separati se tali funzioni vengono eseguite in modo sincrono. Per un ciclo lungo, suddividi il lavoro in batch, aggiorna prima lo stato visibile all’utente, quindi cedi il controllo prima di continuare. In questo modo il browser può elaborare input e rendering tra un batch e l’altro.
Dove è supportato, scheduler.yield() restituisce il controllo al thread principale e poi riprende il lavoro; verifica che la funzionalità sia disponibile e usa un fallback per i browser non supportati. Non cedere dopo ogni singola piccola operazione: ha overhead e può aumentare il tempo di completamento. Scegli i confini basandoti sulle misurazioni, preserva la cancellazione e previeni che risultati obsoleti sovrascrivano stato più recente.
Mostra accettazione o progresso prima di follow-up non visibile.
Cedi prima che il lavoro misurato diventi lungo, anziché una volta per elemento.
Le linee guida correnti di web.dev non raccomandano una nuova strategia basata su isInputPending().
Sposta il calcolo, non l’interfaccia, in un worker
Un Web Worker esegue uno script su un thread in background separato dal thread principale di esecuzione. È adatto per parsing costosi, trasformazioni dati, indicizzazione di ricerca e altri calcoli che non necessitano di accesso diretto all’interfaccia. Invia un input definito, ritorna un risultato definito e mantieni rendering e modifiche di stato visibile sul thread principale.
I worker non sono universali. Non possono manipolare direttamente il DOM né usare Window, e la comunicazione tramite messaggi copia i dati. La creazione del worker, il trasferimento dei dati e il coordinamento degli errori possono superare i benefici per un calcolo di piccole dimensioni. Misura l’intera interazione, termina i worker non necessari e progetta un fallback se il lavoro del worker fallisce.
Inizia con un calcolo il cui input e output possono essere serializzati e testati.
Scarta i risultati generati per un filtro, una rotta o un'azione non più attuali.
Comunica progresso significativo attraverso l’interfaccia normale.
Governare il JavaScript di terze parti come una dipendenza di produzione
Analytics, advertising, esperimenti, embed sociali, player video e widget di supporto possono aggiungere richieste, valutazione JavaScript, iframe e dipendenze. Uno script vendor può essere necessario, ma è fuori dal controllo diretto del team applicativo e può influire su performance, privacy, sicurezza e continuità. Registra il suo scopo, le rotte, la condizione di caricamento, l'approvatore, il requisito di consenso e il responsabile della rimozione.
Quando condizioni e contratti lo permettono, compara una pagina rappresentativa con e senza una singola origine di terze parti. Gli strumenti di performance possono evidenziare valutazione costosa, payload e attribuzione di long-task. Mantieni un’integrazione leggera o posticipata solo quando il suo valore documentato giustifica il costo misurato. Verifica che i contenuti essenziali e la transazione principale funzionino quando una dipendenza opzionale è lenta o assente.
Carica un tag solo su rotte e condizioni che ne hanno bisogno.
Includi le modifiche al tag manager nella revisione della gestione delle modifiche, delle prestazioni, della privacy, della sicurezza e del rollback.
Documenta e testa come disabilitare un’integrazione non critica.
Rendi la reattività una salvaguardia del rilascio
Trasforma la traccia vincente in un piccolo controllo di regressione per il percorso importante. Definisci le interazioni coperte, il vincolo di dispositivo o CPU, la risposta attesa e il revisore. Abbinalo all’inventario dei bundle e delle terze parti affinché un nuovo pacchetto o tag non possa reintrodurre silenziosamente lavoro sul thread principale.
Status Is UP usa questa evidenza per ottimizzazione proattiva e rimedio sicuro, non per sostituire il monitoraggio della disponibilità in produzione. Prima di una modifica ad alto rischio, prepara il rollback e verifica il percorso critico dopo il rilascio. I risultati variano per dispositivo, rete, browser, contenuto e stato account; tratta le soglie come guardrail, non garanzie.
Richiedi tracce prima e dopo per navigazione condivisa, checkout, ricerca o grandi bundle.
Conosci il feature flag, l’impostazione del tag o la versione di deployment che ripristina il comportamento noto-buono.
Ripeti la profilazione dopo rilasci importanti, cambiamenti di fornitore o variazioni nella composizione dei dispositivi.