前端性能优化基于iframe的多项目集成应用，主要从共享静态资源，减小打包体积、利用浏览器缓存等方面来优化性能，并着重研

背景：基于iframe的多项目集成应用，主要从共享静态资源，减小打包体积、利用浏览器缓存等方面来优化性能

一、所有子项目共享基座字体包

1、以我们的反洗钱产品化项目为例，该项目在我优化前是子项目和基座分别使用自己的字体包，但字体包做了gzip压缩和浏览器内存缓存。

2、初步想法

（1）思路：子项目还是继续使用自己的字体css文件，但字体包使用基座的

（2）实现步骤

基座配置：

配置允许跨域

字体单独打包
子项目配置：

字体包css文件配置代理标识字符

nginx根据该标识将请求重定向到基座的服务地址

线上部署完成，本地走vue.config.js中的代理地址

上述步骤成功实现子项目引用基座字体包的性能优化，但通过页面观察到，点击菜单请求的时候虽然使用了浏览器缓存，但用的是磁盘缓存，还是会有请求时间，理想状态是希望请求完一次之后所有的子项目就都走浏览器内存缓存，不会再次花费时间去请求字体包。

3、进一步想法实现

（1）思路：子项目全部使用基座的字体css文件

（2）实现步骤

基座配置

基座需要将字体css文件单独打包出来（未分离出来字体css文件），采用了迂回思路，直接将基座字体css文件复制到打完包的dist文件中

基座打完包后的字体css文件

由此实现了想要的效果，希望请求完一次之后所有的子项目就都走浏览器内存缓存，不会再次花费时间去请求字体包。但是直接将字体css文件复制进dist文件夹，不经过webpack打包，这样的方式很不合理，所有后面着重研究了一下单独打包css文件的相关知识。

4、单独打包css文件

（1）经过查阅资料了解到webpack4以上可以使用mini-css-extract-plugin插件来单独分离css文件

先看下webpack单独分离css文件的相关配置

入口文件index.js

webpack.config.js配置

打完包的main.css文件

未配置mini-css-extract-plugin打完包的文件

对比发现，确实将css分离出来了，但打完包后发现只有一个main.css文件，并且里面包含了index.css和global.css里面的所有样式。

思考之后再次理解“mini-css-extract-plugin插件来单独分离css文件”的含义应该将css从js中分离出来，并且会打包合并生成一个css文件，并不能将不同的css文件单独打包成相应的css文件（比如index.css->index.css，global.css->global.css）

要实现将css打包成多个文件，需要结合webpack的代码分离特性去实现。

（2）代码分离（splitChunks）

module、chunk和bundle

要理解splitChunks，先要理解webpack的提出的几个概念，module、chunk和bundle。
- module：每个import引入的文件就是一个模块（也就是直接手写的代码）
- chunk：当module源文件传到webpack进行打包时，webpack会根据文件引用关系生成chunk（也就是module在webpack处理时是chunk）
- bundle：是对chunk进行压缩等处理后的产出（也就是打包后可以直接运行的文件）
webapck拆分出的chunk有四种：
- 根据入口文件拆分
- 根据异步文件拆分（import(‘…’)）
- 根据spliteChunk拆分
- 还有一些运行时runtimeChunk,负责
  
  形如 import('abc').then(res=>{}) 这种异步加载的代码，在webpack中即为运行时代码
  
  每次更改所谓的运行时代码文件时，打包构建时app.js的hash值是不会改变的。如果每次项目更新都会更改app.js的hash值，那么用户端浏览器每次都需要重新加载变化的app.js，如果项目大切优化分包没做好的话会导致第一次加载很耗时，导致用户体验变差。现在设置了runtimeChunk，就解决了这样的问题。所以这样做的目的是避免文件的频繁变更导致浏览器缓存失效，所以其是更好的利用缓存。提升用户体验。
webpack配置splitChunks
- 入口文件index.js
- webpack.config.js配置
- 打完包的dist文件目录
- common.css文件
- main.css文件
由上面结果可以看出mini-css-extract-plugin结合splitChunks确实分离出来了想要分离的css，webpack相关配置已经实现出我想要的理想状态，接下来我们就来看看vue如何实现。