Fact: As web applications grow, so do their stylesheets. CSS growth can be caused by:

  • Feature-specific and page-specific stylesheets
  • Custom selectors
  • Additional declarations
  • CSS framework selector overrides (e.g. Bootstrap, Foundation, etc.)
  • Third-party plugins
  • Growing engineering team
  • Responsive design

Over the years, duplicate selectors have been added, old selectors have been orphaned, and a general CSS pollution has accumulated. To address this pollution, we decided to take a first-pass at reducing duplication and eliminating unused styles. Not only does this effort reduce the overhead of maintaining our CSS, but it also has performance implications.

Before starting our cleanup effort, we scanned our stylesheets using Parker, a stylesheet analysis tool. The tool provides a breakdown of selectors, rule counts, and more in a given set of stylesheets. Armed with these scans as a baseline, we started digging through CSS to reduce the clutter.

The Cleanup Process

To start, we ran global searches on each unique color code Parker gave us. As we found colors that were similar to our app colors and were not required, we updated them. Our search covered the stylesheets as well as view templates and JavaScript to catch styles being applied outside of the actual CSS files. We updated many plugins that used colors similar to ours to use our app colors for better continuity. We managed to reduce the amount of unique colors by 24%.

Next, we searched our non-plugin stylesheets for duplicate rules. Once identified, we verified that the duplicates were not being used anywhere within the project (HTML, JavaScript, Ruby template files, etc.) and eliminated them. Part of our removal tests included visual verification that the deleted rule didn’t have an adverse impact on the UI. For this, we compared local and production pages that utilized the deleted rule. We confirmed that 9% of our rules were duplicates or unused and subsequently deleted.

Throughout the cleanup, we reorganized our stylesheets to separate plugin stylesheets from application and override stylesheets. This did not directly impact page performance, but it helped maintain cleaner, more organized CSS for current and future developers. We also created a new article in our internal wiki that details how our stylesheets are organized and where to write new selectors going forward. This documentation will help current and new developers learn our conventions and avoid further pollution.

Monitoring our CSS Cleanup

Since we already monitor Rigor using Rigor (and with rigor!), we set up a new check to specifically compare the before and after effects of this cleanup. Our new check monitors the home dashboard page, which makes requests to many of the stylesheets affected by this cleanup (plugins, application, overrides and theme).

The following bar graph compares our check’s response time for the week leading up to the optimization deploy against the response time for the the three weeks following its release:

response_time_css.png

The first column shows the week of 11/30 – 12/6 before the optimization happened — we deployed on the 7th. We were averaging 7-8 second response times. The next columns show the 3 weeks following where we were averaging 5-6 second response times.

The Results

With our initial cleanup effort completed, we ran another set of Parker scans to benchmark our improvement. Here’s a look at our results:

Total # of..BeforeAfter
Rules60485503
Selectors82937667
Identifiers1962617978
Declarations1501412976
Id Selectors9285
Unique Colors193147
Important Keywords440329

In summary, we removed 626 selectors, 1648 identifiers, 2038 declarations, 7 ID selectors, 46 color codes, and 111 important keywords making up 545 unused, unnecessary or duplicate rules.

Going Forward

This type of stylesheet pollution is bound to happen with any team, but can be mitigated with some CSS best practices. A few best practices from our internal wiki that we follow are:

  • Search for an existing selector before creating a new one
  • Use existing colors unless absolutely necessary to create a new color
  • Create a new stylesheet for feature-specific or page-specific CSS
  • Use comments to organize sections of a stylesheet
  • If you can optimize or reorganize something to improve the CSS, do it

Good luck with your next CSS cleanup, and let us know in the comments or on Twitter your CSS best practices or optimization tricks with #webperfectionist.