一、簡單介紹一下什么是瀏覽器內核。
瀏覽器最重要或者說核心的部分是“Rendering Engine”，可大概譯為“解釋引擎”，不過我們一般習慣將之稱為“瀏覽器內核”。負責對網頁語法的解釋（如HTML、JavaScript）並渲染（顯示）網頁。 所以，通常所謂的瀏覽器內核也就是瀏覽器所采用的渲染引擎，渲染引擎決定了瀏覽器如何顯示網頁的內容以及頁面的格式信息。不同的瀏覽器內核對網頁編寫語法的解釋也有不同，因此同一網頁在不同的內核的瀏覽器里的渲染（顯示）效果也可能不同，這也是網頁編寫者需要在不同內核的瀏覽器中測試網頁顯示效果的原因。
改而來的，並沿用到目前的IE9。Trident實際上是一款開放的內核，其接口內核設計的相當成熟，因此才有許多
采用IE內核而非IE的瀏覽器涌現（如 Maxthon、The World 、TT、GreenBrowser、AvantBrowser等）。此外，
為了方便也有很多人直接簡稱其為IE內核（當然也不排除有部分人是因為不知道內核名稱而只好如此說）。由於IE本身的“壟斷性”（雖然名義上IE並非壟斷，但實際上，特別是從Windows 95年代一直到XP初期，就市場占有率來說IE的確借助Windows的東風處於“壟斷”的地位）而使得Trident內核的長期一家獨大，微軟很長時間都並沒有更新Trident內核，這導致了兩個后果——一是Trident內核曾經幾乎與W3C標准脫節（2005年），二是Trident內核的大量 Bug等安全性問題沒有得到及時解決，然后加上一些致力於開源的開發者和一些學者們公開自己認為IE瀏覽器不安全的觀點，也有很多用戶轉向了其他瀏覽器，Firefox和Opera就是這個時候興起的。非Trident內核瀏覽器的市場占有率大幅提高也致使許多網頁開發人員開始注意網頁標准和非IE瀏覽器的瀏覽效果問題。
是代碼完全公開，因此，其可開發程度很高，全世界的程序員都可以為其編寫代碼，增加功能。因為這是個開源
內核，因此受到許多人的青睞，Gecko內核的瀏覽器也很多，這也是Geckos內核雖然年輕但市場占有率能夠迅速
提高的重要原因。 事實上，Gecko引擎的由來跟IE不無關系，前面說過IE沒有使用W3C的標准，這導致了微軟內部一些開發人員的不滿；他們與當時已經停止更新了的 Netscape的一些員工一起創辦了Mozilla，以當時的Mosaic內核為基礎
重新編寫內核，於是開發出了Geckos。不過事實上，Gecko 內核的瀏覽器仍然還是Firefox (火狐) 用戶最多，
所以有時也會被稱為Firefox內核。此外Gecko也是一個跨平台內核，可以在Windows、 BSD、Linux和Mac OS X
中使用。
實際上這是一個動態內核，與前面幾個內核的最大的區別就在腳本處理上，Presto有着天生的優勢，頁面的全部或者部分都能夠在回應腳本事件時等情況下被重新解析。
此外該內核在執行Javascrīpt的時候有着最快的速度，根據在同等條件下的測試，Presto內核執行同等Javascrīpt所需的時間僅有Trident和Gecko內核的約1/3（Trident內核最慢，不過兩者相差沒有多大）。
那次測試的時候因為Apple機的硬件條件和普通PC機不同所以沒有測試WebCore內核。只可惜Presto是商業引擎，使用Presto的除開Opera以外，只剩下NDSBrowser、Wii Internet Channle、Nokia 770網絡瀏覽器等，這很大程度上限制了Presto的發展。
所以Webkit也是自由軟件，同時開放源代碼。在安全方面不受IE、Firefox的制約，所以Safari瀏覽器在國內還是很安全的。
限於Mac OS X的使用不廣泛和Safari瀏覽器曾經只是Mac OS X的專屬瀏覽器，這個內核本身應該說市場范圍並不大；但似乎根據最新的瀏覽器調查表明，該瀏覽器的市場甚至已經超過了Opera的Presto了——當然這一方面得益於蘋果轉到x86架構之后的人氣暴漲，另外也是因為Safari 3終於推出了Windows版的緣故吧。
Mac下還有OmniWeb、Shiira等人氣很高的瀏覽器。
google的chrome也使用webkit作為內核。
WebKit 內核在手機上的應用也十分廣泛，例如 Google 的手機 Gphone、 Apple 的 iPhone， Nokia’s Series 60 browser 等所使用的 Browser 內核引擎，都是基於 WebKit。
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腳本執行了這條語句，它命令瀏覽器隱藏掉代碼中的某個
9. 終於等到了</html>的到來，瀏覽器淚流滿面……
10. 等等，還沒完，用戶點了一下界面中的“換膚”按鈕，Javascript讓瀏覽器換了一下<link>標簽的CSS路徑；
11. 瀏覽器召集了在座的各位
求了新的CSS文件，重新渲染頁面。
瀏覽器每天就這么來來回回跑着，要知道不同的人寫出來的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書寫過程中，總結出如下性能提升的方案：
- 避免使用通配規則 如 *{} 計算次數驚人！只對需要用到的元素進行選擇
- 盡量少的去對標簽進行選擇，而是用class 如：#nav li{},可以為li加上nav_item的類名，如下選擇.nav_item{}
- 不要去用標簽限定ID或者類選擇符 如：ul#nav,應該簡化為#nav
- 盡量少的去使用后代選擇器，降低選擇器的權重值 后代選擇器的開銷是最高的，盡量將選擇器的深度降到最低，最高不要超過三層，更多的使用類來關聯每一個標簽元素
- 考慮繼承 了解哪些屬性是可以通過繼承而來的，然后避免對這些屬性重復指定規則
選用高效的選擇符，可以減少頁面的渲染時間，從而有效的提升用戶體驗（頁面越快，用戶當然越喜歡^_^）,你可以看一下CSS selectors Test，這個實驗的重點是評估復雜選擇符和簡單選擇符的開銷。也許當你想讓渲染速度最高效時，你可能會給每個獨立的標簽配置一個ID，然后用這些ID寫樣式。那的確會超級快，也超級荒唐！這樣的結果是語義極差，后期的維護難到了極點。
但說到底，CSS性能這東西對於小的項目來講可能真的是微乎其微的東西，提升可能也不是很明顯，但對於大型的項目肯定是有幫助的。而且一個好的CSS書寫習慣和方式能夠幫助我們更加嚴謹的要求自己。