Collecting CSS tokens is not a design-driven whim or aesthetics for aesthetics’ sake. It is an engineering practice aimed at normalizing visual decisions and reducing frontend operational costs.
In this article, we will cover:
- what CSS tokens mean in practical terms;
- how they actually appear in real-world projects;
- which issues token collection exposes;
- and why this process should be automated as part of an audit.
What CSS Tokens Mean in Practice
A design token is a named design decision, such as a color or spacing value. Collecting repeated CSS values is a way to find candidates for such tokens; repetition alone does not make a value a token. Typical values to inventory include:
- colors (
#0d6efd,rgb(13,110,253)) - font sizes (
14px,1rem) - line heights
- spacings (
8px,16px,24px) - border radii
- shadows, z-index values, and so on
Illustrative e-commerce example:
.button-primary {
background: #005bff;
border-radius: 6px;
}
.checkout-button {
background-color: #005bff;
border-radius: 8px;
}
The two buttons use the same background color but different corner radii. Check whether that difference is intentional before combining their values into shared tokens.
Typical Issues Revealed by Token Collection
1. False Diversity
Consider an illustrative SaaS audit with these findings:
- 27 unique shades of blue
- 19 of them differed by 1–3 RGB units
This is a classic symptom of:
- manual copy-paste from Figma;
- the absence of a design contract between teams;
- accumulated technical debt.
2. Spacing Without a System
An admin interface example:
margin-bottom: 12px;
margin-bottom: 14px;
margin-bottom: 16px;
margin-bottom: 18px;
Check why four spacing values are used and whether their different purposes justify keeping them. A 4-point or 8-point scale is a design choice, not a rule that every interface must follow.
Token collection allows you to:
- visualize value distribution;
- identify clusters;
- make an informed decision: 8-pt grid, 4-pt grid, or another model.
3. Typographic Drift
Another illustrative example is a corporate portal with:
- 11 font sizes
- 7 line-height values
- 5 font weights for body text
Grouping these values by purpose may reveal just three typographic roles. Confirm their actual use before merging the remaining values.
How CSS Token Collection Works Technically
At a mechanical level, the process is straightforward:
- Load the page.
- Collect all CSS (inline and external).
- Parse declarations.
- Aggregate values by category:
- colors
- font-size
- spacing
- border-radius
- Calculate frequency.
Example JSON output:
{
"colors": {
"#005bff": 143,
"#ffffff": 98,
"#f5f7fa": 34
},
"spacing": {
"8px": 76,
"16px": 112,
"24px": 41
}
}
These counts provide evidence for an investigation. Frequency alone does not establish a value’s meaning or priority.
Why a Manual Approach Does Not Scale
At an early stage, teams can “agree verbally.” At the point where you have:
- 5+ developers;
- parallel feature branches;
- multiple design sources;
verbal agreements become harder to maintain.
Without automated token collection, you:
- it is harder to keep a reliable inventory;
- the effect of refactoring is harder to compare;
- visual regressions are easier to miss.
Illustrative scenario: redesign without stopping development
Consider a marketing site with about 120 pages. The figures below illustrate a possible migration and are not a verified customer result or a forecast:
Before:
- 4,000+ CSS rules
- 32 colors
- 19 font sizes
Steps taken:
- Collect values across key pages.
- Sort them by frequency.
- Define a core set of tokens.
- Migrate incrementally without a full rewrite.
After:
- 9 base colors
- 6 typographic tokens
- −18% CSS size
- fewer visual regressions during A/B tests
Where Performance Gains Come In
CSS tokens are not just about design:
- consolidating duplicate declarations may reduce CSS size;
- shared values can make styles easier to maintain;
- simplifying rules may reduce cascade conflicts;
- the impact on gzip/Brotli compression, coverage and critical CSS must be measured.
Collecting tokens alone does not make a page faster. Compare transferred bytes and loading times after the actual code change.
Why We Treat This as an Audit Problem
At milten.io, CSS token collection is:
- diagnostics, not a “pretty report” generator;
- a way to expose structure where it appears absent;
- an entry point to standardization, design systems, and scalable frontend architecture.
If token candidates are hard to formalize, inspect the design rules and exceptions. That difficulty alone does not prove the absence of a design system.
Summary
Reduced to management logic:
- CSS without tokens = an unmanaged asset
- token collection = inventory
- frequency = priorities
- automation = scalability
You can ignore this. But then every redesign will start with: “Let’s just carefully tweak the styles” — and end with another layer of chaos.
Use a token inventory to see which values occur in your project, choose justified changes and measure their effects.
