聊聊關於效能優化（一）

隔了許久都沒有更新部落格，前一陣子是因為忙其他事去了，現在想寫點什麼，但是思前想後不知道該寫些什麼，這是這個系列的第一篇，這篇文章沒有乾貨，只是聊聊關於前端優化，關於5G的到來，關於前端的未來。

關於為什麼要優化

前端的大咖們在推動前端屆蓬勃發展的同時，越來越多的人能抄起手上的工具（ React、Vue、Angular ）加上各種 CLI 一鍵生成， 再加上天然的 UI 庫（ Antd、Element-UI、iView、Bootstrap ）就能快速構建寫出一個使用者介面，加上在這個效能過剩的年代，非大廠能夠投入人力優化前端效能，大部分網頁能載入出來功能沒問題就告之大吉，只要不是太 過分 的程式碼編寫，一般來說，電腦端的網頁載入也就差個 1~3 秒，更多的則是網路問題。

這麼一看，效能優化彷彿不是那麼重要，但是由於前端圈的蓬勃發展，越來越多的功能實現放置在前端頁面上，現代的網站擁有比以往多很多的功能，頁面數量都是幾倍的增長，甚至該網站是這個企業的核心業務，尤其是這幾年移動裝置的爆發式發展，如果這麼多的功能放置在移動端時，輕微的效能問題可能只會導致輕微的延遲、等待，僅僅會給使用者帶來短暫的不便，但是嚴重的效能問題就會導致使用者無法訪問或者無法響應使用者的動作之類，很多人意識到這個問題，可惜的是，大部分網站都將這個原因歸結於網路條件不好或者使用者裝置太差，從而忽略真正的前端效能的優化。

對於一般網站來說，使用者進入瀏覽，關心的是自己的使用者體驗、網頁瀏覽舒適度，他們很大一部分並不關心網路和裝置問題，有很多資料表明，一個網站的舒適度決定了使用者的去留。

對不起，我真的不想等（優化和使用者去留的關係）

我們希望我們所構建的頁面能和使用者進行互動，而不是呆板的純靜態頁面，一個可互動的頁面可以留存很多的使用者。

如果我們構建的是部落格，我們希望使用者能順暢的讀完博文，並給予點評。

如果我們構建的是商城系統，我們希望使用者能快速精準的定位到需要購買的商品。

如果我們構建的是社交系統，我們希望使用者能快速找到對應的人並進行彼此的互動。

而這一切，差異化是一條出路，但是差異化很容易就被抄襲、模仿，企業更多的這是面對同質化的紅海競爭，與此同時，效能扮演著至關重要的角色。

有幾組資料來表明效能優化與使用者留存的關係：

• 使用者等待感知時間減少 40%，Priterest 的搜尋引擎流量和註冊人數增長 15%
• 平均載入時間減少 850 毫秒，COOK 使用者轉化率提升 7%，流失率下降 7%，平均瀏覽頁數增加 10%
• BBC 發現其網站載入時間每增加一秒，使用者便會流失 10%
• DoubleClick by Google 發現，如果移動裝置頁面載入時間超過 3 秒，53%的使用者將停止訪問

根據 DoubleClick by Google 更多研究，如果一個網站載入時間越短，優勢越大。

根據大量測試發現，同一個頁面，載入時間 19 秒和載入時間 5 秒是兩種截然不同的結果，載入在 5 秒之內的網站，使用者瀏覽率增長 70%，流失率下降 35%，廣告可見率提升 25%。

大家可以使用 Speed Scorecard 工具進行移動網站的載入速度測試，由於沒有中國大陸節點，大家移步至香港節點進行測試。

以下是我對一些常用網站4G載入的測試：

高優化和收入的關係

從上一小節可以看出來，一個好的優化可以提升使用者的轉化率，反之流失率會大大增加。

下面一些小栗子顯示了一些優化對收入的影響：

• 根據 Mobify 研究發現，首頁載入時間每減少 100 毫秒，使用者留存率就會增加 1.11% ，年收入增長近 380,000 美元。此外，結賬頁面載入時間每減少 100 毫秒，使用者付款率增長 1.55%，從而，年均收入增長近 530,000 美元。
• DoubleClick 發現網站載入時間在 5 秒內的服務商比網站載入時間在 19 秒內的服務商的廣告收入增長一倍多。
• AutoAnything 的頁面載入時間減少一半，其銷售額提升 12%-13%。
• 支付寶和微信開通離線支付，無網路也可以支付。

使用者體驗的哲學

關於載入速度

當使用者在用移動裝置訪問某一個網站時，由於各種外在條件的因素（網速、裝置硬體條件），開啟同一網站的效果可能截然不同（某錘官網）：

• 在 Fast 3G 情況下大概使用了 34 秒全部載入完畢：

  

• 在 模擬 4G（5MB/s） 的速度下大概使用了 11 秒全部載入完畢：

  

