資訊專欄INFORMATION COLUMN
摘要：二目前最先進的加載方法在上面的代碼中，通過一些內聯樣式我們可以加速初始渲染，同時隱藏起還沒有加載完樣式的組件，并通過異步地完成加載。
Chrome 瀏覽器有意改變的加載方式，當其出現在中時，這一變化將更加明顯。筆者決定在本文中進行詳細說明這種改變可能帶來影響與好處。
…content…
CSS 會阻礙渲染，因此在all-of-my-styles.css全部加載完之前，用戶就只能面對一片空白的屏幕。
通常，我們將某個站點的所有 CSS 樣式合并為一到兩個資源，這意味著用戶會下載一堆當前頁面根本就用不上的規則。這是因為網站可能包含許多不同類型的頁面，每個頁面都有自己的「組件」；而在組件級別傳遞 CSS 的話，會降低 HTTP/1 的性能。
然而，對 SPDY 和 HTTP/2 來說，事實卻并非如此。在這些協議中，許多小資源只需要很小的代價就能完成遞送，并且被獨立緩存。
…content…
這樣一來就解決了冗余問題，但也意味著你需要知道輸出時頁面將包含的內容，從而防止 streaming。與此同時，瀏覽器還是只能等待所有 CSS 樣式加載完畢，才能開始渲染。如果加載 /site-footer.css的速度不夠快，就會耽誤所有頁面的渲染。
在上面的代碼中，通過一些內聯樣式我們可以加速初始渲染，同時隱藏起還沒有加載完樣式的組件，并通過 JavaScript 異步地完成加載。剩余的 CSS 加載完后會重寫.main-article中的display:none。
這個方法受到性能專家的推崇,他們認為這是快速完成初始渲染的好方法，并且經過實地測量確實在加載的時候快了不少。
但也存在一些不足之處。。。。。。
「1.它需要一個（小的）JavaScript 庫」
這是由 WebKit 的實現方式造成的。一旦頁面中添加了，即使樣式表是由 JavaScript 加載的，WebKit 還是會在加載完成之前阻礙渲染。
在 Firefox 和 IE/Edge 瀏覽器中，通過 JS 加載樣式表是完全異步進行的。穩定版本的 Chrome 瀏覽器是通過 WebKit 的方式加載的，但在 Canary 版本中，仍然是使用 Firefox/Edge 加載方式。
「2.必須經歷兩個加載階段」
在上述模式中，內聯的 CSS 通過display:none隱藏了沒有加載完樣式的內容，直到異步加載完剩余的 CSS 樣式。如果你將這些樣式分派到兩個或多個 CSS 文件中，這些文件有可能不按照順序加載，導致加載過程中出現內容錯亂：
內容錯亂，就好比彈出廣告一樣，會導致用戶體驗挫敗，必須全力消滅。
既然有兩個加載階段，你就必須決定渲染的先后順序。你當然會想首先渲染「位置顯要」的內容。但是，所謂的「位置」是根據窗口大小來決定的。因此，問題來了，你得找出一把「萬能」鑰匙。
… … … …
計劃是這樣的：針對每個，加載樣式表時我們阻止渲染它的后續內容，但是允許渲染它之前的內容。樣式表是并行加載的，但是按照一定的順序顯示。這使得的效用與相近。
假設網站 header、正文和 footer 的 CSS 已經加載完畢，但其余內容仍在等待，那么頁面會是這樣的：
Header：已渲染
正文：已渲染
評論部分：未渲染，它前面的 CSS 還未被加載（/comment.css）。
關于本站：未渲染。它前面的 CSS 還未被加載（/comment.css）。
Footer：未渲染。盡管它本身的 CSS 已加載完成，但它前面的 CSS 還未被加載（/comment.css）。
這是一個按順序渲染的頁面。你不需要決定哪部分內容在「顯要位置」，只要在頁面組件第一次實例化之前引入該組件的 CSS 即可。它完全兼容 Streaming，因為除非你需要，否則不必要輸出。
當使用內容決定布局的布局系統時（例如表格和 flexbox），要注意避免加載時出現內容錯位。這不是什么新問題了，但是分步渲染會使得它出現得更為頻繁。你可以通過 hack flexbox 來解決，但對整體頁面布局來說，使用 CSS grid 工具效果更佳（不過對小一些的組件來說，flexbox 還是很棒的）。
HTML 規范并沒有規定 CSS 應當怎樣阻止頁面渲染，它不鼓勵在 body 中使用，但是所有的瀏覽器都允許使用。當然了，瀏覽器們在處理 body 中的 link 時都有自己的方法：
Chrome和Safari：一旦發現 就停止渲染，并且在已發現的樣式表全部完成加載之前不會開始渲染。這會導致 前未被渲染的內容也被阻塞。
Firefox： head中的會阻塞渲染，直至所有已發現的樣式表加載完畢，body中的并不阻塞任何渲染，除非某個 head 中的樣式表已經阻塞了渲染，這會導致無樣式的內容出現閃爍（FOUC）。
IE/Edge： 阻塞解析器直到樣式表加載完畢，但是允許渲染之前的內容。
在 Chrome 團隊，我們喜歡 IE/Edge 的方式，所以打算跟它看齊。這就允許上文描述的漸進式 CSS 渲染方式。我們正在努力把它變成標準，從允許中的開始。
目前 Chrome/Safari 采用的方式是向下兼容的，帶來的問題是阻塞渲染的時間比實際需要的長。Firefox 的方式稍微復雜一些，但有個解決的方法：
「Firefixing！」
因為 Firefox 并不總是為了中的阻塞渲染，我們得為這個多花點功夫來避免 FOUC。謝天謝地這很容易，因為
此處的
筆者之前做過前端優化的工作，國內外的前端性能優化工具也使用了不少，現階段可以較好實現這個定位頁面慢加載因素的工具有：
OneAPM Browser Insight、AppDynamics、Ruxit，大家有興趣的話可以去嘗試下。
注：本文原文作者為 Jake Archibald，由 OneAPM 運營人員翻譯整理
原文地址：https://jakearchibald.com/2016/link-in-b...
Browser Insight 是一個基于真實用戶的 Web 前端性能監控平臺，能夠幫大家定位網站性能瓶頸，網站加速效果可視化；支持瀏覽器、微信、App 瀏覽 HTML 和 HTML5 頁面。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。
本文轉自 OneAPM 官方博客
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/115195.html
摘要：可構造樣式表是一種使用進行創建和分發可重用樣式的新方法。它甚至可以直接用于瀏覽器解析器直接的接口，無需將他們注入到就可以很輕易的加載樣式表。構建一個樣式表與引入一個新不同，可構造樣式表規范使得其可以通過調用構造函數來強制創建樣式表。 可構造樣式表是一種使用Shadow DOM進行創建和分發可重用樣式的新方法。 使用Javascript來創建樣式表是可能的。然而，這個過程在歷史上一直是使...
摘要：但有時候我們希望關閉輸入框的自動完成功能，例如當用戶輸入內容的時候，我們希望使用技術從數據庫搜索并列舉而不是在用戶的歷史記錄中搜索。 以下是我整理的一些HTML的基礎面試體，并自己整理了答案。 1 DOCTYPE有什么作用？標準模式與混雜模式如何區分？它們有何意義? 告訴瀏覽器使用哪個版本的HTML規范來渲染文檔。DOCTYPE不存在或形式不正確會導致HTML文檔以混雜模式呈現。標準模...
摘要：標準模式的排版和運作模式都是以該瀏覽器支持的最高標準運行。使用之前需要考慮這兩個缺點。數據的有效期不同。在設置的過期時間之前一直有效，即使窗口或者瀏覽器關閉。僅在瀏覽器窗口關閉之前有效。 一、HTML常見題目01、Doctype作用？嚴格模式與混雜模式如何區分？它們有何意義？02、 HTML5 為什么只需要寫 !DOCTYPE HTML？03、行內元素有哪些？塊級元素有哪些？空(voi...
摘要：標準模式的排版和運作模式都是以該瀏覽器支持的最高標準運行。使用之前需要考慮這兩個缺點。數據的有效期不同。在設置的過期時間之前一直有效，即使窗口或者瀏覽器關閉。僅在瀏覽器窗口關閉之前有效。 一、HTML常見題目01、Doctype作用？嚴格模式與混雜模式如何區分？它們有何意義？02、 HTML5 為什么只需要寫 !DOCTYPE HTML？03、行內元素有哪些？塊級元素有哪些？空(voi...
閱讀 2403·2021-10-14 09:43
閱讀 2434·2021-09-09 09:34
閱讀 1601·2019-08-30 12:57
閱讀 1198·2019-08-29 14:16
閱讀 716·2019-08-26 12:13
閱讀 3200·2019-08-26 11:45
閱讀 2281·2019-08-23 16:18
閱讀 2652·2019-08-23 15:27
