標籤：
一、簡單介紹一下什麼是瀏覽器核心。
瀏覽器最重要或者說核心的部分是“Rendering Engine”，可大概譯為“解釋引擎”，不過我們一般習慣將之稱為“瀏覽器核心”。負責對網頁文法的解釋（如HTML、JavaScript）並渲染（顯示）網頁。 所以，通常所謂的瀏覽器核心也就是瀏覽器所採用的渲染引擎，渲染引擎決定了瀏覽器如何顯示網頁的內容以及頁面的格式資訊。不同的瀏覽器核心對網頁編寫文法的解釋也有不同，因此同一網頁在不同的核心的瀏覽器裡的渲染（顯示）效果也可能不同，這也是網頁編寫者需要在不同核心的瀏覽器中測試網頁顯示效果的原因。
Web頁面運行在各種各樣的瀏覽器當中，瀏覽器載入、渲染頁面的速度直接影響著使用者體驗簡單地說，頁面渲染就是瀏覽器將html代碼根據CSS定義的規則顯示在瀏覽器視窗中的這個過程。先來大致瞭解一下瀏覽器都是怎麼幹活的：
1. 使用者輸入網址（假設是個html頁面，並且是第一次訪問），瀏覽器向伺服器發出請求，伺服器返回html檔案；
2. 瀏覽器開始載入html代碼，發現<head>標籤內有一個<link>標籤引用外部CSS檔案；
3. 瀏覽器又發出CSS檔案的請求，伺服器返回這個CSS檔案；
4. 瀏覽器繼續載入html中<body>部分的代碼，並且CSS檔案已經拿到手了，可以開始渲染頁面了；
5. 瀏覽器在代碼中發現一個<img>標籤引用了一張圖片，向伺服器發出請求。此時瀏覽器不會等到圖片下載完，而是繼續渲染後面的代碼；
6. 伺服器返回圖片檔案，由於圖片佔用了一定面積，影響了後面段落的排布，因此瀏覽器需要回過頭來重新渲染這部分代碼；
7. 瀏覽器發現了一個包含一行Javascript代碼的<script>標籤，趕快運行它；
8. Javascript指令碼執行了這條語句，它命令瀏覽器隱藏掉代碼中的某個
瀏覽器每天就這麼來來回回跑著，要知道不同的人寫出來的html和css代碼品質參差不齊，說不定哪天跑著跑著就掛掉了。好在這個世界還有這麼一群人——頁面重構工程師，平時挺不起眼，也就幫視覺設計師們切切圖啊改改字，其實背地裡還是幹了不少實事的。
說到頁面為什麼會慢？那是因為瀏覽器要花時間、花精力去渲染，尤其是當它發現某個部分發生了點變化影響了布局，需要倒回去重新渲染，內行稱這個回退的過程叫reflow。
reflow幾乎是無法避免的。現在介面上流行的一些效果，比如樹狀目錄的摺疊、展開（實質上是元素的顯示與隱藏）等，都將引起瀏覽器的 reflow。滑鼠滑過、點擊……只要這些行為引起了頁面上某些元素的佔位面積、定位方式、邊距等屬性的變化，都會引起它內部、周圍甚至整個頁面的重新渲染。通常我們都無法預估瀏覽器到底會reflow哪一部分的代碼，它們都彼此相互影響著。
reflow問題是可以最佳化的，我們可以盡量減少不必要的reflow。比如開頭的例子中的<img>圖片載入問題，這其實就是一個可以避免的reflow——給圖片設定寬度和高度就可以了。這樣瀏覽器就知道了圖片的佔位面積，在載入圖片前就預留好了位置。
另外，有個和reflow看上去差不多的術語：repaint，中文叫重繪。 如果只是改變某個元素的背景色、文字顏色、邊框顏色等等不影響它周圍或內部布局的屬性，將只會引起瀏覽器repaint。repaint的速度明顯快於 reflow（在IE下需要換一下說法，reflow要比repaint 更緩慢）。
三、從瀏覽器的渲染原理講CSS效能(http://hi.baidu.com/zhoumm1008/blog/item/03fa88f97fe5ddebfd037f4b.html)
平時我們幾乎每天都在和瀏覽器打交道，寫出來的頁面很有可能在不同的瀏覽器下顯示的不一樣。苦逼的前端攻城師們為了相容各個瀏覽器而不斷地去測試和調試，還在腦子中記下各種遇到的BUG及解決方案，而我們好像並沒有去主動地關注和瞭解下瀏覽器的工作原理。如果我們對此做一點瞭解，我想在項目過程中就可以根據它有效避免一些問題以及對頁面效能做出相應的改進。今天我們主要根據瀏覽器的渲染原理對CSS的書寫效能做一點改進（當然還有JS本篇文章暫不考慮，後面的文章會做介紹），下面讓我們一起來揭開瀏覽器的渲染原理這一神秘的面紗吧：
最終決定瀏覽器表現出來的頁面效果的差異是：渲染引擎 Rendering Engine（也叫做排版引擎），也就是我們通常所說的“瀏覽器核心”，負責解析網頁文法（如HTML、JavaScript）並渲染、展示網頁。相同的代碼在不同的瀏覽器呈現出來的效果不一樣，那麼就很有可能是不同的瀏覽器核心導致的。
我們來看一下載入頁面時瀏覽器的具體工作流程（圖一）：
（圖一）
1、解析HTML以重建DOM樹（Parsing HTML to construct the DOM tree ）：渲染引擎開始解析HTML文檔，轉換樹中的標籤到DOM節點，它被稱為“內容樹”。
2、構建渲染樹（Render tree construction）：解析CSS（包括外部CSS檔案和樣式元素），根據CSS選取器計算出節點的樣式，建立另一個樹 —- 渲染樹。
3、布局渲染樹（Layout of the render tree）: 從根節點遞迴調用，計算每一個元素的大小、位置等，給每個節點所應該出現在螢幕上的精確座標。
4、繪製渲染樹（Painting the render tree） : 遍曆渲染樹，每個節點將使用UI後端層來繪製。
主要的流程就是：構建一個dom樹，頁面要顯示的各元素都會建立到這個dom樹當中，每當一個新元素加入到這個dom樹當中，瀏覽器便會通過css引擎查遍css樣式表，找到符合該元素的樣式規則應用到這個元素上。
注意了：css引擎尋找樣式表，對每條規則都按從右至左的順序去匹配。 看如下規則：
| 1 | #nav li {} |
看起來很快，實際上很慢，儘管這讓人有點費解#_#。我們中的大多數人，尤其是那些從左至右閱讀的人，可能猜想瀏覽器也是執行從左至右匹配規則的，因此會推測這條規則的開銷並不高。在腦海中，我們想象瀏覽器會像這樣工作：找到唯一的ID為nav的元素，然後把這個樣式應用到直系子項目的li元素上。我們知道有一個ID為nav的元素，並且它只有幾個Li子項目，所以這個CSS選擇符應該相當高效。
事實上，CSS選擇符是從右至左進行匹配的。瞭解這方面的知識後，我們知道這個之前看似高效地規則實際開銷相當高，瀏覽器必須遍曆頁面上每個li元素並確定其父元素的id是否為nav。
| 1 | *{} |
額，這種方法我剛寫CSS的也寫過，殊不知這種效率是差到極點的做法，因為*萬用字元將匹配所有元素，所以瀏覽器必須去遍曆每一個元素，這樣的計算次數可能是上萬次！
| 1 | ul#nav{} ul.nav{} |
在頁面中一個指定的ID只能對應一個元素，所以沒有必要添加額外的限定符，而且這會使它更低效。同時也不要用具體的標籤限定類選擇符，而是要根據實際的情況對類名進行擴充。例如把ul.nav改成.main_nav更好。
| 1 | ul li li li .nav_item{} |
對於這樣的選取器，之前也寫過，最後自己也數不過來有多少後代選取器了，何不用一個類來關聯最後的標籤元素，如.extra_navitem，這樣只需要匹配class為extra_navitem的元素，效率明顯提升了
對此，在CSS書寫過程中，總結出如下效能提升的方案：
選用高效的選擇符，可以減少頁面的渲染時間，從而有效提升使用者體驗（頁面越快，使用者當然越喜歡^_^）,你可以看一下CSS selectors Test，這個實驗的重點是評估複雜選擇符和簡單選擇符的開銷。也許當你想讓渲染速度最高效時，你可能會給每個獨立的標籤配置一個ID，然後用這些ID寫樣式。那的確會超級快，也超級荒唐！這樣的結果是語義極差，後期的維護難到了極點。
但說到底，CSS效能這東西對於小的項目來講可能真的是微乎其微的東西，提升可能也不是很明顯，但對於大型的項目肯定是有協助的。而且一個好的CSS書寫習慣和方式能夠協助我們更加嚴謹的要求自己。
不同核心瀏覽器的差異以及瀏覽器渲染(轉)
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