然而，實際情況下，由於地理位置、人流量等環境因素，很少有移動裝置能滿速 5MB 的下載。 而使用者體驗的基礎是在於已經看到顯示的內容，在此之前就談不上使用者體驗，如果網路較快可能還好點，如果網速不好，使用者就不得不等待，還可能會遇到各種各樣的問題，例如，JS 載入不完整導致點選事件無效等。 全部載入完畢之後的某錘網站使用感覺還可以，我們來看一下此次載入了多少 JS 資源：

居然有一個 JS 檔案達到了 2.3MB，這顯然是不合理的，縱使網站優化再好，載入很慢就會導致使用者的不耐煩。

關於程式碼優化

得益於現在移動端 CPU 的高速發展，甚至有些媲美桌面端處理器，但是使用者不可能一直手持最新裝置，所有現在不要高估了移動端的處理器，其計算能力和記憶體大小依舊有限。

一些未經優化的程式碼，我們在 Chrome 下除錯可能沒覺得有差，但是到移動裝置上時，就會出現各種各樣的問題，當問題多到一定程度時，使用者必然忍受不了，將其拋棄。

利用 Google 提供的 Lighthouse 外掛，我們可以直觀的分析一個網站的優劣，以及優化點，讓我們有方向的去改進：

嗯，再看看我們的掘金（還是挺不錯滴）：

優化關乎使用者成本

這是一個最好的時代，所有的一切都在迅速發展；這是一個最壞的時代，漸漸地越來越多的人們跟不上時代的步伐（比如我們的父母，哎）。

未來一定是移動的世界。

根據 statcounter 統計，全球範圍內，移動端裝置佔據了較大比例，這一比例在中國更大，甚至佔到了 70%-80%，我們要記住，絕大多數使用者都是通過 LTE、4G、3G 訪問網路，在 2017 年，Ben Schwarz做出真實網路與優化的調查：Beyond the Bubble: Real world performance 顯示，愈加成熟的網路建設背後，使用者資料流量的成本正在逐漸下滑，到了 5G 時代又是另一番景象，這個我們下面再討論。

這一現象表明，幾乎任何使用者都可以廉價的訪問網路，在這個互通互聯的時代，網路幾乎成為我們生活的必需品。

另一研究表明，從 2011 年起，網站頁面數量就開始穩步增長，其中移動端的 URL 總數甚至超過了桌面端，更多統計資料點選 這裡 檢視：

上圖統計發現，2011 年起，網站頁面數量就開始穩步增長，尤其是近幾年，得益於移動端的爆發式增長，桌面端也配套了對應的頁面，但是增速仍然低於移動端。

這一趨勢發展下去，意味著我們需要花費更多的流量（貌似現在已經是這樣了）。

關於如何優化

效能優化並不是一件很難得事，但也絕對不輕鬆，做到以下幾點便提升效能，這次沒有具體的實施細節，只有一些建議。

關於資源的載入

構建一個高效能高效的 WEBAPP 最為有效的一個注意點就是，檢查使用者在進入頁面時，到底載入了多少有效的資源，又載入了多少無效的資源。儘管我們可以從 Chrome DevTools 的 Network 皮膚檢視所有已載入的資源，但是如果開發者從未關注過，不知該如何下手，可以看看以下幾個意見：

• 如果使用網上開源的 UI 庫，例如：Bootstrap、Antd 來構建自己的介面，在做之前詢問自己是不是一定要用，結合自身的專案需求，但至少應做到按需引入而不是在 app.js 裡全部引入這些樣式和元件。另外，若使用 link 標籤來引入資源，這些資源在網站資源載入之前載入，可能會有些阻礙。
• 多使用 Flex 和 Grid 來進行佈局，這兩種佈局方式可以使用較少的程式碼來實現簡單或複雜的佈局。
• CSS 載入是一種阻塞瀏覽器渲染的資源（以後會聊到），使用 CSS 框架的消耗某些情況下會導致渲染延遲嚴重，最好視情況引用資源，加速渲染。
• JavaScript 庫十分方便，但是不一定是必須的。例如 JQuery，現代瀏覽器都支援了 querySelector 和 querySelectorAll 等，能夠快捷的選擇元素。addEventListener 可以輕鬆的繫結事件。classList、setAttribute 和 getAttribute 提供了類和元素屬性的簡便方法。如果不得已一定要使用庫，請選擇合適並且佔用空間較小的替代產品，例如使用 dayjs 來代替 moment.js、Zepto 代替 JQuery 、 Preact 代替 React 等。
• 得益於網路條件日益變好和 WEBAPP 的迅猛發展，現在很多一部分企業選擇 SPA 作為首選，此類應用通常需要載入大量的JavaScript，例如上面的某錘科技。根據 Addy Osmani 釋出的文章 The Cost Of JavaScript 分析發現，此類資源必須經過下載、解析、編譯和執行這一過程，瀏覽器會花費很長時間解析/編譯程式碼，嚴重時會嚴重延遲使用者與網站互動的時間。因此網站傳送的 JavaScript 越多，網站進行互動之前解析和編譯它所需的時間就越長。但是這並不是說 SPA 不可取，合理使用 HTTP 快取或者 Service Worker，相比傳統的多頁面網站，經過優化的 SPA 網站往往能提供更好的使用者體驗。

