国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

CSS和網(wǎng)絡(luò)性能

chanthuang / 908人閱讀

摘要：對(duì)于性能來(lái)說(shuō)真的非常糟糕。的推出使網(wǎng)頁(yè)性能提高了大約，所有這些都不需要開(kāi)發(fā)人員參與。這意味著和中的存在錯(cuò)誤。將放在中這個(gè)最終策略是一個(gè)相對(duì)較新的策略，對(duì)感知性能和漸進(jìn)式渲染有很大好處。

CSS對(duì)于呈現(xiàn)頁(yè)面至關(guān)重要 - 在找到，下載和解析所有CSS之前，瀏覽器不會(huì)開(kāi)始呈現(xiàn) - 因此我們必須盡可能快地將其加載到用戶的設(shè)備上。 關(guān)鍵路徑上的任何延遲都會(huì)影響我們的“開(kāi)始渲染”并讓用戶看到空白屏幕。

什么是大問(wèn)題？

從廣義上講，這就是CSS對(duì)性能至關(guān)重要的原因：

瀏覽器在構(gòu)建渲染樹之前無(wú)法渲染頁(yè)面;

渲染樹是DOM和CSSOM的組合結(jié)果;

DOM是HTML加上需要對(duì)其進(jìn)行操作的任何阻塞JavaScript;

CSSOM是針對(duì)DOM應(yīng)用的所有CSS規(guī)則;

使用async和defer屬性很容易使JavaScript無(wú)阻塞;

CSS不容易異步;

所以要記住的一個(gè)好的經(jīng)驗(yàn)法則是，您的頁(yè)面會(huì)在你最慢的樣式表加載完成之后才展示。

考慮到這一點(diǎn)，我們需要盡快構(gòu)建DOM和CSSOM。 在大多數(shù)情況下，構(gòu)建DOM相對(duì)較快：您的第一個(gè)HTML響應(yīng)是DOM。 但是，由于CSS幾乎總是HTML的子資源，因此構(gòu)建CSSOM通常需要更長(zhǎng)的時(shí)間。

在這篇文章中，我想看看CSS如何證明是網(wǎng)絡(luò)上的一個(gè)重大瓶頸（本身和其他資源）以及我們?nèi)绾尉徑馑瑥亩s短關(guān)鍵路徑并縮短開(kāi)始渲染的時(shí)間。

使用關(guān)鍵CSS

如果你有能力，減少Start Render時(shí)間的最有效方法之一就是使用Critical CSS模式：識(shí)別Start Render所需的所有樣式（通常是首屏所需的樣式）， 將它們內(nèi)聯(lián)到文檔的中的

將產(chǎn)生這個(gè)瀑布圖：

由于無(wú)效預(yù)裝載掃描程序?qū)е翭irefox失去并行化（N.B.在IE / Edge中出現(xiàn)相同的瀑布。）

這個(gè)問(wèn)題的直接解決方案是交換

兩個(gè) s讓我們回到并行化。 （N.B. IE / Edge中出現(xiàn)相同的瀑布。）

Blink和WebKit：用HTML格式引用@import URL

僅當(dāng)您的@import URL缺少引號(hào)（“）時(shí)，WebKit和Blink的行為與Firefox和IE / Edge完全相同。這意味著WebKit和Blink中的Preload Scanner存在錯(cuò)誤。

簡(jiǎn)單地將@import包裝在引號(hào)中將解決問(wèn)題，您無(wú)需重新排序任何內(nèi)容。 不過(guò)，和以前一樣，我的建議是完全避免使用@import，而是選擇第二個(gè)。

之前

瀑布圖：

我們的@ import網(wǎng)址中缺少引號(hào)會(huì)破壞Chrome的預(yù)裝掃描程序（N.B.在Opera和Safari中會(huì)出現(xiàn)相同的瀑布。）

修改之后：

在我們的@ import網(wǎng)址中添加引號(hào)可修復(fù)Chrome的Preload Scanner（N.B.在Opera和Safari中也會(huì)出現(xiàn)相同的瀑布。）

這絕對(duì)是WebKit / Blink中的一個(gè)錯(cuò)誤 - 缺少引號(hào)不應(yīng)該隱藏Preload Scanner中的@imported樣式表。

不要在Async 腳本之前放置

上一節(jié)討論了如何通過(guò)其他資源減慢CSS，本節(jié)將討論CSS如何無(wú)意中延遲下載資源的下載，主要是使用異步加載代碼段插入的JavaScript，如下所示：

