Сбор CSS-токенов: от хаоса стилей к управляемой системе

Сбор CSS-токенов — это не дизайнерская прихоть и не «красота ради красоты». Это инженерная задача по нормализации визуальных решений и снижению операционных издержек фронтенда.

В этой статье разберём:

• что именно мы считаем CSS-токенами;
• как они реально выглядят в живых проектах;
• какие проблемы выявляет их сбор;
• и зачем автоматизировать этот процесс на уровне аудита.

Что такое CSS-токены в практическом смысле

Если отбросить маркетинг, CSS-токены — это повторяющиеся значения, которые фактически выполняют роль констант:

• цвета (#0d6efd, rgb(13,110,253))
• размеры шрифтов (14px, 1rem)
• межстрочные интервалы
• отступы (8px, 16px, 24px)
• радиусы скруглений
• тени, z-index и т.д.

Пример из реального проекта e-commerce:

.button-primary {
    background: #005bff;
    border-radius: 6px;
}
 
.checkout-button {
    background-color: #005bff;
    border-radius: 8px;
}

Формально — два разных значения. По факту — один и тот же дизайн-смысл, размноженный без контроля.

Типовые проблемы, которые вскрывает сбор токенов

1. Ложное разнообразие

На одном из SaaS-проектов после анализа выяснилось:

• 27 уникальных оттенков синего
• из них 19 отличались на 1–3 единицы RGB

Это классический симптом:

• ручной копипасты из Figma;
• отсутствия дизайн-контракта между командами;
• накопленного техдолга.

2. Отступы без системы

Пример из админки:

margin-bottom: 12px;
margin-bottom: 14px;
margin-bottom: 16px;
margin-bottom: 18px;

Вопрос не в том, «какой отступ правильный». Вопрос в том, почему их вообще четыре.

Сбор токенов позволяет:

• увидеть распределение значений;
• выявить кластеры;
• принять управленческое решение: 8-pt grid, 4-pt grid или другая модель.

3. Типографический дрейф

В одном корпоративном портале:

• 11 размеров шрифта
• 7 line-height
• 5 font-weight для body-текста

После агрегации токенов стало очевидно, что реально используются 3 типографических роли, всё остальное — шум.

Как выглядит сбор CSS-токенов технически

На уровне механики всё достаточно прямолинейно:

1. Загружаем страницу.
2. Собираем все CSS-файлы (inline + external).
3. Парсим декларации.
4. Агрегируем значения по типам:

• colors
• font-size
• spacing
• border-radius

5. Считаем частотность.

Пример результата в JSON:

{
    "colors": {
        "#005bff": 143,
        "#ffffff": 98,
        "#f5f7fa": 34
    },
    "spacing": {
        "8px": 76,
        "16px": 112,
        "24px": 41
    }
}

Это уже материал для решений, а не субъективных споров.

Почему ручной подход не масштабируется

На ранней стадии проекта можно «договориться словами». На стадии:

• 5+ разработчиков;
• параллельных фич-веток;
• нескольких дизайн-источников

договорённости перестают работать.

Без автоматического сбора токенов вы:

• не видите реальную картину;
• не можете измерить эффект от рефакторинга;
• не контролируете регресс.

Реальный кейс: редизайн без остановки разработки

Компания с большим маркетинговым сайтом (~120 страниц):

До:

• 4000+ CSS-правил
• 32 цвета
• 19 размеров шрифта

Шаги:

1. Собрали токены со всех ключевых страниц.
2. Отсортировали по частотности.
3. Зафиксировали «ядро» токенов.
4. Начали миграцию без фулл-переписывания.

После:

• 9 базовых цветов
• 6 типографических токенов
• −18% CSS-объёма
• меньше визуальных регрессов при A/B тестах

Где здесь ценность для performance

CSS-токены — это не только про дизайн:

• меньше уникальных значений → лучше gzip/brotli
• выше CSS coverage
• меньше каскадных конфликтов
• проще critical CSS

На крупных страницах это даёт реальные миллисекунды.

Почему мы смотрим на это как на аудит

В milten.io сбор CSS-токенов — это:

• диагностика, а не генерация «красивого отчёта»;
• способ увидеть систему там, где кажется, что её нет;
• входная точка для стандартизации, design system и масштабирования фронтенда.

Если токены невозможно формализовать — значит, система отсутствует.

Если упростить до управленческой логики:

• CSS без токенов = неконтролируемый актив
• сбор токенов = инвентаризация
• частотность = приоритеты
• автоматизация = масштаб

Игнорировать это можно. Но тогда каждый редизайн будет начинаться с фразы: «Давайте просто аккуратно подправим стили» — и заканчиваться очередным слоем хаоса.

Если вы хотите увидеть, какие CSS-токены реально живут на вашем проекте, а не «должны бы» — это как раз тот случай, когда аудит даёт быстрый и измеримый эффект._