任何上過網的用戶對瀏覽器是再熟悉不過了。只是用戶看到僅僅只是瀏覽器本身，卻很少能看到瀏覽器最核心的部分—瀏覽器內核。從第一款libwww（Library WorldWideWeb）瀏覽器發展至今已經經歷了無數競爭與淘汰了。現在國內常見的瀏覽器有：IE、Firefox、QQ瀏覽器、Safari、Opera、Google Chrome、百度瀏覽器、搜狗瀏覽器、獵豹瀏覽器、360瀏覽器、UC瀏覽器、遨游瀏覽器、世界之窗瀏覽器等。
但目前最為主流瀏覽器有五大款，分別是IE、Firefox、Google Chrome、Safari、Opera。
瀏覽器最重要的部分是瀏覽器的內核。瀏覽器內核是瀏覽器的核心，也稱“渲染引擎”，用來解釋網頁語法並渲染到網頁上。瀏覽器內核決定了瀏覽器該如何顯示網頁內容以及頁面的格式信息。不同的瀏覽器內核對網頁的語法解釋也不同，因此網頁開發者需要在不同內核的瀏覽器中測試網頁的渲染效果。
- 對網頁的語法解釋不同
- 渲染效果不一樣
- 性能不一樣，支持腳本的執行速度等不一樣，而且支持局部（隱藏元素等）repaint和reflow的情況比較復雜不一樣1、IE瀏覽器：
IE是微軟公司旗下瀏覽器，是目國內用戶量最多的瀏覽器。IE誕生於1994年，當時微軟為了對抗市場份額占據將近百分之九十的網景Netscape Navigator，於是在Windows中開發了自己的瀏覽器Internet Explorer，自此也引發了第一次瀏覽器大戰。結果可想而知，微軟大獲全勝，網景不得不將自己賣給AOL公司。但實際上事情並沒有結束，網景后來開發了風靡一時的Firefox火狐，至今Firefox也成為世界五大瀏覽器之一。
1996年，微軟從Spyglass手里拿到Spyglass Mosaic的源代碼和授權，開始開發自己的瀏覽器IE。后來，微軟以IE和Windows捆綁的模式不斷向市場擴展份額，使IE成為市場的絕對主流。現在裝了Windows系統的電腦基本無法卸載IE。
2、Opera瀏覽器：
Opera是挪威Opera Software ASA公司旗下的瀏覽器。1995年，opera公司發布第一版Opera瀏覽器，使用自己研發的Presto內核。當時opera公司的開發團隊不斷完善Presto內核，使Opera瀏覽器一度成為頂級瀏覽器。直到2016年奇虎360和昆侖萬維收購了Oprea瀏覽器，從此也丟棄了強大的Presto內核，改用當時Google開源的webkit內核。后來Opera瀏覽器跟隨Google將瀏覽器內核改為Blink內核。自此Presto內核也淡出了互聯網市場。
3、Safari瀏覽器：
第二次瀏覽器大戰是從蘋果公司發布Safari瀏覽器開始的。2003年，蘋果公司在蘋果手機上開發Safari瀏覽器，利用自己得天獨厚的手機市場份額使Safari瀏覽器迅速成為世界主流瀏覽器。Safari是最早使用webkit內核的瀏覽器也是現在蘋果默認的瀏覽器。
4、Firefox瀏覽器：
Firefox瀏覽器使Mozilla公司旗下瀏覽器，也是剛才提到的網景公司后來的瀏覽器。網景被收購后，網景人員創辦了Mozilla基金會，這是一個非盈利組織，他們在2004年推出自己的瀏覽器Firefox。Firefox采用Gecko作為內核。Gecko是一個開源的項目，代碼完全公開，因此受到很多人的青睞。Firefox的問世加快了第二次瀏覽器大戰的開始。第二次瀏覽器大戰與第一次二元鼎力的局面不同，這一次的特點就是百家爭鳴，也自此打破了IE瀏覽器從98年網景被收購后獨步瀏覽器市場的局面。
5、Chrome瀏覽器：
Chrome瀏覽器是google旗下的瀏覽器。Chrome瀏覽器至發布以來一直講究簡潔、快速、安全，所以Chrome瀏覽器到現在一直受人追捧。最開始Chrome采用webkit作為瀏覽器內核，直到2013年，google宣布不再使用蘋果的webkit內核，開始使用webkit的分支內核Blink。
以上是五大瀏覽器的簡介，接下來是四大內核。在介紹五大瀏覽器的同時也已經順便介紹了四大內核。四大內核分別是：Trident（也稱IE內核）、webkit、Blink、Gecko。五大瀏覽器采用的都是單內核，而隨着瀏覽器的發展現在也出現了雙內核。像360瀏覽器、QQ瀏覽器都是采用雙內核。
作為前端開發，熟悉四大內核是非常有必要的。四大內核的解析不同使網頁渲染效果更具多樣化。下面總結一下各常用瀏覽器所使用的內核。
1、IE瀏覽器內核：Trident內核，也是俗稱的IE內核；
2、Chrome瀏覽器內核：統稱為Chromium內核或Chrome內核，以前是Webkit內核，現在是Blink內核；
3、Firefox瀏覽器內核：Gecko內核，俗稱Firefox內核；
4、Safari瀏覽器內核：Webkit內核；
5、Opera瀏覽器內核：最初是自己的Presto內核，后來是Webkit，現在是Blink內核；
6、360瀏覽器、獵豹瀏覽器內核：IE+Chrome雙內核；
7、搜狗、遨游、QQ瀏覽器內核：Trident（兼容模式）+Webkit（高速模式）；
8、百度瀏覽器、世界之窗內核：IE內核；
9、2345瀏覽器內核：以前是IE內核，現在也是IE+Chrome雙內核；瀏覽器渲染原理
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腳本執行了這條語句，它命令瀏覽器隱藏掉代碼中的某個
（style.display=”none”）。杯具啊，突然就少了這么一個元素，瀏覽器不得不重新渲染這部分代碼；
9. 終於等到了</html>的到來，瀏覽器淚流滿面……
10. 等等，還沒完，用戶點了一下界面中的“換膚”按鈕，Javascript讓瀏覽器換了一下<link>標簽的CSS路徑；
11. 瀏覽器召集了在座的各位<span><ul><li>們，“大伙兒收拾收拾行李，咱得重新來過……”，瀏覽器向服務器請
求了新的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書寫習慣和方式能夠幫助我們更加嚴謹的要求自己。