1、簡單介紹一下什麼是瀏覽器內核。php
瀏覽器最重要或者說核心的部分是「Rendering Engine」,可大概譯爲「解釋引擎」,不過咱們通常習慣將之稱爲「瀏覽器內核」。負責對網頁語法的解釋(如HTML、JavaScript)並渲染(顯示)網頁。css
因此,一般所謂的瀏覽器內核也就是瀏覽器所採用的渲染引擎,渲染引擎決定了瀏覽器如何顯示網頁的內容以及頁面的格式信息。html
不一樣的瀏覽器內核對網頁編寫語法的解釋也有不一樣,所以同一網頁在不一樣的內核的瀏覽器裏的渲染(顯示)效果也可能不一樣,這也是網頁編寫者須要在不一樣內核的瀏覽器中測試網頁顯示效果的緣由。前端
目前微軟的Trident在移動終端上主要爲WP系統內置瀏覽器,Webkit內核的適用範圍則較爲普遍,Android原生瀏覽器、蘋果的Safari、谷歌的Chrome(Android4.0使用)都是基於Webkit開源內核開發的。html5
從實際狀況出發:程序員
對於Android手機而言,使用率最高的就是Webkit內核,咱們看到不少手機瀏覽器廠商都宣稱有着自主內核,好比手機UC就號稱採用了U3內核、而華爲也常常標榜本身的每天瀏覽器採用了T9內核,事實上,他們都是基於開源內核Webkit進行二次開發的,並非徹底的自主內核。web
而在iOS以及WP7平臺上,因爲系統封閉,不容許除系統自帶瀏覽器內核之外的瀏覽器內核進入,所以各家瀏覽器的開發均爲在Safari或者IE內核的基礎上進行二次開發,優化功能和自制UI。chrome
好比海豚、遨遊等瀏覽器就是直接採用系統自帶瀏覽器的內核,這點從這幾款瀏覽器的HTML5評分與系統自帶瀏覽器評分結果徹底一致就能夠看出。windows
內核並沒有手機與PC的區分,手機瀏覽器的內核與PC瀏覽器相似,例如:
後端
至於國內的UC和QQ等手機瀏覽器也都是根據Webkit修改過來的內核。
首先釐清一下瀏覽器內核是什麼東西。
英文叫作:Rendering Engine,中文翻譯不少,排版引擎、解釋引擎、渲染引擎,如今流行稱爲瀏覽器內核,至於爲何流行這麼稱呼,請自行領悟。
Rendering Engine,顧名思義,就是用來渲染網頁內容的,將網頁的內容和排版代碼轉換爲可視的頁面。由於是排版,因此確定會排版錯位等問題。爲何會排版錯位呢?有的是因爲網站自己編寫不規範,有的是因爲瀏覽器自己的渲染不標準。
如今有幾個主流的排版引擎,由於這些排版引擎都有其表明的瀏覽器,因此經常會把排版引擎的名稱和瀏覽器的名稱混用,好比常的說IE內核、Chrome內核。其實這樣子是不太合理的,由於一個完整的瀏覽器不會只有一的排版引擎,還有本身的界面框架和其它的功能支撐,而排版引擎自己也不可能實現瀏覽器的全部功能。下面羅列一下幾款主流的排版引擎和瀏覽器。
IE瀏覽器所使用的內核,也是不少瀏覽器所使用的內核,一般被稱爲IE內核。基於Trident內核的瀏覽器很是多,這是由於Trident內核提供了豐富的調用接口。老的Trident內核(好比常說的IE6內核)一直是不遵循W3C標準的,可是因爲它的市場份額最大,因此後果就是大量的網站只支持老的Trident內核,依據W3C標準寫的網頁在老的Trident內核下面又出現誤差。目前可供調用的最新版的Trident內核是IE9所用的內核,相較以前的版本對W3C標準的支持加強了不少。
Trident內核的瀏覽器:
IE六、IE七、IE8(Trident 4.0)、IE9(Trident 5.0)、IE10(Trident 6.0);
世界之窗一、世界之窗二、世界之窗3;
360安全瀏覽器一、360安全瀏覽器二、360安全瀏覽器三、360安全瀏覽器四、360安全瀏覽器5;
傲遊一、傲遊2;搜狗瀏覽器1;騰訊TT;阿雲瀏覽器(早期版本)、百度瀏覽器(早期版本)、瑞星安全瀏覽器、Slim Browser;
GreenBrowser、愛帆瀏覽器(12 以前版本)、115瀏覽器、155瀏覽器;
閃遊瀏覽器、N氧化碳瀏覽器、糖果瀏覽器、彩虹瀏覽器、瑞影瀏覽器、勇者無疆瀏覽器、114瀏覽器、螞蟻瀏覽器、飛騰瀏覽器、速達瀏覽器、佐羅瀏覽器;
Netscape6啓用的內核,如今主要由Mozilla基金會進行維護,是開源的瀏覽器內核,目前最主流的Gecko內核瀏覽器是Mozilla Firefox,因此也經常稱之爲火狐內核。由於Firefox的出現,IE的霸主地位逐步被削弱,Chrome的出現則是加速了這個進程。非Trident內核的興起正在改變着整個互聯網,最直接的就是推進了編碼的標準化,也使得微軟在競爭壓力下不得不改進IE。不過比較惋惜的是,雖然是開源的,也開發了這麼多年,基於Gecko的瀏覽器並很少見,除了一些簡單的改動(坑爹的X瀏覽器)或者是從新編譯(綾川ayakawa、tete009),深度定製或者加強型外殼的還比較少見。另外就是有一些其它軟件借用了Gecko內核,好比音樂管理軟件SongBird。
常見的Gecko內核的瀏覽器
Mozilla Firefox、Mozilla SeaMonkey
Epiphany(早期版本)、Flock(早期版本)、K-Meleon
KDE開發的內核,速度快捷,容錯度低。這個內核可能不見得不少人知道,可是後面再看下去你就明白了。
常見的KHTML內核的瀏覽器:Konqueror
由KHTML發展而來,也是蘋果給開源世界的一大貢獻。是目前最火熱的瀏覽器內核,火熱倒不是說市場份額,而是應用的面積和勢頭。由於是脫胎於KHTML,因此也是具備高速的特色,一樣遵循W3C標準。
常見的WebKit內核的瀏覽器:Apple Safari、Symbian系統瀏覽器
維基百科裏面並無將Chromium從WebKit分出來,這個區分徹底是基於我我的的惡趣味。記得之前看過一個大牛的博文說過,Chromium把WebKit的代碼梳理得可讀性提升不少,因此之前可能須要一天進行編譯的代碼,如今只要兩個小時就能搞定。這個我本身也沒有考究過,可是估計可信。這個也能解釋爲何Gecko和WebKit出來了這麼久,第三方編譯、定製的版本並很少,可是由Chromium衍生出來的瀏覽器早就滿坑滿谷了。
常見的Chromium內核的瀏覽器:Chromium、Google Chrome、SRWare Iron、Comodo Dragon
Opera的內核,準確地說,是Opera 7.0及之後版本的內核,Opera 3.5-6.1版本使用的內核叫作Elektra。不用說,Presto對W3C標準的支持也是很良好的。雖然我很喜歡Opera,可是我對Presto的渲染速度一直有保留態度。以前在OperaChina論壇看見有人說過,Presto優先解析文字,保證可閱讀性,媒體資源的渲染放後。
常見的Presto內核的瀏覽器:Opera
http://zh.wikipedia.org/wiki/排版引擎
說完了排版引擎,接下來講說JavaScript引擎。顧名思義,JavaScript引擎就是用來渲染JavaScript的。
爲何要單獨拿出來講呢?由於它涉及到跑分。常常看見不少文章在報道說哪一個瀏覽器更快,其實大部分說的就是JavaScript的渲染速度,而不是頁面的載入速度。在網速許可的狀況下,其實各個瀏覽器的頁面載入速度差異不大(Opera遜色一些)。那是否是說對比JavaScript的渲染速度其實沒有意義?也不是這麼說,由於如今JavaScript在頁面中的比重會愈來愈大,愈來愈多的動態頁面開始大量藉助JavaScript,好比如今主流的SNS、郵箱、網頁遊戲,因此JavaScript的渲染速度也是一個很重要的指標。
JavaScript的渲染速度越快,動態頁面的展現也越快。Opera在JavaScript引擎的跑分上面一直都是很牛逼的,通常來講最新測試版之間PK,Opera基本都會奪冠。
查克拉,IE9啓用的新的JavaScript引擎。
SpiderMonkey應用在Mozilla Firefox 1.0-3.0,TraceMonkey應用在Mozilla Firefox 3.5-3.6版本,JaegerMonkey應用在Mozilla Firefox 4.0及後續的版本。
應用於Chrome、傲遊3。
應用於Safari 4及後續的版本。
Linear A應用於Opera 4.0-6.1版本,Linear B應用於Opera 7.0~9.2版本,Futhark應用於Opera 9.5-10.2版本,Carakan應用於Opera 10.5及後續的版本。
KHTML對應的JavaScript引擎。
http://v8.googlecode.com/svn/data/benchmarks/v6/run.html
如今不少「雙核」瀏覽器都用它來跑分測試JavaScript引擎,分數越高越好。
標準支持測試,分數越高越好,滿分是100分。
測試瀏覽器對HTML5標準的支持,分數越高越好。
在沒有第三方編譯版本的時候,IETab一直是Mozilla Firefox、Chrome等非Trident內核的瀏覽器的安裝量最大的擴展之一,方便用戶在不開啓IE的狀況下調用Trident內核訪問一些兼容性比較差的網站。
雖然IETab能實現部分需求,可是深度訂製的畢竟仍是不同,因此Trident/Gecko雙核瀏覽器就誕生了,Sleipnir、Avant 12(Orca)是這類裏面比較常見的。Avant 12由於有Orca的前期積累,因此輕車熟路,後面還打算加入Chromium,變成三核瀏覽器,可是恰恰如今Mozilla Firefox和Chrome都在瘋狂刷版本號,確定有一部分精力要花在跟進版本上。
如今國內最主流的「雙核」瀏覽器基本都是這個架構,360極速瀏覽器、世界之窗瀏覽器極速版、傲遊3搜狗瀏覽器三、QQ瀏覽器、楓樹瀏覽器、快快瀏覽器、百度瀏覽器、阿雲瀏覽器(後期版本)、太陽花瀏覽器,其中最奇葩的是傲遊3。其它雙核瀏覽器都是基於Chromium的,而傲遊是基於WebKit的,可是恰恰又用的是V8引擎。
目前能見的應該就是日本的Lunascape,Avant增長了WebKit內核以後也會歸類到這裏。說實話,Lunascape真的很難用,真的很奇葩。各個內核相對獨立,外殼自己不夠強化,穩定性不高,因此還不如用回單核瀏覽器。
不少人都會說本身用的雙核瀏覽器是Chrome/IE雙核的,或者說是基於Chrome的。其實這種說法並不正確,由於Chrome自己並不開源,其它廠商是不能去定製Chrome的。能被修改、定製的是Chromium,Chrome的開源開發版本,代碼和Build都提供下載。Chromium/Chrome兩個單詞都是鉻,分別是拉丁文和英文,除了名字以外,頗有不少不一樣,你能夠本身對比一下。
Chromium一天最多能夠更新十幾二十個版本,實驗性的新特性都會如今這裏放出,可是Chromium自己其實並不穩定。
Chrome總共有四個更新分支:Canary、Dev、Beta、Stable,穩定性依次加強。
自行搜索,一段歷史。
在確保IE瀏覽器沒有損壞的基礎上,搭配一款非Trident內核的瀏覽器進行判斷,若是能夠的話,最好全部內核都配齊了。
控制變量就能找到問題所在,是瀏覽器自己的問題,仍是頁面編碼有問題。對於用戶來講就能更好地去選擇本身該用什麼瀏覽器訪問什麼頁面,對於開發者來講應該要寫出無差異代碼。
Opera其實很好看也很好用,並且極度創新,可是市場佔有率一直很低。不少很好用的新特性老是被抄襲,因此你們笑稱Opera「一直被模仿,一直被超越」。坊間傳聞多標籤頁瀏覽器就是Opera發明的,可是貌似有人考究了這個傳聞其實不屬實。不過快速撥號、Turbo瀏覽等功能就是紮紮實實Opera獨創的。你能夠不用Opera,可是你會損失不少樂趣。
如今版本號最高的瀏覽器是Chrome,穩定版的版本號是14,也是如今主流瀏覽器裏面誕生時間最短的,真是一個刷版本號高手。早期的Chrome版本更迭還會增長一些比較重要的新特性,好比擴展支持,如今的版本更迭基本上並無伴隨什麼大的更新。如今不少僞高端用戶就會成天追着第三方編譯版本趕忙跟進版本號,可是其實真正的意義並不大。
多虧了Chrome的「提攜」,今年Firefox也在猛刷版本號,年初仍是3.x,如今正式版已是7.0.1,每夜版已經到了10.0。Opera積累了多年纔到11.50,測試版是12.0。IE的正式版是9,平臺預覽版是10。
通常來講,查看源代碼和使用開發者工具是比較實用的,可能用的機會並很少,可是在判斷一些問題的時候實際上是頗有用的。經過查看源代碼或者使用開發者工具,能夠大體瞭解這些網站裏面的一些元素或者加載的腳本或者是規則,對於判斷兼容性問題有必定的幫助,也能夠用來準確捕捉頁面元素。
官網:
http://windows.microsoft.com/zh-CN/internet-explorer/products/ie/home
IE7下載:
IE8下載:
http://windows.microsoft.com/zh-CN/internet-explorer/downloads/ie-8
IE9下載:
http://windows.microsoft.com/zh-CN/internet-explorer/downloads/ie-9/worldwide-languages
官網:
7.x Release:
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/latest/win32/zh-CN/
8.x Candidates:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/8.0b1-candidates/build1/win32/zh-CN/
9.x Aurora:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/
10.x Nightly:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
官網:
http://www.apple.com.cn/safari/
下載:
http://www.apple.com.cn/safari/download/
官網:
下載:
http://build.chromium.org/f/chromium/snapshots/Win_Webkit_Latest/
官網:
http://www.google.com/chrome?hl=zh-cn
Stable在線安裝包:
http://www.google.com/chrome/eula.html?hl=zh-cn
Beta在線安裝包:
http://www.google.com/chrome/eula.html?hl=zh-CN&extra=betachannel
Dev在線安裝包:
http://www.google.com/chrome/eula.html?hl=zh-CN&extra=devchannel
Canary在線安裝包:
http://www.google.com/chrome/eula.html?hl=zh-CN&extra=canarychannel
Stable離線安裝包:
http://www.google.com/chrome/eula.html?hl=zh-CN&standalone=1
Beta離線安裝包:
http://www.google.com/chrome/eula.html?hl=zh-CN&standalone=1&extra=betachannel
Dev離線安裝包:
http://www.google.com/chrome/eula.html?hl=zh-CN&standalone=1&extra=devchannel
Canary離線安裝包:
http://www.google.com/chrome/eula.html?hl=zh-CN&standalone=1&extra=canarychannel
(6)Opera
官網:
正式版:
http://www.opera.com/download/
測試版:
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」)。杯具啊,忽然就少了這麼一個元素,瀏覽器不得不從新渲染這部分代碼;
瀏覽器天天就這麼來來回回跑着,要知道不一樣的人寫出來的html和css代碼質量良莠不齊,說不定哪天跑着跑着就掛掉了。
好在這個世界還有這麼一羣人——頁面重構工程師,平時挺不起眼,也就幫視覺設計師們切切圖啊改改字,其實背地裏仍是幹了很多實事的。
說到頁面爲何會慢?那是由於瀏覽器要花時間、花精力去渲染,尤爲是當它發現某個部分發生了點變化影響了佈局,須要倒回去從新渲染,內行稱這個回退的過程叫reflow。
reflow幾乎是沒法避免的。如今界面上流行的一些效果,好比樹狀目錄的摺疊、展開(實質上是元素的顯示與隱藏)等,都將引發瀏覽器的 reflow。
鼠標滑過、點擊……只要這些行爲引發了頁面上某些元素的佔位面積、定位方式、邊距等屬性的變化,都會引發它內部、周圍甚至整個頁面的從新渲染。
一般咱們都沒法預估瀏覽器到底會reflow哪一部分的代碼,它們都彼此相互影響着。
reflow問題是能夠優化的,咱們能夠儘可能減小沒必要要的reflow。
好比開頭的例子中的<img>圖片載入問題,這其實就是一個能夠避免的reflow——給圖片設置寬度和高度就能夠了。
這樣瀏覽器就知道了圖片的佔位面積,在載入圖片前就預留好了位置。
另外,有個和reflow看上去差很少的術語:repaint,中文叫重繪。
若是隻是改變某個元素的背景色、文字顏色、邊框顏色等等不影響它周圍或內部佈局的屬性,將只會引發瀏覽器repaint。
repaint的速度明顯快於 reflow(在IE下須要換一下說法,reflow要比repaint 更緩慢)。
3、從瀏覽器的渲染原理講CSS性能
平時咱們幾乎天天都在和瀏覽器打交道,寫出來的頁面頗有可能在不一樣的瀏覽器下顯示的不同。苦逼的前端攻城師們爲了兼容各個瀏覽器而不斷地去測試和調試,還在腦子中記下各類遇到的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書寫過程當中,總結出以下性能提高的方案:
選用高效的選擇符,能夠減小頁面的渲染時間,從而有效的提高用戶體驗(頁面越快,用戶固然越喜歡^_^),你能夠看一下CSS selectors Test,這個實驗的重點是評估複雜選擇符和簡單選擇符的開銷。
也許當你想讓渲染速度最高效時,你可能會給每一個獨立的標籤配置一個ID,而後用這些ID寫樣式。那的確會超級快,也超級荒唐!這樣的結果是語義極差,後期的維護難到了極點。
但說到底,CSS性能這東西對於小的項目來說可能真的是微乎其微的東西,提高可能也不是很明顯,但對於大型的項目確定是有幫助的。並且一個好的CSS書寫習慣和方式可以幫助咱們更加嚴謹的要求本身。
--------------------------- 原文 -----------------------------