在所有瀏覽器中都存在一種有意和預(yù)期的迷人行為，但我從未遇到過(guò)一個(gè)了解它的開(kāi)發(fā)人員。 當(dāng)您考慮它可以帶來(lái)的巨大性能影響時(shí)，這是非常令人驚訝的：

如果有任何當(dāng)前CSS在加載，瀏覽器將不會(huì)執(zhí)行

這是設(shè)計(jì)的。 這是故意的。 當(dāng)前正在下載任何CSS時(shí)，HTML中的任何同步

根據(jù)這個(gè)順序，我們可以清楚地看到JavaScript文件甚至在構(gòu)建CSSOM之前甚至沒(méi)有開(kāi)始下載。 我們完全失去了任何并行化：

在異步代碼段之前使用樣式表可以撤消我們并行化的機(jī)會(huì)。
有趣的是，Preload Scanner希望提前獲得對(duì)analytics.js的引用，但是我們無(wú)意中隱藏了它：“analytics.js”是一個(gè)字符串，并且在<<之前不會(huì)成為可標(biāo)記的src屬性 script>元素存在于DOM中。 這是我早些時(shí)候說(shuō)的，當(dāng)我稍后再說(shuō)這個(gè)時(shí)。

第三方供應(yīng)商提供這樣的異步代碼片段以更安全地加載腳本是很常見(jiàn)的。 開(kāi)發(fā)人員對(duì)這些第三方持懷疑態(tài)度，并在頁(yè)面后面放置異步片段也是很常見(jiàn)的。 雖然這是出于最好的意圖 - 我不想在我自己的資產(chǎn)之前放置第三方

交換樣式表和異步代碼片段可以重新獲得并行化。

現(xiàn)在您可以看到我們已經(jīng)完全重新獲得了并行化，并且頁(yè)面加載速度提高了近2倍。

在CSS之前放置任何非CSSOM查詢JavaScript; 在CSS之后放置任何CSSOM查詢JavaScript

更進(jìn)一步，除了異步加載片段之外，我們應(yīng)該如何更普適地加載CSS和JavaScript？ 為了解決這個(gè)問(wèn)題，我提出了以下問(wèn)題并從那里開(kāi)始工作：

如果：

在CSSOM構(gòu)造上阻止CSS后定義的同步JS;

同步JS阻止DOM構(gòu)造

那么 - 假設(shè)沒(méi)有相互依賴 - 哪個(gè)更快/更喜歡？

Script -> style;
style -> script?

答案是：

如果文件不相互依賴，那么您應(yīng)該將阻塞腳本置于阻塞樣式之上 - 沒(méi)有必要將JavaScript執(zhí)行延遲到JavaScript實(shí)際上不依賴的CSS。

（Preload Scanner確保即使在腳本上阻止了DOM構(gòu)造，CSS仍然會(huì)并行下載。）

如果你的一些JavaScript做了但有些不依賴于CSS，那么加載同步JavaScript和CSS的絕對(duì)最佳順序是將JavaScript分成兩部分并將其加載到CSS的任何一側(cè)：

使用這種加載模式，我們可以按最佳順序進(jìn)行下載和執(zhí)行。 我為下面的截圖中的微小細(xì)節(jié)道歉，但希望你能看到代表JavaScript執(zhí)行的小粉紅色標(biāo)記。
entry（1）是計(jì)劃在其他文件到達(dá)和/或執(zhí)行時(shí)執(zhí)行某些JavaScript的HTML;
entry（2）執(zhí)行它到達(dá)的那一刻;
entry（3）是CSS，所以不執(zhí)行任何JavaScript;
在CSS完成之前，entry（4）實(shí)際上不會(huì)執(zhí)行。

注： 您必須根據(jù)自己的特定用例測(cè)試此模式：根據(jù)您之前的CSS JavaScript文件與CSS本身之間的文件大小和執(zhí)行成本是否存在巨大差異，可能會(huì)有不同的結(jié)果。 測(cè)試，測(cè)試，測(cè)試。

將放在中

這個(gè)最終策略是一個(gè)相對(duì)較新的策略，對(duì)感知性能和漸進(jìn)式渲染有很大好處。 它也非常友好。

在HTTP / 1.1中，我們將所有樣式連接到一個(gè)主要包中是很典型的。 我們稱之為app.css：





  




  


    

  


  


    


      
...


      
...

這帶來(lái)三個(gè)關(guān)鍵的低效率：

任何給定的頁(yè)面只會(huì)使用app.css中的一小部分樣式：我們幾乎肯定會(huì)下載比我們需要的更多的CSS。

