大家好我又來了，本章給大家?guī)淼膬?nèi)容是：上線和上線后的性能優(yōu)化

實戰(zhàn)預(yù)覽地址

實戰(zhàn)項目地址

本章代碼地址

前端需要了解的 docker 基礎(chǔ)知識

部署前端項目到本地/外網(wǎng)服務(wù)

前端項目的 gZip 優(yōu)化

了解 CDN 的重要性

webpack 按需加載

圖片的相關(guān)優(yōu)化

如何分析項目依賴，方便針對性處理

如何減小 webpack 打包大小/速度

我們通常在本地開發(fā)，本地環(huán)境和線上也并非完全一樣，很多項目第一次上線幾乎都會遇到本地開發(fā)無法復(fù)現(xiàn)的問題，可能是字體、樣式的問題，也可能是webpack 編譯的問題、甚至可能是本地的奇葩環(huán)境。所以 本地完美運行 ≠ 線上完美運行，我們需要 build 項目，模擬線上測試一下，看看是否可以完美運行，有問題可以方便及時作出調(diào)整。

為了避免本教程污染大家本地環(huán)境，推薦大家安裝一個docker，后期運維也會根據(jù) docker 展開。

看到這個 Title ：《準(zhǔn)備docker》，沒接觸過的前端不要慫，裝一個，勇于跨出第一步，不學(xué)習(xí)就是等死「點擊這里了解 docker」

雖然 tomcat nginx apache jboss jetty 等等等等都可以作為 http 服務(wù)，本章以最常見的 nginx 展開講述：

docker 就是用更優(yōu)雅的方法，做到了虛擬機的事情，并且做的更好，可編程管理集群。docker 啟動容器，在容器內(nèi)部運行你的環(huán)境，默認(rèn)各個容器是互相隔離的，當(dāng)然你可以通過 link network 關(guān)聯(lián)容器，或者直接使用 docker-compose 編排，啟動容器的前提是鏡像，也類似與虛擬機的鏡像，想跑容器，先得下載「pull」鏡像。

也許很多人沒用過，沒用過也不講怎么安裝了，自己去看官網(wǎng)吧中文官網(wǎng)、社區(qū)版下載、中國鏡像加速，windows 的話可能要開啟虛擬化，linux 推薦 ubuntu， 為了性能請不要在ventos中運行 Docker ，證據(jù)在這里 - 查看翻譯點這里)，幾年前的文章了，現(xiàn)在怎么樣有待考究。

docker images

可以看到我已經(jīng)有一些鏡像了「我已經(jīng)刪除了nginx」

docker pull registry.docker-cn.com/library/nginx:latest

正常 docker pull nginx 即可，中間那段是中國鏡像源

ok，我們成功 pull 下來了 Nginx 的鏡像。默認(rèn)存儲的鏡像名為： registry.docker-cn.com/library/nginx

進(jìn)入我們上一章源碼的目錄，build 一下進(jìn)行發(fā)布。
上一章源碼在這里

npm run build

docker run --name nginx -d -p 8888:80 -v /new-bee/dist:/usr/share/nginx/html  registry.docker-cn.com/library/nginx

上調(diào)命令一些解釋「不多講，避免消化不良，自己探究」

http://localhost:8888/#/

當(dāng)然初次嘗試 docker 你可能會有更多的疑問：

你怎么知道需要將主目錄掛載到： /usr/share/nginx/html ?

能否/怎樣 查看 Nginx 日志 ?

容器內(nèi)的 nginx 能否自定義配置 ?

......

這些小白問題本章簡單講講，后面做自動運維的時候多帶帶展開講，可以關(guān)注我的博客

我們可以通過 webpack 壓縮腳本文件，上傳到 http 服務(wù)器，瀏覽器瀏覽的時候，經(jīng)過壓縮的HTTP應(yīng)答報文是由瀏覽器解壓的，比起壓縮，解壓的速度是非?？斓模ㄖ灰獢?shù)據(jù)正常，可以解壓的話），所以不用擔(dān)心瀏覽器用于解壓的時間會降低用戶體驗。事實上，瀏覽器解壓消耗的這點時間比起數(shù)據(jù)包因為網(wǎng)絡(luò)擁堵而耽誤的時間要少的多也可控的多。

