任何上過網的用戶對瀏覽器是再熟悉不過了。只是用戶看到僅僅只是瀏覽器自己，卻不多能看到瀏覽器最核心的部分—瀏覽器內核。從第一款libwww（Library WorldWideWeb）瀏覽器發展至今已經經歷了無數競爭與淘汰了。如今國內常見的瀏覽器有：IE、Firefox、QQ瀏覽器、Safari、Opera、Google Chrome、百度瀏覽器、搜狗瀏覽器、獵豹瀏覽器、360瀏覽器、UC瀏覽器、遨遊瀏覽器、世界之窗瀏覽器等。css
但目前最爲主流瀏覽器有五大款，分別是IE、Firefox、Google Chrome、Safari、Opera。
瀏覽器最重要的部分是瀏覽器的內核。瀏覽器內核是瀏覽器的核心，也稱「渲染引擎」，用來解釋網頁語法並渲染到網頁上。瀏覽器內核決定了瀏覽器該如何顯示網頁內容以及頁面的格式信息。不一樣的瀏覽器內核對網頁的語法解釋也不一樣，所以網頁開發者須要在不一樣內核的瀏覽器中測試網頁的渲染效果。html
- 對網頁的語法解釋不一樣
- 渲染效果不同
- 性能不同，支持腳本的執行速度等不同，並且支持局部（隱藏元素等）repaint和reflow的狀況比較複雜不同一、IE瀏覽器：IE是微軟公司旗下瀏覽器，是目國內用戶量最多的瀏覽器。IE誕生於1994年，當時微軟爲了對抗市場份額佔據將近百分之九十的網景Netscape Navigator，因而在Windows中開發了本身的瀏覽器Internet Explorer，自此也引起了第一次瀏覽器大戰。結果可想而知，微軟大獲全勝，網景不得不將本身賣給AOL公司。但實際上事情並無結束，網景後來開發了風靡一時的Firefox火狐，至今Firefox也成爲世界五大瀏覽器之一。1996年，微軟從Spyglass手裏拿到Spyglass Mosaic的源代碼和受權，開始開發本身的瀏覽器IE。後來，微軟以IE和Windows捆綁的模式不斷向市場擴展份額，使IE成爲市場的絕對主流。如今裝了Windows系統的電腦基本沒法卸載IE。二、Opera瀏覽器：Opera是挪威Opera Software ASA公司旗下的瀏覽器。1995年，opera公司發佈初版Opera瀏覽器，使用本身研發的Presto內核。當時opera公司的開發團隊不斷完善Presto內核，使Opera瀏覽器一度成爲頂級瀏覽器。直到2016年奇虎360和崑崙萬維收購了Oprea瀏覽器，今後也丟棄了強大的Presto內核，改用當時Google開源的webkit內核。後來Opera瀏覽器跟隨Google將瀏覽器內核改成Blink內核。自此Presto內核也淡出了互聯網市場。三、Safari瀏覽器：第二次瀏覽器大戰是從蘋果公司發佈Safari瀏覽器開始的。2003年，蘋果公司在蘋果手機上開發Safari瀏覽器，利用本身得天獨厚的手機市場份額使Safari瀏覽器迅速成爲世界主流瀏覽器。Safari是最先使用webkit內核的瀏覽器也是如今蘋果默認的瀏覽器。四、Firefox瀏覽器：Firefox瀏覽器使Mozilla公司旗下瀏覽器，也是剛纔提到的網景公司後來的瀏覽器。網景被收購後，網景人員創辦了Mozilla基金會，這是一個非盈利組織，他們在2004年推出本身的瀏覽器Firefox。Firefox採用Gecko做爲內核。Gecko是一個開源的項目，代碼徹底公開，所以受到不少人的青睞。Firefox的問世加快了第二次瀏覽器大戰的開始。第二次瀏覽器大戰與第一次二元鼎力的局面不一樣，這一次的特色就是百家爭鳴，也自此打破了IE瀏覽器從98年網景被收購後獨步瀏覽器市場的局面。五、Chrome瀏覽器：Chrome瀏覽器是google旗下的瀏覽器。Chrome瀏覽器至發佈以來一直講究簡潔、快速、安全，因此Chrome瀏覽器到如今一直受人追捧。最開始Chrome採用webkit做爲瀏覽器內核，直到2013年，google宣佈再也不使用蘋果的webkit內核，開始使用webkit的分支內核Blink。以上是五大瀏覽器的簡介，接下來是四大內核。在介紹五大瀏覽器的同時也已經順便介紹了四大內核。四大內核分別是：Trident（也稱IE內核）、webkit、Blink、Gecko。五大瀏覽器採用的都是單內核，而隨着瀏覽器的發展示在也出現了雙內核。像360瀏覽器、QQ瀏覽器都是採用雙內核。做爲前端開發，熟悉四大內核是很是有必要的。四大內核的解析不一樣使網頁渲染效果更具多樣化。下面總結一下各經常使用瀏覽器所使用的內核。一、IE瀏覽器內核：Trident內核，也是俗稱的IE內核；二、Chrome瀏覽器內核：統稱爲Chromium內核或Chrome內核，之前是Webkit內核，如今是Blink內核；三、Firefox瀏覽器內核：Gecko內核，俗稱Firefox內核；四、Safari瀏覽器內核：Webkit內核；五、Opera瀏覽器內核：最初是本身的Presto內核，後來是Webkit，如今是Blink內核；六、360瀏覽器、獵豹瀏覽器內核：IE+Chrome雙內核；七、搜狗、遨遊、QQ瀏覽器內核：Trident（兼容模式）+Webkit（高速模式）；八、百度瀏覽器、世界之窗內核：IE內核；九、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 更緩慢）。3、從瀏覽器的渲染原理講CSS性能(http://hi.baidu.com/zhoumm1008/blog/item/03fa88f97fe5ddebfd037f4b.html)平時咱們幾乎天天都在和瀏覽器打交道，寫出來的頁面頗有可能在不一樣的瀏覽器下顯示的不同。苦逼的前端攻城師們爲了兼容各個瀏覽器而不斷地去測試和調試，還在腦子中記下各類遇到的BUG及解決方案，而咱們好像並無去主動地關注和了解下瀏覽器的工做原理。若是咱們對此作一點了解，我想在項目過程當中就能夠根據它有效的避免一些問題以及對頁面性能作出相應的改進。今天咱們主要根據瀏覽器的渲染原理對CSS的書寫性能作一點改進（固然還有JS本篇文章暫不考慮，後面的文章會作介紹），下面讓咱們一塊兒來揭開瀏覽器的渲染原理這一神祕的面紗吧：最終決定瀏覽器表現出來的頁面效果的差別是：渲染引擎 Rendering Engine（也叫作排版引擎），也就是咱們一般所說的「瀏覽器內核」，負責解析網頁語法（如HTML、JavaScript）並渲染、展現網頁。相同的代碼在不一樣的瀏覽器呈現出來的效果不同，那麼就頗有多是不一樣的瀏覽器內核致使的。咱們來看一下加載頁面時瀏覽器的具體工做流程（圖一）： （圖一）一、解析HTML以重建DOM樹（Parsing HTML to construct the DOM tree ）：渲染引擎開始解析HTML文檔，轉換樹中的標籤到DOM節點，它被稱爲「內容樹」。二、構建渲染樹（Render tree construction）：解析CSS（包括外部CSS文件和樣式元素），根據CSS選擇器計算出節點的樣式，建立另外一個樹 —- 渲染樹。三、佈局渲染樹（Layout of the render tree）: 從根節點遞歸調用，計算每個元素的大小、位置等，給每一個節點所應該出如今屏幕上的精確座標。四、繪製渲染樹（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書寫習慣和方式可以幫助咱們更加嚴謹的要求本身。