umi应用首屏加载速度提高3倍+（通用性能优化）
根据以往的博客,目前我就司的公司前端框架umi[1], ali出品以路由为基础的，同时支持配置式路由和约定式路由，保证路由的功能完备，并以此进行功能扩展的前端应用框架。
问题所在
一直以来我们网站的首页加载速度很慢,虽然使用了umi但是我们没有使用ssr依旧使用的是spa.首屏加载速度在6s左右, 当我们看network分析为什么加载速度为什么这么慢，看到一些静态资源umi[hash].js占据的内存是3.5M,响应速度超过了6s,这只是单纯的一个js文件更何况是一个spa首屏加载的文件本身来说就很多。
初步思考
期间我想了很多首页加载更快的方法, 比如:
- 抽组件
- 压缩图片, 为此我还写了一个node应用前端项目组图片管理[2]
- 还有一些网上的压缩速度,比如拆分文件使用更小的插件库
深入研究
最近在好好研究加载速度的问题，重新梳理network的请求体,发现最占据带宽的就是几个静态文件,通过Response Header看得出来我们服务器上面是通过nginx启动 按照道理我们使用了nginx应该是有着负载均衡的,我相信使用过umi-cli或者是任意的cli的同学应该都会看到打包在服务器上面响应静态资源都很大
仔细分析了看了下请求头部信息
Request Headers
Accept - Encoding: gzip, deflate
复制代码
一直是知道gzip压缩这个概念，但是我只在我们这个网络请求req里面看到了gzip，并没有在res内容看到，由于服务器的部署一直不在前端手上，也不好直接说后端或者运维的同学。
我打开了百度对, 比了下百度的响应
Response Headers
Accept - Encoding: gzip, deflate
server: JSP3/2.0.14
Request Headers
accept-encoding: gzip, deflate, br
复制代码
由此立马判断出来是服务端的同学没有使用nginx做负载均衡，对静态资源做压缩,然后去网上搜了下关于nginx 和 gzip的知识。这类文章很多，同学可以自行google。
解决问题
庆幸本人的权限够大，先是拿到了测试服务器按照网站的提示开启gzip
最后我们的Nginx.conf的配置如下
server {
gzip on;
gzip_buffers 32 4 K;
gzip_comp_level 6;
gzip_min_length 100;
gzip_types application/javascript
text/javascript text/css text/xml;
gzip_disable "MSIE [1-6]\.";
#配置禁用gzip条件, 支持正则. 此处表示ie6及以下不启用gzip（ 因为ie低版本不支持）
gzip_vary on;
}
复制代码
Tips 很多配置的gzip_types会少_application/javascript_，但是实打实你会发现网络请求中大部分的js文件请求如下：
Content-Type: application/javascript
复制代码
这个很重要,毕竟都2021年了.
配置完成以后,记得重启nginx,当我们在回过头再来看整个network请求,之前占据最大内存的umi[hash].js等在size里面大小缩小了近4倍,整体响应的速度快了3倍+,这个数字真的已经可以说基本上算很快的响应速度。
总结
对于前端来说,客户端的性能优化是前端一直追求的目标，那种秒开得到的喜悦。
关于性能优化，个人感慨要有针对性的性能优化，比如首屏速度/压缩文件/整合资源，要学会观察请求响应 - 分析 - 解决问题。
来源：pro-xiaoy
https://juejin.cn/post/6964352706832302117