?

在瀏覽器發(fā)給服務(wù)器的HTTP請求報文中，使用Accept-Encoding字段標(biāo)明自己支持的壓縮格式，即自己可以解壓哪幾種壓縮報文（gzip、zlib庫提供的deflate）。服務(wù)器回復(fù)客戶端的HTTP應(yīng)答報文中，使用Content-Encoding字段標(biāo)明該應(yīng)答報文使用哪種壓縮方式。

像我這樣屌絲的服務(wù)器一般都買 1M 的，大的資源文件 hold 不住，一個動輒 400K 的 vendar 文件這很蛋疼，不上 gZIp 很難受。

打開 network 觀察一下:

它有 144K 這么大

我們就以 webpack 打包的核心 vendor 為例，我們發(fā)現(xiàn)，客戶端向服務(wù)端請求了 gZIp 資源 Accept-Encoding: gzip, deflate，但可惜服務(wù)端并沒有給我們理想中的 response - Content-Encoding: gzip 的響應(yīng), 我們需要排查一下原因。

首先看看 webpack 到底打沒打出來打出來 gZip 呢？看看他的目錄有沒有 js 的 .gz 文件。

很遺憾沒有，只有一些壓縮文件和用于定位的 map 文件，看來首先我們的打包就出現(xiàn)了問題。

大家還記得當(dāng)初構(gòu)建項目我發(fā)的這張圖嗎？

package.json 項目描述文件

打開看看 build 命令執(zhí)行了哪個腳本？

打開 build.js 看看執(zhí)行了哪些內(nèi)容，難道是 vue-cli 沒有為我們配置好webpack gZip 相關(guān)的配置嗎？

我們發(fā)現(xiàn)沒什么特別的，發(fā)現(xiàn)一個
const webpackConfig = require("./webpack.prod.conf")
的依賴，大概就是字面意思（webpack生產(chǎn)配置）進(jìn)去看看。

哦，我們看到了，webpack 確實為我們配置了 gZip 相關(guān)配置。

可是發(fā)現(xiàn)這個配置被這個判斷包裹住了：

if (config.build.productionGzip) {

}

追蹤下去

    // 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: false,

我們的全部疑惑都被揭開了，開發(fā)者通過注釋這樣告訴我們他的理由，我簡單翻譯一下：

首先下載一下依賴：

 vim package.json
 
 "devDependencies": {
    "compression-webpack-plugin": "^1.1.12",
    }

然后 productionGzip 改成 true

廢話不多說打個包試試：

npm run build

成功了，出現(xiàn)了 .zg 文件壓縮包，但是 gZip 是需要服務(wù)端的支持的，服務(wù)器通過客戶端請求的 Accept-Encoding 首部開判斷返回哪種格式的腳本文件，然后由瀏覽器解壓，我們拉下來的 nginx 鏡像，nginx 是不會為我們默認(rèn)配置 gZIp 服務(wù)端壓縮的，我們?nèi)ゲ榭匆幌掳伞?/p> 進(jìn)入 docker 主機

 docker exec -it nginx /bin/bash

或者

 docker exec -it nginx "bash"

Linux whereis 命令用于查找文件。

該指令會在特定目錄中查找符合條件的文件。這些文件應(yīng)屬于原始代碼、二進(jìn)制文件，或是幫助文件。

該指令只能用于查找二進(jìn)制文件、源代碼文件和man手冊頁，一般文件的定位需使用locate命令。

語法

whereis [-bfmsu][-B <目錄>...][-M <目錄>...][-S <目錄>...][文件...]

查看 nginx 位置

root@e0017cab245f:/# whereis nginx
nginx: /usr/sbin/nginx /usr/lib/nginx /etc/nginx /usr/share/nginx

我們在 /usr/share/nginx 找到了根目錄 html/

我們在 /etc/nginx/ 找到了 nginx 配置文件

ps 中間件這么多，誰記得住呢，記不住自己看看就行了不是嗎?

查看一下 nginx 的配置

確實 gZip 真的沒開啟，被注掉了。

