前端效能優化第四篇-為什麼在head中引入CSS
前端效能優化第四篇-為什麼在head中引入CSS
寫在前面：有很長一段時間沒有更新這個專欄，是因為在準備一些課程上的東西，不過這個專欄一定不會爛尾的~
寫這篇文章的原因是因為從我初學前端開始，就一直有人告訴我：“樣式表文件在head中通過link引入，script檔案在body的末尾引入，這樣頁面載入速度更快。”那麼著一切究竟是為什麼呢，下面我們來看一下~
（如果真的不想看這些鋪墊內容，不妨直接跳到最後的總結，嚶嚶嚶~）
曾經的錯誤嘗試
下面這個例子摘自《高效能網站建設指南》第五章開頭：
Yahoo！前端團隊曾經為了優化入口網站的效能，調整了CSS的位置——由於一個div是在點選某個功能時才會彈出，所以工程師將與這個div有關的CSS在文件的末尾引入，希望以這種方式提高首頁的渲染效率。
但是事實上，狀況並不理想，甚至恰恰相反——將CSS在文件head引入反而更快。
錯誤原因：逐步呈現被阻止
逐步呈現
我們都希望頁面的呈現過程是一個逐步呈現的過程，理想的效果是使用者能夠儘快看到頁面上的內容，同時內容可以呈現一個柔滑的增加，畢竟不是所有的使用者都有非常良好的網路環境。這樣做有幾個好處：
- 讓使用者感受到系統並沒有崩潰，它正在有條不紊的運作
- 讓使用者知道自己大概還需等待多長時間
- 讓使用者對頁面內容有一個概覽，同時有內容可以看
注：上面列出的三點是由 Jakob Nielson 提出的視覺化回饋的重要性
錯誤
為了增強使用者體驗，瀏覽器也採用了這樣的方式來處理一個頁面。
但是，為了避免當樣式表改變時重繪頁面中的內容，瀏覽器會在樣式表載入好之前阻止內容呈現。所以將樣式表放在文件底部，頁面上的內容雖然很快載入
解決方法
解決上面提到的問題其實很簡單，只要將CSS以下面的方式引入：
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>嚶嚶嚶？</title>
<link rel="stylesheet" type="text/css" href="mystyle.css">
</head>
<body>
</body>
</ 這時又有一個問題產生了，引入CSS有兩種方法：link和@improt。我們要為什麼一般使用link呢？
吃了語法更簡單，link比@import的效能好很多，因為@import仍然沒有解決白屏問題。
使用@import會導致下載的無序性，我們的樣式表仍然會在最後被下載。
瀏覽器為什麼這麼做
如果樣式表仍然在載入，構建呈現樹就是一種效能浪費，因為在所有樣式表載入並解析完畢之前無需繪製任何東西。否則我們將會遇到FOUC（無樣式內容閃爍）問題。
瀏覽器構建頁面的順序我在之前的文章中寫到過，戳戳->前端效能優化第二篇
如果瀏覽器不做任何操作的話，我們將CSS放在文件後面會導致FOUC問題，具體表現為頁面最初呈現一個樣式，在短暫的幾秒後，樣式表載入好，頁面佈局突然發生了變化。
而白屏現象則是瀏覽器對閃爍的彌補措施，避免額外的呈現過程，瀏覽器得以延遲呈現這個頁面。
總結
- 我們應當遵守規範，使用LINK標籤，將樣式表文件新增到HEAD中
- 如果我們將樣式表放到文件的底部或者使用
@import可能會導致“白屏”或者“無樣式內容閃爍”，具體會發生什麼取決於瀏覽器的策略。