如何讓網頁“看起來”展現地更快?骨架屏二三事

發表於2018-11-27

讓網頁展現的更快,官方說法叫做首屏繪製,First Paint 或者簡稱 FP,直白的說法叫做白屏時間,就是從輸入 URL 到真的看到內容(不必可互動,那個叫 TTI, Time to Interactive)之間經歷的時間。當然這個時間越短越好。

但這裡要注意,和首屏相關的除了 FP 還有兩個指標,分別稱為 FCP (First Contentful Paint,頁面有效內容的繪製) 和 FMP (First Meaningful Paint,頁面有意義的內容繪製)。雖然這幾個概念可能會讓我們繞暈,但我們只需要瞭解一點:首屏時間 FP 並不要求內容是真實的,有效的,有意義的,可互動的。換言之,隨便 給使用者看點啥都行。

如何讓網頁“看起來”展現地更快?骨架屏二三事

這就是本文標題的玄機了:“看起來”。是的,只是看起來更快,實際上還是那樣。所以本文並不討論效能優化,討論的是一個投機取巧的小伎倆,但的確能夠實實在在的提升體驗。打個比方,效能優化是修煉內功,提升你本身的各項機能;而本文接下來要討論的是一些招式,能讓你在第一時間就唬住對手。

這所謂的招式就是我接下來要談的內容,學名骨架屏,也叫 Skeleton。你可能沒聽過這個名字,但你不可能沒見過它。

骨架屏長什麼樣

如何讓網頁“看起來”展現地更快?骨架屏二三事

這種應該是最常見的形式,使用各種形狀的灰色矩形來模擬圖片和文字。有些 APP 也會使用圓形,但重點都是和實際內容結構近似,不能差距太大。

如果追求效果,還可以在色塊表面新增動畫(如波紋),顯示出一種動態的效果,算是致敬 Loading 了。

如何讓網頁“看起來”展現地更快?骨架屏二三事

在圖片居多的站點,這將會是一個很好的體驗,因為圖片通常載入較慢。如上圖演示中的佔點陣圖片採用了低畫素的圖片,即大體配色和變化是和實際內容一致的。

如果無法生成這樣的低畫素圖片,稍微降級的方案是通過演算法獲取圖片的主體顏色,使用純色塊佔位。

再退一級,還可以使用全站相同的站點陣圖片,或者直接一個統一顏色的色塊。雖說效果肯定不如上面兩種,但也聊勝於無。

骨架屏完全是自定義的,想做成什麼樣全憑你的想象。你想做圓形的,三角形的,立體的都可以,但“佔位”決定了它的特性:它不能太複雜,必須第一時間,最快展現出來。

骨架屏有哪些優勢

大體來說,骨架屏的優勢在於:

  1. 在頁面載入初期預先渲染內容,提升感官上的體驗。
  2. 一般情況骨架屏和實際內容的結構是類似的,因此之後的切換不會過於突兀。這點和傳統的 Loading 動圖不同,可以認為是其升級版。
  3. 只需要簡單的 CSS 支援 (涉及圖片懶載入可能還需要 JS ),不要求 HTTPS 協議,沒有額外的學習和維護成本。
  4. 如果頁面採用元件化開發,每個元件可以根據自身狀態定義自身的骨架屏及其切換時機,同時維持了元件之間的獨立性。

骨架屏能用在哪裡

現在的 WEB 站點,大致有兩種渲染模式:

前端渲染

由於最近幾年 Angular/React/Vue 的相繼推出和流行,前端渲染開始佔據主導。這種模式的應用也叫單頁應用(SPA, Single Page Application)。

前端渲染的模式是伺服器(多為靜態伺服器)返回一個固定的 HTML。通常這個 HTML 包含一個空的容器節點,沒有其他內容。之後內部包含的 JS 包含路由管理,頁面渲染,頁面切換,繫結事件等等邏輯,所以稱之為前端渲染。

因為前端要管理的事情很多,所以 JS 通常很大很複雜,執行起來也要花較多的時間。在 JS 渲染出實際內容之前,骨架屏就是一個很好的替補隊員。

