相比於早些年前後端程式碼緊密耦合、後端工程師還得寫前端程式碼的時代,如今已發展到前後端分離,這種開發方式大大提升了前後端專案的可維護性與開發效率,讓前後端工程師關注於自己的主業。然而在帶來便利的同時,也帶來了一些弊端,比如首屏渲染時間(FCP)因為首屏需要請求更多內容,比原來多了更多HTTP的往返時間(RTT),這造成了白屏,如果白屏時間過長,使用者體驗會大打折扣,如果使用者網速差,則FCP會更長。
由此引申出一系列的優化方法,骨架屏也因此被提出。
1. FCP優化
在 Google 提出的以使用者為中心的四個頁面效能衡量指標中,FP/FCP可能是開發者們最熟悉的了:
為了優化首屏渲染時間這個指標,減少白屏時間,前端仔們想了很多辦法:
- 加速或減少HTTP請求損耗:使用CDN載入公用庫,使用強快取和協商快取,使用域名收斂,小圖片使用Base64代替,使用Get請求代替Post請求,設定
Access-Control-Max-Age
減少預檢請求,頁面內跳轉其他域名或請求其他域名的資源時使用瀏覽器prefetch預解析等; - 延遲載入:非重要的庫、非首屏圖片延遲載入,SPA的元件懶載入等;
- 減少請求內容的體積:開啟伺服器Gzip壓縮,JS、CSS檔案壓縮合並,減少cookies大小,SSR直接輸出渲染後的HTML等;
- 瀏覽器渲染原理:優化關鍵渲染路徑,儘可能減少阻塞渲染的JS、CSS;
- 優化使用者等待體驗:白屏使用載入進度條、菊花圖、骨架屏代替等;
這裡要介紹的就是優化使用者等待體驗的骨架屏,它可以被視為是原來載入菊花圖的一種升級版,結合傳統的首屏優化方法對應用進行優化可以達到不錯的效果。
2. 骨架屏
骨架屏可以理解為是當資料還未載入進來前,頁面的一個空白版本,一個簡單的關鍵渲染路徑。可以看一下下面Facebook的骨架屏實現,可以看到在頁面完全渲染完成之前,使用者會看到一個樣式簡單,描繪了當前頁面的大致框架的骨架屏頁面,然後骨架屏中各個佔位部分被實際資源完全替換,這個過程中使用者會覺得內容正在逐漸載入即將呈現,降低了使用者的焦躁情緒,使得載入過程主觀上變得流暢。
可以看一下下面的示例圖,第一個為骨架屏,第二個為菊花圖,第三個為無優化,可以看到相比於傳統的菊花圖會在感官上覺得內容出現的流暢而不突兀,體驗更加優良。
如今這項技術已經在Facebook、Google、支付寶、餓了麼、簡書、新浪微博、知乎、美團、領英等公司的產品中被廣泛的使用。在論壇和社群也都有不少文章討論骨架屏的實現和使用場景等。
3. 生成骨架屏的方法
生成骨架屏的方式主要有:
- 手寫HTML、CSS的方式為目標頁定製骨架屏
做法可以參考<Vue頁面骨架屏注入實踐>,主要思路就是使用 vue-server-renderer 這個本來用於服務端渲染的外掛,用來把我們寫的
.vue
檔案處理為HTML
,插入到頁面模板的掛載點中,完成骨架屏的注入。這種方式不甚文明,如果頁面樣式改變了,還得改一遍骨架屏,增加了維護成本。 骨架屏的樣式實現參考 CodePen - 使用圖片作為骨架屏; 簡單暴力,讓UI同學花點功夫吧哈哈;小米商城的移動端頁面採用的就是這個方法,它是使用了一個Base64的圖片來作為骨架屏。
- 自動生成並自動插入靜態骨架屏 這種方法跟第一種方法類似,不過是自動生成骨架屏,可以關注下餓了麼開源的外掛 page-skeleton-webpack-plugin ,它根據專案中不同的路由頁面生成相應的骨架屏頁面,並將骨架屏頁面通過 webpack 打包到對應的靜態路由頁面中,不過要注意的是這個外掛目前只支援history方式的路由,不支援hash方式,且目前只支援首頁的骨架屏,並沒有元件級的區域性骨架屏實現,作者說以後會有計劃實現(issue9)。
另外還有個外掛 vue-skeleton-webpack-plugin,它將插入骨架屏的方式由手動改為自動,原理在構建時使用 Vue 預渲染功能,將骨架屏元件的渲染結果 HTML 片段插入 HTML 頁面模版的掛載點中,將樣式內聯到 head
標籤中。這個外掛可以給單頁面的不同路由設定不同的骨架屏,也可以給多頁面設定,同時為了開發時除錯方便,會將骨架屏作為路由寫入router中,可謂是相當體貼了。
vue-skeleton-webpack-plugin
的具體使用參考 vue-style-codebase,主要關注build目錄的幾個檔案,線上Demo 在Chrome的DevTools中把network的網速調為Gast 3G / Slow 3G
就能看到效果了~
網上的帖子大多深淺不一,甚至有些前後矛盾,在下的文章都是學習過程中的總結,如果發現錯誤,歡迎留言指出~
參考:
PS:歡迎大家關注我的公眾號【前端下午茶】,一起加油吧~