iT邦幫忙

DAY 9
0

30 天學會 Web 前端效能優化系列 第 9

[30 天學會 Web 前端效能優化] 9. flush early, flush often

上一篇我們提到了 DOM Construction ,這一篇我們來談談一個優化技法。

首先要跟大家提一個觀念,Browser 並不會等到所有 HTML Document 都抵達才開始 parse ,只要一有東西送來,就會立刻進行 parsing 的動作。

一般傳統網站都是整份 HTML Document 都產生之後才會傳送給 client ,事實上這樣非常沒效率,假設現在 Backend 程式正在處理一段比較耗時的動作,這段等待的期間不就浪費掉了?從 Server 傳到 Client 是需要時間的,如果我們可以盡快地把HTML Document 的一些部分傳給 Client , Client 便不會無事可做,尤其若我們盡快將 head 部分傳給 client ,瀏覽器就可以立即將所需的 CSS、JS 都抓下來,之後等 Backend 程式處理完、傳回後面剩餘的 chunk 後,就不需要花費額外的時間去抓所需的 component 了。

這就是這一篇文章要介紹的技法-flushing。簡單來說,可以總結成一句口訣:flush early, flush often。

我知道 Rails 有實作這個功能,聽說 Django 也有(不過我沒寫過所以不太確定)。各程式語言、Framework 要怎麼做到這件事,各位可以自行 Google ,應該可以查到資料。

Chrome 裡面的開發人員工具可以讓我們知道 HTML Document 的 First Packet 抵達所花的時間。最後讓我們介紹一下這項功能。

我們以台灣 Google 為例,請大家使用 Chrome 打開 Google 搜尋首頁,並且記得打開開發人員工具 -> Network,應該會看到如下的畫面:

請注意我在圖片標注紅色的部分,Latency 那邊,黑色字體寫的是抓整個 HTML Document 所花費的時間,而灰色字體寫的是 First Chunk 抵達所花費的時間。你仔細看就會發現開發人員工具會顯示每一個東西從 server 傳到 client 所花的時間,以及是在哪個時間點送出 request 的,非常詳細。


上一篇
[30 天學會 Web 前端效能優化] 8. 瀏覽器是如何建構 DOM 的?
下一篇
[30 天學會 Web 前端效能優化] 10. CSSOM
系列文
30 天學會 Web 前端效能優化30

尚未有邦友留言

立即登入留言