May 19, 2023

RUCSS: Remove Unused CSS, a view to the pros and cons in the various real contexts.

When the Remove Unused CSS technique can make your site slower and ruin the user experience.

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.

remove-unused-css

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.

Do you have doubts? Don't know where to start? Contact us!

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.

0256569681

Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.

INFORMATION

Managed Server Srl is a leading Italian player in providing advanced GNU/Linux system solutions oriented towards high performance. With a low-cost and predictable subscription model, we ensure that our customers have access to advanced technologies in hosting, dedicated servers and cloud services. In addition to this, we offer systems consultancy on Linux systems and specialized maintenance in DBMS, IT Security, Cloud and much more. We stand out for our expertise in hosting leading Open Source CMS such as WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart and Magento, supported by a high-level support and consultancy service suitable for Public Administration, SMEs and any size.

Red Hat, Inc. owns the rights to Red Hat®, RHEL®, RedHat Linux®, and CentOS®; AlmaLinux™ is a trademark of AlmaLinux OS Foundation; Rocky Linux® is a registered trademark of the Rocky Linux Foundation; SUSE® is a registered trademark of SUSE LLC; Canonical Ltd. owns the rights to Ubuntu®; Software in the Public Interest, Inc. holds the rights to Debian®; Linus Torvalds owns the rights to Linux®; FreeBSD® is a registered trademark of The FreeBSD Foundation; NetBSD® is a registered trademark of The NetBSD Foundation; OpenBSD® is a registered trademark of Theo de Raadt. Oracle Corporation owns the rights to Oracle®, MySQL®, and MyRocks®; Percona® is a registered trademark of Percona LLC; MariaDB® is a registered trademark of MariaDB Corporation Ab; REDIS® is a registered trademark of Redis Labs Ltd. F5 Networks, Inc. owns the rights to NGINX® and NGINX Plus®; Varnish® is a registered trademark of Varnish Software AB. Adobe Inc. holds the rights to Magento®; PrestaShop® is a registered trademark of PrestaShop SA; OpenCart® is a registered trademark of OpenCart Limited. Automattic Inc. owns the rights to WordPress®, WooCommerce®, and JetPack®; Open Source Matters, Inc. owns the rights to Joomla®; Dries Buytaert holds the rights to Drupal®. Amazon Web Services, Inc. holds the rights to AWS®; Google LLC holds the rights to Google Cloud™ and Chrome™; Facebook, Inc. owns the rights to Facebook®; Microsoft Corporation holds the rights to Microsoft®, Azure®, and Internet Explorer®; Mozilla Foundation owns the rights to Firefox®. Apache® is a registered trademark of The Apache Software Foundation; PHP® is a registered trademark of the PHP Group. CloudFlare® is a registered trademark of Cloudflare, Inc.; NETSCOUT® is a registered trademark of NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, and Kibana® are registered trademarks of Elastic NV This site is not affiliated, sponsored, or otherwise associated with any of the entities mentioned above and does not represent any of these entities in any way. All rights to the brands and product names mentioned are the property of their respective copyright holders. Any other trademarks mentioned belong to their registrants. MANAGED SERVER® is a registered trademark at European level by MANAGED SERVER SRL Via Enzo Ferrari, 9 62012 Civitanova Marche (MC) Italy.

JUST A MOMENT !

Would you like to see how your WooCommerce runs on our systems without having to migrate anything? 

Enter the address of your WooCommerce site and you will get a navigable demonstration, without having to do absolutely anything and completely free.

No thanks, my customers prefer the slow site.
Back to top