Що сталося

Уявіть спільний ліфт в офісі. Команди продуктів оздоблюють свої поверхи, але якщо кабіна довго відчиняє двері, жодна поліровка поверху цього не врятує. Дизайн-система — саме така кабіна: будь-який екран поверх неї успадковує її затримки.

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), але для фронтенду тижня головний урок простий: міряйте клік, а не лише кілобайти.