前面我們已經學習 Browser 是如何運作的了，從這一篇開始，我們會繼續針對一些前面沒講到的特性繼續作說明。

假設今天瀏覽器取得以下頁面 ：

  <link href="layout.css" rel="stylesheet" type="text/css" />


  <p>Hello this is a test page.</p>

瀏覽器取得此 HTML Document 後便開始進行 parsing ，當它遇到 CSS 那一段時，就會立刻 dispatch 一個 request 去取得 CSS file，接著 HTML Parser 又會繼續執行它的工作。

假設取得這一份 CSS ，從 server 到 client 需要花費 200ms ，但是因為這份 HTML 行數很少的關係，在瀏覽器 dispatch 一個 request 取得 CSS file 後，瀏覽器只花了 10ms 就完成解析 HTML 的動作，即使如此，我們仍必須花費 190ms 等待 CSS file 的抵達，外加 10ms 解析、建構 CSSOM 的時間才能完成整個頁面的 Rendering。為什麼這麼說？

如果各位還記得前面提到的內容的話，就會知道瀏覽器完成一個頁面的 rendering 需要經過：建構 DOM -> 建構 CSSOM -> 建構 Render Tree -> Layout -> Paint 等階段，而 Render Tree 是 DOM 和 CSSOM 的結合，因此今天就算 DOM 建構完成了，如果 CSSOM 還沒完成的話，還是無法進入 Rendering 的階段，也就是說使用者是無法看到任何內容的。這就是為什麼許多 Web 前端優化的 Best Practice 會提到將 CSS 放在 HTML Document 越上面越好，因為越快取得 CSS ，意味著可以越快完成 Rendering。

不過如果 CSS 很小的話，直接使用 inline CSS 是更好的，為什麼呢？假設 CSS 只有以下幾行：

body {
  width: 80%;
  margin: 0 auto;
}
p {
  font-size: 15px;
}

那麼如果 server 傳送資料到 clinet 需要花費 200ms ，而瀏覽器解析這份 CSS 只需花費 2ms ，不就白白浪費了 198ms 嗎？改成 inline CSS ，瞬間就榨出了這麼多時間。

（然而CSS 很大的話，使用 external CSS 會比較好，因為瀏覽器會 cache，如果是使用 inline CSS 的話，瀏覽器並不會 cache。）