摘要：既然出現了，那怎么辦，目前并沒聽說出現什么新的技術替代它雖然它真的已經很不適合現代的前端了，那么只能開發一個新的引擎提高性能，這就是火狐家的量子引擎又叫。這就是所謂的，火狐前一個引擎所做的那樣。

本文翻譯自Inside a super fast CSS engine: Quantum CSS ，如果想要閱讀原文，可以點擊前往，以下內容夾雜本人一些思考，翻譯也并不一定完全。

為什么翻譯這篇文章尼，一開始只是好奇，基本在前端技術圈子混過都知道火狐正在用Rust語言開發新的瀏覽器引擎，作為前端開發對火狐的感情還是大大的有（雖然現在已經離不開chrome了），但是還是希望火狐能夠再次引領Web的變革。
可以說前端這幾年解決了前端工程化的很多痛點，但是性能這個坎依舊，期望webassembly盡快普及，但是對于前端必定又是一場腥風血雨，前端不會一直是現在這樣的前端。既然webassembly出現了，那css怎么辦，目前并沒聽說出現什么新的技術替代它（雖然它真的已經很不適合現代的前端了），那么只能開發一個新的引擎提高性能，這就是火狐家的量子引擎：Quantum CSS（又叫Stylo）。

這是火狐正在開發的Quantum項目，目的當然是為了讓瀏覽器更快，從上圖可以看得到各個模塊，而Quantum CSS處于中間位置，這跟它在整個渲染過程中的位置一樣，利用Rust可以相當有效利用現代處理器多核心的特性，能夠幾倍的提速。既然這么厲害，那從哪里可以體驗尼：在火狐Nightly版進入about:config設置layout.css.servo.enabled 屬性為 true就可以體驗這吊炸天的引擎。

站在巨人的肩膀上，當然除了利用現代處理器的并行能力，還借鑒當前各家瀏覽器積累的一些優化技術，接下來會一一解析這些優化技術，如何讓引擎更快。

CSS引擎是瀏覽器渲染引擎的一部分，而渲染引擎會把我們的HTML和CSS轉換成屏幕上的像素（也就是畫面吧）。
各家瀏覽器都會有自家的渲染引擎，例如谷歌的Blink，Edge的EdgeHTML，Safari的Webkit和火狐的Gecko，雖然有這么多引擎，但是他們都做著同樣的事情：把HTML和CSS渲染成我們可以感知的界面。
而他們內部的工作需要：

首先解析HTML文檔，生成DOM節點樹，讓瀏覽器可以知道頁面的結構和各個節點的關系。

然后就要弄清楚每個元素長什么樣子了，圓的還是方的，有邊框還是沒邊框等等；所以這個時候就需要知道每個元素需要應該用什么樣式。

除了知道長的樣子，還要知道各個節點的位置和布局。引擎會為所有可見的節點都會創建一個box，但是box并不僅為DOM節點而創建，DOM節點內部也可以有其他box，例如幾行文字。

知道該應用的樣式和位置，現在輪到繪制這些box了，這個工作可能會在多個layer上發生。可以認為就像舊時動畫制作技術，在一張透明的膠片上繪制背景，在另外的膠片上繪制人物或者其他元素。這樣的話就如果人物會動起來的時候，就只用重新繪制人物那張膠片了，不用繪制其他的，這樣就省事好多了。

到了這一步現在我們有不同的膠片（layer），是時候開始合成了（composite），但是合成之前，我們可能還會應用一些transform，旋轉啊，偏移啊等等。最后把他們按照層級堆在一起，背景在后，人物在前等等，然后最終渲染到屏幕上。

綜合后，我們可以知道CSS引擎開始計算樣式時需要兩樣東西：DOM的節點樹和一系列的樣式規則。
CSS引擎會遍歷所有DOM節點并計算每個節點所應用的樣式，它會讓DOM節點每個CSS屬性都有一個值，就算你在樣式表中并沒有聲明，它可能來自繼承或者默認值，或者客戶端的樣式表（User Agent Style）。
可以認為引擎就像填表格一樣，把這些最后計算出來的值一個一個填進去。

為了得到上面的表格，CSS引擎需要做兩件事：

搞清楚每個節點所應用的樣式規則（selector matching）

把一些你沒有聲明的值，根據繼承或者默認值補充上去（the cascade）

首先找出配置當前的節點的樣式規則，放到一個list上去，這里也包括客戶端的樣式表。

然后會計算各個樣式規則之間的權重，并且根據權重排序。

根據權重大小，得出最終應用的樣式屬性的值。

級聯（The cascade）目的是為了讓CSS更容易編寫和維護，由于級聯的存在，你可以在body上設置color屬性，而li,p,span等元素可以直接使用同樣的color，不需要每個元素都要去定義一次。
為了實現這個功能，CSS引擎會從表格里面尋找一些屬性值仍然為空的值，如果屬性默認是繼承的話，CSS引擎會從父節點那里繼承屬性值，如果所有父節點都沒有定義該屬性值的話，就會使用默認的值。
現在我們的表格都填滿了

