——本文是對之前同名文章的修正，將所有webpack3的內容更新為webpack4，以及加入了筆者近期在公司工作中學習到的自動化思想，對文章內容作了進一步提升。
0.引言
作為網際網路專案，最重要的便是使用者體驗。在舉國“網際網路+”的熱潮中，使用者至上也已經被大多數企業所接收，特別是在如今移動端快速發展的時代，我們的網頁不僅只是呈現在使用者的PC瀏覽器裡，更多的時候，使用者是通過移動產品瀏覽我們的網頁。加之有越來越多的開發者投入到Web APP和Hybrid APP的開發隊伍中，效能這一問題又再一次被提上了程式設計師們重點關注的要素。我曾經看到過這樣一句話：一個網站的體驗，決定了使用者是否願意去了解網站的功能；而網站的功能，決定了使用者是否會一票否決網站的體驗。這是改版自網路上的一句流行語，但卻把網站效能這件事說的十分透徹，特別是在網站這樣的專案中，如果一個使用者需要超過5s才能看見頁面，他會毫不猶豫地關閉它。效能優化，作為工程師界的“上乘武功”，是我們在開發中老生常談的話題，也是一名開發者從入門向資深進階的必經階段，雖然我們看到過很多的標準、軍規，但在真正實踐中，卻常常力不從心，不知道落下了什麼，不知道效能是否還有進一步優化的空間。
對於網站的效能，在行業內有很多既定的指標，但就以前端er而言，我們應該更加關注以下指標：白屏時間、首屏時間、整頁時間、DNS時間、CPU佔用率。而我之前自己搭建的一個網站（網址：jerryonlyzrj.com/resume/ ，近日因域名備案無法開啟，幾日後即恢復正常），完全沒做效能優化時，首屏時間是12.67s，最後經過多方面優化，終於將其降低至1.06s，並且還未配置CDN加速。其中過程我踩了很多坑，也翻了許多專業書籍，最後決定將這幾日的努力整理成文，幫助前端愛好者們少走彎路。文章更新可能之後不會實時同步在論壇上，歡迎大家關注我的Github，我會把最新的文章更新在對應的專案裡，讓我們一起在程式碼的海洋裡策馬奔騰：github.com/jerryOnlyZR… 。
今天，我們將從效能優化的三大方面工作逐步展開介紹，其中包括網路傳輸效能、頁面渲染效能以及JS阻塞效能，系統性地帶著讀者們體驗效能優化的實踐流程。
1.網路傳輸效能優化
在開始介紹網路傳輸效能優化這項工作之前，我們需要了解瀏覽器處理使用者請求的過程，那麼就必須奉上這幅神圖了：
這是navigation timing監測指標圖，從圖中我們可以看出，瀏覽器在得到使用者請求之後，經歷了下面這些階段：重定向→拉取快取→DNS查詢→建立TCP連結→發起請求→接收響應→處理HTML元素→元素載入完成。不著急，我們對其中的細節一步步展開討論：
1.1.瀏覽器快取
我們都知道，瀏覽器在向伺服器發起請求前，會先查詢本地是否有相同的檔案，如果有，就會直接拉取本地快取，這和我們在後臺部屬的Redis和Memcache類似，都是起到了中間緩衝的作用，我們先看看瀏覽器處理快取的策略：
因為網上的圖片太籠統了，而且我翻過很多講快取的文章，很少有將狀態碼還有什麼時候將快取存放在記憶體（memory）中什麼時候快取在硬碟中（disk）系統地整理出來，所以我自己繪製了一張瀏覽器快取機制流程圖，結合這張圖再更深入地說明瀏覽器的快取機制。
這裡我們可以使用chrome devtools裡的network皮膚檢視網路傳輸的相關資訊：
（這裡需要特別注意，在我們進行快取除錯時，需要去除network皮膚頂部的Disable cache 勾選項，否則瀏覽器將始終不會從快取中拉取資料）
瀏覽器預設的快取是放在記憶體內的，但我們知道，記憶體裡的快取會因為程式的結束或者說瀏覽器的關閉而被清除，而存在硬碟裡的快取才能夠被長期保留下去。很多時候，我們在network皮膚中各請求的size項裡，會看到兩種不同的狀態：from memory cache 和 from disk cache，前者指快取來自記憶體，後者指快取來自硬碟。而控制快取存放位置的，不是別人，就是我們在伺服器上設定的Etag欄位。在瀏覽器接收到伺服器響應後，會檢測響應頭部（Header），如果有Etag欄位，那麼瀏覽器就會將本次快取寫入硬碟中。
之所以拉取快取會出現200、304兩種不同的狀態碼，取決於瀏覽器是否有向伺服器發起驗證請求。 只有向伺服器發起驗證請求並確認快取未被更新，才會返回304狀態碼。
這裡我以nginx為例，談談如何配置快取:
首先，我們先進入nginx的配置文件
$ vim nginxPath/conf/nginx.conf
在配置文件內插入如下兩項：
etag on; //開啟etag驗證
expires 7d; //設定快取過期時間為7天
複製程式碼開啟我們的網站，在chrome devtools的network皮膚中觀察我們的請求資源，如果在響應頭部看見Etag和Expires欄位，就說明我們的快取配置成功了。
【！！！特別注意！！！】 在我們配置快取時一定要切記，瀏覽器在處理使用者請求時，如果命中強快取，瀏覽器會直接拉取本地快取，不會與伺服器發生任何通訊，也就是說，如果我們在伺服器端更新了檔案，並不會被瀏覽器得知，就無法替換失效的快取。所以我們在構建階段，需要為我們的靜態資源新增md5 hash字尾，避免資源更新而引起的前後端檔案無法同步的問題。
1.2.資源打包壓縮
我們之前所作的瀏覽器快取工作，只有在使用者第二次訪問我們的頁面才能起到效果，如果要在使用者首次開啟頁面就實現優良的效能，必須對資源進行優化。我們常將網路效能優化措施歸結為三大方面：減少請求數、減小請求資源體積、提升網路傳輸速率。現在，讓我們逐個擊破：
結合前端工程化思想，我們在對上線檔案進行自動化打包編譯時，通常都需要打包工具的協助，這裡我推薦webpack，我通常都使用Gulp和Grunt來編譯node，Parcel太新，而且webpack也一直在自身的特性上向Parcel靠攏。
在對webpack進行上線配置時，我們要特別注意以下幾點：
①JS壓縮：（這點應該算是耳熟能詳了，就不多介紹了）
optimization: {
minimizer: [
new UglifyJsPlugin({
cache: true,
parallel: true,
sourceMap: true // set to true if you want JS source maps
}),
...Plugins
]
}
複製程式碼②HTML壓縮：
new HtmlWebpackPlugin({
template: __dirname + '/views/index.html', // new 一個這個外掛的例項，並傳入相關的引數
filename: '../index.html',
minify: {
removeComments: true,
collapseWhitespace: true,
removeRedundantAttributes: true,
useShortDoctype: true,
removeEmptyAttributes: true,
removeStyleLinkTypeAttributes: true,
keepClosingSlash: true,
minifyJS: true,
minifyCSS: true,
minifyURLs: true,
},
chunksSortMode: 'dependency'
})
複製程式碼我們在使用html-webpack-plugin 自動化注入JS、CSS打包HTML檔案時，很少會為其新增配置項，這裡我給出樣例，大家直接複製就行。據悉，在Webpack5中，``html-webpack-plugin的功能會像common-chunk-plugin`那樣，被整合到webpack內部，這樣我們就不需要再install額外的外掛了。
PS：這裡有一個技巧，在我們書寫HTML元素的src 或 href 屬性時，可以省略協議部分，這樣也能簡單起到節省資源的目的。
③提取公共資源：
splitChunks: {
cacheGroups: {
vendor: { // 抽離第三方外掛
test: /node_modules/, // 指定是node_modules下的第三方包
chunks: 'initial',
name: 'common/vendor', // 打包後的檔名，任意命名
priority: 10 // 設定優先順序，防止和自定義的公共程式碼提取時被覆蓋，不進行打包
},
utils: { // 抽離自定義公共程式碼
test: /\.js$/,
chunks: 'initial',
name: 'common/utils',
minSize: 0 // 只要超出0位元組就生成一個新包
}
}
}
複製程式碼④提取css並壓縮：
在使用webpack的過程中，我們通常會以模組的形式引入css檔案（webpack的思想不就是萬物皆模組嘛），但是在上線的時候，我們還需要將這些css提取出來，並且壓縮，這些看似複雜的過程只需要簡單的幾行配置就行：
（PS:我們需要用到mini-css-extract-plugin ，所以還得大家自行npm install）
const MiniCssExtractPlugin = require('mini-css-extract-plugin')
module: {
rules: [..., {
test: /\.css$/,
exclude: /node_modules/,
use: [
_mode === 'development' ? 'style-loader' : MiniCssExtractPlugin.loader, {
loader: 'css-loader',
options: {
importLoaders: 1
}
}, {
loader: 'postcss-loader',
options: {
ident: 'postcss'
}
}
]
}]
}
複製程式碼我這裡配置前處理器postcss，但是我把相關配置提取到了單獨的檔案postcss.config.js裡了，其中cssnano是一款很不錯的CSS優化外掛。
⑤將webpack開發環境修改為生產環境：
在使用webpack打包專案時，它常常會引入一些除錯程式碼，以作相關除錯，我們在上線時不需要這部分內容，通過配置剔除：
devtool: 'false'
複製程式碼如果你能按照上述六點將webpack上線配置完整配置出來，基本能將檔案資源體積壓縮到極致了，如有疏漏，還希望大家能加以補充。
最後，我們還應該在伺服器上開啟Gzip傳輸壓縮，它能將我們的文字類檔案體積壓縮至原先的四分之一，效果立竿見影，還是切換到我們的nginx配置文件，新增如下兩項配置專案：
gzip on;
gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php application/vnd.ms-fontobject font/ttf font/opentype font/x-woff image/svg+xml;
複製程式碼【！！！特別注意！！！】 不要對圖片檔案進行Gzip壓縮！不要對圖片檔案進行Gzip壓縮！不要對圖片檔案進行Gzip壓縮！我只會告訴你效果適得其反，至於具體原因，還得考慮伺服器壓縮過程中的CPU佔用還有壓縮率等指標，對圖片進行壓縮不但會佔用後臺大量資源，壓縮效果其實並不可觀，可以說是“弊大於利”，所以請在gzip_types 把圖片的相關項去掉。針對圖片的相關處理，我們接下來會更加具體地介紹。
1.3.圖片資源優化
剛剛我們介紹了資源打包壓縮，只是停留在了程式碼層面，而在我們實際開發中，真正佔用了大量網路傳輸資源的，並不是這些檔案，而是圖片，如果你對圖片進行了優化工作，你能立刻看見明顯的效果。
1.3.1.不要在HTML裡縮放影象
很多開發者可能會有這樣的錯覺（其實我曾經也是這樣），我們會為了方便在一個200✖200的圖片容器內直接使用一張400✖400的圖片，我們甚至認為這樣能讓使用者覺得圖片更加清晰，其實不然，在普通的顯示器上，使用者並不會感到縮放後的大圖更加清晰，但這一切卻導致網頁加速速度下降，同時照成頻寬浪費，你可能不知道，一張200KB的圖片和2M的圖片的傳輸時間會是200m和12s的差距（親身經歷，深受其害(┬＿┬)）。所以，當你需要用多大的圖片時，就在伺服器上準備好多大的圖片，儘量固定圖片尺寸。
1.3.2.使用雪碧圖（CSS Sprite）
雪碧圖的概念大家一定在生活中經常聽見，其實雪碧圖是減小請求數的顯著運用。而且很奇妙的是，多張圖片聘在一塊後，總體積會比之前所有圖片的體積之和小（你可以親自試試）。這裡給大家推薦一個自動化生成雪碧圖的工具：www.toptal.com/developers/… （圖片來自官網首頁）
只要你新增相關資原始檔，他就會自動幫你生成雪碧圖以及對應的CSS樣式。
其實我們在工程中還有更為自動的方法，便是一款雪碧圖生成外掛webpack-spritesmith。首先，先簡單介紹一下使用外掛生成雪碧圖的思路：
首先，我們會把我們所需要的小圖示放置在一個資料夾內以便於管理：
（這裡的@2x圖片是為了適配視網膜二倍屏的圖片資源，webpack-spritesmith內有專門為適配多倍屏提供的配置項，稍候將會講到）
然後，我們需要外掛去讀取這個資料夾內的所有圖片資原始檔，以資料夾名稱為圖片名稱生成一張雪碧圖到指定位置，並且輸出能夠正確使用這些雪碧圖的CSS檔案。
如今，webpack-spritesmith這款外掛能實現我們想要的一切，先奉上配置內容：
（具體可參照webpack-spritesmith官方文件： www.npmjs.com/package/web… ）
執行webpack之後，就會在開發目錄裡生成上面兩張圖的結果，我們可以看看common.css裡面的內容：
我們可以看到，所有我們之前放在common資料夾裡的圖片資源都自動地生成了相應的樣式，這些都不需要我們手動處理，``webpack-spritesmith`這款外掛就已經幫我們完成了！
1.3.3.使用字型圖示（iconfont）
不論是壓縮後的圖片，還是雪碧圖，終歸還是圖片，只要是圖片，就還是會佔用大量網路傳輸資源。但是字型圖示的出現，卻讓前端開發者看到了另外一個神奇的世界。
我最喜歡用的是阿里向量圖示庫（網址：www.iconfont.cn/），裡面有大量的向量圖…
圖片能做的很多事情，向量圖都能作，而且它只是往HTML裡插入字元和CSS樣式而已，和圖片請求比起來資源佔用完全不在一個數量級，如果你的專案裡有小圖示，就是用向量圖吧。
但如果我們做的是公司或者團隊的專案，需要使用到許多自定義的字型圖示，可愛的設計小姐姐們只是丟給你了幾份.svg圖片，你又該如何去做呢？
其實也很簡單，阿里向量圖示庫就提供了上傳本地SVG資源的功能，這裡另外推薦一個網站——icomoon。icomoon這個網站也為我們提供了將SVG圖片自動轉化成CSS樣式的功能。（圖片來自icomoon首頁）
我們可以點選Import Icons按鈕匯入我們本地的SVG資源，然後選中他們，接下來生成CSS的事情，就交給icomoon吧，具體的操作，就和阿里向量圖示庫類同了。
1.3.4.使用WebP
WebP格式，是谷歌公司開發的一種旨在加快圖片載入速度的圖片格式。圖片壓縮體積大約只有JPEG的2/3，並能節省大量的伺服器頻寬資源和資料空間。Facebook、Ebay等知名網站已經開始測試並使用WebP格式。
我們可以使用官網提供的Linux命令列工具對專案中的圖片進行WebP編碼，也可以使用我們的線上服務，這裡我推薦叉拍雲（網址：www.upyun.com/webp）。但是在實際…
1.4.網路傳輸效能檢測工具——Page Speed
除了network版塊，其實chrome還為我們準備好了一款監測網路傳輸效能的外掛——Page Speed，我們們的文章封面，就是用的Page Speed的官方宣傳圖（因為我覺得這張圖再合適不過了）。我們只需要通過下面步驟安裝，就可以在chrome devtools裡找到它了：chrome選單→更多工具→擴充程式→chrome網上應用商店→搜尋pagespeed後安轉即可。
（PS：使用chrome應用商店需要翻牆，怎麼翻牆我就不便多說了）
這就是Page Speed的功能介面：
我們只需要開啟待測試的網頁，然後點選Page Speed裡的 Start analyzing按鈕，它就會自動幫我們測試網路傳輸效能了，這是我的網站測試結果：
Page Speed最人性化的地方，便是它會對測試網站的效能瓶頸提出完整的建議，我們可以根據它的提示進行優化工作。這裡我的網站已經優化到最好指標了(•́⌄•́๑)૭✧，Page Speed Score表示你的效能測試得分，100/100表示已經沒有需要優化的地方。
優化完畢後再使用chorme devtools的network版塊測量一下我們網頁的白屏時間還有首屏時間，是不是得到了很大的提升？
1.5.使用CDN
Last but not least，
再好的效能優化例項，也必須在CDN的支撐下才能到達極致。
如果我們在Linux下使用命令$ traceroute targetIp 或者在Windows下使用批處理 > tracert targetIp，都可以定位使用者與目標計算機之間經過的所有路由器，不言而喻，使用者和伺服器之間距離越遠，經過的路由器越多，延遲也就越高。使用CDN的目的之一便是解決這一問題，當然不僅僅如此，CDN還可以分擔IDC壓力。
當然，憑著我們單個人的資金實力（除非你是王思聰）是必定搭建不起來CDN的，不過我們可以使用各大企業提供的服務，諸如騰訊雲等，配置也十分簡單，這裡就請大家自行去推敲啦。
2.頁面渲染效能優化
2.1.瀏覽器渲染過程（Webkit）
其實大家應該對瀏覽器將的HTML渲染機制比較熟悉了，基本流程同上圖所述，大家在入門的時候，你的導師或者前輩可能會告訴你，在渲染方面我們要減少重排和重繪，因為他們會影響瀏覽器效能。不過你一定不知道其中原理是什麼，對吧。今天我們就結合《Webkit技術內幕》（這本書我還是很推薦大家買來看看，好歹作為一名前端工程師，你得知道我們天天接觸的瀏覽器核心是怎樣工作的）的相關知識，給大家普及普及那些深層次的概念。
PS：這裡提到了Webkit核心，我順帶提一下瀏覽器內部的渲染引擎、直譯器等元件的關係，因為經常有師弟或者一些前端愛好者向我問這方面的知識，分不清他們的關係，我就拿一張圖來說明：（如果你對著不感興趣，可以直接跳過）
瀏覽器的直譯器，是包括在渲染引擎內的，我們常說的Chrome（現在使用的是Blink引擎）和Safari使用的Webkit引擎，Firefox使用的Gecko引擎，指的就是渲染引擎。而在渲染引擎內，還包括著我們的HTML直譯器（渲染時用於構造DOM樹）、CSS直譯器（渲染時用於合成CSS規則）還有我們的JS直譯器。不過後來，由於JS的使用越來越重要，工作越來越繁雜，所以JS直譯器也漸漸獨立出來，成為了單獨的JS引擎，就像眾所周知的V8引擎，我們經常接觸的Node.js也是用的它。
2.2.DOM渲染層與GPU硬體加速
如果我告訴你，一個頁面是有許多許多層級組成的，他們就像千層麵那樣，你能想象出這個頁面實際的樣子嗎？這裡為了便於大家想象，我附上一張之前Firefox的3D View外掛的頁面Layers層級圖：
對，你沒看錯，頁面的真實樣子就是這樣，是由多個DOM元素渲染層（Layers）組成的，實際上一個頁面在構建完render tree之後，是經歷了這樣的流程才最終呈現在我們面前的：
①瀏覽器會先獲取DOM樹並依據樣式將其分割成多個獨立的渲染層
②CPU將每個層繪製進繪圖中
③將點陣圖作為紋理上傳至GPU（顯示卡）繪製
④GPU將所有的渲染層快取（如果下次上傳的渲染層沒有發生變化，GPU就不需要對其進行重繪）並複合多個渲染層最終形成我們的影象
從上面的步驟我們可以知道，佈局是由CPU處理的，而繪製則是由GPU完成的。
其實在chrome中，也為我們提供了相關外掛供我們檢視頁面渲染層的分佈情況，以及GPU的佔用率：（所以說，平時我們得多去嘗試嘗試chrome的那些莫名其妙的外掛，真的會發現好多東西都是神器）
chrome開發者工具選單→more tools→Layers（開啟渲染層功能模組）
chrome開發者工具選單→more tools→rendering（開啟渲染效能監測工具）
執行上面的操作後，你會在瀏覽器裡看到這樣的效果：
太多東西了，分模組講吧：
（一）最先是頁面右上方的小黑窗：其實提示已經說的很清楚了，它顯示的就是我們的GPU佔用率，能夠讓我們清楚地知道頁面是否發生了大量的重繪。
（二）Layers版塊：這就是用於顯示我們剛提到的DOM渲染層的工具了，左側的列表裡將會列出頁面裡存在哪些渲染層，還有這些渲染層的詳細資訊。
（三）Rendering版塊：這個版塊和我們的控制檯在同一個地方，大家可別找不到它。前三個勾選項是我們最常使用的，讓我來給大家解釋一下他們的功能（充當一次免費翻譯）
①Paint flashing：勾選之後會對頁面中發生重繪的元素高亮顯示
②Layer borders：和我們的Layer版塊功能類似，它會用高亮邊界突出我們頁面中的各個渲染層
③FPS meter：就是開啟我們在（一）中提到的小黑窗，用於觀察我們的GPU佔用率
可能大家會問我，和我提到DOM渲染層這麼深的概念有什麼用啊，好像跟效能優化沒一點關係啊？大家應該還記得我剛說到GPU會對我們的渲染層作快取對吧，那麼大家試想一下，如果我們把那些一直髮生大量重排重繪的元素提取出來，單獨觸發一個渲染層，那樣這個元素不就不會“連累”其他元素一塊重繪了對吧。
那麼問題來了，什麼情況下會觸發渲染層呢？大家只要記住：
video元素、WebGL、Canvas、CSS3 3D、CSS濾鏡、z-index大於某個相鄰節點的元素都會觸發新的Layer，其實我們最常用的方法，就是給某個元素加上下面的樣式：
transform: translateZ(0);
backface-visibility: hidden;
複製程式碼這樣就可以觸發渲染層啦(^__^) 。
我們把容易觸發重排重繪的元素單獨觸發渲染層，讓它與那些“靜態”元素隔離，讓GPU分擔更多的渲染工作，我們通常把這樣的措施成為硬體加速，或者是GPU加速。大家之前肯定聽過這個說法，現在完全清楚它的原理了吧。
2.3.重排與重繪
現在到我們的重頭戲了，重排和重繪。先丟擲概念：
①重排（reflow）：渲染層內的元素佈局發生修改，都會導致頁面重新排列，比如視窗的尺寸發生變化、刪除或新增DOM元素，修改了影響元素盒子大小的CSS屬性（諸如：width、height、padding）。
②重繪（repaint）：繪製，即渲染上色，所有對元素的視覺表現屬性的修改，都會引發重繪。
我們習慣使用chrome devtools中的performance版塊來測量頁面重排重繪所佔據的時間：
①藍色部分：HTML解析和網路通訊佔用的時間
②黃色部分：JavaScript語句執行所佔用時間
③紫色部分：重排佔用時間
④綠色部分：重繪佔用時間
不論是重排還是重繪，都會阻塞瀏覽器。要提高網頁效能，就要降低重排和重繪的頻率和成本，近可能少地觸發重新渲染。正如我們在2.3中提到的，重排是由CPU處理的，而重繪是由GPU處理的，CPU的處理效率遠不及GPU，並且重排一定會引發重繪，而重繪不一定會引發重排。所以在效能優化工作中，我們更應當著重減少重排的發生。
這裡給大家推薦一個網站，裡面詳細列出了哪些CSS屬性在不同的渲染引擎中是否會觸發重排或重繪：
csstriggers.com/ （圖片來自官網）
2.4.優化策略
談了那麼多理論，最實際不過的，就是解決方案，大家一定都等著急了吧，做好準備，一大波乾貨來襲：
（一）CSS屬性讀寫分離：瀏覽器沒次對元素樣式進行讀操作時，都必須進行一次重新渲染（重排 + 重繪），所以我們在使用JS對元素樣式進行讀寫操作時，最好將兩者分離開，先讀後寫，避免出現兩者交叉使用的情況。最最最客觀的解決方案，就是不用JS去操作元素樣式，這也是我最推薦的。
（二）通過切換class或者style.csstext屬性去批量操作元素樣式
（三）DOM元素離線更新：當對DOM進行相關操作時，例如innerHTML、appendChild等都可以使用Document Fragment物件進行離線操作，帶元素“組裝”完成後再一次插入頁面，或者使用display:none 對元素隱藏，在元素“消失”後進行相關操作。
（四）將沒用的元素設為不可見：visibility: hidden，這樣可以減小重繪的壓力，必要的時候再將元素顯示。
（五）壓縮DOM的深度，一個渲染層內不要有過深的子元素，少用DOM完成頁面樣式，多使用偽元素或者box-shadow取代。
（六）圖片在渲染前指定大小：因為img元素是內聯元素，所以在載入圖片後會改變寬高，嚴重的情況會導致整個頁面重排，所以最好在渲染前就指定其大小，或者讓其脫離文件流。
（七）對頁面中可能發生大量重排重繪的元素單獨觸發渲染層，使用GPU分擔CPU壓力。（這項策略需要慎用，得著重考量以犧牲GPU佔用率能否換來可期的效能優化，畢竟頁面中存在太多的渲染層對與GPU而言也是一種不必要的壓力，通常情況下，我們會對動畫元素採取硬體加速。）
3.JS阻塞效能
JavaScript在網站開發中幾乎已經確定了壟斷地位，哪怕是一個再簡單不過的靜態頁面，你都可能看到JS的存在，可以說，沒有JS，就基本沒有使用者互動。然而，指令碼帶來的問題就是他會阻塞頁面的平行下載，還會提高程式的CPU佔用率。更有甚者，現在node.js已經在前端開發中普及，稍有不慎，我們引發了記憶體洩漏，或者在程式碼中誤寫了死迴圈，會直接造成我們的伺服器奔潰。在如今這個JS已經遍佈前後端的時代，效能的瓶頸不單單只是停留在影響使用者體驗上，還會有更多更為嚴重的問題，對JS的效能優化工作不可小覷。
在程式設計的過程中，如果我們使用了閉包後未將相關資源加以釋放，或者引用了外鏈後未將其置空（比如給某DOM元素繫結了事件回撥，後來卻remove了該元素），都會造成記憶體洩漏的情況發生，進而大量佔用使用者的CPU，造成卡頓或當機。我們可以使用chrome提供的JavaScript Profile版塊，開啟方式同Layers等版塊，這裡我就不再多說了，直接上效果圖：
我們可以清除看見JS執行時各函式的執行時間以及CPU佔用情況，如果我在程式碼裡增加一行while(true){}, 那麼它的佔用率一定會飆升到一個異常的指標（親測93.26%）。
其實瀏覽器強大的記憶體回收機制在大多數時候避免了這一情況的發生，即便使用者發生了當機，他只要結束相關程式（或關閉瀏覽器）就可以解決這一問題，但我們要知道，同樣的情況還會發生在我們的伺服器端，也就是我們的node中，嚴重的情況，會直接造成我們的伺服器當機，網站奔潰。所以更多時候，我們都使用JavaScript Profile版塊來進行我們的node服務的壓力測試，搭配node-inspector 外掛，我們能更有效地檢測JS執行時各函式的CPU佔用率，針對性地進行優化。
（PS：沒修煉到一定水平，千萬別在服務端使用閉包，一個是真沒啥用，我們會有更多優良的解決辦法，二是真的很容易記憶體洩漏，造成的後果是你無法預期的）
4.【擴充】負載均衡
之所以將負載均衡作為擴充內容，是因為如果是你自己搭建的個人網站，或者中小型網站，其實並不需要考慮多大的併發量，但是如果你搭建的是大型網站，負載均衡便是開發過程不可或缺的步驟。
4.1.Node.js處理IO密集型請求
現在的開發流程都注重前後端分離，也就是軟體工程中常提到的“高內聚低耦合”的思想，你也可以用模組化的思想去理解，前後解耦就相當與把一個專案分成了前端和後端兩個大模組，中間通過介面聯絡起來，分別進行開發。這樣做有什麼好處？我就舉最有實際效果的一點：“非同步程式設計”。這是我自己想的名字，因為我覺得前後解耦的形式很像我們JS中的非同步佇列，傳統的開發模式是“同步”的，前端需要等後端封裝好介面，知道了能拿什麼資料，再去開發，時間短，工程大。而解耦之後，我們只需要提前約定好介面，前後兩端就可以同時開發，不僅高效而且省時。
我們都知道node的核心是事件驅動，通過loop去非同步處理使用者請求，相比於傳統的後端服務，它們都是將使用者的每個請求分配到非同步佇列進行處理，推薦大家去看這樣一篇博文：mp.weixin.qq.com/s?__biz=MzA… 。特別生動地講解了事件驅動的執行機制，通俗易懂。事件驅動的最大優勢是什麼？就是在高併發IO時，不會造成堵塞，對於直播類網站，這點是至關重要的，我們有成功的先例——快手，快手強大的IO高併發究其本質一定能追溯到node。
其實現在的企業級網站，都會搭建一層node作為中間層。大概的網站框架如圖所示：
4.2.pm2實現Node.js“多執行緒”
我們都知道node的優劣，這裡分享一份連結，找了挺久寫的還算詳細：www.zhihu.com/question/19… 。其實都是老套路，那些說node不行的都是指著node是單執行緒這一個軟肋開撕，告訴你，我們有解決方案了——pm2。這是它的官網：pm2.keymetrics.io/ 。它是一款node.js程式管理器，具體的功能，就是能在你的計算機裡的每一個核心都啟動一個node.js服務，也就是說如果你的電腦或者伺服器是多核處理器（現在也少見單核了吧），它就能啟動多個node.js服務，並且它能夠自動控制負載均衡，會自動將使用者的請求分發至壓力小的服務程式上處理。聽起來這東西簡直就是神器啊！而且它的功能遠遠不止這些，這裡我就不作過多介紹了，大家知道我們在上線的時候需要用到它就行了，安裝的方法也很簡單，直接用npm下到全域性就可以了$ npm i pm2 -g具體的使用方法還有相關特性可以參照官網。這裡我在build資料夾內新增了pm2.json檔案，這是pm2的啟動配置檔案，我們可以自行配置相關引數，具體可參考github原始碼，執行時我們只要在上線目錄下輸入命令$ pm2 start pm2.json即可。
下面是pm2啟動後的效果圖：
4.3.nginx搭建反向代理
在開始搭建工作之前，首先得知道什麼是反向代理。可能大家對這個名詞比較陌生，先上一張圖：
所謂代理就是我們通常所說的中介，網站的反向代理就是指那臺介於使用者和我們真實伺服器之間的伺服器（說的我都拗口了），它的作用便是能夠將使用者的請求分配到壓力較小的伺服器上，其機制是輪詢。聽完這句話是不是感覺很耳熟，沒錯，在我介紹pm2的時候也說過同樣的話，反向代理起到的作用同pm2一樣也是實現負載均衡，你現在應該也明白了兩者之間的差異，反向代理是對伺服器實現負載均衡，而pm2是對程式實現負載均衡。大家如果想深入瞭解反向代理的相關知識，我推薦知乎的一個貼子：www.zhihu.com/question/24… 。但是大家會想到，配伺服器是運維的事情啊，和我們前端有什麼關係呢？的確，在這部分，我們的工作只有一些，只需要向運維提供一份配置文件即可。
http {
upstream video {
ip_hash;
server localhost:3000;
}
server {
listen: 8080;
location / {
proxy_pass: http://video
}
}
}
複製程式碼也就是說，在和運維對接的時候，我們只需要將上面這幾行程式碼改為我們配置好的文件傳送給他就行了，其他的事情，運維小哥會明白的，不用多說，都在酒裡。
但是，這幾行程式碼該怎麼去改呢？首先我們得知道，在nginx中，模組被分為三大類：handler、filter和upstream。而其中的upstream模組，負責完成完成網路資料的接收、處理和轉發，也是我們需要在反向代理中用到的模組。接下來我們將介紹配置程式碼裡的內容所表示的含義
4.3.1.upstream配置資訊：
upstream關鍵字後緊跟的識別符號是我們自定義的專案名稱，通過一對花括號在其中增添我們的配置資訊。
ip_hash 關鍵字：控制使用者再次訪問時是否連線到前一次連線的伺服器
server關鍵字：我們真實伺服器的地址，這裡的內容肯定是需要我們去填寫的，不然運維怎麼知道你把專案放在那個伺服器上了，也不知道你封裝了一層node而得去監聽3000埠。
4.3.2.server配置資訊
server是nginx的基本配置，我們需要通過server將我們定義的upstream應用到伺服器上。
listen關鍵字：伺服器監聽的埠
location關鍵字：和我們之前在node層說到的路由是起同樣的功能，這裡是把使用者的請求分配到對應的upstream上
5.擴充閱讀
網站的效能與監測是一項複雜的工作，還有很多很多後續的工作，我之前所提到的這些，也只能算是冰山一角，在熟悉開發規範的同時，也需要實踐經驗的積累。
在翻閱了許多與網站效能相關的書籍後，我還是更鐘情於唐文前輩編著的《大型網站效能監測、分析與優化》，裡面的知識較新，切合實際，至少我讀完一遍後很有收穫、醍醐灌頂，我也希望對效能感興趣的讀者在看完我的文章後能去翻翻這本著作。
這裡筆者還建議大家平時有事沒事可以多去看幾遍雅虎軍規，雖是老生常談，但卻字字珠璣。如果大家能熟記於心更是再好不過了，傳送門：