爲何瀏覽器讀取css規則的順序是從右到左

 最近研究css性能優化，明白了瀏覽器讀取css選擇器的順序是從右到左。可是爲何呢？這就涉及到了瀏覽器渲染頁面的順序，而關於瀏覽器的渲染，咱們首頁要了解瀏覽器的架構

瀏覽器構架圖

如上圖所示，瀏覽器主要由 用戶界面（User Interface）, 瀏覽器引擎(Browser engine), 渲染引擎（Rendering engine), 網絡模塊(Networking)，js解析器(Javascript Interpreter)，用戶界面後臺（UI Backend）和數據持久層(Data persistence) 等幾部分組成。其中各模塊除了Browser engine是用來協調Render engine和UI層（也許還有別的層）的，UI Backend是用來繪製頁面上的各個組件的，其它模塊的用途都見名知義，因此也就很少說了。

 

OK,進入正題。從用戶在地址欄中輸入地址並按下回車，到他看到整個頁面的過程大體以下：

1.用戶在瀏覽器地址欄輸入地址，按下回車；
2. 瀏覽器向服務器發送請求，服務器響應請求並返回數據；（這其中的DNS解析，路由解析，服務器mvc請求分發，鏈接數據庫等一系列操做略過）
3.瀏覽器接收服務器傳回的html代碼，經過詞法解析和語法解析生成dom樹，生成dom樹期間，解析到link標籤則去下載相應的css文件，待全部外部css文件下載完成後，結合頁面中的style標籤和標籤行內style樣式，生成render樹. render樹包含了每一個dom節點的樣式信息（位置，大小，字體，背景等）。
4.結合dom樹和render樹繪製頁面，以下圖所示：

渲染引擎基本工做流程

咱們要研究的問題發生在步驟3,構建render樹的過程當中。
       構建render樹的過程是遍歷dom樹, 每次拿出一個dom節點，而後遍歷全部的樣式規則查找與當前節點匹配的規則，最後將全部匹配的規則中定義的樣式寫入一個render對象中，再將該render對象掛到render樹上（這個render對象和 dom節點會以某種方式創建聯接，知道彼此的存在）。
    也就是說，每次只有一個dom節點，且該節點標籤名稱，擁有的class和id等我是已知的，例如<span class="abc" id="demo">，但卻可能有成千上萬條css規則(這個數量並不誇張)，咱們須要從這多的規則中找中符合當前的節點的1條或幾條規則(這個數量毫不會不少)。
    因爲每條規則均可能有多層嵌套，例如 #container p.content  .title a {...}，若是採用從左到右的方式讀取css規則，那麼大多數規則讀到最後會發現是不匹配的，這樣會作不少無用功。
    而若是採起從右到左的方式，那麼只要發現最右邊的key selector不匹配，整條規則就都沒必要再看下去了。例如當前節點是<span class="abc" id="demo">, 那麼只有最右端選擇器是span或.abc或#demo的css 規則有可能匹配，其它的就能夠直接被捨棄了。
    根據2009年Google和Firefox的測試，right-to-left方式能夠避免70%左右的無效匹配，所以目前主流瀏覽器都採用這種方式讀取css selector(css規則).



參考資料：
http://stackoverflow.com/questions/5797014/why-do-browsers-match-css-selectors-from-right-to-left
http://taligarsiel.com/Projects/howbrowserswork1.htm

注： 文中圖片均引自http://taligarsiel.com/Projects/howbrowserswork1.htm