Material UI：Icon组件与@material-ui/icons包的性能、包体积差异

项目打包体积层面的差异 #

• @material-ui/core内置<Icon />组件方案
  打包阶段只会纳入<Icon />组件本身的JS/CSS逻辑：如果你的项目本来就已经在用@material-ui/core的其他组件，这个图标组件几乎不会带来额外的体积负担；但如果为了只用图标功能单独安装@material-ui/core，哪怕开了tree-shaking，<Icon />依赖的基础样式工具、主题注入逻辑也会额外增加数KB到十几KB的打包体积。
  这个方案用到的Material Icons字体文件走公网CDN加载，完全不占项目本身的打包体积。
• @material-ui/icons独立图标包方案
  这个包里的每个图标都是单独封装的React SVG组件，只要构建时正确配置了tree-shaking，没在代码里引用的图标根本不会被打进产物，实际打包体积和你引入的图标数量直接挂钩——单个图标的SVG代码压缩完通常不到1KB，只引个位数图标时总体积非常小。
  要注意的常见坑：如果构建配置没做好tree-shaking，直接把整个图标包全局引进来，会把几千个没用的图标全打进产物，光这部分就能多出来数MB的体积，上线前一定要检查。

页面运行时加载性能的差异 #

• @material-ui/core内置<Icon />组件方案
  这种方式必须加载完整的Material Icons字体包才能正常渲染图标：哪怕你页面上只放了1个星星图标，也得把包含近千个图标的完整字体资源（WOFF2格式下大概40~60KB）下完才能正常显示，还会额外多一次字体CSS请求、一次字体资源请求。
  受字体加载机制影响，还容易出现图标延迟渲染、没加载完时留个空白块的问题，如果CDN响应慢，图标的视觉露出时间会被拉得很长。反过来如果你的页面要用到几十上百个图标，这种方式只要字体加载完，后面所有图标都不需要额外发请求，DOM节点的渲染开销也更低。
• @material-ui/icons独立图标包方案
  这种方式没有全局字体、全局CSS的额外网络请求，所有用到的SVG图标代码都会和业务JS代码一起打包，还能配合路由级代码分割做懒加载——用户没访问到的页面对应的图标，根本不会被下载。
  图标渲染完全不依赖外部字体资源，只要对应模块的JS加载完，图标立刻就能显示，不会有字体加载导致的延迟闪烁、空白占位问题，也不存在跨域字体渲染的兼容问题。反过来如果页面要加载的图标特别多，内联SVG的总体积会超过完整字体包的大小，反而拖慢首屏加载速度。

实际选型根本不需要纠结：数下项目里总共用到的图标数量，如果不到20个，独立SVG组件方案的打包、加载体积优势非常明显；如果用到的图标超过50个，全局字体引入的方案总体积会更低。

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