Indice dei contenuti dell'articolo:
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.