我們受限于一種效率低下的緩存策略：例如，對(duì)僅在一個(gè)頁(yè)面上使用的日期選擇器上當(dāng)前所選日期的背景顏色進(jìn)行更改將需要我們緩存整個(gè)app.css。

整個(gè)app.css阻止渲染：如果當(dāng)前頁(yè)面只需要17％的app.css并不重要，我們?nèi)匀恍枰却渌?3％才能開(kāi)始渲染。

使用HTTP / 2，我們可以開(kāi)始解決點(diǎn)（1）和（2）：





  
  
  
  
  
  
  
  
  




  


    

  


  


    


      
...


      
...

現(xiàn)在我們正在解決冗余問(wèn)題，因?yàn)槲覀兡軌蚣虞d更適合頁(yè)面的CSS，而不是不加選擇地下載所有內(nèi)容。 這減少了關(guān)鍵路徑上阻塞CSS的大小。

我們還可以采用更有意思的緩存策略，只緩存破壞需要它的文件，并保持其余部分不受影響。

我們還沒(méi)有解決的問(wèn)題是它仍然阻止渲染 - 我們?nèi)匀恢挥凶盥臉邮奖怼?這意味著如果無(wú)論出于何種原因，site-footer.css需要很長(zhǎng)時(shí)間才能下載，瀏覽器無(wú)法開(kāi)始渲染.site-header。

但是，由于Chrome最近發(fā)生了變化（我相信版本69），以及Firefox和IE / Edge中已經(jīng)存在的行為， 只會(huì)阻止后續(xù)內(nèi)容的呈現(xiàn)，而不是 整頁(yè)。 這意味著我們現(xiàn)在能夠像這樣構(gòu)建我們的頁(yè)面：





  




  
  


    
    

  


  
  


    
    


      
...


      
      
...

這樣做的實(shí)際結(jié)果是，我們現(xiàn)在能夠逐步呈現(xiàn)我們的頁(yè)面，在頁(yè)面可用時(shí)有效地將頁(yè)面輸送樣式添加到頁(yè)面中。

在目前不支持這種新行為的瀏覽器中，我們不會(huì)遇到性能下降：我們會(huì)回到原來(lái)的行為，我們只有最慢的CSS文件加載完成才會(huì)展示頁(yè)面。

總結(jié)

本文中有很多要消化的內(nèi)容。 它最終超越了我最初打算寫的帖子。 嘗試總結(jié)加載CSS的最佳網(wǎng)絡(luò)性能實(shí)踐：

Lazyload Start Start Render不需要的任何CSS：

   拆分關(guān)鍵CSS;
   或?qū)⒛腃SS拆分為媒體查詢。

避免@import：

   在你的HTML中;
   特別是在CSS中;
   并提防Preload Scanner的奇怪之處。

警惕同步CSS和JavaScript命令：

   在CSSOM完成之前，CSS之后定義的JavaScript將無(wú)法運(yùn)行
   所以如果你的JavaScript不依賴于你的CSS，在CSS之前加載它;
   如果它取決于你的CSS，在CSS之后加載它。

在DOM需要時(shí)加載CSS，這將取消阻止“開(kāi)始渲染”并允許漸進(jìn)式渲染

我上面概述的所有內(nèi)容都遵循規(guī)范或已知/預(yù)期的行為，但是，一如既往，自己測(cè)試一切。 雖然這在理論上都是正確的，但在實(shí)踐中事情總是有所不同。 套用中國(guó)的一句老話，實(shí)踐出真知啊。

創(chuàng)建了一個(gè)程序員交流微信群，大家進(jìn)群交流IT技術(shù)

如果已過(guò)期，可以添加博主微信號(hào)15706211347，拉你進(jìn)群

文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址：http://specialneedsforspecialkids.com/yun/53401.html

