Почему Tailwind раздувает бандл на 40%: реальный рефакторинг

hannadev

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

Появляется соблазн накинуть PurgeCSS и считать проблему решённой. Но это половинчатое решение. Нужно понять, откуда вообще берётся этот раздутый бандл и как его предотвратить изначально.

Откуда растут ноги проблемы

Тailwind работает просто: он сканирует исходный код, ищет классы и генерирует CSS только для найденных комбинаций. Звучит идеально, но на практике происходит вот что. Если твой конфиг включает плагины, которые добавляют готовые компоненты и утилиты, то CSS генерируется для всех них — независимо от того, используешь ты их или нет.

Официальные плагины Tailwind оптимизированы и занимают всего 2-4 килобайта. Но если ты подключил пять плагинов от разных авторов, каждый добавляет свой оверхед. К этому добавляются кастомные темы, расширенные цветовые палитры, кастомные брейкпоинты. Результат — бандл, который мог бы быть стройным, вырастает в неконтролируемый монстр.

Вторая граблей — неправильная конфигурация paths для сканирования. Если в tailwind.config.js указано слишком широко (например, сканируется вся папка node_modules), Tailwind начинает искать классы везде, включая код зависимостей. Вот откуда в бандле появляются утилиты, которые никогда не видел в проекте.

Плагины: враги за дружественным интерфейсом

Когда ты используешь стартовый шаблон или copypaste конфиг с Githib, там часто предустановлены плагины. Список выглядит красиво: есть плагин для форм, для типографики, для сетки. Казалось бы, почему бы их не оставить? Ответ: каждый плагин генерирует CSS, даже если ты его не юзаешь.

Представь ситуацию: ты скопировал конфиг с плагином @tailwindcss/forms. На твоём сайте нет форм, но плагин всё равно добавит стили для всех возможных input элементов. Минус 15-20 килобайт на пустом месте. Умножь это на три-четыре плагина, и получишь заметное вздутие.

Смотрите, какие плагины реально нужны в вашем проекте:

@tailwindcss/forms - подключай только если активно используешь input, textarea, select
@tailwindcss/typography - нужен для оформления статей и контента с классом prose
@tailwindcss/container-queries - актуален только если работаешь с container queries
Кастомные плагины от сообщества - проверяй их размер и функционал перед подключением

Правило простое: отключи плагины по умолчанию, подключай только те, что используешь. Если со временем понадобится новый функционал, добавишь его. Лучше разрастись плавно, чем карать бандл от начала.

Конфиг как причина лишних стилей

Тайвинд генерирует утилиты на основе конфига. Если в теме определено 50 цветов вместо базовых 10, будет сгенерировано 50 вариантов для каждой утилиты. Это не мелочь. Вот где срезать можно:

Первое - цветовая палитра. Стандартная палитра Tailwind уже покрывает 99% потребностей. Если добавляешь кастомные цвета, добавляй только те, что реально используются в дизайне. Не копируй всю палитру из Figma - возьми только нужные оттенки.

Второе - размеры и расстояния. Дефолтные scale-значения (8px, 16px, 32px, 64px и так далее) работают отлично. Если расширяешь, делай это целенаправленно, а не добавляй значения “на всякий случай”.

Третье - брейкпоинты. Нужны ли тебе брейкпоинты для каждого размера экрана? Нет. Обычно хватает трёх-четырёх: мобила, планшет, десктоп, большой десктоп. Каждый брейкпоинт множит количество генерируемых утилит.

Потенциальные места утечки в конфиге:

Палитра цветов со 100+ вариантами вместо 10-15 базовых
Брейкпоинты для каждого размера устройства вместо необходимого минимума
Расширенные размеры шрифтов, которые используются в одном месте
Кастомные утилиты, определённые через addUtilities без нужной функциональности
Вариация стилей для каждого возможного состояния (hover, focus, active, group-hover и так далее)

Минификация и сжатие: финальный слой защиты

