如何分析emotion/css-in-js在自有业务应用中的实际性能损耗

1. 基于浏览器Performance API的定向打点统计 #

你可以在不改动Emotion源码的前提下，通过轻量的包裹逻辑实现精准耗时统计：

• 对项目中引入的css方法、styled组件渲染逻辑做外层封装，执行前调用performance.mark('emotion-exec-start')做标记，执行结束后调用performance.mark('emotion-exec-end')，再通过performance.measure()即可计算单次执行的耗时
• 如果你的项目用到了SSR，还可以单独标记服务端样式注入、客户端hydrate阶段的样式解析耗时，覆盖全场景的开销统计
  所有标记的耗时可以直接在Performance面板的Timings分类下查看，也可以批量上报到内部性能监控平台统计线上用户的整体耗时分布。

2. Performance面板原生筛选统计方案 #

无需修改代码即可快速得到统计结果：

• 打开Chrome DevTools的Performance面板，勾选「JavaScript」选项后录制你要测试的典型业务操作路径，比如页面首次加载、弹窗打开、长列表滚动这类高频交互
• 录制结束后在下方调用栈的搜索框输入@emotion或者你项目里引入的Emotion包名，就能过滤出所有Emotion相关的函数执行耗时，这些耗时的总和就是该操作下CSS-in-JS的直接运行时开销
• 如果要统计样式注入带来的间接渲染开销，可以对比样式静态化前后的Layout、Paint阶段耗时差值，即可得到CSS-in-JS带来的额外重排重绘成本。

3. 业务场景对照测试方案 #

可以拿到最贴合实际业务的影响程度数据：

• 选取一个业务典型页面，在测试环境通过打包工具别名功能，临时把Emotion的styled组件替换为绑定静态class的原生元素，或者替换为零运行时的CSS-in-JS方案
• 分别在两个版本下统计页面的LCP、FID、交互响应耗时等核心性能指标，两组数据的差值就是Emotion在该业务场景下的实际性能影响
• 建议同时覆盖中低端机型、弱网场景的测试，这类环境下CSS-in-JS的运行时开销会比高端机环境下明显很多，更能暴露潜在的性能问题。

内容的提问来源于stack exchange，提问作者Oliver Ullman