@TOCjavascript
2019/06/22 週六 pm 天氣晴 有點小困php
開始我想把這個鍋甩給網速,但我發現一些大商城項目(淘寶,京東),在網速通常的狀況下,加載速度依然仍是挺快,哎,網速不背這個鍋 仍是找項目的緣由吧,加載時間4.5s css
監控首頁加載的過程,找到拖後腿的 vendors***.js 這個鍋他來背 1.9M 的 js文件下載3.42秒 ,先不說網速,這個js也太TM大了吧插件使用:html
// 文件路徑 build --> webpack.prod.conf.js
//增長如下配置
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
...
plugins: [
...
new BundleAnalyzerPlugin(),
...
]
複製代碼
添加上面代碼以後, 運行打包命令 npm run build,打包成功後會自動彈出 127.0.0.1:8888 像下面同樣,看到許多小塊,每一個小塊對應每一個模塊,小塊越大文件越大vue
看到vendor.js了嗎? 這樣是否是佷清楚的看到它裏面到底都裝了什麼東西,恍然大悟,對滴, 它裝的就是咱們項目裏應用的依賴 java
vendor.js 是被 依賴 (第三方庫) 充大的 ,因此先檢查每一個依賴,是否存在引入但沒有使用的==閒置依賴包==排除了 ==閒置依賴包== 的存在後,就須要對鋼需依賴進行優化webpack
ThinkerK 理解的 CDN加速:將本身的源碼跟第三方庫代碼分離,減少項目體積, 利用別人的服務器去請求第三方庫,來減輕本身服務器的壓力nginx
針對體積比較大的一些鋼需依賴,選擇CDN加速的方式(以 echarts 來舉例)web
//index.html
<script src="https://cdn.bootcss.com/echarts/4.2.1-rc1/echarts.min.js"></script>
複製代碼
//文件路徑 build --> webpack.base.conf.js
module.exports = {
externals: { //externals 裏的庫不會被webpack打包
echarts: 'echarts',
},
}
複製代碼
再次 npm run build 的時候,echarts 就不會被打包進去, vendor.js的體積就會減少vue-cli
webpack.dll 其實更可能是對webpack打包速度的優化,對優化首頁加載速度方面效果不是佷明顯,因此在這裏只提一嘴。 有興趣的話能夠看下 webpack dllplugin的使用
gzip壓縮能力很強,壓縮力度可達到70%
server {
listen 8103;
server_name ************;
# 開啓gzip
gzip on;
# 進行壓縮的文件類型。
gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;
# 是否在http header中添加Vary: Accept-Encoding,建議開啓
gzip_vary on;
}
複製代碼
npm i compression-webpack-plugin@1.1.12 --save-dev
複製代碼
注意這裏的版本 @1.1.12 若是不加版本號 在 npm run build 時會報錯 由於compression最新版本跟webpack版本不匹配//文件路徑 config --> index.js
build: {
// Gzip off by default as many popular static hosts such as
// Surge or Netlify already gzip all static assets for you.
// Before setting to `true`, make sure to:
// npm install --save-dev compression-webpack-plugin
productionGzip: true, //以前時false 改成true
productionGzipExtensions: ['js', 'css'],
}
複製代碼
配置完後的打包效果
瀏覽器上能夠看到gzip 優化後的效果 比以前快4s多 體驗一下就上來了