CSS e JavaScript inutilizzati: come alleggerire il sito senza comprometterne le funzioni

Che cosa significa davvero “codice inutilizzato”

CSS e JavaScript svolgono lavori diversi: il primo definisce l’aspetto delle pagine, il secondo può gestire interazioni e funzioni. Un tema o un componente distribuito su tutto il sito può includere risorse necessarie soltanto in poche sezioni. Il visitatore le riceve comunque, anche quando consulta una semplice pagina di servizio.

Il pannello Coverage di Chrome (si apre in una nuova scheda) misura quali parti risultano usate durante la registrazione. Se non apri il menu, non compili il modulo o non attivi una scheda, il codice corrispondente può risultare inutilizzato in quella prova. La misura va quindi associata a un percorso preciso.

Per il titolare dell’attività la domanda utile è concreta: quali risorse stiamo facendo scaricare senza un beneficio su questa pagina? Chiedi al tecnico di rispondere con nomi dei componenti, pagine interessate e funzioni coinvolte, evitando un elenco di percentuali senza interpretazione.

Preparare un campione che rappresenti il sito

Controllare soltanto la homepage lascia fuori molti casi importanti. Seleziona una pagina di servizio, una guida, la pagina contatti e, quando presenti, una scheda prodotto e il percorso di acquisto. Aggiungi una pagina con galleria o prenotazione se usa componenti diversi dalle altre. L’obiettivo è riconoscere le differenze, non provare ogni indirizzo con la stessa profondità.

Per ogni pagina scrivi una breve sequenza: aprire il menu, raggiungere una sezione, espandere una risposta, compilare un campo, provocare un errore comprensibile. Ripeti almeno i percorsi decisivi su telefono e computer. Considera anche lo stato iniziale del consenso, se il sito utilizza servizi che lo richiedono.

Salva URL, dispositivo, data e comportamento atteso. Questa scheda diventa il riferimento condiviso fra chi gestisce i contenuti e chi sviluppa. Per una diagnosi più generale parti dalla guida sul sito lento e le sue possibili cause.

Ricondurre ogni file a una funzione e a un responsabile

Un nome tecnico poco chiaro non basta per decidere. Chiedi una mappa delle risorse più pesanti: a quale componente appartengono, chi lo mantiene e in quali pagine serve. La documentazione di Lighthouse sul JavaScript inutilizzato (si apre in una nuova scheda) ricorda che anche gli script asincroni competono per la banda disponibile. Non bloccare direttamente la visualizzazione non significa essere privi di costo.

Un esempio ipotetico: una pagina dedicata a un servizio carica lo stesso sistema di mappe usato nella pagina contatti, pur senza mostrare una mappa. La verifica riguarda il caricamento condizionale di quel componente. Se invece lo script prepara un modulo necessario, occorre valutare come distribuirlo senza perdere la funzione.

Per servizi esterni raccogli anche una decisione commerciale: li usiamo davvero, quale beneficio offrono e chi può modificarli? Un’integrazione lasciata da una vecchia campagna può richiedere una semplice rimozione concordata; una prenotazione attiva richiede un collaudo più approfondito.

Intervenire sul componente prima di aggiungere un’ottimizzazione

Conviene partire dalle funzioni dismesse e dai caricamenti estesi inutilmente a tutte le pagine. In un sito con CMS il tecnico può controllare le impostazioni dei componenti e del tema; in un sito sviluppato su misura può valutare come separare il codice comune da quello specifico. Non esiste un comando valido per qualunque piattaforma.

Per il CSS, la guida ufficiale di Lighthouse sulle regole inutilizzate (si apre in una nuova scheda) illustra il costo delle risorse superflue. L’intervento deve però rispettare gli stati meno visibili: errori dei moduli, menu aperti, tastiera, stampa e dimensioni diverse dello schermo.

Chiedi una modifica per volta e una motivazione leggibile. Ritardare indiscriminatamente tutti gli script può rendere più rapido il primo fotogramma e più lenta la prima interazione. Anche aggiungere un altro plugin di ottimizzazione va valutato rispetto agli strumenti già presenti e alle responsabilità di aggiornamento.

Verificare ciò che porta contatti e vendite

Il collaudo deve includere le azioni con cui un visitatore diventa un contatto. Controlla un invio di prova autorizzato, la ricezione nel canale corretto, il messaggio di conferma e la possibilità di correggere un campo errato. Per acquisti o prenotazioni utilizza l’ambiente di test previsto dal servizio: non generare transazioni reali solo per misurare la velocità.

• Menu e collegamenti devono funzionare anche alla prima apertura.
• Il contenuto deve restare leggibile nelle dimensioni mobili.
• Moduli, messaggi di errore e conferme devono essere completi.
• Gallerie e componenti devono mantenere i controlli necessari.

Chiedi di verificare anche la navigazione da tastiera e l’assenza di nuovi errori tecnici. Se una funzione non è stata provata, riportalo nel resoconto. Un controllo dichiarato incompleto è più utile di un generico “tutto a posto” basato sull’apertura della homepage.

Misurare il beneficio nelle stesse condizioni

Confronta prima e dopo usando le stesse pagine e condizioni di prova. Registra peso trasferito, risorse eliminate e tempi osservati, senza affidarti a una sola esecuzione. Distingui la prima visita da quella successiva: la cache del browser può ridurre nuovi trasferimenti, ma non giustifica la presenza di componenti inutili.

Un esempio ipotetico: rimuovere una libreria superflua alleggerisce il download, ma il modulo resta lento perché aspetta una risposta esterna. Il primo intervento è utile; il secondo problema richiede una diagnosi separata. Non attribuire alla pulizia del codice miglioramenti che la prova non dimostra.

Nel documento finale chiedi tre informazioni: cosa è stato rimosso o caricato diversamente, quali funzioni sono state collaudate e quale beneficio è stato misurato. Aggiungi le condizioni in cui il risultato potrebbe cambiare, come un dispositivo meno potente o una connessione diversa.

Evitare che il codice superfluo ritorni

Il lavoro perde valore se il successivo aggiornamento ripristina tutte le risorse eliminate. Conserva la mappa dei componenti e un piccolo elenco di prove da ripetere dopo modifiche a tema, moduli o integrazioni. Se un intervento dipende da una configurazione particolare, documenta chi deve verificarla.

Per ogni nuova funzione chiedi quale pagina la userà e quale costo aggiungerà. Una richiesta di design può avere una soluzione semplice già disponibile nel sito, senza introdurre un’intera libreria. Allo stesso tempo, una funzione utile ai clienti può giustificare un costo: la decisione deve essere consapevole e misurata.

La guida al sito che rallenta dopo gli aggiornamenti aiuta a trasformare questa verifica in un’abitudine. Il criterio finale resta l’esperienza del cliente: trovare il servizio, capire l’offerta e completare il contatto senza attese o malfunzionamenti evitabili.

Domande frequenti

Posso cancellare tutti i file segnalati da PageSpeed?

No. Il rapporto osserva una situazione specifica: alcune risorse possono servire su altre pagine o dopo un’interazione. Prima occorrono una mappa delle funzioni e un collaudo.

Basta comprimere CSS e JavaScript?

La compressione riduce il trasferimento, ma non elimina automaticamente componenti superflui o lavoro del browser. Va accompagnata da una verifica di ciò che ogni pagina carica.

Devo cambiare tema per eliminare il codice inutilizzato?

Non necessariamente. Prima si valutano configurazione, caricamenti per pagina e componenti dismessi. Il cambio di tema ha senso solo se i limiti del sistema rendono sproporzionati gli interventi circoscritti.