前端性能優化與上線

時間 2019-11-11

標籤前端性能優化上線欄目系統性能简体版

原文原文鏈接

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

性能優化 - 屌絲前端性能優化、上線一條龍

你們好我又來了，本章給你們帶來的內容是：上線和上線後的性能優化css

項目地址

本章你會了解

前端須要瞭解的 docker 基礎知識
部署前端項目到本地/外網服務
前端項目的 gZip 優化
瞭解 CDN 的重要性
webpack 按需加載
圖片的相關優化
如何分析項目依賴，方便針對性處理
如何減少 webpack 打包大小/速度

上線

咱們一般在本地開發，本地環境和線上也並不是徹底同樣，不少項目第一次上線幾乎都會遇到本地開發沒法復現的問題，多是字體、樣式的問題，也多是webpack 編譯的問題、甚至多是本地的奇葩環境。因此本地完美運行 ≠ 線上完美運行，咱們須要 build 項目，模擬線上測試一下，看看是否能夠完美運行，有問題能夠方便及時做出調整。html

準備

爲了不本教程污染你們本地環境，推薦你們安裝一個docker，後期運維也會根據 docker 展開。

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

雖然 tomcat nginx apache jboss jetty 等等等等均可以做爲 http 服務，本章以最多見的 nginx 展開講述：vue

大白話介紹下 docker

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

使用 docker

也許不少人沒用過，沒用過也不講怎麼安裝了，本身去看官網吧中文官網、社區版下載、中國鏡像加速，windows 的話可能要開啓虛擬化，linux 推薦 ubuntu，爲了性能請不要在ventos中運行 Docker ，證據在這裏 - 查看翻譯點這裏)，幾年前的文章了，如今怎麼樣有待考究。node

看下 images 狀態

docker images

能夠看到我已經有一些鏡像了「我已經刪除了nginx」linux

dockerHub 拉 Nginx 鏡像

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

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

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

打包

進入咱們上一章源碼的目錄，build 一下進行發佈。
上一章源碼在這裏nginx

npm run build

啓動 docker 容器

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

上調命令一些解釋「很少講，避免消化不良，本身探究」

CMD	解釋
-d	守護進程運行
-p	端口映射 8888 ：80 docker80端口映射到本機「宿主機」
-v	掛載宿主機的一個目錄本機「宿主機」: docker容器
—name	爲容器命名

測試一下

http://localhost:8888/#/

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

你怎麼知道須要將主目錄掛載到： /usr/share/nginx/html ?
可否/怎樣查看 Nginx 日誌 ?
容器內的 nginx 可否自定義配置 ?
......

這些小白問題本章簡單講講，後面作自動運維的時候單獨展開講，能夠關注個人博客

gZip

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

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

gZip 攻破 webpack、nginx

像我這樣屌絲的服務器通常都買 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 主機

docker exec -it nginx /bin/bash

或者

docker exec -it nginx "bash"

CMD	解釋
exec	進入docker容器
-i	-i: 以交互模式運行容器，一般與 -t 同時使用；
-t	-t: 爲容器從新分配一個僞輸入終端，一般與 -i 同時使用；
-it	-it = -i -t
「bash」或 /bin/bash	/bin/bash的做用是由於docker後臺必須運行一個進程，不然容器就會退出

進入 nginx 主機的第一件事

nginx 在哪？？？

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配置代碼在這裏

如何修改 docker 內部的配置

就目前來看，你有兩種方法能夠選擇：

直接 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 的意義了，主要意義不是節省開源項目服務器帶寬，而是全國各個節點的訪問速度問題，也就解釋了：我部署的項目訪問速度還不錯，你這裏怎麼這麼慢，你網很差吧？CDN 來告訴你答案。

cookie

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

使用 CDN 的幾點優點

訪問快
服務端壓力小
webpack打包小且快（下面講）

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

節省 webpack 打包大小/速度

很長時間前經歷過公司前端 webpack 編譯特別慢的問題，dev 模式下咱們能夠注掉開發範圍外的路由，可是 build 發佈的時候彷佛無法解決，使用了 Happypack 多線程打包仍是不如人意，查閱資料讀到了這篇文章

咱們能夠把可以 externals 調的排除掉，而後使用 webpack 的 webpack.DllPlugin 生成依賴庫（這點很重要），大大減小便以速度，DllPlugin 本質上的作法和咱們手動分離這些第三方庫是同樣的，可是對於包極多的應用來講，自動化明顯加快了生產效率。

如何分析項目依賴

webpack-bundle-analyzer

其實不少人都知道，可能剛入坑的同窗不太瞭解，無論是 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 餓了麼組件比較大，（我比較懶，全局導入的，能夠用哪一個引入哪一個避免全局打包問題）能夠優化，而後無聊的同窗沒事兒點點玩玩吧。

webpack 按需加載：一切皆模塊

當打包構建應用時，Javascript 包會變得很是大，影響頁面加載。若是咱們能把不一樣路由對應的組件分割成不一樣的代碼塊，而後當路由被訪問的時候才加載對應組件，這樣就更加高效了。 Webpack 的代碼分割功能，實現路由組件的懶加載.

官方詳細說明

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

會發現不少這種註釋：

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

那麼相似：

/* webpackChunkName: "blog" */

不是白寫的，他是配合 webpack 對項目各路由拆分的，咱們能夠看看實際項目加載狀況：

這個 blog.hash.js

不是咱們寫的，是 webpack 進行分割的，這樣相似 vue 這樣的單頁面架構，不會加載某模塊老是加載所有腳本，大大提高加載速度。

圖片處理

原本不想講的，簡單說說吧，經常使用的也就那幾種 svg 、base6四、或使用fastdfs組件相似 CDN 的服務。

base64

簡單來說 base64 會減小你的 http 請求數量，要知道 XHR 可不是省油的燈，他會帶來額外的處理請求和處理響應損耗，以表情爲例，動輒幾十個表情 http 請求彷佛太智障了一些，一般採用 base64 處理，減小了 http 請求數量，可是增大了圖片自己的體積，若是你用了webpack 且你的表情在本地，那麼 webpack 能夠幫你自動進行 base64 編碼哦。