<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>设计系统性能优化 | 锤子前端</title><description>Now vibe coding, so learning hammer FE ?</description><link>https://channel.meo-ai.com</link><item><title>《设计系统应该默认就是快的》</title><link>https://channel.meo-ai.com/posts/730</link><guid isPermaLink="true">https://channel.meo-ai.com/posts/730</guid><pubDate>Thu, 29 Oct 2026 09:14:04 GMT</pubDate><content:encoded>&lt;span class=&quot;post-title-source&quot;&gt;《设计系统应该默认就是快的》&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;标签：&lt;br /&gt;&lt;a href=&quot;/search/result?q=%23%E5%89%8D%E7%AB%AF%E5%BC%80%E5%8F%91&quot; title=&quot;#前端开发&quot;&gt;#前端开发&lt;/a&gt; &lt;a href=&quot;/search/result?q=%23%E8%AE%BE%E8%AE%A1%E7%B3%BB%E7%BB%9F%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96&quot; title=&quot;#设计系统性能优化&quot;&gt;#设计系统性能优化&lt;/a&gt; &lt;a href=&quot;/search/result?q=%23%E6%80%A7%E8%83%BD%E6%B5%8B%E8%AF%95&quot; title=&quot;#性能测试&quot;&gt;#性能测试&lt;/a&gt; &lt;a href=&quot;/search/result?q=%23%E6%80%A7%E8%83%BD%E9%A2%84%E7%AE%97&quot; title=&quot;#性能预算&quot;&gt;#性能预算&lt;/a&gt; &lt;a href=&quot;/search/result?q=%23WebComponents&quot; title=&quot;#WebComponents&quot;&gt;#WebComponents&lt;/a&gt; &lt;a href=&quot;/search/result?q=%23%E7%BB%84%E4%BB%B6%E6%B8%B2%E6%9F%93%E4%BC%98%E5%8C%96&quot; title=&quot;#组件渲染优化&quot;&gt;#组件渲染优化&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;总结：&lt;br /&gt;这篇文章通过实测十大主流开源设计系统（Mantine、Ant Design、Material UI、React Spectrum、Carbon、Fluent、Web Awesome、UI5、Spectrum Web Components、Ionic），论证了性能应当与设计系统团队所重视的可达性（accessibility）平起平坐：底层组件的每一个性能修复，都会同时惠及所有基于该设计系统构建的应用。测试发现性能优劣并不取决于框架本身，而在于具体实现细节，作者还深入剖析了 Ionic、Ant Design、UI5、React Spectrum 等慢速组件的根因，并给出了可行的修复建议，最后提供了基于 Playwright 的自动化性能测试方案与「Fast by Default（默认即快）」的理念。&lt;br /&gt;&lt;br /&gt;文章要点：&lt;br /&gt;1. 浏览器的 JavaScript 主线程是所有层共用的，设计系统组件越慢，留给应用代码的余地就越小——修复一个设计系统组件的性能，等于同时提升所有依赖它的应用。&lt;br /&gt;2. 作者选取了十个基于不同框架（React、Lit、FAST、Stencil、SAP 自研框架）的设计系统，在 4 倍 CPU 降速、Chrome 155 环境下实测了两大典型场景：打开含 249 个国家的下拉选择器、一次性全选 100 个复选框。&lt;br /&gt;3. 实测结果差异巨大：国家选择器从最快 Fluent 的 61ms 到最慢 Ionic 的 1,266ms（比第二名慢 5 倍以上）；复选框从 Fluent 的 29ms 到 Ant Design 的 421ms——同一框架（如 React 或 Lit）内部差距同样悬殊，性能问题出在实现而非框架。&lt;br /&gt;4. 十个设计系统中只有 Spectrum Web Components 在每个 PR 上自动跑组件级性能基准，多数团队只检查包体积——但包体积与组件在页面上的响应速度并无直接关系。&lt;br /&gt;5. 作者逐一剖析了慢速根因：Ionic 因 Stencil 在无 shadow DOM 的场景下用 &lt;code&gt;appendChildSlotFix&lt;/code&gt; 模拟插槽、每次新增选项都要遍历全部既有子节点三次（O(n²)）；React Spectrum 因 React Aria 逐个清空高度再读取尺寸造成「布局抖动」；UI5 因隐藏弹层中预置全部 249 个选项，打开瞬间浏览器要一次性完成约 1500 个元素的样式计算；Ant Design 的慢则主要来自 100 个复选框同时触发的颜色渐变动画。&lt;br /&gt;6. 性能瓶颈各有解法：长列表用虚拟滚动（Ant Design 的做法值得借鉴，还为屏幕阅读器保留了高亮项的隐藏副本）；动画改由合成器线程运行的 opacity 渐变替代主线程上的颜色渐变；Stencil 可直接修复插槽回退内容的第三次检查，作者实测去掉后加 2000 个元素快约 7 倍。&lt;br /&gt;7. 作者分享了用 Playwright + Chrome DevTools 协议（CPU 降速 4 倍 + Long Animation Frames 长帧 API）编写组件性能测试的完整代码，包含「总耗时预算 300ms」和「最长无响应帧不超过 100ms」两条性能预算（performance budget），以及一条「选项翻倍时耗时增长不超过 2.5 倍」的防 O(n²) 回归测试。&lt;br /&gt;8. 落地的最佳实践是「默认就提供快的行为」：超过性能预算的列表自动切换虚拟化、复选框仅在被直接点击时才播放动画，并在文档中写明每个组件的测试数据规模上限，发布说明中给出修复前后的量化数据（如「500 个选项下打开从 300ms 降到 150ms」）。&lt;br /&gt;9. 以上测试代码已开源在 GitHub 仓库 design-system-performance-tests 中，可直接复制改造用于自己的设计系统，并附带 GitHub Actions 工作流实现每个 PR 自动跑性能测试。&lt;br /&gt;10. 文章结尾宣传了作者的新书《Fast by Default: Practical Performance Engineering》（Manning 早期访问版），把这套思路延伸到后端与移动端。&lt;br /&gt;&lt;br /&gt;URL：&lt;a href=&quot;https://denodell.com/blog/design-systems-should-be-fast-by-default&quot; target=&quot;_blank&quot; rel=&quot;noopener&quot; title=&quot;https://denodell.com/blog/design-systems-should-be-fast-by-default&quot;&gt;https://denodell.com/blog/design-systems-should-be-fast-by-default&lt;/a&gt;&lt;a class=&quot;tgme_widget_message_link_preview&quot; href=&quot;https://denodell.com/blog/design-systems-should-be-fast-by-default&quot; target=&quot;_blank&quot; rel=&quot;noopener&quot; title=&quot;If a design system’s components are slow to interact with, so are any apps built with it. I timed large dropdowns and checkbox lists in some popular design systems, worked out how to make the slow ones faster, and wrote tests that fail when they’re too slow.&quot;&gt;
  
  &lt;div class=&quot;link_preview_site_name accent_color&quot;&gt;Den Odell&lt;/div&gt;
  &lt;img class=&quot;link_preview_image&quot; alt=&quot;Design Systems Should Be Fast by Default&quot; src=&quot;/static/https://cdn4.telesco.pe/file/prwDcUJjanfw3iDWSDKbwkdZNnwMgqXd8jse5-sGrIQFZEQ-bM__2cCdCrCKuuMxJn8qbhJIz27feWIXXSJ4RzrlsYlA0KbHp-HDqYfd-XCo_hd1SFHnRsM0VKHnl6faIKdO3Ga2GjMP5NPqFysbIFdTXxI4IQ8sbshAgYrFsSX8KuwMxYAFyVjPKL7AMRowWXal7pJwDx3cCUyRUqdEyPKWxsgr5-_k1pGbKifxUOOqggDzd_sFGafjxxdFuTkkb3JRwMGQhTANx-8Mlia_Qqw7mYYIoG7WpJLcJT2ZKFKG6vPWDSvUSsh84ousi-MwLEF8zrTeP8bDLgBQ0p6tXQ.jpg&quot; width=&quot;1200&quot; height=&quot;630&quot; loading=&quot;eager&quot; /&gt;
  &lt;div class=&quot;link_preview_title&quot;&gt;Design Systems Should Be Fast by Default&lt;/div&gt;
  &lt;div class=&quot;link_preview_description&quot;&gt;If a design system’s components are slow to interact with, so are any apps built with it. I timed large dropdowns and checkbox lists in some popular design systems, worked out how to make the slow ones faster, and wrote tests that fail when they’re too slow.&lt;/div&gt;
&lt;/a&gt;</content:encoded></item></channel></rss>