關於資源的傳輸

• 遷移至 HTTP2，相比HTTP1.1，HTTP2 能夠提升至少 50% 資源的獲取速度，並解決 HTTP1.1 固有的效能問題，例如併發請求數的限制、缺乏標頭壓縮。
• 在上面使用者成本那裡統計圖可以看出來，現代網站的大小也在逐漸增加，在 HTTP1 中， 由於併發請求數量的限制（瀏覽器通常是 6 個），常見的做法是將 CSS 和 JavaScript 捆綁打包成較大的 bundle，但是這麼做及其影響資源的載入，對效能造成不利的影響。而在 HTTP2 之後不需要考慮此問題，因為 HTTP2 採用流傳輸，可以一次請求多個檔案，極大的提升了效能，趕緊讓後端小夥伴支援 HTTP2 吧！
• 採用 Webpack 程式碼拆分技術，僅下載目前需要用到的指令碼，合理的拆分模組並且合理利用 HTTP1.1 協議傳輸，同樣能夠大幅提升載入速度。

關於資源的大小

• 壓縮 HTML，CSS，JS，充分利用 Webpack 的能力，將各種資源打包壓縮，這會大大減少資源的大小，而且不會影響功能。
• 利用 UglifyJS 將 JS 的內容醜化（變數名壓縮），它會通過縮短變數名和函式名來節省空間。
• 利用 SVGO 優化 SVG 檔案。
• 利用 GZIP 方式進行資源再次壓縮。但是請記住，壓縮能只能加快資源載入速度，並不是解決效能問題的萬能方法。
• 如果有充足的時間，可以利用 WebP 格式代替 JPEG 或者 PNG，它能使用及其少量的資料保持和傳統圖片格式一樣的高質量水平。
• 使用 自適應圖片。最簡單的，使用 <img> 標籤中的 srcset 屬性，以指定瀏覽器可以選擇的一組影象。
• 使用視訊而不是 GIF。同等畫質下，視訊大小會比 GIF 小 80% 左右。

關於 5G 的到來

什麼是 5G ？

寫下這篇文章的時候，第一批支援 5G 的手機已經發布了。

在實驗室測試結果上看，5G 的速度是 4G 的 65000 倍，能夠直接實時傳輸 4K 流媒體，同時，5G 網路將具有接近零延遲。4G 的平均延遲 50 毫秒，當切割到 5G 後，只有 1 毫秒，這是 GSMA 設定的基準。

5G 的來臨能改變很多行業，例如，視訊直播互動，雲，虛擬現實、擴增實境，前端等行業，同時同等流量下的資費肯定愈發變低，頻寬問題也可能不再是問題了。

隨著技術的升級，HTTP2 也一定會越來越普遍，檔案大小和數量可能不再是問題，以後優化的重點可能就是對應於瀏覽器（客戶端）的優化，如何提升使用者的使用體驗可能是那個時候最重要的吧。

由於傳輸技術的巨大升級，一些很酷的客戶端技術未來將可能在前端實現，隨用隨訪問，比如 CAD 製圖，power bi 等。

瀏覽器的地位將越來越重要。

目前來說，4G 的頻寬已經足夠，5G 的到來也只是加快了資源載入速度，最終阻礙 WebApp 的還是使用者體驗的問題，是有限的顯示效果，不流暢的滑動，Native 硬體支援不完善，底下的效能等等，才是最重要的原因。

關於前端的未來

這幾年前端層出不窮的框架技術讓人有一種學不動的感覺，但是這大多是都是圍繞著瀏覽器而進行的。

在我看來，其實就分兩個端，客戶端和服務端。一個和使用者打交道，一個和伺服器打交道而已。

真正讓人興奮不已的技術革新，Flutter、RN、WebAssembly、PWA 等技術讓人眼前一亮； nodeJS 包攬後端一部分功能，讓人心花怒放； 小程式 這種於 APP 之內的微小應用即用即開的能力。

未來

• Rxjs 可以應對低延遲和萬物互聯的複雜非同步
• Web Worker 不阻塞主執行緒，高重新整理率的渲染頁面
• 5G 的低延遲意味著渲染交給伺服器沒有問題，開啟網頁玩大型主機遊戲也不是夢想
• 隨著瀏覽器的更新，WebGL/OpenGL/Canvas 的能力被完全挖掘出來，Web 3D、Web VR、視覺化將變成主流，影象和動畫互動將是個長期熱點

總之，前端的路是光明的。