後端渲染

在這波前端渲染流行之前,早期的傳統網站採用的模式叫做後端渲染,即伺服器直接返回網站的 HTML 頁面,已經包含首頁的全部(或絕大部分) DOM 元素。其中包含的 JS 的作用大多是繫結事件,定義使用者互動後的行為等。少量會額外新增/修改一些 DOM,但無礙大局。

此外,前端渲染的模式存在 SEO 不友好的問題,因為它返回的 HTML 是一個空的容器。如果搜尋引擎沒有執行 JS 的能力(稱為 Deep Render),那它就不知道你的站點究竟是什麼內容,自然也就無法把站點排到搜尋結果中去。這對於絕大部分站點來說是不可接受的,於是前端框架又相繼推出了服務端渲染(簡稱 SSR, Server Side Rendering)模式。這個模式和傳統網站很接近,在於返回的 HTML 也是包含所有的 DOM,而非前端渲染。而前端 JS 除了繫結事件之外,還會多做一個事情叫做“啟用”(hydration),這裡就不再贅述了。

不論是傳統模式還是 SSR,只要是後端渲染,就不需要骨架屏。因為頁面的內容直接存在於 HTML,所以並沒有骨架屏出場的餘地。

骨架屏怎麼用

討論了一波背景,我們來看如何使用。首先先無視具體的實現細節,先看思路。

實現思路

大體分為幾個步驟:

  • 往本應為空的容器節點內部注入骨架屏的 HTML。
    骨架屏為了儘快展現,要求快速和簡單,所以骨架屏多數使用靜態的圖片。而且把圖片編譯成 base64 編碼格式可以節省網路請求,使得骨架屏更快展現,更加有效。
  • 在執行 JS 開始真正內容的渲染之前,清空骨架屏 HTML
    以 Vue 為例,即在 mount 之前清空內容即可。

僅此兩步,並不牽涉多麼複雜的機制和高階的 API,因此非常容易應用,趕快用起來!

示例

我編寫了一個示例,用於快速展現骨架屏的效果,程式碼在此

  • index.html
    預設包含了骨架屏,並且內聯了樣式(以 <style> 標籤新增在頭部)。
  • render.js
    它負責建立 DOM 元素並新增到 <body> 上,渲染頁面實際的內容,用來模擬常見的前端渲染模式。
  • index.css
    頁面實際內容的樣式表,不包含骨架屏的樣式。

程式碼的三個檔案各司其職,配合上面的實現思路,應該還是很好理解的。可以在 這裡 檢視效果。

因為這個示例的邏輯太過簡單,而實際的前端渲染框架複雜得多,包含的功能也不單純是渲染,還有狀態管理,路由管理,虛擬 DOM 等等,所以檔案大小和執行時間都更大更長。我們在檢視例子的時候,把網路調成 “Fast 3G” 或者 “Slow 3G” 能夠稍微真實一些。

但匪夷所思的是,對著這個地址重新整理試幾次,我也基本看不到骨架屏(骨架屏的內容是一個居中的藍色方形圖片,外加一條白色橫線反覆側滑的高亮動畫)。是我們的實現思路有問題嗎?

瀏覽器的奧祕:減少重排

為了排除肉眼的遺漏和干擾,我們用 Chrome Dev Tools 的 Performance 工具來記錄剛才發生了什麼,截圖如下:(截圖時的網路設定為 “Fast 3G”)

如何讓網頁“看起來”展現地更快?骨架屏二三事

我們可以很明顯地看到 3 個時間點:

  1. HTML 載入完成了。瀏覽器在解析 HTML 的同時,發現了它需要引用的 2 個外部資源 index.js 和 index.css,於是傳送網路請求去獲取。
  2. 獲取成功後,執行 JS 並註冊 CSS 的規則。
  3. JS 一執行,很自然的渲染出了實際的內容,並應用了樣式規則(隨機顏色的橫條)。

