聊聊關於性能優化和其餘（一）

聊聊關於性能優化（一）

隔了許久都沒有更新博客，前一陣子是由於忙其餘事去了，如今想寫點什麼，可是思前想後不知道該寫些什麼，這是這個系列的第一篇，這篇文章沒有乾貨，只是聊聊關於前端優化，關於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、可視化將變成主流，圖像和動畫交互將是個長期熱點

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