Table of contents of the article:
Introduction
In the current web performance optimization landscape, i Google Core Web Vitals they have become a fundamental aspect in defining a quality user experience. Among the many factors that influence these parameters, one of the most significant is the management of CSS style sheets. Classic techniques like asynchronous loading of CSS, while useful, can lead to layout shifting problems, penalized by Cumulative Layout Shift (CLS).
A promising solution to this problem is the del technique Remove Unused CSS (RUCSS), which provides for the elimination of unused CSS codes within a specific web page.
How RUCSS works and WP Rocket implementation
The RUCSS approach is based on reducing the weight of the CSS code sent to the browser by identifying and eliminating unnecessary CSS selectors for displaying a specific web page. This process takes place through a thorough scanning of the HTML content of the page, a thorough analysis of the CSS rules defined in the style sheets linked to it, and finally the creation of a 'clean' CSS that contains only the styles used in the current page. This process helps improve page load efficiency and reduce render block time.
Let's take a more concrete example: if a website has a style sheet of 200 kilobytes, but actually uses only 20% of it for a given page, RUCSS will strip away the 80% of unused CSS. The result will be a style sheet of just 40 kilobytes, significantly improving the time it takes to download the CSS and the speed of page loading.
WP Rocket, one of the best-known WordPress performance plugins, implements the RUCSS technique by saving 'clean' CSS in the 'wp_rocket_css' table. However, this practice can lead to a dramatic increase in storage usage, particularly on websites with large numbers of pages. In fact, the 'wp_rocket_css' table can reach several gigabytes in size, especially in high page availability environments.
In fact, it is not uncommon when performing administrative and maintenance operations on customer websites, both at an application and system level, to come across situations in which a database of a few tens of megabytes has literally exploded to several tens of gigabytes, also producing important slowdowns at DBMS MySQL level.
For example a user on Github points out his experience and grievances:
For a site with 10 products (of 50 attributes) the table is 5GB.
I don't think creating CSS for every single page/product is the solution, regardless of the storage method. Of course, when using a filesystem, you won't have the increased memory requirements we're dealing with now. Our site consumes 15GB of RAM even when it's “idle” – thanks to your massive table that's eight times the size of the rest of your content.
What you need to do, folks, is to follow TagDiv's lead and create ONLY ONE optimal CSS for each page template, NOT ONE FOR EACH INDIVIDUAL PAGE. For example, ONE CSS file for product page, one for category page, ONE for homepage etc. Assuming of course the "worst case scenario", for example a page that includes related products, cross-sells, up-sells etc. and apply this ONE template to all product pages.
If you're not sure, allow end users to manually run the optimizer on their… more complex product page, like TagDiv does for each template. I would really like to use your great CSS optimization work in another project. Unfortunately it has over 150 thousand products and your architecture makes it prohibitively expensive.
As we can see from the comment above, which deals with a real specific case, therefore the problem is not so much in the technique used (i.e. that of removing unused css), but in the bad implementation of a very famous plugin like WP Rocket.
Evaluations on the wisdom of using the RUCSS
The use of the RUCSS, although it may seem attractive from a theoretical point of view, requires a thoughtful evaluation. The main reason lies in the computational cost associated with generating 'clean' stylesheets. The analysis required to find unused CSS selectors on each page of your site requires significant CPU and memory resources.
Another aspect to consider is storage management: the 'clean' CSS generated needs to be saved somewhere, with a consequent impact on storage usage.
As already mentioned, in the case of WP Rocket, these are stored in the 'wp_rocket_css' table of the MySQL database, which can grow to several gigabytes in size. This circumstance, in addition to requiring considerable disk space, also involves a high computational cost for the execution of SQL queries, both in the data insertion and selection phase.
In contexts such as e-commerce, the adoption of RUCSS could lead to the need to download numerous, albeit small, CSS files with each visit to a new page. In terms of user experience, a slight delay during the initial load of the site may be more acceptable than experiencing repeated delays on each page.
RUCSS in different contexts: product sites and e-commerce
Product-focused websites, such as cosmetics, eyewear, or clothing, need special attention. In such cases, the user tends to visit numerous product pages and smooth navigation is crucial. The most sensible approach might be to serve a larger CSS file initially, which will then be reused by subsequent HTML pages.
Taking for example an e-commerce such as those of cosmetics, eyewear or clothing, where the user tends to visit numerous product pages, it would be preferable to have the smoothest navigation possible. You may end up downloading many small CSS files with each new page visit. This may make little sense if we consider the user experience: it is probably more acceptable to wait an extra second during the initial load of the site, rather than experiencing repeated small delays on each page.
Recommendations for using the RUCSS
Although Google scores optimization Core Web Vitals may seem tempting, an e-commerce that mainly receives traffic from sponsored campaigns on Facebook or Google Adsense may not benefit significantly from this approach. This is particularly true in the presence of plugins such as WP Rocket, Autoptimize or RapidLoad, which can cause significant page loading delays especially where the CSS is not yet present and must be generated at runtime, creating a paradox in the presence of systems with caches that obviously cache the HTML and not cache static files like JS and CSS.
In some cases, we found ourselves having HTML loading in 40 milliseconds, and CSS waiting in 9 seconds, generating a terrifying user experience to say the least, where it should have been practically immediate.
Although therefore, the RUCSS approach may be effective in certain contexts, it is not a universal solution. Before implementing this technique, it is essential to consider the entire ecosystem of the website, including audience characteristics, site structure, SEO and user experience priorities, as well as the resources available for database management and of the storage.