我們的骨架屏呢?按照預想,骨架屏應該出現在 1 和 2 之間,也就是在獲取 JS 和 CSS 的同時,就應該渲染骨架屏了。這也是我們當時把骨架屏的 HTML 注入到 index.html, 還把 CSS 從 index.css 中分離出來的良苦用心,然而瀏覽器並不買賬。

這其實和瀏覽器的渲染順序有關。

相信大家都整理過行李箱。我們在整理行李箱時,會根據每個行李的大小合理安排,大的和小的配合,填滿一層再放上面一層。現在突然有人跑來跟你說,你的電腦不用帶了,你要多帶兩件衣服,你不能帶那麼多瓶礦泉水。除了想打他之外,為了重新整理行李箱,必然需要把整理好的行李拿出來再重新放。在瀏覽器中這個過程叫做重排 (reflow),而那個餿主意就是新載入的 CSS。顯而易見,重排的開銷是很大的。

熟能生巧,箱子理多了,就能想出解決辦法。既然每個 CSS 檔案載入都可能觸發重繪,那我能不能等所有 CSS 載入完了一起渲染呢?正是基於這一點,瀏覽器會等 HTML 中所有的 CSS 都載入完,註冊完,一起應用樣式,力求一次排列完成工作,不要反覆重排。看起來瀏覽器的設計者經常出差,因為這是一個很正確的優化思路,但應用在骨架屏上就出了問題。

我們為了儘早展現骨架屏,把骨架屏的樣式從 index.css 分離出來。但瀏覽器不知道,它以為骨架屏的 HTML 還依賴 index.css,所以必須等它載入完。而它載入完之後,render.js 也差不多載入完開始執行了,於是骨架屏的 HTML 又被替換了,自然就看不到了。而且在等待 JS, CSS 載入的時候依然是個白屏,骨架屏的效果大打折扣。

所以我們要做的是告訴瀏覽器,你放心大膽的先畫骨架屏,它和後面的 index.css 是無關的。那怎麼告訴它呢?

告訴瀏覽器先渲染骨架屏

我們在引用 CSS 時,會使用 <link rel="stylesheet" href="xxxx> 這樣的語法。但實際上,瀏覽器還提供了其他一些機制確保(後續)頁面的效能,我們稱之為 preload,中文叫預載入。具體來說,使用 <link rel="preload" href="xxxx">,提前把後續要使用的資源先宣告一下。在瀏覽器空閒的時候會提前載入並放入快取。之後再使用就可以節省一個網路請求。

這看似無關的技術,在這裡將起到很大的作用,因為 預載入的資源是不會影響當前頁面的

我們可以通過這種方式,告訴瀏覽器:先不要管 index.css,直接畫骨架屏。之後 index.css載入回來之後,再應用這個樣式。具體來說程式碼如下:

方法的核心是通過改變 rel 可以讓瀏覽器重新界定 <link> 標籤的角色,從預載入變成當頁樣式。(另外也有文章採用修改 media 的方法,但瀏覽器支援度較低,這裡不作展開了。我把文章列在最後了)這樣的話,瀏覽器在 CSS 尚未獲取完成時,會先渲染骨架屏(因為此時的 CSS 還是 preload,也就是後續使用的,並不妨礙當前頁面)。而當 CSS 載入完成並修改了自己的 rel之後,瀏覽器重新應用樣式,目的達成。

不得不考慮的注意點

事實上,並不是把 rel="stylesheet" 改成 rel="preload" 就完事兒了。在真正應用到生產環境之前,我們還有很多事情要考慮。

相容性考慮

首先,在 <link> 內部我們使用了 onload,也就是使用了 JS。為了應對使用者的瀏覽器沒有開啟指令碼功能的情況,我們需要新增一個 fallback。(不過這點對於單頁應用來說可能也無所謂,因為如果沒有指令碼,那頁面實際內容也渲染不出來的)

