1. 优化动力：
      本项目是单页面应用（SPA），SPA的优势在于一旦应用加载完成所有页面切换非常快、前端完成页面渲染逻辑与渲染合并的特性也在一定程度上减少了后端压力、实现了前后端分离，缺点在于首屏加载较慢、SEO问题。
      本项目SEO需求较弱，关键在于优化首屏加载较慢的问题，由于应用了较多的第三方插件诸如（tim、tcplayer、chatui、pinyin、captcha、jverification…）图标也较多，使得首屏加载较慢。

    2. 优化方案

    2.1 启用按需加载

    按需加载说明：部分组件体积太大，不适合直接计入 bundle 中，以免影响首屏加载速度。例如：某组件 HugeA 包含巨大的实现 / 依赖了巨大的三方库，且该组件 HugeA 的使用不在首屏显示范围内，可被单独拆出。这时候，dynamic 就该上场了。

    umi 支持按需加载，只需配置如下：
    export default {
    …
    dynamicImport: {},
    }

    可行性：🌟 🌟 🌟 🌟 🌟

    2.2 静态资源配置CDN

    服务器带宽有限，使用CDN能大大加快资源加载速度。

    需要将umi配置静态资源打包到非根目录，具体实现如下：

    export default {
    …
    publicPath: “http://yourcdn/path/to/static/“
    }
    另外需要Nginx和CDN服务的相关配置支持。

    可行性：🌟 🌟 🌟 🌟

    2.3 图片内存优化

    采用CDN的方式放在存储桶中可以处理问题，但存在后续迭代与维护成本变高问题，图片的增删改查都需要同步到存储桶，会比较麻烦。
    采用字体图标可以有效解决问题，但所有图标需要UI重新设计，前端也需要逐一处理、开发成本非常大，这里建议后续全新项目可以尝试采用该方案。

    好在umi会自动将小于10K的图片打包压缩成base64，真正在渲染到客户端浏览器时，图片内存会明显降低，优先级并不是特别高。

    可行性：🌟 🌟 🌟

    2.4 通讯录拼音插件数据占较多内存

    目前使用的是前端pinyin插件库，该插件占用内存较高，可以通过后端下发带拼音结构的数据解决，但不致命，优先级不高。

    可行性：🌟 🌟

    2.5 服务端渲染SSR

    点击查看详情

    可行性：🌟 🌟

    总结

    现阶段可优先使用2.1方案，未来用户量达到一定级别的时候可就其余方案进行更深度的优化。