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倍+,这个数字真的已经可以说基本上算很快的响应速度。

总结

对于前端来说,客户端的性能优化是前端一直追求的目标，那种秒开得到的喜悦。

关于性能优化，个人感慨要有针对性的性能优化，比如首屏速度/压缩文件/整合资源，要学会观察请求响应 - 分析 - 解决问题。