我們打開 gZip 的注釋，并且防止服務(wù)端對 css 偷懶，我們一步到位加上幾行經(jīng)典配置。

gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_comp_level 6;
gzip_types application/javascript text/plain application/x-javascript text/css application/xml text/javascript application/json;
gzip_vary on;
    

nginx配置 代碼在這里

就目前來看，你有兩種方法可以選擇：

直接 exec 容器進(jìn)行修改，增加上述 gZip 代碼段。缺點：若想重新基于鏡像構(gòu)建容器容器內(nèi)的配置會丟失。（除非你 commit 鏡像）

獨立出配置文件，一勞永逸。

我們基于第二點在 new-bee/ 目錄 同級 創(chuàng)建了一個目錄 nginx/ 創(chuàng)建一個同名的 nginx.conf 文件。

nginx配置 代碼在這里

先停止 nginx 容器

docker stop nginx

刪除 nginx 容器

docker rm nginx

重新構(gòu)建 nginx 容器

docker run --name nginx -d -p 8888:80 -v /new-bee/dist:/usr/share/nginx/html -v /nginx/nginx.conf:/etc/nginx/nginx.conf:ro registry.docker-cn.com/library/nginx

看看效果

http://localhost:8888/#/

為了避免瀏覽器加載剛才的 304 緩存，清除下瀏覽器緩存或進(jìn)行隱身模式

已經(jīng)奏效了。

看看大小壓縮到多少

只有 50K 左右，壓縮了 2/3 的大小，這對于大型項目來說，節(jié)省的不只是 100K ，甚至是更多，webpack 或者說 gz 等壓縮算法，會將所有的大量重復(fù)的片段多帶帶標(biāo)記，所以重復(fù)的越多，壓縮的越多，這對于現(xiàn)在帶寬比金子貴的云服務(wù)來說是十分重要的。

大家注意到，有些能用 CDN 的我選擇使用了 CDN，那么 CDN 對于線上服務(wù)來說到底有多重要呢?

廢話先不說給大家上個對比圖 測試地址

這是我的 論壇

可以看到僅有幾個地方還算不錯，其余地方都是一塌糊涂

這是淘寶

不用說了吧？不過還好，這部分我們資金不足敗了也很正常，但大家可能也大概知道 CDN 的意義了，主要意義不是節(jié)省開源項目服務(wù)器帶寬，而是全國各個節(jié)點的訪問速度問題，也就解釋了：我部署的項目訪問速度還不錯，你這里怎么這么慢，你網(wǎng)不好吧？CDN 來告訴你答案。

我們還是拿實戰(zhàn)的 bbs論壇 舉例子吧，查看網(wǎng)絡(luò)狀態(tài)：

使用 CDN 的幾點優(yōu)勢

訪問快

服務(wù)端壓力小

webpack打包小且快（下面講）

客戶端的 cookie 是綁定服務(wù)端 域名 的, 看上圖，我們需要 XHR 請求攜帶 cookie 訪問服務(wù)端獲取對應(yīng)權(quán)限，但試想一下：每一個 js、img、甚至是css 都攜帶垃圾的 cookie ，在大用戶量下，服務(wù)端承受著不應(yīng)該屬于他的痛苦，這樣的消耗是特別應(yīng)該避免的，我們可以隨便翻一翻任何一個成熟的網(wǎng)站，都會發(fā)現(xiàn)存在自己的 CDN 服務(wù)，這樣既優(yōu)化了中國不同地區(qū)的訪問速度，同時也大大減小了服務(wù)端的開銷。

很長時間前經(jīng)歷過公司前端 webpack 編譯特別慢的問題，dev 模式下我們可以注掉開發(fā)范圍外的 路由，但是 build 發(fā)布的時候似乎沒法解決，使用了 Happypack 多線程打包還是不如人意，查閱資料讀到了 這篇文章

我們可以把能夠 externals 調(diào)的排除掉，然后使用 webpack 的 webpack.DllPlugin 生成依賴庫（這點很重要），大大減少便以速度，DllPlugin 本質(zhì)上的做法和我們手動分離這些第三方庫是一樣的，但是對于包極多的應(yīng)用來說，自動化明顯加快了生產(chǎn)效率。

