Что произошло

Представьте общий лифт в офисе. Команды продуктов отделывают свои этажи, но если кабина долго открывает двери, никакой полировкой этажа это не спасти. Дизайн-система — как раз такая кабина: любой экран поверх неё наследует её задержки.

Odell взял десять активно развивающихся библиотек октября 2026: среди React — Mantine, Ant Design, Material UI, React Spectrum; рядом — веб-компоненты на Lit, FAST, Stencil (Ionic) и другие. Замер: сколько главный поток занят после клика (медиана из трёх прогонов), плюс самый длинный простой интерфейса. Бюджет отзывчивости он положил рядом с доступностью: 100 мс.

Открытие списка стран на CPU×4 (от быстрых к медленным по React Status и статье):

Fluent и Carbon открывались ещё быстрее (~60 мс). Тот же Ionic, который «убил» список, на 100 флажках оказался быстрым — а MUI уложился в 70 мс против 421 мс у Ant Design. Фреймворк сам по себе результат не решил: два Lit-набора разошлись вдвое, один и тот же стек мог быть медленным в одном сценарии и приемлемым в другом.

У Spectrum список виртуализирован, но время почти не падало при половине опций. В профиле сверху — checkVisibility из React Aria: для каждой видимой опции сброс высоты и чтение размера → пересчёт вёрстки снова и снова. Odell предложил сначала сбросить высоты, потом один раз измерить; замечание открыто, правка на проверке.

В том же выпуске коротко: TanStack Redact — более лёгкая подмена React/React DOM в браузере со синхронным рендером без нарезки времени; TanStack DB 1.0 (кандидат RC1) — стабильный по API клиентский слой данных с руководством по переходу. Это фон недели; главная тема — стенд по дизайн-системам.

Почему это важно

Команды продуктов часто чувствуют «тормозит форма», но чинить общий Select из чужого пакета почти нельзя. Размер бандла в непрерывной интеграции ловят чаще, чем реакцию на клик — а пользователь ждёт именно клик. Odell прямо ставит производительность рядом с доступностью в приоритетах команды дизайн-системы.

Цифры полезны как карта рисков, не как рейтинг «кто хуже». MUI медленнее открывает длинный список (рисует все ~250 узлов), зато быстрее массово отмечает флажки. Ant Design быстрее открывается за счёт виртуализации, но дороже на анимациях флажков. Выбор библиотеки без сценария нагрузки — как выбор лифта по цвету кабины.

Разбор Spectrum показывает: узкое место может сидеть не в «React медленный», а в конкретном цикле измерений в общей библиотеке доступности. Одно замечание в React Aria чинит класс приложений сразу: как ремонт мотора кабины для всего здания.

На практике

Стенд чужой — ориентир. Повторяемый тест на своих компонентах важнее чужой таблицы.

1. Возьмите репозиторий denodell/design-system-performance-tests на GitHub и прогоните Playwright на своём Select / списке флажков с CPU×4.
2. Зафиксируйте порог: открытие длинного списка и массовое действие не должны держать главный поток дольше 100 мс без явного решения команды.
3. В профиле Chrome смотрите не только исполнение скриптов, но и расчёт стилей с вёрсткой: серии чтений размеров после записи стилей — классический пересчёт макета.
4. Длинные списки — виртуализация и доступность (скрытая копия выделенной опции, как у Ant Design), а не только «нарезать DOM».
5. Не сводите «производительность дизайн-системы» к размеру бандла: отдельно ловите время до интерактивности после клика.
6. Перед сменой MUI ↔ Ant Design ↔ Mantine прогоните оба сценария на своих данных — таблицы Odell показывают, что победитель зависит от задачи.
7. Если тянете Spectrum / React Aria, следите за замечанием про измерения опций; не копируйте тот же цикл в свой код.

Итог

Дизайн-система под реальной нагрузкой ведёт себя как общий лифт: тормоза кабины чувствует каждый этаж. Стенд Odell на CPU×4 показывает разброс от десятков до тысяч миллисекунд и конкретный баг измерений в React Aria — с тестами, которые можно повесить на свой код.

В React Status #495 рядом мелькают Redact и TanStack DB (кандидат RC1), но для фронтенда недели главный урок простой: меряйте клик, а не только килобайты.