前言
这是项目优化中的一小部分
但是我举得比较适用并且有效的
在优化页面加载时间我之前已经做了一下的这些事
- 使用lighthouse，观察需要优化的有哪些着手点
- 使用前端监控，观察用户实际的效果
优化方向
网络层面
- 开启gzip优化，自动压缩静态文件
- 开启自动智能压缩（brotli压缩）
- 资源的cdn
- dns收拢或预解析（减少dns查询时间，tcp建立时间）
- 使用最新http2.0（使用了二进制协议，压缩了请求头，多路复用）
代码层面
- 对于组件按需加载
- 列表类型的dom进行懒加载
- 以及一些代码的优化，删除没有用的逻辑代码什么的
- 将一些公共的不常更新的抽离出来放cdn（这么做的目的是防止每次发版清理cdn导致的波动,以及长期缓存）
- 对象的冻结
- 页面多个请求并行请求
- 将公共方法按照tree-shaking规则，方便之后摇树，减少js体积
// 原来
import fn from "@/commonjs";
// change
import { time, day } from "@/commonjs";
图片处理
- 雪碧图
- 图片的懒加载(用户体验)
- 图片Base64(小图片，减少http请求)
- 图片响应头设置
- 图片压缩
- 不同dpr或屏幕大小加载不同的图片(减少图片大小)
效果
做完以上的效果有个效果比较最明显的一个页面是平均时间从3.3s到1.9s但是平均时间是不具备说服力的，使用四分位的中位数也就是2.31s到1.2s，下降了1.1s
分析
其实上面的效果最明显的是网络层面的据我观察，代码层面没有任何优化的页面，效果是平均2.7s到2s,使用四分位的中位数也就是1.9s到1.4s，下降了0.5s无言以对~~~~
实际项目
下一步我决定对这个已经优化到1.4s的项目进行优化，证明我的代码层面是比网络层面有效的~~~
当前项目的状态
生产的代码包括（map）
删除map文件后的大小
修改config/index.js的
productionSourceMap:false
打包就就不会在有map文件，可以提高编译速度，但是之后定位问题不大方便
安装打包分析工具
npm i -D webpack-bundle-analyzer
执行report之后
vconsole这未免也太大了吧~~~而且在生产上并不会用到~~~干掉他
drop_debugger: true,//console
drop_console: true,
pure_funcs: ['console.log']//移除console
加入这几行代码是的生产上并不会显示，但是其实打包还是编译进去的
于是我在想在externals里面加入vconsole，确实会户会忽略编译，但是我在测试和预发布环境我还是需要使用到的，这样不方便实际
最后使用
if(process.env.MODE != 'product') {
const VConsole = require('vconsole');
new VConsole();
}
这样的方法，不使用improt的方式引入
import和require的区别
- require是运行时调用，所以require理论上可以运用在代码的任何地方
- import是编译时调用，所以必须放在文件开头，是静态导入的，所有被导入的模块是在加载时就被编译的，无法按需编译
所以在生产环境下vconsole并不会被编译进去
经过代码层面的优化，项目现在的大小如图
744-483=261kb