相關(guān)文章

  • 前端性能優(yōu)化常用總結(jié)

    摘要：前言對(duì)于前端的性能話題，從來(lái)都沒(méi)有斷絕過(guò)。作為一個(gè)前端開(kāi)發(fā)者，性能是我們關(guān)注的指標(biāo)。前端發(fā)展以來(lái)，優(yōu)化方式，琳瑯滿目，有雅虎軍規(guī)等。所以，接下來(lái)我會(huì)從三個(gè)方面就前端性能進(jìn)行總結(jié)網(wǎng)絡(luò)方面操作及渲染方面數(shù)據(jù)方面。 前言 對(duì)于前端的性能話題，從來(lái)都沒(méi)有斷絕過(guò)。因?yàn)檫@個(gè)東西沒(méi)有最好，只有更好。而且往往也是業(yè)務(wù)的繁雜程度去決定優(yōu)化程度的。作為一個(gè)前端開(kāi)發(fā)者，性能是我們關(guān)注的指標(biāo)。它直接影響著我們...

    oliverhuang 評(píng)論0 收藏0

  • 前端性能優(yōu)化常用總結(jié)

    摘要：前言對(duì)于前端的性能話題，從來(lái)都沒(méi)有斷絕過(guò)。作為一個(gè)前端開(kāi)發(fā)者，性能是我們關(guān)注的指標(biāo)。前端發(fā)展以來(lái)，優(yōu)化方式，琳瑯滿目，有雅虎軍規(guī)等。所以，接下來(lái)我會(huì)從三個(gè)方面就前端性能進(jìn)行總結(jié)網(wǎng)絡(luò)方面操作及渲染方面數(shù)據(jù)方面。 前言 對(duì)于前端的性能話題，從來(lái)都沒(méi)有斷絕過(guò)。因?yàn)檫@個(gè)東西沒(méi)有最好，只有更好。而且往往也是業(yè)務(wù)的繁雜程度去決定優(yōu)化程度的。作為一個(gè)前端開(kāi)發(fā)者，性能是我們關(guān)注的指標(biāo)。它直接影響著我們...

    walterrwu 評(píng)論0 收藏0

  • 前端性能優(yōu)化常用總結(jié)

    摘要：前言對(duì)于前端的性能話題，從來(lái)都沒(méi)有斷絕過(guò)。作為一個(gè)前端開(kāi)發(fā)者，性能是我們關(guān)注的指標(biāo)。前端發(fā)展以來(lái)，優(yōu)化方式，琳瑯滿目，有雅虎軍規(guī)等。所以，接下來(lái)我會(huì)從三個(gè)方面就前端性能進(jìn)行總結(jié)網(wǎng)絡(luò)方面操作及渲染方面數(shù)據(jù)方面。 前言 對(duì)于前端的性能話題，從來(lái)都沒(méi)有斷絕過(guò)。因?yàn)檫@個(gè)東西沒(méi)有最好，只有更好。而且往往也是業(yè)務(wù)的繁雜程度去決定優(yōu)化程度的。作為一個(gè)前端開(kāi)發(fā)者，性能是我們關(guān)注的指標(biāo)。它直接影響著我們...

    luzhuqun 評(píng)論0 收藏0

  • 性能優(yōu)化詳解

    摘要：幾個(gè)月前面試的時(shí)候問(wèn)我性能優(yōu)化我可能會(huì)開(kāi)始背誦雅虎軍規(guī)，加點(diǎn)，代碼層面稍稍講點(diǎn)，現(xiàn)在系統(tǒng)的梳理下性能優(yōu)化的方方面面本文涉及方面有代碼優(yōu)化網(wǎng)絡(luò)請(qǐng)求過(guò)程角度入手解析建立鏈接網(wǎng)絡(luò)往返時(shí)延數(shù)據(jù)傳輸網(wǎng)絡(luò)問(wèn)題角度入手請(qǐng)求數(shù)量流量性能優(yōu)化測(cè)試工具代碼優(yōu)化 幾個(gè)月前面試的時(shí)候問(wèn)我性能優(yōu)化我可能會(huì)開(kāi)始背誦雅虎軍規(guī)，加點(diǎn)webp，代碼層面稍稍講點(diǎn)，現(xiàn)在系統(tǒng)的梳理下性能優(yōu)化的方方面面 本文涉及方面有: 代...

    piapia 評(píng)論0 收藏0

  • 性能優(yōu)化詳解

    摘要：幾個(gè)月前面試的時(shí)候問(wèn)我性能優(yōu)化我可能會(huì)開(kāi)始背誦雅虎軍規(guī)，加點(diǎn)，代碼層面稍稍講點(diǎn)，現(xiàn)在系統(tǒng)的梳理下性能優(yōu)化的方方面面本文涉及方面有代碼優(yōu)化網(wǎng)絡(luò)請(qǐng)求過(guò)程角度入手解析建立鏈接網(wǎng)絡(luò)往返時(shí)延數(shù)據(jù)傳輸網(wǎng)絡(luò)問(wèn)題角度入手請(qǐng)求數(shù)量流量性能優(yōu)化測(cè)試工具代碼優(yōu)化 幾個(gè)月前面試的時(shí)候問(wèn)我性能優(yōu)化我可能會(huì)開(kāi)始背誦雅虎軍規(guī)，加點(diǎn)webp，代碼層面稍稍講點(diǎn)，現(xiàn)在系統(tǒng)的梳理下性能優(yōu)化的方方面面 本文涉及方面有: 代...

    godlong_X 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<