devgo.cn你有一个高流量的结账页面，每次渲染都要先拉回 100KB 以上的 JavaScript，多等几百毫秒，用户可能就流失了。Shopify 的 Checkout Blocks 正是这样的场景：它运行在约三分之一的自定义结账页面上，过去用 React 加一套叫 Remote UI 的桥接机制，把扩展代码打包成 100KB 到 112KB 的 gzip 文件，加载慢、体积臃肿。最近 Shopify 公开了如何把这五个高频 UI 扩展整体重写为 Preact + Polaris Web Components，让体积直接缩水 40% 到 85%，其中 payment-icons（支付图标）扩展更是砍掉了 84.4%，加载时间中位数下降约 8%。
这件事为什么值得关注？因为 Shopify 的迁移不是个案，而是整个 UI 扩展体系正在转向“框架无关”的组件。以前开发者写一个结账页面的小部件，必须依赖 React 和那一套 Remote UI 桥（专门用来把扩展代码安全地嵌进宿主页面的通信层），现在他们改用 Web Components——浏览器原生支持的自定义元素，无论你底层用什么框架，渲染出的 UI 都长一样。关键推手是一个硬性预算：2026-01 版本的 remote-dom CLI 强制每个扩展 gzip 后不得超过 64KB，过去动辄 100KB 以上的包必须瘦身。
具体怎么瘦？最狠的一刀是换框架。React 本身带一个 reconciliation 机制（负责计算 UI 更新的算法），加上配套的 react-reconciler，光这块就占了约 89KB。换成 Preact（一个只有约 3KB 的 React 兼容库，API 几乎一样但实现轻量），这 89KB 直接消失。然后是模板引擎：原来用 liquidjs（Liquid 模板语言的 JS 实现，约 73KB），Shopify 团队自己写了一个叫 droplet 的解析器，只有 13KB gzipped。为了不踩坑，他们拿真实商户配置中的 42000 行 Liquid 模板做了一致性测试语料，确保渲染结果与旧版完全一致。日期库 dayjs 也被换成一个自定义小工具，而 markdown-to-jsx 则保留下来并 aliased 到 Preact 上。
如果你自己也要做类似迁移，Shopify 贴出了升级指南和 AI 工具包，重点在于：大多数旧的 Polaris React 组件会直接变成框架无关的 s-* 自定义元素，从 Shopify 的 CDN 加载。这就引出了一个新的工程权衡——新组件不再跟随应用版本发布，而是由 CDN 统一控制，好处是修复立即生效，坏处是你没法锁版本。
这次迁移最早在 2025 年 10 月的 API 版本里亮相，当时开发者普遍叫好。开发平台 Gadget 评价说“Preact 提供了一个 React 般的体验，但运行时开销小得多”；Hacker News 上很多人欢迎 Shopify 不再使用 Shadow DOM（一种隔离样式的浏览器技术，但会导致样式难以穿透），不过也有人冷静提醒：Web Components 不是银弹，不会取代框架的组件系统。
到 2026 年初，随着 2026-01 版本成为强制路径（今年 10 月 1 日起，任何低于该版本的扩展部署都会被阻断），争议开始出现。有人反馈：CDN 脚本没有版本号，无法固定到某个具体版本，对稳定性是噩梦；还有人指出新组件缺少一些 Polaris React 里的能力，比如 Index Table（索引表格组件），说功能“不完整”。这些声音到 2026 年年中还在社区里发酵。
对我们这些做前端或后端但没深入过电商基建的人来说，这个案例的启发很直接：体积预算往往是重构的最大杠杆。Shopify 用 64KB gzip 这条硬线倒逼团队重新审视每一个依赖，结果发现很多重量级库其实可以被轻量实现或自研小程序替代，而且只要用足够的真实数据做对比测试，替换的风险是可控的。另一个点是“框架无关”的长期价值：当你把 UI 组件从某个具体框架里解放出来，后续的迁移成本会显著下降，但代价是失去了版本锁定和部分高级组件能力。这是一笔值得每个团队在架构评审时仔细权衡的账。
内容与图片版权归原作者所有 · 原文: https://www.infoq.com/news/2026/10/shopify-web-components/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global