正值测试阶段，抽时间做一次总结。
由于历史原因，部门的技术栈相对落后且不统一，ng1、react、vue、node、甚至jsp等前后端不分离的比比皆是。但没办法啊，毕竟业务驱动，重构、追赶新技术是需要很大成本的。
米币支付这个项目之前就是前后端不分离的，这次他们希望沿用之前的技术减少时间和人力成本，毕竟前后端分离接口都得改。那我不干啊，好不容易重构了，不向前兼容，怎么还后退了呢。据理力争，找接口协商，最后接口可以完全抽出一个人力配合，才同意前后端分离。本来想采用vue + ts的，但ts被否决了，理由是组内还没有ts的项目，怕后期的维护成本加大，行吧，咱也退一步。
说实话，现在很不屑于做这种项目，没有任何技术难点，没有任何挑战。但没办法，这就是你的工作。
一个多月时间，从项目架构、开发、多语言、CI/CD，错误上报/性能监控全流程搞了一遍，也算摸清了公司的流程。
更细节的内容在组内做了次分享，由于我司对信息安全这一块查的很严，也就不提了。
下面主要说做的性能优化吧，毕竟面试也会关注这一点（有句话：你在这家公司所做的一切都是为下次跳槽做准备），没有实际经验，单靠八股文还是心虚呀。
1. 代码切割，减小包体积。html中prefetch
2. 合并小文件，减少请求次数
小文件合并使用 webpackChunkName 注释， 同名的就会合成一个文件
-
合并前
-
js
image.png
-
css
image (1).png
打包后发现有不少几kb的文件，可以将它们合并成一个，以空间换取时间。
合并之后
image (2).png
image (3).png
3. Gzip 压缩
下面全是Nginx配置。
1. nginx 开启压缩
server {
# 开启gzip 压缩 on 开启；off关闭*
gzip on;
}
压缩前：
image (4).png
注意：Nginx没有压缩过的文件，ETag的值是没有
W/前缀的。即便返回的是前端提供的静态gzip文件，也是没有前缀的。
压缩后：
1.png
由Nginx压缩是需要消耗时间和性能的，可以前端进行压缩，然后配置Nginx。
2. 前端打包Gzip文件
-
安装插件 compression-webpack-plugin
warn: 打包时报以下错误，降低插件的版本即可。（我是从最新版的7.1.2降低到5.0.2）
7b27771d-3345-4ec1-922c-af583fec101a.png
-
配置
-
打包
webpack 压缩前后，生成的.gz文件
2.png
部署到nginx上。配置nginx，nginx会优先返回资源目录下存在的.gz文件
gzip_static on;
配置以后我怎么知道返回的压缩文件是由nginx返回的还是前端打包好的呢？
第一步介绍过前端没有打包生成gzip文件之前，由nginx压缩的文件的ETag具有/W前缀。
直接返回前端生成的压缩文件，ETag没有 /W前缀。
3.png
3. nginx配置
下面是Nginx的配置和说明。
server {
# 开启gzip 压缩 on 开启；off关闭
gzip on;
# 检查是否存在请求静态文件的gz结尾的文件，如果有则直接返回该gz文件内容，不存在则先压缩再返回
gzip_static on;
# 压缩阈值 单位：字节 （从header头中的Content-Length中进行获取。）
# 默认值是0 （即：都进行压缩）
# 建议设置成大于10k的字节数，配合compression-webpack-plugin
gzip_min_length 10k;
# 对特定的MIME类型生效,其中'text/html’被系统强制启用
gzip_types text/javascript application/javascript text/css application/json;
# Nginx作为反向代理的时候启用，开启或者关闭后端服务器返回的结果
# 匹配的前提是后端服务器必须要返回包含"Via"的 header头
# off(关闭所有代理结果的数据的压缩)
# expired(启用压缩,如果header头中包括"Expires"头信息)
# no-cache(启用压缩,header头中包含"Cache-Control:no-cache")
# no-store(启用压缩,header头中包含"Cache-Control:no-store")
# private(启用压缩,header头中包含"Cache-Control:private")
# no_last_modefied(启用压缩,header头中不包含"Last-Modified")
# no_etag(启用压缩,如果header头中不包含"Etag"头信息)*
# auth(启用压缩,如果header头中包含"Authorization"头信息)*
# any - 无条件启用压缩
gzip_proxied any;
# 请求加个 vary头，给代理服务器用的，有的浏览器支持压缩，有的不支持，所以避免浪费不支持的也压缩
gzip_vary on;
# 越小压缩效果越差，但是越大处理越慢，一般取中间值
gzip_comp_level 6;
listen 80;
server_name m.staging.mibi.n.xiaomi.com;
# html 文件
location /dist {
alias mibi;
index index.html index.htm;
# 对于在地址栏直接访问 m.staging.mibi.n.xiaomi.com/dist/record/XXX**之类的路由
# nginx在查找时就回去mibi下的record目录下找，显然没有，就会返回404
# 所以需要配置nginx 找不到的一律打到mibi 下的index.html上，剩下的路由匹配就由前端接管处理了。
# 解析：先根据地址找对应的文件，找不到再试探地址对应的目录，再找不到就返回 /dist/index.html
try_files $uri $uri/ /dist/index.html;
}
# 静态资源
location /assets {
alias mibi;
}
# 接口映射
location / {
proxy_set_header Host $host;
proxy_pass http://120.92.35.3:80/;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
因为支付涉及到很多调用方，需要兼容已有的地址，所有路径前缀和资源前缀不一致。关于路径前缀配置在vue-router中配置base即可。资源前缀在webpack中配置publicPath。而静态资源都放在服务器的mibi目录下，所以就会有上面html和静态资源的配置不一样的情况。
接口映射是因为前后端分离后，分开部署，所以接口需要做一次转发。
4. HTTP缓存
HTTP缓存是性能优化很重要的手段之一。
现在的项目一般都是SPA（多页面也一样），编译打包后生成的静态资源名都带有hash值。所以把html设置成协商缓存。如果资源内容改变，生成新的hash值，资源URL自然也变了，所以js、css、img等设置成强缓存。缓存有效期可以很长，但是也不要太久，一般30天，不然假如频繁更新前端资源，废弃的资源将一直存留在用户的磁盘，会搞死用户的。
# 缓存配置
# html配置
location = /index.html {
add_header Cache-Control no-cache;
}
# js/css配置。一般设置成30d。因为打包后文件名都是hash 缓存时间设置的太长，更新后不再使用的资源会一直占用用户的磁盘
location ~ /(js/\*|css/\*|img/\*|font/\*) {
expires 30d;
add_header Cache-Control public;
}
4.图片和字体图标
- 图片不需要压缩，一方面我用熊猫压缩过了，另一方面图片自身已经做了最优化，压缩后反而大了
- 格式为eot和ttf的字体图标可以进行压缩，效果还可以，而woff格式的，因为CompressionWebpackPlugin插件不支持压缩，即使配置了也没用。
以上就是本次项目做的一点性能优化。
网友评论