RUCSS: Remove Unused CSS, una vista ai pro e contro nei vari contesti reali.

Introduzione

Nell’attuale panorama di ottimizzazione delle performance del web, i Google Core Web Vitals sono diventati un aspetto fondamentale nella definizione di un’esperienza utente di qualità. Fra i numerosi fattori che influenzano questi parametri, uno dei più significativi è la gestione dei fogli di stile CSS. Classiche tecniche come il caricamento asincrono di CSS, sebbene utili, possono portare a problemi di spostamento di layout, penalizzati dal Cumulative Layout Shift (CLS).

Una soluzione promettente a questo problema è rappresentata dalla tecnica del Remove Unused CSS (RUCSS), che prevede l’eliminazione dei codici CSS non utilizzati all’interno di una specifica pagina web.

Come funziona il RUCSS e l’implementazione di WP Rocket

L’approccio RUCSS si basa sulla riduzione del peso del codice CSS inviato al browser attraverso l’identificazione e l’eliminazione dei selettori CSS non necessari per la visualizzazione di una specifica pagina web. Questo processo avviene attraverso una minuziosa scansione del contenuto HTML della pagina, un’analisi approfondita delle regole CSS definite nei fogli di stile ad essa collegati, e infine la creazione di un CSS ‘pulito’ che contiene solo gli stili utilizzati nella pagina corrente. Tale processo contribuisce a migliorare l’efficienza del caricamento della pagina e ridurre il tempo di blocco del rendering.

Prendiamo un esempio più concreto: se un sito web dispone di un foglio di stile di 200 kilobytes, ma ne utilizza effettivamente solo il 20% per una determinata pagina, RUCSS eliminerà l’80% di CSS non utilizzato. Il risultato sarà un foglio di stile di soli 40 kilobytes, migliorando significativamente il tempo necessario per il download del CSS e la velocità di caricamento della pagina.

WP Rocket, uno dei più noti plugin per la performance in WordPress, implementa la tecnica del RUCSS salvando i CSS ‘puliti’ nella tabella ‘wp_rocket_css’. Tuttavia, questa pratica può portare a un considerevole aumento dell’utilizzo dello storage, in particolare nei siti web con un gran numero di pagine. Infatti, la tabella ‘wp_rocket_css’ può raggiungere dimensioni di svariati gigabyte, soprattutto in ambienti ad alta disponibilità di pagine.

Non capita di raro infatti, eseguendo operazioni amministrative e di manutenzione sui siti web di clienti, sia a livello applicativo che a livello sistemistico di imbattersi in situazioni in cui un database di poche decine di megabyte sia letteralmente esploso a svariate decine di gygabyte, producendo anche importartanti rallentamenti a livello di DBMS MySQL.

Ad esempio un utente su Github fa notare la sua esperienza e le sue rimostranze :

Per un sito con 10 mila prodotti (di 50 attributi) la tabella è di 5GB.

Non penso che creare CSS per ogni singola pagina/prodotto sia la soluzione, indipendentemente dal metodo di archiviazione. Ovviamente, quando si utilizza un filesystem, non si avranno i requisiti di memoria aumentati che stiamo affrontando ora. Il nostro sito, consuma 15GB di RAM anche quando è “inattivo” – grazie alla vostra enorme tabella che è otto volte la dimensione del resto del contenuto.

Quello che dovete fare, signori, è seguire l’esempio di TagDiv e creare SOLO UN CSS ottimale per ogni modello di pagina, NON UNO PER OGNI SINGOLA PAGINA. Ad esempio, UN file CSS per la pagina del prodotto, uno per la pagina della categoria, UNO per la homepage ecc. Presumendo ovviamente il “worst case scenario”, ad esempio una pagina che include prodotti correlati, cross-sell, up-sell ecc. e applicare questo UNICO modello a tutte le pagine dei prodotti.

Se non siete sicuri, permettete agli utenti finali di eseguire manualmente l’ottimizzatore sulla loro… pagina del prodotto più complessa, come fa TagDiv per ogni modello. Mi piacerebbe davvero utilizzare il vostro ottimo lavoro di ottimizzazione CSS in un altro progetto. Purtroppo ha oltre 150 mila prodotti e la vostra architettura lo rende proibitivo.

