RUCSS: Remove Unused CSS, una vista ai pro e contro nei vari contesti reali. - 🏆 Managed Server
19 Maggio 2023

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

Quando la tecnica del Remove Unused CSS può rendere più lento il tuo sito e rovinare la user experience.

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.

remove-unused-css

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.

Hai dei dubbi? Non sai da dove partire? Contattaci


Abbiamo tutte le risposte alle tue domande per aiutarti nella giusta scelta.

Chatta con noi

Chatta direttamente con il nostro supporto prevendita.

0256569681

Contattaci telefonicamente negli orari d’ufficio 9:30 – 19:30

Contattaci online

Apri una richiesta direttamente nell’area dei contatti.

INFORMAZIONI

ManagedServer.it è il principale provider italiano di soluzioni hosting ad alte performance. Il nostro modello di sottoscrizione ha costi contenuti e prevedibili, affinché i clienti possano accedere alle nostre affidabili tecnologie di hosting, server dedicati e cloud. ManagedServer.it offre, inoltre, eccellenti servizi di supporto e consulenza su Hosting dei principali CMS Open Source come WordPress, WooCommerce, Drupal, Prestashop, Magento.

SOLO UN ATTIMO !

Vorresti vedere come gira il tuo WooCommerce sui nostri sistemi senza dover migrare nulla ? 

Inserisci l'indirizzo del tuo sito WooCommerce e otterrai una dimostrazione navigabile, senza dover fare assolutamente nulla e completamente gratis.

No grazie, i miei clienti preferiscono il sito lento.
Torna in alto