• Tools for Auditing CSS
• Original post: Silvestar Bistrović
• The Nuggets translation Project
• Permanent link to this article: github.com/xitu/gold-m…
• Translator: Hoarfroster
• Proofread by zenblo

Checking CSS is not a common task in a developer’s daily routine, but it is sometimes necessary. Perhaps this is part of a performance check to identify problematic CSS or remove unused selectors. Perhaps as part of an effort to improve accessibility, all colors used in the code base are evaluated against each other. Maybe even to enforce consistency.

Whatever the case, when it comes time to check out CSS, I usually use the tools I’ll cover in the next article. But before we do that, let’s take a look at what CSS really is.

directory

1. Development tools in the browser
2. Online tools
3. CLI tool

It is difficult to check CSS

In general, code review involves analyzing code to find bugs or other irregularities, such as potential performance problems. For most programming languages, the concept of checking code is relatively simple: does it work or does it not work? But CSS is a special language, and errors are mostly ignored by browsers. And the fact that we can implement the same style in many different ways makes checking CSS a little tricky, to say the least.

Using an extension to your favorite code editor, or setting up a CSS linter or CSS code checker, might help you catch these errors in time, but that’s not what I want to show you here, and we shouldn’t stop there. Because we can use too many colors, typographical definitions, or Z-index values, all of which can make a CSS codebase confusing, unmaintainable, and unstable.

To really examine CSS, we need to dig deep and find areas that are not considered best practices. To find these places, we can use the following tools:

Built-in browser development tools

Let’s take a look at Chrome DevTools CSS checker. I’m using the Brave browser based on Chromium. You might also want to check out this post from Umar Hansa — he compiled a bunch of “great” DevTool features released in 2020.

If you prefer to examine CSS code manually, we can use the Inspect tool to find the CSS code applied to a particular element. With “Inspect Arrow “, we can even see additional details about color, font, size, and accessibility.

Inspector for Grid and Flex

There are many useful utilities and details in the DevTools interface, but my favorites are the Grid and Flex inspectors. To enable them, go to Settings (a pinion icon in the top right of DevTools), click On Experiments, and then enable CSS Grid and Flexbox debugging. Although this tool is mainly used to debug layout issues, I sometimes use it to quickly determine whether a page is using CSS Grid or Flexbox.

CSS Overview

Checking CSS is very basic and everything needs to be done manually. Let’s take a look at some of the more advanced DevTools features.

CSS Overview is one of them. To enable the CSS Overview tool, go to Settings and click On Experiments to enable the CSS Overview option.

To open the CSS Overview palette, use the ⌘ ⇧ P or Ctrl ⇧ P shortcut, type CSS Overview, and select Show CSS Overview. This tool presents an overview of CSS properties, such as colors, fonts, contrast issues, unused declarations, and media queries. I usually use this tool to judge the current CSS code. For example, if there are 50 grayscale colors or too many typographical definitions, it means that the style guide is not applied in practice, or it may not even exist.

Note, however, that the tool provides an overview of the styles used for the page, not individual files.

Coverage Panel

The Coverage Panel tool shows the amount and percentage of code used on the page. To check it, use the ⌘ CONTRIBUp or Ctrl contribup shortcut, type Coverage, select Show Coverage, and click the Refresh icon.

You can type.css in the URL filter input to filter specific CSS files. I usually use this tool to understand delivery techniques for websites. For example, if I see that CSS coverage is fairly high, I can assume that CSS files are generated individually for each page. This may not be critical data, but sometimes it helps to understand caching strategies.

Rendering Panel

Rendering Panel is another useful tool. To open the render palette, we can use the ⌘ ⇧ P or Ctrl ⇧ P shortcut. This time enter “Rendering” and select the “Show Rendering” option. There are many options for this tool, but my favorite is:

• Paint Flashing – displays a green rectangle when a redraw event occurs. I use it to identify areas that take too much rendering time.
• Layout Shift Regions – Displays blue rectangles when Layout movement occurs. To take full advantage of these options, I usually set the “slow 3G” default under the” Network “TAB. I sometimes record my screen and then slow down the video to look for layout shifts.
• Frame Rendering Stats — Displays real-time GPU and Frame usage. This tool is handy for identifying heavy animation and scrolling problems.

These tools give you something you don’t get in a regular review, but I’ve found it essential to know if your CSS code is performing and not consuming power on your device.

Other options might be more beneficial for debugging the problem, such as emulating and disabling various features, forcing the use of the PREFERence-color-scheme feature or printing media types, and disabling local fonts.