其實很多人都知道，可能剛?cè)肟拥耐瑢W(xué)不太了解，不管是 npm maven 都有自己一套以來分析工具，當(dāng)然也都來源于第三方，這里為大家介紹 npm 的以來分析工具： webpack-bundle-analyzer ，他會在瀏覽器生成一個報表，直觀的展示哪里大，哪里需要優(yōu)化，以及預(yù)測 gZip 的大小，還是以 實戰(zhàn)項目為例：

按照官方指引的配置，下載依賴，package.json 文件指定下 build 的腳本：

"analyz": "NODE_ENV=production npm_config_report=true npm run buildProd",

運行一下：

npm run analyz

效果：

分析：

發(fā)現(xiàn)了問題，static/ 靜態(tài)文件下 hightlight 文件比較大，有錢可以考慮下 CDN，node_modules/ 下 element-ui 餓了么組件比較大，（我比較懶，全局導(dǎo)入的，可以用哪個引入哪個避免全局打包問題）可以優(yōu)化，然后無聊的同學(xué)沒事兒點點玩玩吧。

當(dāng)打包構(gòu)建應(yīng)用時，Javascript 包會變得非常大，影響頁面加載。如果我們能把不同路由對應(yīng)的組件分割成不同的代碼塊，然后當(dāng)路由被訪問的時候才加載對應(yīng)組件，這樣就更加高效了。 Webpack 的代碼分割功能， 實現(xiàn)路由組件的懶加載.

官方詳細(xì)說明

官方說的挺詳細(xì)了，這里就偷個懶不上代碼了，給大家提供一種經(jīng)典處理方式，我們不放在組件上，直接對路由進(jìn)行拆分，具體可以看 實戰(zhàn)項目路由 的路由拆分

會發(fā)現(xiàn)很多這種注釋：

const Blog = () => import(/* webpackChunkName: "blog" */ "@/container/blog/Blog")

那么類似：

/* webpackChunkName: "blog" */

不是白寫的，他是配合 webpack 對項目各路由拆分的，我們可以看看 實際項目加載情況 ：

這個 blog.hash.js

不是我們寫的，是 webpack 進(jìn)行分割的，這樣類似 vue 這樣的單頁面架構(gòu)，不會加載某模塊總是加載全部腳本，大大提升加載速度。

本來不想講的，簡單說說吧，常用的也就那幾種 svg 、base64、 或使用fastdfs組件類似 CDN 的服務(wù)。

簡單來講 base64 會減少你的 http 請求數(shù)量，要知道 XHR 可不是省油的燈，他會帶來額外的處理請求和處理響應(yīng)損耗，以表情為例，動輒幾十個表情 http 請求似乎太智障了一些，通常采用 base64 處理，減少了 http 請求數(shù)量，但是增大了圖片本身的體積，如果你用了webpack 且你的表情在本地，那么 webpack 可以幫你自動進(jìn)行 base64 編碼哦。

用戶上傳的圖片可以通過壓縮圖片大小或質(zhì)量減少帶寬哦，通常使用 GM 對用戶上傳的有必要大鎖的圖片 壓縮成不同大小的，根據(jù)業(yè)務(wù)加載，比如頭像，默認(rèn)肯定不會請求原始圖片，今日頭條的正文，使用流量的情況下也會默認(rèn)加載小圖，這些都不是客戶端能做到的，需要服務(wù)端壓縮。

當(dāng)然這些知識萬里長征的第一步，以后的優(yōu)化之路茫茫多，能大概想起來的比如 ：Lazy-Load（優(yōu)化首屏體驗）、PWA（構(gòu)建web APP）、服務(wù)端渲染（為了SEO）、骨架屏（提升用戶體驗），后端和服務(wù)端文章還沒寫，沒時間了 1.0 版本就放這些吧，回頭可以補個第二版。

SO - 努力吧!

項目預(yù)覽地址

實戰(zhàn)項目地址

博客地址

本章代碼地址

感興趣可以點個 star

ps：mac下求推薦個懶人圖床，七牛開始收費了，mweb 不能直接發(fā)布到七牛了，一張一張上傳，我也很無奈啊。