摘要：看下?tīng)顟B(tài)可以看到我已經(jīng)有一些鏡像了我已經(jīng)刪除了拉鏡像正常即可，中間那段是中國(guó)鏡像源，我們成功下來(lái)了的鏡像。攻破像我這樣屌絲的服務(wù)器一般都買(mǎi)的，大的資源文件不住，一個(gè)動(dòng)輒的文件這很蛋疼，不上很難受。

4000字長(zhǎng)文，多圖預(yù)警！??！流量慎入??！

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

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

實(shí)戰(zhàn)項(xiàng)目地址

本章代碼地址

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

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

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

了解 CDN 的重要性

webpack 按需加載

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

如何分析項(xiàng)目依賴，方便針對(duì)性處理

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

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

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

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

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

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

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

docker images

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

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

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

ok，我們成功 pull 下來(lái)了 Nginx 的鏡像。默認(rèn)存儲(chǔ)的鏡像名為： 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 你可能會(huì)有更多的疑問(wèn)：

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

能否/怎樣 查看 Nginx 日志 ?

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

......

這些小白問(wèn)題本章簡(jiǎn)單講講，后面做自動(dòng)運(yùn)維的時(shí)候多帶帶展開(kāi)講，可以關(guān)注我的博客

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

?

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

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

打開(kāi) network 觀察一下:

它有 144K 這么大

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

首先看看 webpack 到底打沒(méi)打出來(lái)打出來(lái) gZip 呢？看看他的目錄有沒(méi)有 js 的 .gz 文件。

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

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

package.json 項(xiàng)目描述文件

打開(kāi)看看 build 命令執(zhí)行了哪個(gè)腳本？

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

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

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

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

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,

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

首先下載一下依賴：

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

然后 productionGzip 改成 true

廢話不多說(shuō)打個(gè)包試試：

npm run build

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

 docker exec -it nginx /bin/bash

或者

 docker exec -it nginx "bash"

Linux whereis 命令用于查找文件。

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

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

語(yǔ)法

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

查看 nginx 位置

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

我們?cè)?/usr/share/nginx 找到了根目錄 html/

我們?cè)?/etc/nginx/ 找到了 nginx 配置文件

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

查看一下 nginx 的配置

確實(shí) gZip 真的沒(méi)開(kāi)啟，被注掉了。

我們打開(kāi) gZip 的注釋，并且防止服務(wù)端對(duì) 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配置 代碼在這里

就目前來(lái)看，你有兩種方法可以選擇：

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

獨(dú)立出配置文件，一勞永逸。

我們基于第二點(diǎn)在 new-bee/ 目錄 同級(jí) 創(chuàng)建了一個(gè)目錄 nginx/ 創(chuàng)建一個(gè)同名的 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 的大小，這對(duì)于大型項(xiàng)目來(lái)說(shuō)，節(jié)省的不只是 100K ，甚至是更多，webpack 或者說(shuō) gz 等壓縮算法，會(huì)將所有的大量重復(fù)的片段多帶帶標(biāo)記，所以重復(fù)的越多，壓縮的越多，這對(duì)于現(xiàn)在帶寬比金子貴的云服務(wù)來(lái)說(shuō)是十分重要的。

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

廢話先不說(shuō)給大家上個(gè)對(duì)比圖 測(cè)試地址

這是我的 論壇

可以看到僅有幾個(gè)地方還算不錯(cuò)，其余地方都是一塌糊涂

這是淘寶

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

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

使用 CDN 的幾點(diǎn)優(yōu)勢(shì)

訪問(wèn)快

服務(wù)端壓力小

webpack打包小且快（下面講）

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

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

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

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

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

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

運(yùn)行一下：

npm run analyz

效果：

分析：

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

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

官方詳細(xì)說(shuō)明

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

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

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

那么類似：

/* webpackChunkName: "blog" */

不是白寫(xiě)的，他是配合 webpack 對(duì)項(xiàng)目各路由拆分的，我們可以看看 實(shí)際項(xiàng)目加載情況 ：

這個(gè) blog.hash.js

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

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

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

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

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

SO - 努力吧!

項(xiàng)目預(yù)覽地址

實(shí)戰(zhàn)項(xiàng)目地址

博客地址

本章代碼地址

感興趣可以點(diǎn)個(gè) star

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