摘要：看下狀態可以看到我已經有一些鏡像了我已經刪除了拉鏡像正常即可，中間那段是中國鏡像源，我們成功下來了的鏡像。攻破像我這樣屌絲的服務器一般都買的，大的資源文件不住，一個動輒的文件這很蛋疼，不上很難受。

4000字長文，多圖預警！！！流量慎入！！

大家好我又來了，本章給大家帶來的內容是：上線和上線后的性能優化

實戰預覽地址

實戰項目地址

本章代碼地址

前端需要了解的 docker 基礎知識

部署前端項目到本地/外網服務

前端項目的 gZip 優化

了解 CDN 的重要性

webpack 按需加載

圖片的相關優化

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

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

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

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

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

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

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

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

docker images

可以看到我已經有一些鏡像了「我已經刪除了nginx」

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

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

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

進入我們上一章源碼的目錄，build 一下進行發布。
上一章源碼在這里

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

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

http://localhost:8888/#/

當然初次嘗試 docker 你可能會有更多的疑問：

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

能否/怎樣 查看 Nginx 日志 ?

容器內的 nginx 能否自定義配置 ?

......

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

我們可以通過 webpack 壓縮腳本文件，上傳到 http 服務器，瀏覽器瀏覽的時候，經過壓縮的HTTP應答報文是由瀏覽器解壓的，比起壓縮，解壓的速度是非常快的（只要數據正常，可以解壓的話），所以不用擔心瀏覽器用于解壓的時間會降低用戶體驗。事實上，瀏覽器解壓消耗的這點時間比起數據包因為網絡擁堵而耽誤的時間要少的多也可控的多。

?

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

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

打開 network 觀察一下:

它有 144K 這么大

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

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

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

大家還記得當初構建項目我發的這張圖嗎？

package.json 項目描述文件

打開看看 build 命令執行了哪個腳本？

打開 build.js 看看執行了哪些內容，難道是 vue-cli 沒有為我們配置好webpack gZip 相關的配置嗎？

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

哦，我們看到了，webpack 確實為我們配置了 gZip 相關配置。

可是發現這個配置被這個判斷包裹住了：

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,

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

首先下載一下依賴：

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

然后 productionGzip 改成 true

廢話不多說打個包試試：

npm run build

成功了，出現了 .zg 文件壓縮包，但是 gZip 是需要服務端的支持的，服務器通過客戶端請求的 Accept-Encoding 首部開判斷返回哪種格式的腳本文件，然后由瀏覽器解壓，我們拉下來的 nginx 鏡像，nginx 是不會為我們默認配置 gZIp 服務端壓縮的，我們去查看一下吧。

 docker exec -it nginx /bin/bash

或者

 docker exec -it nginx "bash"

Linux whereis 命令用于查找文件。

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

該指令只能用于查找二進制文件、源代碼文件和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 的注釋，并且防止服務端對 css 偷懶，我們一步到位加上幾行經典配置。

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 容器進行修改，增加上述 gZip 代碼段。缺點：若想重新基于鏡像構建容器容器內的配置會丟失。（除非你 commit 鏡像）

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

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

nginx配置 代碼在這里

先停止 nginx 容器

docker stop nginx

刪除 nginx 容器

docker rm nginx

重新構建 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 緩存，清除下瀏覽器緩存或進行隱身模式

已經奏效了。

看看大小壓縮到多少

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

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

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

這是我的 論壇

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

這是淘寶

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

我們還是拿實戰的 bbs論壇 舉例子吧，查看網絡狀態：

使用 CDN 的幾點優勢

訪問快

服務端壓力小

webpack打包小且快（下面講）

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

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

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

其實很多人都知道，可能剛入坑的同學不太了解，不管是 npm maven 都有自己一套以來分析工具，當然也都來源于第三方，這里為大家介紹 npm 的以來分析工具： webpack-bundle-analyzer ，他會在瀏覽器生成一個報表，直觀的展示哪里大，哪里需要優化，以及預測 gZip 的大小，還是以 實戰項目為例：

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

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

運行一下：

npm run analyz

效果：

分析：

發現了問題，static/ 靜態文件下 hightlight 文件比較大，有錢可以考慮下 CDN，node_modules/ 下 element-ui 餓了么組件比較大，（我比較懶，全局導入的，可以用哪個引入哪個避免全局打包問題）可以優化，然后無聊的同學沒事兒點點玩玩吧。

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

官方詳細說明

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

會發現很多這種注釋：

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

那么類似：

/* webpackChunkName: "blog" */

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

這個 blog.hash.js

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

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

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

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

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

SO - 努力吧!

項目預覽地址

實戰項目地址

博客地址

本章代碼地址

感興趣可以點個 star

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