css的效率和瀏覽器渲染的速度

來源:互聯網
上載者:User

瀏覽器如何讀取你的CSS選取器有一個很重要的原則,那就是它們從右至左讀取。這意味這像 ul > li a[title="home"] 這樣的選取器,a[title="home"] 將是最先被讀取的。

我承認我並不經常想這個問題......我們寫的css的效率是怎麼樣的呢,瀏覽器渲染的速度又如何呢?

這是應該是瀏覽器開發人員應該關心的(頁面載入更快,使用者就會更愉快)。Mozilla有一篇文章: about best practices . Google 當然也很關心這個問題,他們也有這樣一篇文章:Optimize browser rendering 。

讓我們瞭解下他們主要倡導的東東,然後討論他們的實用性。

從右至左

瀏覽器如何讀取你的CSS選取器有一個很重要的原則,那就是它們從右至左讀取。這意味這像 ul > li a[title="home"] 這樣的選取器,a[title="home"] 將是最先被讀取的。這一部分通常被稱為 “key selector” (可否稱為“目標選取器” -_-!)選取器的最後一部分,也是被選擇的標籤。

ID's 是最有效率的,通用符是最慢的

有四種目標選取器:ID, class, tag和通用符。看下他們各自的效率如何:
#main-navigation { } /* ID (最快) */
body.home #page-wrap { } /* ID */
.main-navigation { } /* Class */
ul li a.current { } /* Class *
ul { } /* Tag */
ul li a { } /* Tag */
* { } /* Universal (最慢) */
#content [title='home'] /* Universal */ 然後我們結合從右至左和目標選取器的概念,我們可以知道下面這個選取器並不高效:
#main-nav > li { } /* 看著很快實則很慢 */
儘管這讓人有點費解......因為ID's是最高效的,瀏覽器可以通過ID迅速的找到 li。但事實是,li 標籤是被先讀取的。

不要用標籤修飾

死也不要像下面這樣幹:

ul#main-navigation { }

ID's 是唯一的,所以不需要用標籤修飾,這隻會讓它更低效。
如果你可以避免的話,也不要用它修飾 class 。class 不是唯一的,所以理論上你可以把它用在不同的標籤。如果你願意的話,你可以用標籤控制不同的樣式,這樣你可能需要標籤修飾(比如:li.first),但這樣做的人很少,所以,don't .

絕對沒有比用後代選取器更糟糕的做法了
David Hyatt:
後代選取器是CSS裡最昂貴的選取器,昂貴得可怕——特別是當它放在標籤和通用符後面時。
就如下面這個東東一樣,絕對的效率毒瘤:

html body ul li a { }

一個選取器渲染失敗比這個選取器被渲染更高效

我不是很確定是否有更好的證據去證明這一點,因為如果你有大量的選取器在CSS樣式表裡無法找到,這樣的事情貌似很離奇,但一點必需注意的是,從右至左的解釋一個選取器來說,一旦它找不到,那它就會停止嘗試。然而如果它找到了,那它就需要花更多精力去解釋了。

試想一下為何你這樣寫選取器

思考下這東東:

#main-navigation li a { font-family: Georgia, Serif; }

你可能不需要從 a 選取器開始(如果你只是想換個字型)。下面這個可能更高效些:

#main-navigation { font-family: Georgia, Serif; }

實用性

還刻前面提到的Mozilla的一篇文章?已經有十年了。事實是:電腦比十年前變慢了(不是我理解錯了,還是作者想說現在的WEB越來越複雜了)。我感覺這東東在當年似乎還更受重視。十年前我還是個21歲的英俊小生,當然我不覺得那裡我會認識css這東東。所以我也無法跟你講以前的情況......但我覺得渲染效率的問題之所以沒被重視是因為這從來就不是一個大問題。
這是我的一些看法:不管怎樣上面提到的東東都是有意義的,你可以按照上面的方法去做,因為它並不會限制你的CSS製作。但你也沒必要太教條主義。如果你是個完美主義者,而之前又沒有考慮過那東東,那是時候去重新看一下你之前寫的一些樣式是否有改進的地方了。如果你沒發現你的網站明顯的渲染緩慢,那大可別太在意,在以後的工作中多注意就行了。

超級快速,零實用性

我們知道ID's 是最高效的選取器。當你想讓渲染速度最高效時,你可能會給每個獨立的標籤配置一個ID,然後用這些ID寫樣式。那會超級快,也超級荒唐。這樣的結果是語義極差,維護難到了極點。即使在核心部分你也不應該見過這樣做的。我認為這個可以提醒我們不要為了高效的CSS放棄語義和可維護性。

Thanks to Jason Beaudoin for emailing me about the idea. If anyone knows more about this stuff, or if you have additional tips that you use in this same vein, let’s hear it!

順便提一下,因為CSS選取器被很多javascript庫使用,上面提到的東東仍然適用,ID選取器還是最快的,後代選取器和類似的東東比較慢。

PS:看誰還敢用N多的後代選取器。。。還有反對我用ID的。。。哇哈哈。。。



相關文章

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.