Если конфиг уже настроен, а бандл всё ещё выглядит пухлым, включай инструменты минификации. Tailwind рекомендует cssnano для уменьшения размера. С флагом --minify размер падает на 10-20 процентов сверху.

Большая картина выглядит так: сначала Tailwind генерирует только нужные классы (это его основная фишка). Потом минификатор сжимает CSS, убирая пробелы и переводы строк. Затем браузер сжимает передачу по сети через Brotli или gzip. Итог: вместо 50 килобайт едет 5-8 килобайт.

Этапы оптимизации бандла:

Отключи неиспользуемые плагины в конфиге
Ограничь цветовую палитру только реальными цветами дизайна
Сократи брейкпоинты до необходимого минимума
Укажи правильные paths для сканирования - не сканируй node_modules без необходимости
Включи минификацию через cssnano
Проверь, что используется PurgeCSS правильно - если вообще нужен (актуален для Tailwind v2 и старше)

Для production рекомендуется сжатие через Brotli. Эффективность компрессии резко растёт на CSS файлах.

Реальная архитектура: как структурировать проект

Не достаточно просто обрезать конфиг один раз. Нужно продумать архитектуру так, чтобы раздутия не происходило изначально. Это касается и самого CSS-кода, и способа его подключения.

Первое правило: разделяй Tailwind по смыслу, а не по размеру. Если проект большой, можно разбить CSS на несколько файлов - один для основного стиля, второй для компонентов, третий для кастомных утилит. Но это нужно только если проект действительно большой и управление одним файлом становится неудобным.

Второе: не генерируй утилиты для вариантов, которые не используются. Tailwind позволяет управлять модификаторами через конфиг. Если не нужен group-hover, отключи его. Если focus-within используется в трёх местах, может быть, проще написать эти стили вручную?

Третье: кэширование и versioning. Когда бандл оптимизирован, он становится стабильным. Это хороший момент для настройки кэша - браузер будет загружать его один раз, а потом использовать из памяти. Если изменяешь конфиг, добавь версию в имя файла.

Когда считают бандл оптимальным:

Production CSS для небольшого проекта: менее 15 килобайт (до сжатия)
Production CSS для крупного проекта: менее 50 килобайт (до сжатия)
После gzip/brotli: обычно 5-10 килобайт для небольшого, 15-25 для крупного

Если видишь бандл 100+ килобайт, значит, где-то остался мусор в конфиге.

Инструменты для анализа: видишь своих врагов

Не гадай вслепую - используй инструменты, чтобы понять, что реально раздувает бандл. Tailwind CLI позволяет проверить, какие утилиты генерируются для конкретного проекта. Можно запустить команду и увидеть полный список классов в выходном CSS.

Второй подход - поднять DevTools браузера, найти стилизацию конкретного элемента и проследить, откуда она едет. Если видишь классы, которые не используешь в коде - это сигнал, что конфиг или плагины добавляют лишнее.

Третий способ - профилирование бандла через webpack-bundle-analyzer или аналоги. Это даст визуальное представление, какие части занимают больше всего места. Для CSS работает похоже - можно увидеть доминирующие селекторы и утилиты.

Инструменты, которые помогают:

Tailwind CLI с флагом --minify - сразу видно итоговый размер
cssnano - минификатор для CSS, интегрируется в PostCSS
lighthouse - встроена в DevTools, показывает размеры ресурсов
npm run build --analyze - если используешь bundler с поддержкой анализа

Что остаётся за кадром

Проблема раздутого бандла часто говорит о более глубокой беде - о неправильном планировании архитектуры проекта. Tailwind сам по себе экономен, но если его ломать неправильно, он тоже выступает соучастником. Главное - настроить конфиг один раз, проверить размер бандла и потом просто жить спокойно. Не нужна религиозная позиция “вообще не буду расширять Tailwind”. Нужна позиция практичная: подключу только то, что использую, и буду мониторить размер при добавлении нового функционала.

kirilljsx

Нахрен вообще эти css фреймворки, я очень долго прям когда-то сидел на bootstrap, но понял что лучше писать css самому