聊聊關於性能優化（一）
隔了許久都沒有更新博客，前一陣子是因為忙其他事去了，現在想寫點什么，但是思前想后不知道該寫些什么，這是這個系列的第一篇，這篇文章沒有干貨，只是聊聊關於前端優化，關於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 的速度是 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、可視化將變成主流，圖像和動畫交互將是個長期熱點
總之，前端的路是光明的。