...
...
資訊專欄INFORMATION COLUMN
摘要：對于性能來說真的非常糟糕。的推出使網(wǎng)頁性能提高了大約，所有這些都不需要開發(fā)人員參與。這意味著和中的存在錯誤。將放在中這個最終策略是一個相對較新的策略，對感知性能和漸進式渲染有很大好處。
CSS對于呈現(xiàn)頁面至關(guān)重要 - 在找到，下載和解析所有CSS之前，瀏覽器不會開始呈現(xiàn) - 因此我們必須盡可能快地將其加載到用戶的設備上。 關(guān)鍵路徑上的任何延遲都會影響我們的“開始渲染”并讓用戶看到空白屏幕。
什么是大問題？從廣義上講，這就是CSS對性能至關(guān)重要的原因：
瀏覽器在構(gòu)建渲染樹之前無法渲染頁面;
渲染樹是DOM和CSSOM的組合結(jié)果;
DOM是HTML加上需要對其進行操作的任何阻塞JavaScript;
CSSOM是針對DOM應用的所有CSS規(guī)則;
使用async和defer屬性很容易使JavaScript無阻塞;
CSS不容易異步;
所以要記住的一個好的經(jīng)驗法則是，您的頁面會在你最慢的樣式表加載完成之后才展示。
考慮到這一點，我們需要盡快構(gòu)建DOM和CSSOM。 在大多數(shù)情況下，構(gòu)建DOM相對較快：您的第一個HTML響應是DOM。 但是，由于CSS幾乎總是HTML的子資源，因此構(gòu)建CSSOM通常需要更長的時間。
在這篇文章中，我想看看CSS如何證明是網(wǎng)絡上的一個重大瓶頸（本身和其他資源）以及我們?nèi)绾尉徑馑瑥亩s短關(guān)鍵路徑并縮短開始渲染的時間。
使用關(guān)鍵CSS如果你有能力，減少Start Render時間的最有效方法之一就是使用Critical CSS模式：識別Start Render所需的所有樣式（通常是首屏所需的樣式）， 將它們內(nèi)聯(lián)到文檔的
中的將產(chǎn)生這個瀑布圖：
由于無效預裝載掃描程序?qū)е翭irefox失去并行化（N.B.在IE / Edge中出現(xiàn)相同的瀑布。）
這個問題的直接解決方案是交換
兩個 s讓我們回到并行化。 （N.B. IE / Edge中出現(xiàn)相同的瀑布。）
Blink和WebKit：用HTML格式引用@import URL僅當您的@import URL缺少引號（“）時，WebKit和Blink的行為與Firefox和IE / Edge完全相同。這意味著WebKit和Blink中的Preload Scanner存在錯誤。
簡單地將@import包裝在引號中將解決問題，您無需重新排序任何內(nèi)容。 不過，和以前一樣，我的建議是完全避免使用@import，而是選擇第二個。
之前
瀑布圖：
我們的@ import網(wǎng)址中缺少引號會破壞Chrome的預裝掃描程序（N.B.在Opera和Safari中會出現(xiàn)相同的瀑布。）
修改之后：
在我們的@ import網(wǎng)址中添加引號可修復Chrome的Preload Scanner（N.B.在Opera和Safari中也會出現(xiàn)相同的瀑布。）
這絕對是WebKit / Blink中的一個錯誤 - 缺少引號不應該隱藏Preload Scanner中的@imported樣式表。
不要在Async 腳本之前放置上一節(jié)討論了如何通過其他資源減慢CSS，本節(jié)將討論CSS如何無意中延遲下載資源的下載，主要是使用異步加載代碼段插入的JavaScript，如下所示：
在所有瀏覽器中都存在一種有意和預期的迷人行為，但我從未遇到過一個了解它的開發(fā)人員。 當您考慮它可以帶來的巨大性能影響時，這是非常令人驚訝的：
如果有任何當前CSS在加載，瀏覽器將不會執(zhí)行
這是設計的。 這是故意的。 當前正在下載任何CSS時，HTML中的任何同步
根據(jù)這個順序，我們可以清楚地看到JavaScript文件甚至在構(gòu)建CSSOM之前甚至沒有開始下載。 我們完全失去了任何并行化： 在異步代碼段之前使用樣式表可以撤消我們并行化的機會。 第三方供應商提供這樣的異步代碼片段以更安全地加載腳本是很常見的。 開發(fā)人員對這些第三方持懷疑態(tài)度，并在頁面后面放置異步片段也是很常見的。 雖然這是出于最好的意圖 - 我不想在我自己的資產(chǎn)之前放置第三方
交換樣式表和異步代碼片段可以重新獲得并行化。 現(xiàn)在您可以看到我們已經(jīng)完全重新獲得了并行化，并且頁面加載速度提高了近2倍。 在CSS之前放置任何非CSSOM查詢JavaScript; 在CSS之后放置任何CSSOM查詢JavaScript 更進一步，除了異步加載片段之外，我們應該如何更普適地加載CSS和JavaScript？ 為了解決這個問題，我提出了以下問題并從那里開始工作： 如果： 在CSSOM構(gòu)造上阻止CSS后定義的同步JS; 同步JS阻止DOM構(gòu)造 那么 - 假設沒有相互依賴 - 哪個更快/更喜歡？ Script -> style; 答案是： 如果文件不相互依賴，那么您應該將阻塞腳本置于阻塞樣式之上 - 沒有必要將JavaScript執(zhí)行延遲到JavaScript實際上不依賴的CSS。 （Preload Scanner確保即使在腳本上阻止了DOM構(gòu)造，CSS仍然會并行下載。） 如果你的一些JavaScript做了但有些不依賴于CSS，那么加載同步JavaScript和CSS的絕對最佳順序是將JavaScript分成兩部分并將其加載到CSS的任何一側(cè)： 使用這種加載模式，我們可以按最佳順序進行下載和執(zhí)行。 我為下面的截圖中的微小細節(jié)道歉，但希望你能看到代表JavaScript執(zhí)行的小粉紅色標記。 注： 您必須根據(jù)自己的特定用例測試此模式：根據(jù)您之前的CSS JavaScript文件與CSS本身之間的文件大小和執(zhí)行成本是否存在巨大差異，可能會有不同的結(jié)果。 測試，測試，測試。 這個最終策略是一個相對較新的策略，對感知性能和漸進式渲染有很大好處。 它也非常友好。 在HTTP / 1.1中，我們將所有樣式連接到一個主要包中是很典型的。 我們稱之為app.css： 這帶來三個關(guān)鍵的低效率： 任何給定的頁面只會使用app.css中的一小部分樣式：我們幾乎肯定會下載比我們需要的更多的CSS。 我們受限于一種效率低下的緩存策略：例如，對僅在一個頁面上使用的日期選擇器上當前所選日期的背景顏色進行更改將需要我們緩存整個app.css。 整個app.css阻止渲染：如果當前頁面只需要17％的app.css并不重要，我們?nèi)匀恍枰却渌?3％才能開始渲染。 使用HTTP / 2，我們可以開始解決點（1）和（2）： 現(xiàn)在我們正在解決冗余問題，因為我們能夠加載更適合頁面的CSS，而不是不加選擇地下載所有內(nèi)容。 這減少了關(guān)鍵路徑上阻塞CSS的大小。 我們還可以采用更有意思的緩存策略，只緩存破壞需要它的文件，并保持其余部分不受影響。 我們還沒有解決的問題是它仍然阻止渲染 - 我們?nèi)匀恢挥凶盥臉邮奖怼?這意味著如果無論出于何種原因，site-footer.css需要很長時間才能下載，瀏覽器無法開始渲染.site-header。 但是，由于Chrome最近發(fā)生了變化（我相信版本69），以及Firefox和IE / Edge中已經(jīng)存在的行為， 只會阻止后續(xù)內(nèi)容的呈現(xiàn)，而不是 整頁。 這意味著我們現(xiàn)在能夠像這樣構(gòu)建我們的頁面： 這樣做的實際結(jié)果是，我們現(xiàn)在能夠逐步呈現(xiàn)我們的頁面，在頁面可用時有效地將頁面輸送樣式添加到頁面中。 在目前不支持這種新行為的瀏覽器中，我們不會遇到性能下降：我們會回到原來的行為，我們只有最慢的CSS文件加載完成才會展示頁面。 本文中有很多要消化的內(nèi)容。 它最終超越了我最初打算寫的帖子。 嘗試總結(jié)加載CSS的最佳網(wǎng)絡性能實踐：
Lazyload Start Start Render不需要的任何CSS：
有趣的是，Preload Scanner希望提前獲得對analytics.js的引用，但是我們無意中隱藏了它：“analytics.js”是一個字符串，并且在<<之前不會成為可標記的src屬性 script>元素存在于DOM中。 這是我早些時候說的，當我稍后再說這個時。
style -> script?
entry（1）是計劃在其他文件到達和/或執(zhí)行時執(zhí)行某些JavaScript的HTML;
entry（2）執(zhí)行它到達的那一刻;
entry（3）是CSS，所以不執(zhí)行任何JavaScript;
在CSS完成之前，entry（4）實際上不會執(zhí)行。
...
...
...
...
...
...
拆分關(guān)鍵CSS;
或?qū)⒛腃SS拆分為媒體查詢。
避免@import：
在你的HTML中; 特別是在CSS中; 并提防Preload Scanner的奇怪之處。
警惕同步CSS和JavaScript命令：
在CSSOM完成之前，CSS之后定義的JavaScript將無法運行 所以如果你的JavaScript不依賴于你的CSS，在CSS之前加載它; 如果它取決于你的CSS，在CSS之后加載它。
在DOM需要時加載CSS，這將取消阻止“開始渲染”并允許漸進式渲染
我上面概述的所有內(nèi)容都遵循規(guī)范或已知/預期的行為，但是，一如既往，自己測試一切。 雖然這在理論上都是正確的，但在實踐中事情總是有所不同。 套用中國的一句老話，實踐出真知啊。
創(chuàng)建了一個程序員交流微信群，大家進群交流IT技術(shù)
如果已過期，可以添加博主微信號15706211347，拉你進群
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/114370.html
摘要：前言對于前端的性能話題，從來都沒有斷絕過。作為一個前端開發(fā)者，性能是我們關(guān)注的指標。前端發(fā)展以來，優(yōu)化方式，琳瑯滿目，有雅虎軍規(guī)等。所以，接下來我會從三個方面就前端性能進行總結(jié)網(wǎng)絡方面操作及渲染方面數(shù)據(jù)方面。 前言 對于前端的性能話題，從來都沒有斷絕過。因為這個東西沒有最好，只有更好。而且往往也是業(yè)務的繁雜程度去決定優(yōu)化程度的。作為一個前端開發(fā)者，性能是我們關(guān)注的指標。它直接影響著我們...
摘要：前言對于前端的性能話題，從來都沒有斷絕過。作為一個前端開發(fā)者，性能是我們關(guān)注的指標。前端發(fā)展以來，優(yōu)化方式，琳瑯滿目，有雅虎軍規(guī)等。所以，接下來我會從三個方面就前端性能進行總結(jié)網(wǎng)絡方面操作及渲染方面數(shù)據(jù)方面。 前言 對于前端的性能話題，從來都沒有斷絕過。因為這個東西沒有最好，只有更好。而且往往也是業(yè)務的繁雜程度去決定優(yōu)化程度的。作為一個前端開發(fā)者，性能是我們關(guān)注的指標。它直接影響著我們...
摘要：前言對于前端的性能話題，從來都沒有斷絕過。作為一個前端開發(fā)者，性能是我們關(guān)注的指標。前端發(fā)展以來，優(yōu)化方式，琳瑯滿目，有雅虎軍規(guī)等。所以，接下來我會從三個方面就前端性能進行總結(jié)網(wǎng)絡方面操作及渲染方面數(shù)據(jù)方面。 前言 對于前端的性能話題，從來都沒有斷絕過。因為這個東西沒有最好，只有更好。而且往往也是業(yè)務的繁雜程度去決定優(yōu)化程度的。作為一個前端開發(fā)者，性能是我們關(guān)注的指標。它直接影響著我們...
摘要：幾個月前面試的時候問我性能優(yōu)化我可能會開始背誦雅虎軍規(guī)，加點，代碼層面稍稍講點，現(xiàn)在系統(tǒng)的梳理下性能優(yōu)化的方方面面本文涉及方面有代碼優(yōu)化網(wǎng)絡請求過程角度入手解析建立鏈接網(wǎng)絡往返時延數(shù)據(jù)傳輸網(wǎng)絡問題角度入手請求數(shù)量流量性能優(yōu)化測試工具代碼優(yōu)化 幾個月前面試的時候問我性能優(yōu)化我可能會開始背誦雅虎軍規(guī)，加點webp，代碼層面稍稍講點，現(xiàn)在系統(tǒng)的梳理下性能優(yōu)化的方方面面 本文涉及方面有: 代...
摘要：幾個月前面試的時候問我性能優(yōu)化我可能會開始背誦雅虎軍規(guī)，加點，代碼層面稍稍講點，現(xiàn)在系統(tǒng)的梳理下性能優(yōu)化的方方面面本文涉及方面有代碼優(yōu)化網(wǎng)絡請求過程角度入手解析建立鏈接網(wǎng)絡往返時延數(shù)據(jù)傳輸網(wǎng)絡問題角度入手請求數(shù)量流量性能優(yōu)化測試工具代碼優(yōu)化 幾個月前面試的時候問我性能優(yōu)化我可能會開始背誦雅虎軍規(guī)，加點webp，代碼層面稍稍講點，現(xiàn)在系統(tǒng)的梳理下性能優(yōu)化的方方面面 本文涉及方面有: 代...
閱讀 3002·2021-10-27 14:16
閱讀 712·2021-10-13 09:39
閱讀 3727·2021-09-29 09:46
閱讀 2107·2019-08-30 15:54
閱讀 2612·2019-08-30 15:52
閱讀 3009·2019-08-30 15:44
閱讀 1120·2019-08-30 15:44
閱讀 511·2019-08-30 10:51