其次,rel="preload" 並不是沒有相容性問題。對於不支援 preload 的瀏覽器,我們可以新增一些 polyfill 程式碼(來使所有瀏覽器獲得一致的效果。

polyfill 的壓縮程式碼可以參見 Lavas 的 SPA 模板第 29 行

載入順序

不同於傳統頁面,我們的實際 DOM 是通過 render.js 生成的。所以如果 JS 先於 CSS 執行,那將會發生跳動。(因為先渲染了實際內容卻沒有樣式,而後樣式載入,頁面出現很明顯的變化)所以這裡我們需要嚴格控制 CSS 早於渲染。

JS 對外暴露一個 mountApp 方法用於渲染頁面(其實是模擬 Vue 的 mount

如果 CSS 更快載入完成,那麼通過設定 window.STYLE_READY 允許 JS 載入完成後直接執行;而如果 JS 更快,則先不自己執行,而是把機會留給 CSS 的 onload

清空 onload

loadCSS 的開發者提出,某些瀏覽器會在 rel 改變時重新出發 onload,導致後面的邏輯走了兩次。為了消除這個影響,我們再在 onload 裡面新增一句 this.onload=null

最終的 CSS 引用方式

修改後的效果

修改後的程式碼在 這裡,訪問地址在 這裡。(為了簡便,我省去了處理相容性的程式碼,即 <noscript> 和 preload polyfill)

Performance 截圖如下:(依然採用了 “Fast 3G” 的網路設定)

如何讓網頁“看起來”展現地更快?骨架屏二三事

這次在 render.js 和 index.css 還在載入的時候頁面已經呈現出骨架屏的內容,實際肉眼也可以觀測到。在截圖的情況下,骨架屏的展現大約持續了 300ms,佔據整個網路請求的大約一半時間。

至於說為什麼不是 HTML 載入完成立馬展現骨架屏,而是還要等大約 300ms 才展現,從圖上看是瀏覽器 ParseHTML 所花費的時間,可能在 Dev Tools 開啟的情況下計算資源有限,不過可優化空間已經不大。(可能簡化骨架屏的結構能起一些作用吧)

多骨架屏的支援

一般來說一個站點的所有頁面不太可能是同一種展示型別。例如說首頁和內部頁面就展示風格而言會很有區別,另外例如列表頁和搜尋頁比較接近(可能都有列表展示),但和詳情頁(可能是商品,服務,個人資訊,部落格文章等等)就會很不相同。但單頁應用的 index.html 只有一個,所有的變化都源自前端渲染框架在容器節點內部進行改變。所以直接將骨架屏注入到 index.html中會導致所有的頁面都用同一個骨架屏,那就很難達成“和實際內容結構類似”的目標了,骨架屏就退化為 Loading 了。

為了要支援多種骨架屏,我們需要在 index.html 裡面進行判斷邏輯(獨立於主體 JS 之外),具體來說:

  1. 把所有種類的骨架屏的 HTML 和樣式全部寫入 index.html
  2. 在 index.html 底下新增內聯的指令碼 <script>,根據當前路由判斷應該展示哪一個骨架屏

這樣會導致 index.html 體積變大一點,但整體感覺依然是收益大於付出,我認為是值得的。

後記

這個優化點最早由我的前同事 xiaop 同學 在開發 Lavas 的 SPA 模板中發現並完成的,Issue 記錄在此。我在他的基礎上,做了一個分離 Lavas 和 Vue 環境並且更直白的例子,讓截圖也儘可能易於理解,方便閱讀。在此非常感謝他的工作!

另外骨架屏的編寫我全部採用的是純粹的手寫 HTML 和 CSS,不止展現邏輯,包括開發流程也是獨立於單頁應用其他常規頁面的。當然這可能給開發者帶來一點不便,所以這時候需要推出 xiaop 同學的利器:vue-skeleton-webpack-plugin。它的作用是把骨架屏本身也當成一個 Vue 元件,配上單獨的路由規則來統一在 Vue 專案中的開發體驗,最後使用 webpack 在打包構建的時候加以區分並注入,對於使用 Vue + webpack 開發的同學來說可以一試。

參考文章

相關文章