Performance Monitor

Another tool for checking the Performance of CSS code is the Performance Monitor. To enable it, use the ⌘ ⇧ P or Ctrl ⇧ P shortcut, type Performance Monitor, and then select the Show Performance Monitor option. I usually use this tool to see how many recalculations and layouts are triggered when interacting with a page or animation occurs.

Performance Panel

On the Performance Panel, we can look at all the browser events during page loading in detail. To enable the Performance utility, use the ⌘ ⇧ P or Ctrl ⇧ P shortcut, type Performance, select Show Performance, and click the “Reload” icon. I usually enable Screenshots and The Web Vitals option. The most interesting ones for me are “first render”, “first rich render”, “layout transitions” and “largest rich render”. There is also a pie chart showing drawing and rendering times.

DevTools may not be a classic inspection tool, but it helps us understand which CSS features are being used, how efficient the code is, and how well the code is executing, which are all key to CSS code inspection.

Online tools

DevTools is just one of many tools available for checking, but there are other tools available for checking CSS code:

Specificity Visualizer

A Special Visualizer shows the Specificity of a CSS selector in a code base. Just go to the site and paste in the CSS.

The Main Chart shows the relationship of a particular style to the position in the style sheet. The other two charts show the use of specific styles. I often use this site to find “bad” selectors. For example, if I see a lot of specific styles marked red, I can easily conclude that the CSS code here could be better. It’s helpful to keep screenshots for reference as you work on improving.

CSS Specificity Graph Generator

CSS Wide Spectrum Graph Generator is a similar tool for visualizing specific styles. It shows a slightly different chart that might help you see how your CSS selectors are organized in a particular style. As it says on the tools page, “spikes are bad, and the general trend should be towards higher specific styles later in the style sheet”. It would be interesting to discuss this further, but it is beyond the scope of this article. However, Harry Roberts did write extensively about this in his article “The Specificity Graph” and it’s worth a try.

CSS Stats

CSS Stats is another tool that provides analysis and visualization of your stylesheets. In fact, Robin wrote about it a while back and showed how he used it to audit stylesheets in his work.

All you need to do is type in the URL of the site and hit Enter. This information is broken down into meaningful pieces, including the number of style declarations, color, typography, Z-index, specific style, and so on. Also, you may want to save your screenshots for future reference.

Project Wallace

Project Wallace was developed by Bart Veneman, who has covered the Project on CSS Tricks. The power of Project Wallace is its ability to compare and visualize import-based changes. This means you can see the previous state of your CSS code base and see how your code changes from state to state. I find this feature quite useful, especially if you want to convince people that the code has been improved. The tool is free for individual projects and offers paid plans for more projects.

CLI tool

In addition to DevTools and online tools, there are command line interface (CLI) tools that can help us check CSS:

Wallace

One of my favorite CLI tools is Wallace. Once installed, type Wallace, then the site name, and it will automatically output everything you need to know about your site’s CSS code. My favorite! The number of times important was used, and how many ids were in the code. Another neat piece of information is the number of top-level specific styles and how many selectors use them. These could be red flags of “bad” code.

What I like most about this tool is that it can pull all the CSS code from the site — not just external files, but also the ability to include inline code. This is why CSS Stats and Wallace’s report do not match.

csscss

The CSSCSS CLI tool can show which rules share the same declaration, which can be useful for identifying duplicate code and reducing the amount of code written. I’d think twice before doing this, because it might not be worth it, especially with today’s caching mechanisms. It is worth mentioning that CSSCSS requires a Ruby runtime environment.

Other useful tools

Other CSS tools may not be used for checking, but they are still useful. Let’s list these as well.

• Color Sorter – Sorts CSS colors by hue and then saturation.
• CSS Analyzer – – Analyzes a list of CSS.
• Constyble – This is a CSS complexity Analyzer based on CSS Analyzer.
• Extract CSS Now – Extract all CSS from a web page.
• Get CSS – Get all CSS from a web page.
• UCSS – Crawls web sites to identify unused CSS.

conclusion

CSS is everywhere, and we need to treat it like a first-class citizen of every project. It doesn’t matter what other people think of your CSS, but what you think of it does matter. If your CSS is well-organized and well-written, you’ll spend less time debugging it and more time developing new features. In an ideal world, we would educate everyone to write CSS well, but it takes time.

Make today the day you start taking care of your CSS code.

I know checking CSS isn’t going to be fun for everyone. But if you’re running your code against any of these tools and trying to improve even one part of your CSS codebase, this article has done its job.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.