Come possiamo vedere dal commento sopra, che tratta un caso specifico reale, dunque il problema non è tanto nella tecnica utilizzata (ovvero quella di rimuovere i css inutilizzati), quanto la pessima implementazione di un plugin famosissimo come WP Rocket.

Valutazioni sulla saggezza dell’utilizzo del RUCSS

L’utilizzo del RUCSS, sebbene possa sembrare attraente dal punto di vista teorico, richiede una valutazione ponderata. Il motivo principale risiede nel costo computazionale associato alla generazione dei fogli di stile ‘puliti’. L’analisi necessaria per individuare i selettori CSS inutilizzati su ciascuna pagina del sito richiede risorse significative in termini di CPU e memoria.

Un altro aspetto da considerare riguarda la gestione dello storage: i CSS ‘puliti’ generati devono essere salvati da qualche parte, con un conseguente impatto sull’utilizzo dello storage.

Come già accennato, nel caso di WP Rocket, questi vengono memorizzati nella tabella ‘wp_rocket_css’ del database MySQL, che può crescere fino a raggiungere dimensioni di svariati gigabyte. Questa circostanza, oltre a richiedere un notevole spazio su disco, comporta anche un elevato costo computazionale per l’esecuzione delle query SQL, sia in fase di inserimento che di selezione dei dati.

In contesti come gli e-commerce, l’adozione del RUCSS potrebbe portare all’esigenza di scaricare numerosi, sebbene piccoli, file CSS a ogni visita di una nuova pagina. In termini di user experience, può risultare più accettabile un leggero ritardo durante il caricamento iniziale del sito, piuttosto che riscontrare ripetuti ritardi su ogni pagina.

RUCSS in diversi contesti: siti di prodotti e e-commerce

Siti web focalizzati su prodotti, come quelli di cosmetici, occhiali o abbigliamento, richiedono particolare attenzione. In tali casi, l’utente tende a visitare numerose pagine di prodotti e una navigazione fluida è fondamentale. L’approccio più sensato potrebbe essere quello di servire un file CSS più grande inizialmente, che verrà poi riutilizzato dalle successive pagine HTML.

Prendendo ad esempio un e-commerce come quelli di prodotti cosmetici, occhiali o abbigliamento, dove l’utente tende a visitare numerose pagine di prodotti, sarebbe preferibile avere una navigazione più fluida possibile. Si potrebbe finire con il dover scaricare molti piccoli file CSS a ogni visita di una nuova pagina. Questo può avere poco senso se consideriamo l’esperienza dell’utente: è probabilmente più accettabile attendere un secondo in più durante il caricamento iniziale del sito, piuttosto che riscontrare piccoli ritardi ripetuti su ogni pagina.

Consigli per l’uso del RUCSS

Sebbene l’ottimizzazione dei punteggi Google Core Web Vitals possa sembrare allettante, un e-commerce che riceve principalmente traffico da campagne sponsorizzate su Facebook o Google Adsense potrebbe non trarre benefici significativi da questo approccio. Questo è particolarmente vero in presenza di plugin come WP Rocket, Autoptimize o RapidLoad, che possono causare notevoli ritardi nel caricamento delle pagine sopratutto laddove il CSS non è ancora presente e deve essere generato a runtime, creando un paradosso in presenza di sistemi con cache che ovviamente cache l’HTML e non cacha file statici come JS e come CSS.

Ci si è trovati in alcuni casi ad avere un caricamento dell’HTML in 40 millisecondi, e l’attesa del CSS a 9 secondi, generando un’esperienza utente a dir poco terrificante, laddove avrebbe dovuto essere praticamente immediata.

Nonostante dunque,  l’approccio RUCSS possa risultare efficace in certi contesti, non è una soluzione universale. Prima di implementare questa tecnica, è fondamentale prendere in considerazione l’intero ecosistema del sito web, incluse le caratteristiche del pubblico, la struttura del sito, le priorità in termini di SEO e user experience, nonché le risorse disponibili per la gestione del database e dello storage.