280KB CSS в бандле: почему это мертвый груз

hannadev

Допустим, ты открыл DevTools, глянул на размер CSS-бандла и офигел: 280 килобайт. При том, что в проде используется максимум половина селекторов. Звучит знакомо? Это не редкость — это норма для легаси-проектов и фреймворков, которые тащат за собой целый шкаф стилей “на всякий случай”.

Вопрос не в том, нужна ли оптимизация. Вопрос в том, почему мы до сих пор возим с собой такой балласт. Давай разберём, как этот груз влияет на реальную производительность и что с этим делать.

Когда 280KB перестают быть просто числом

Люди часто думают: ну, 280 килобайт — это же не мегабайт, какие проблемы? На десктопе с широким каналом действительно может быть не страшно. Но спустись с облаков: мобильное устройство, 4G, потерянные пакеты, задержки в сети — и вот уже парсинг CSS жрёт 800 миллисекунд процессорного времени.

Чем больше CSS-файл, тем дольше браузер его парсит и применяет стили. Это не просто увеличивает время загрузки страницы — это блокирует рендеринг. CSSOM (объектная модель CSS) строится медленнее, флоу и макет пересчитываются дольше, First Contentful Paint смещается вправо на графике. Юзер смотрит на белый экран, пока браузер разбирается с твоим раздутым бандлом.

Главная ловушка: неиспользуемый CSS занимает место в бандле, но браузер не знает, какие селекторы понадобятся — поэтому парсит всё. Результат: ненужные стили замораживают рендеринг.

Каждый килобайт CSS = время парсинга и применения стилей
На мобильном оборудовании эффект усиливается в 2-3 раза
Неиспользуемые селекторы замораживают рендеринг, даже если они никогда не применятся

Откуда берётся этот мертвый груз

Обычно всё начинается невинно: подключил UI-фреймворк, забыл удалить исходники старого дизайна, накопилось несколько переписанных компонентов. За полгода продакшена это растёт, как ком снега. Потом приходит новый девелопер, видит готовый CSS, копирует куски в свою фичу — и вот уже 280 килобайт.

Критическая ошибка — не проверять, что реально используется. Никто не ходит по всему коду и не ищет мёртвый CSS: лень, время, приоритеты. CSS не вызовет ошибку, если он не используется — просто будет сидеть в бандле и ничего не делать.

Типичные источники раздутого CSS:

Полный импорт фреймворков (Bootstrap, Tailwind в режиме development) без tree-shaking
Морозный код от старых версий компонентов
Копипаста стилей из других проектов без адаптации
Экспериментальные медиа-запросы и селекторы, которые потом забыли удалить
Множественные переопределения одних и тех же свойств

Инструменты для поиска и удаления мусора

Хорошая новость: это реально найти и убрать. Плохая: нужно быть внимательным и не сломать при этом ничего.

Существуют инструменты, которые анализируют используемые селекторы и помечают orphan-CSS. PurgeCSS и аналоги сканируют твой HTML, JS и помечают селекторы, которые ни разу не встретились в коде. Звучит просто, но есть трюки: динамические классы, которые генерируются в runtime, инструменты могут не увидеть. Поэтому любой автоматический анализ нужно перепроверять вручную.

Реальный процесс очистки:

Запусти PurgeCSS или аналог (PostCSS purge, cssnano) и посмотри, что он найдёт
Включи в конфиг всех твоих компонентов и динамические паттерны (например, btn-* для утилит)
Минифицируй результат через cssnano или swc
Добавь тесты: убедись, что ничего не сломалось визуально
Повтори через месяц-два: код растёт, новый мусор накапливается

Использование автоматического tree-shaking при импорте CSS — это не фишка, а обязательное условие. Если ты подключаешь стили через модули (CSS-in-JS, SCSS imports), убедись, что бандлер именно tree-shakит неиспользуемые селекторы. Иначе весь фреймворк поедет в prod.

Инструмент	Что делает	Подходит для
PurgeCSS	Анализирует код, ищет orphan-селекторы	Любых проектов с чистой HTML-структурой
cssnano	Минифицирует и объединяет CSS	Финальной оптимизации на уровне PostCSS
Tailwind purge	Встроенная очистка неиспользуемых утилит	Проектов на Tailwind CSS
Chrome DevTools Coverage	Показывает неиспользуемый код прямо в браузере	Анализа и отладки

Что реально экономит: caching, splitting, loading

Когда 280 килобайт уже в бандле, оптимизация CSS переходит на второй уровень: как быстро его загрузить и примени**.** Здесь работают старые, проверенные методы.

Сервер-сайд кэширование CSS-файлов с правильными заголовками (Cache-Control: max-age) экономит тысячи повторных загрузок. Версионирование через хеши в имени файла гарантирует, что обновление пойдёт только при изменении. Это база — но часто забывают настроить правильно.

Разбиение CSS на несколько файлов — не волшебство, но работает: critical CSS (стили выше сгиба) инлайнится в HTML, остальное загружается асинхронно. Медиа-запросы для мобильных устройств можно загружать условно, они не блокируют рендеринг на десктопе.

Практические шаги:

Выдели critical CSS (стили для видимой части страницы) и закинь их в <style> в <head>
Остальной CSS загружай через <link rel="preload"> с атрибутом media для условной загрузки
Минифицируй каждый файл отдельно, используй Gzip или Brotli на сервере
Убедись, что Cache-Control установлены правильно: заголовки не нужно переусложнять
Посмотри LCP (Largest Contentful Paint) в Core Web Vitals — если блокируется на CSS, это виднов

Над чем стоит подумать

Чистка CSS — это не одноразовая акция, а процесс. Если ты просто удалил мусор и забыл про это, через полгода история повторится. Нужна система: регулярные проверки в CI, тесты на регрессию (visual regression testing), возможно, даже бюджет на размер бандла.

И да, иногда 280 килобайт CSS — это следствие более глубокой проблемы: неправильная архитектура компонентов, отсутствие компонентной системы или просто небрежность. Оптимизация CSS — это симптом. Лечить нужно диагноз.

Посмотри на свой проект честно: может, проще переписать стили для реальных нужд, чем таскать легаси? Иногда это быстрее, чем отлавливать phantom-CSS по всему коду.