上述表格的形式，只是一種表現方式，引擎真實的內部不是這樣的。CSS擁有成千上百的屬性，如果引擎為每個節點都生成這樣一張表，會很快耗掉所有內存。
相反引擎內部通常會使用style struct sharing，樣式的數據會集中在不同對象里面（style struct），然后使用指針指向這些對象。

這會很大程度上節省內存，因為各個節點間都很有可能擁有相似的屬性值（例如兄弟節點間），另外因為很多屬性也是通過繼承獲取的，所以父節點可以跟子節點間共享這些屬性值。

如果我們不去優化這些工作，整個樣式計算工作就會是這樣：

這是巨量的工作，而且并不僅僅在頁面加載的時候發生，它會隨著用戶的交互時刻都在存在（例如hover一個元素，CSS引擎需要從新計算樣式）。

這樣就意味著必須得去優化樣式的計算工作，在過去20年，已經測試過不同的優化策略，而Quantum CSS則是組合利用這些最優的優化策略。

我們現在的CPU大多擁有多個核心，而Quantum CSS則會把不同DOM節點的樣式計算工作分配到不同的核心上去，但是實現也有相當的難度，其中一個原因就是DOM節點樹并不一定均勻的，這會導致其中一部分核心工作負荷比其他核心大。

為了讓各個核心工作負荷更加合理，Quantum CSS使用了一種技術稱作 work stealing，當一個DOM節點被處理的時候，引擎可以把它的子節點計算工作分成幾個“work units”并且放進隊列中。
當其中一個核心清空自身隊列的工作后，它能夠尋找其他隊列上的其他work units然后執行，這意味著我們不需要提前就去分配好工作，在運行時也會達到最高的工作效率。

在大部分瀏覽器里面，很難讓這種機制毫無錯誤的運行，而且CSS引擎本身就非常復雜，它在渲染引擎中兩個最復雜的模塊（DOM和layout）中間。這個過程非常容易產生bug，而且并行程序導致的bug非常難debug，可以通過這篇文章了解更多。

對于每個DOM節點，CSS引擎需要遍歷所有樣式規則去進行selector matching，且對于大部分節點這種matching并不會經常改變。例如，用戶hover一個父節點，它的樣式規則可能會改變，但是我們仍然需要重新子節點的樣式規則去處理屬繼承的屬性值，而子節點之前匹配的規則很有可能不會改變。
如果我們記錄好子節點匹配哪些樣式規則，而不用每次都進行一次selector matching，這可能會得到很大的優化。這就是所謂的rule tree，火狐前一個引擎所做的那樣。
CSS引擎會遍歷樣式規則幫DOM節點找出匹配的選擇器，然后根據權重排序，從而創建出一個樣式規則的鏈表，然后將這個鏈表添加到rule tree中。

CSS引擎會盡可能利用已有的分支，為rule tree保持最少的分支數。
如果大部分鏈表中大部分的選擇器，跟已存在的分支一樣，引擎會順著路徑，除非它到達一個節點，rule tree并不存在一樣分支，引擎就會添加一個新的分支。

在重新計算樣式的過程中，引擎會快速檢查父節點的改變是否會導致子節點匹配的樣式規則改變。如果沒有，子節點可以根據自己指向rule tree節點的指針計算樣式。引擎會rule tree的節點往上查找，獲取整個匹配的規則，從權重最大到權重最小的。這樣就可以很輕松的跳過selector matching這一步了。

但是這樣仍然還有很多工作要做，畢竟一個頁面上節點成千上萬，這時候并行計算的魔法又可以大顯神威了。

由于整個頁面的節點可能會有成千上萬個，它們當中很多都匹配著相同的規則。例如wiki頁面中每個p元素其實逗匹配著相同的樣式規則，擁有一樣的computed styles。
如果這里沒有做優化，可能每個段落都要重新計算，但是如果有一種方法來證明每個段落的樣式規則都是一樣，引擎就只需計算一次就可以了。
這就是所謂的style sharing cache，由Chrome和Safari所發明的一種優化方式，在引擎處理一個節點后會把computed style放到cache里面，然后開始計算下一個節點的時候，引擎會先檢查cache里面是否已經存在計算后的值。
而這些檢查包括：

兩個節點是否都有一樣的ID和Class等，如果一樣它們匹配同樣的規則。

對于非selector的行內樣式，它們是否擁有一樣的值。

它們的父節點都是否指向同一個computed style object，如果一樣它們的繼承的值都會一樣。

但是也有很多其他的情況，導致這些檢查失效，例如：如果一個CSS規則使用了:first-child選擇器，就算兩個節點都已經符合上述的規則，結果也會是檢查不通過。
在Webkit和Blink, style sharing cache在這些情況下會放棄檢查并不會使用cache。由于大部分網站都使用了這些modern selectors（CSS3），這個優化的作用變得越來越少，所以Blink團隊最近把它移除了。
在Quantum CSS，我們收集了所有這些怪異的選擇器（CSS3）然后讓它們加入檢查。我們會把結果存儲為0和1，如果兩個元素擁有同樣的0和1，那我們就知道他們是匹配同樣的樣式規則。

這樣我們就可以繼續享受style sharing cache帶來的優化。

前半部分可以讓我們知道CSS引擎的工作內容，后半部分讓我們了解新引擎是如何優化性能的，真的學習了很多，我想你也一樣。