摘要：載入流程被限制在兩個階段根據上面的模式，內嵌透過隱藏尚未套用樣式的內容，然後非同步得載入之後呈現內容。樣式表本身的載入機制是平行的，但是套用樣式卻是要照順序的。我們需要一點小技巧來避免。
這週閱讀到這篇有意思的文章，於是便動手寫下簡單的翻譯，如果有理解錯誤的地方歡迎指教。
Chrome 正在試圖改變當 寫在 的行為，從blink-dev 的文章並不能很清楚的知道其優點。所以這篇文章想要深入的介紹這點。
目前的 CSS 載入機制blink 是 Chrome 和 Opera 渲染引擎，而 blink-dev 是其開發社群
…content…
當 CSS 段落在渲染時，會讓使用者瞪著白白的頁面直到 all-of-my-styles.css 完全下載完畢。
通常我們會把站內所有的 CSS 封裝成較少，可能只有一兩個資源檔，但這同時也意味著使用者需要下載大量的樣式設定(CSS Rules)卻沒有在該頁面使用。因為一個網站包含著各種不同的頁面與元件，而這些東西需要套用不同的樣式規則，如果因此分拆成許多檔案而產生大量的請求 request 這在 HTTP/1 是非常耗效能的。
不過在 SPDY 和 HTTP/2 卻不是這樣，傳輸許多分散的小資源只會增加一點點的開銷，並且這些東西可以個別暫存(cached)。
content
這樣一來就解決了許多問題，我們可以拆成很多小檔案個別載入，不過也意味著當我們在 下 時，得要知道這些頁面各自需要哪些資源。
另外，瀏覽器在開始輸出之前，仍然得下載所有的 CSS。如果出現一個下載比較慢的 CSS 例如 /site-footer.css 將會造成渲染的東西延遲。請觀察範例。
上面程式碼，我們有一些內嵌的樣式(inline style)來讓我們可以快速的渲染初始化的樣式，接著把那些還沒取得樣式的部分隱藏起來，然後開始透過 Javascript 非同步下載剩餘的樣式。這些剩餘的 CSS會覆寫掉在 .main-article 和其他選擇器內的 display: none。
這種第一次先快速的初始化渲染，然後持續匯入的方法是許多效能專家所推薦的。
為 CSS 傳送進行最佳化處理
How we make RWD sites load fast as heck
Optimizing the Critical Rendering Path
看看範例
原作者實作了wiki-offline並將狀況紀錄如下圖
上面這張圖片是在 3G 的環境下測試。不過這樣的方法還是有些不足的地方:
需要一個輕量的 Javascript 函式庫不幸的，因為 WebKit 的實作。當 一被加到頁面時，WebKit 會阻塞渲染(render)，直到樣式都被載入，即使這個樣式是透過 Javascript 加入的。
在 Firefox 和 IE/Edge，透過 JS 加入的樣式完全是非同步載入。Chrome 當前穩定版本然仍是遵循 WebKit 的行為，不過在 Canary 已經跟 Firefox/Edge 一樣了。
載入流程被限制在兩個階段(Inline css and A css file)根據上面的模式，內嵌 CSS(inline CSS) 透過 display: none 隱藏尚未套用樣式的內容，然後非同步得載入 CSS 之後呈現內容。如果您需要增加多個 CSS 檔案那麼結果可能就是內容不按順序出現
檢視範例
如果內容還在異動的過程結果周圍的廣告就先出現這通常會讓使用者覺得不開心就關閉你的網站了。
因此被限制在只有兩個載入階段，你必須要決定哪些是第一次渲染時就要出現，哪些是比較晚的。當然，你希望上方的區塊越快顯示越好，不過所謂"上方的區塊"取決於 viewport 可視區域的大小。最後你可能決定定義一個尺寸範圍套用在所有人身上。
如果你想讓事情更加複雜，當然你可以選擇客製 CSS 相依屬性來建立 CSS 之間渲染的相依性
更簡單，更好的方式… … … …
這個概念是透過每一個 在其下載樣式時去阻塞跟在後面的內容，但允許前面的內容先開始渲染。樣式表(CSS)本身的載入機制是平行的，但是套用樣式卻是要照順序的。這讓 的行為類似為
這個標籤不能完全沒有內容，所以我們需要留一個"空白"。
實際執行的結果查閱範例
Firefox 和 Edge/IE 將會循序的載入輸出，而 Chrome 和 Safari 則是先看到空白的頁面一陣子直到 CSS 全部載完。目前 Chrome/Safari 的行為比起把樣式連結放在 也沒有差到哪去，所以現在就可以開始使用這個方式，很快的 Chrome 將會往 Edge 的機制修正，這麼一來渲染會更加迅速。
以上就是一個簡單的技巧協助我們加快速度並逐步載入 CSS
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/115060.html
摘要：現在，我們可以開始探討介面的設計模式了。匯出命名空間一個簡單且常用的設計模式就是匯出一個包含數個屬性的物件，這些屬性具體的內容主要是函式，但並不限於函式。如此，我們就能夠透過匯入該模組來取得這個命名空間下一系列相關的功能。 前言 這篇文章試著要整理，翻譯Export This: Interface Design Patterns for Node.js Modules這篇非常值得一讀的...
摘要：的架構設計促使第三方開發者讓核心發揮出無限的潛力。當然建置比起開發是較進階的議題，因為我們必須要理解內部的一些事件。這個編譯結果包含的訊息包含模組的狀態，編譯後的資源檔，發生異動的檔案，被觀察的相依套件等。 本文將對 webpack 周邊的 middleware 與 plugin 套件等作些介紹，若您對於 webpack 還不了解可以參考這篇彙整的翻譯。 webpack dev ser...
摘要：目錄許多開發者會把的目錄命名為但這並不強迫。所有的檔案都會使用從被編譯成。同時有個小小的重點那就是我們可已觀察編譯後的檔案大小。在專案目錄下執行可以觀察截至目前為止的結果。我們的目標是要把編譯封裝到我們的中。 在今時今日，webpack 已經成為前端開發非常重要的工具之一。本質上它是一個 Javascript 模組封裝工具，但透過 loaders 和 plugins 它也可以轉換封裝其...
摘要：接下來我們將會更具體的說明是什麼東西和這傢伙會怎麼解決這些問題，並且列出目前開發中一些令人興奮的功能。這個功能甚至還沒有一個瀏覽器支援。完整的清單請查閱目前還未被寫入規範，意思是這邊提到任何內容極有可能會改變。 譯者：其實...我想說這可能是最令我感到興奮..但又害怕頭痛的功能... 附上原文連結 你曾經想要使用某個 CSS 的新功能，但是最後卻因為這個功能瀏覽器還未全面支援而放棄了嗎...
摘要：確切位置因平台而異。如果以編程方式使用，這個頁面也是一個強大的調試工具，能看到所有原始的協議命令通過連線，於瀏覽器進行通信。警告協議可以做很多有趣的事，但作為入門選項他令人沮喪。目前，提供了比協議高級別的。 本文翻譯自：Getting Started with Headless Chrome原文更新時間：July 28,2017作者：Eric Bidelman（Engineer @ G...
阅读 1960·2021-11-23 09:51
阅读 872·2021-11-19 09:40
阅读 827·2021-10-27 14:20
阅读 5002·2021-10-09 09:52
阅读 3295·2021-10-09 09:44
阅读 1727·2021-10-08 10:05
阅读 5051·2021-09-09 11:47
阅读 3480·2019-08-30 12:47
