How to perform analysis for CSS rules on your website

CSS stats does not particularly show or suggest if your stylesheet is maintainable or not.

As a general rule of thumb and as a front end developer one should always be following best practices. There are uncountable resources available on internet that talks about CSS best practices.

Your code is maintainable if

• Another developer can understand intent of it and takes no time to learn what you have done
• Its very fast to adjust your stylesheet if there is a requirement for applying it to similar sites or indivudual modules.
• Use technologies such as SASS or LESS
• Have bare minimum duplicate or redundant rules.
• Follow naming and style conventions
• Properly indented and organized.
• Use bare minimum nesting i.e. descendant or child selectors; selectors which rely on a thing within a thing

  .foo {
  .bar {}
  }

Now that we know what cssstats does and we have a long page of data available. Lets try to make sense of it. For an example I am using https://www.imgcake.com to perform analysis on and this is rather a small site in comparison to other massive portals such as Facebook, Pinterest etc. Feel free to perform analysis on these bigger sites too.

Key numbers

First section tells us how many rules, selectors, declarations and properties we have in our stylesheets. Next section goes into a bit more depth on presenting numbers of declarations we have.

Question here you may need to answer are

1. Do I really need those many color declarations or Can I just remove close ones. 
   Example: There is ONLY a marginal difference between say #F5F5F5 and #F6F6F6 or #000 and #333
2. Do I really need those !important flags. Most of the time your don't need those.
3. Do I really need those many background colors? 
4. Do I really need those many font sizes and families.

What we are looking at is to get rid or redundant rules, selectors that you will never use.

Said that, there are exceptions too. Say you are using a good CSS framework such as Bootstrap, it itself has over 2350+ selectors. You do not maintain this framework so you may not be interested in changing that. So its ok to just leave it just like that and concentrate on what you can do with your custom stylesheet.

While we are discussing rules, ensure that you take care of redundancy well

Addressing Redundancy

Ask yourself some questions

Do I write same lines over and over again for multiple selectors,  an example is shown below

.top-bar {
    background-color:#eee;
    color: #333;
    font-size: 14px;
    font-weight:bold;
    padding:10px;
}

Now this will give us a container with light grey background and black font. Now lets assume that you want another bar at the middle of the page and you want font to be slightly bigger, so we define another style as shown below

.middle-bar {
    background-color:#eee;
    color: #333;
    font-size: 20px;
    font-weight:bold;
    padding:10px;
}

You can already be thinking. Oh! I have been doing that for ages. But you can see that above example is against common known thing called "Don't repeat yourself", Now ask yourself what if there is a requirement to update value of color property to say #C00, you would now have to go to 2 places and make a change at both places. Lets now check more efficient way of addressing this

.top-bar {
    background-color:#eee;
    color: #333;
    font-size: 14px;
    font-weight:bold;
    padding:10px;
}

.top-bar.bottom-bar {
    font-size: 20px;
}

And that's what I call clean. As you can see that bottom-bar extends all the properties of top-bar and just overrides font-size

Please keep in mind that you have to balance spending so much time on this vs time allocated to your project. You don't really want to go overboard and miss a deadline just because you were optimizing your stylesheets. Keep that balance. Optimization becomes easy when you already know what styles you are defining for i.e. you already know the design. For prototyping and stuff, following best practices is good but going overboard is not.

Lets now talk about specificity

Specificity

Specificity sometimes is rather hard to understand and is an area that becomes too hard to manage even for Ninja front end developers. To achieve specificity we don't really use

• IDs to style containers
• Nested selectors

Its sometimes hard to avoid.

In our example of imgcake, our spcificity is a smooth upward graph as shown below

This graph shows the specificity of selectors as they are detected in the CSS our example site imgcake.com.

Those peaks that you see are specificity levels. More specific the rule higher the peak and that's bad news if more of the peaks are found at the begining of the document.

Graph moves along the x axis from left to right as it reads down the stylesheet from start to end of the file.

So what should be done about it

As per the best practices

1. Don't be much specific at the start of the document. !important flags are best avoided at the start.
2. Target for lowest possible average specificity
3. Try to minimize peaks in that graph. Peaks found in start, mid or anywhere before the end of that graph is actually a bad news

Learn more about specificity here

We’ll talk about each of these more in depth, but first let’s talk a little bit about how specificity works.

How does it work?

Glad you ask! Lets find out.

CSS selectors are assigned a specificity score so that web browser rendering engine knows how to style an element based on the style definitions provided and which element to style. Rendering engine consolidates all these styles and then renders elements onto the browser canvas with certain look and feel.

To get into how specificity is calculated please check this artcle on Mozilla develop website [Link]

Here is how scores are assigned

• Element selectors and pseudo-elements receive [1 point].
• Class selectors and psuedo-classes receive [1,0 points].
• ID selectors receive [1,0,0 points]
• Inline styles receive [1,0,0,0 points]
• !important get highest specificity 
• * selectors get a specificity score of all [0s].

Use indicator below on how to calculate specificity [Source CSSTricks]

Allright that's a bit inmidating. Let's check out some examples

Consider this

ul li span {} /*All element selectors: get specificity value [0,0,0,3] */
.class {} /* Class selector [0,0,1,0]*/
span .btn {} /*Element selector and class selector [0,0,1,1]*/
div #id {} /*element and id selector [0,1,0,1]*/
 /* inline style much hight specificity for fontsize [1,0,0,0]*/
span {font-size: 16 !important} /* !important qualifier will override previoud inline style for font-size*/

Ok, so this has started to make a bit more sense and now we can can go back to our best practices points

1. Don't be much specific at the start of the document. !important flags are best avoided at the start.
   Our graph from imgCake is perfect example on how it should be. Having more specific rules at the start will mean that code become less maintainable as it evolves. You may have to use !important far too many times at the end or start declaring redundant rules which are not always the best idea.
   A Bad specificity exampleis shown below
   
2. Target for lowest possible average specificity
   As you see how we score specificity. There is another online tool to calculate it http://specificity.keegan.st/, Use it for more understanding of it. End of the day we want to make it easier for browser rendering engine so that it can think less and does the job faster
   
   
   1. Favor classes over IDs 
   2. Don't go mad on nesting your selectors., keep it to 3 or 4 levels, make use of extending classes
   3. Try to minimize use of !important flag
3. Try to minimize peaks in that graph. Peaks found in start, mid or anywhere before the end of that graph is actually a bad news
   Try to put class definitions contextually i.e. logical place where it is linked to other specific selectors.

I hope that this will get you going with your CSS optimization and will give you better understanding on how to make your Stylesheet awesome. In next part I will share some resources for futher reading.