網(wǎng)站性能，刻不容緩?。。∪笠蛩豤ss、images、js

1、網(wǎng)站性能，刻不容緩??！三大因素:CSS、IMAGES、JS,主講人：侯彪,CSS也有性能開銷華麗的外衣--IMAGESJS優(yōu)化幾則雜談---DOM的加載也有SEO的技巧,CSS也有性能開銷,網(wǎng)站性能一說讓多數(shù)的人第一時(shí)間想起的是javascript，但對(duì)于一個(gè)WEB來說同樣重要的CSS呢？你會(huì)考慮到他的性能開銷嗎？ul#my_list > li{color:#f00}理解一下CSS選擇符的概念,把樣式表放在標(biāo)簽中以提升

2、頁面的逐步渲染速度。不要在IE中使用CSS Expression，因?yàn)樗麜?huì)被執(zhí)行到很多次，你想知道是多少嗎？好的，以萬為單位，甚至可以搞死你的IE！避免或杜絕使用行內(nèi)樣式，因?yàn)檫@會(huì)增加下載頁面的大小，并搞亂你的CSS權(quán)重。,在前輩們的指點(diǎn)下，關(guān)于CSS的最佳性能實(shí)踐大致總結(jié)了如下幾點(diǎn)：,CSS也有性能開銷,怎么樣這些很容易理解吧。不過……以上幾點(diǎn)已經(jīng)不能滿足我們追求性能的野心了。于是更多的CSS性能規(guī)則開始展現(xiàn)他們的力量！,CSS

3、也有性能開銷,ID選擇符 #toc{margin-left:20px}類選擇符 .chapter{font-weight:bold}類型選擇符 a{text-decoration:none}相鄰兄弟選擇符 h1 + #toc{margin-top:40px}子選擇 #toc > li{font-weight:bold}后代選擇符 #toc a{color:#333}通配選擇符 *{font-family:

4、Arial}屬性選擇符 [href="#index"]{font-style:italic}偽類和偽元素 a:hover{text:decoration:underline},CSS也有性能開銷,最右邊優(yōu)先?。?！#toc > li{font-weight:bold}瀏覽器并不是從左到右的順序來解析CSS選擇符，所以，看看上面這個(gè)本以為很高效的選擇符，瀏覽器先要遍歷DOM中所有的li標(biāo)簽，并確定他的父

5、級(jí)元素為#toc。#toc a{color:#333}看看這個(gè) 豈不是更糟糕！,CSS也有性能開銷,知道了選擇符的匹配順序，我們便有了如下的更具體的優(yōu)化法則！避免使用通配規(guī)則 *不要限定ID選擇符 div#wrap不要限定類選擇符 li.ele to .list_ele讓規(guī)則越具體越好 ol li a to .list_link避免使用后代選擇符 ul li避免使用子選擇符 ul > li > a質(zhì)疑子選擇

6、符的所有用途 盡可能使用具體的類依靠繼承,華麗的外衣--IMAGES,搞清楚你要處理的圖片類型圖形 VS 圖像（照片）,華麗的外衣--IMAGES,圖形：一般來說，網(wǎng)站的LOGO，草圖，手稿圖和部分ICON圖標(biāo)都屬于圖形，這些通常由連續(xù)的線條或其他尖銳的顏色過渡，顏色數(shù)量相對(duì)較少。,華麗的外衣--IMAGES,圖像（照片）：百萬數(shù)量級(jí)的顏色，包含平滑的顏色過渡和漸變，比如網(wǎng)站的KV輪播圖，數(shù)碼相機(jī)拍出來的產(chǎn)品圖。,華麗的外衣--

7、IMAGES,華麗的外衣--IMAGES,華麗的外衣--IMAGES,華麗的外衣--IMAGES,三種不同的圖片格式JPEG GIF PNG（此處只考慮PNG8）相關(guān)的系統(tǒng)知識(shí)這里不再闡述，有興趣的自己上百度GOOGLE一下以下介紹重點(diǎn)的屬性！,華麗的外衣--IMAGES,JPEG：有損：它是一種有損的格式，用戶可以設(shè)置自定義質(zhì)量級(jí)別，這個(gè)級(jí)別決定了有多少圖像信息會(huì)被拋棄。級(jí)別從0-100，但即便是100也同樣會(huì)有一定程度的質(zhì)量

8、損耗。當(dāng)我們要對(duì)一個(gè)圖像反復(fù)編輯時(shí)，比如隨時(shí)都會(huì)往里邊繼續(xù)加新圖的CSS精靈，最好使用無損的格式來保存中間結(jié)果，然后在最終結(jié)果的時(shí)候存為JPEG格式，否則你將在每次保存為JPEG的時(shí)候都損耗一些質(zhì)量。,華麗的外衣--IMAGES,JPEG：但也有少數(shù)操作是無損的：以90的倍數(shù)進(jìn)行旋轉(zhuǎn)的時(shí)候裁剪水平翻轉(zhuǎn)或垂直翻轉(zhuǎn)從標(biāo)準(zhǔn)模式切換到漸進(jìn)模式 反之亦然編輯圖像的元數(shù)據(jù)此格式不支持透明和動(dòng)畫,華麗的外衣--IMAGES,GIF：

9、GIF是無損的，也就是說你可以打開任意一個(gè)GIF文件，做一些修改，保存關(guān)閉時(shí)不會(huì)損失任何質(zhì)量。透明，允許一個(gè)二進(jìn)制透明，每個(gè)像素要么完全透明 要么完全不透明 這就意味著他不支持alpha透明。取而代之的是，調(diào)色板中的某個(gè)顏色可以被標(biāo)記為表示透明，而透明像素則會(huì)被分配為這個(gè)顏色值，所以，如果你為GIF設(shè)置了透明像素，那么就會(huì)消耗一個(gè)調(diào)色板條目。,華麗的外衣--IMAGES,GIF：動(dòng)畫，GIF支持“逐幀動(dòng)畫”。應(yīng)用最廣的當(dāng)屬LOADI

10、NG256色限制。逐行掃描，當(dāng)生成一個(gè)GIF文件時(shí)，會(huì)使用一個(gè)壓縮算法LZW來減小文件的大小，壓縮GIF文件時(shí)，會(huì)從上到下一行一行的對(duì)像素進(jìn)行掃描，這種情況下，當(dāng)圖像在水平方向有很多重復(fù)顏色時(shí)，可以獲得更好的壓縮效果。如下圖：,華麗的外衣--IMAGES,1.77 KB,華麗的外衣--IMAGES,3.84 KB,華麗的外衣--IMAGES,PNG：為了彌補(bǔ)GIF文件的缺點(diǎn)，并規(guī)避LZW算法的專利問題（2004年已經(jīng)過了保護(hù)期）P

11、NG文件誕生！你可以使用PNG8代替不需要?jiǎng)赢嫷腉IF并用PNG24或32來代替JPEG！PNG是無損的圖像格式。多次編輯不會(huì)降低其質(zhì)量，這使得采用PNG格式來存儲(chǔ)中間格式非常合適。比如我們網(wǎng)站的品牌旗艦館的LOGO就是用PNG8來保存的，每次有新品牌的時(shí)候直接在PNG上操作，存儲(chǔ)完畢不會(huì)有任何的消耗，如果是JPEG那保存幾次就完了。如下圖：,華麗的外衣--IMAGES,華麗的外衣--IMAGES,今天又添加了新的品牌 使用PNG無損

12、直接在原圖上進(jìn)行添加,華麗的外衣--IMAGES,PNG：透明。PNG8支持和GIF一樣的二進(jìn)制透明，PNG24支持alpha透明逐行掃描。和GIF格式一樣，但是壓縮比更高！如下圖,華麗的外衣--IMAGES,2.14 KB,華麗的外衣--IMAGES,就圖像格式而言，GIF通常用于顯示圖形，JPEG更適合顯示圖片，而PNG則兩者都適合。和GIF相比：用PNG來代替GIF（不帶動(dòng)畫）會(huì)更好，文件大小也更小，并且具備除動(dòng)畫以外的所

13、有GIF特性，所以應(yīng)該盡量以PNG8代替GIF。有一個(gè)例外就是顏色數(shù)很少的小圖像，這時(shí)GIF的壓縮比可能更高一些，但是這樣的小圖片應(yīng)該被放在了CSS精靈中，因?yàn)镠TTP的請(qǐng)求增加已經(jīng)遠(yuǎn)遠(yuǎn)超過節(jié)省的那點(diǎn)帶寬，而且用PNG來保存CSS精靈可以獲得更高的壓縮比。,華麗的外衣--IMAGES,和JPEG相比：當(dāng)圖像中的顏色超過256時(shí)，需要使用真彩色圖像格式---PNG24或JPEG。JPEG的壓縮比更高，而且一般來說JPEG也是照片存儲(chǔ)

14、的實(shí)際標(biāo)準(zhǔn)。但由于JPEG是有損的而且在清晰的顏色過渡周圍會(huì)有大色塊，因此以下2種情況更適合PNG,華麗的外衣--IMAGES,和JPEG相比：當(dāng)圖像的顏色略超過256種，可以在不損耗任何可見質(zhì)量的前提下，將圖像轉(zhuǎn)換為PNG8，雖然有時(shí)存儲(chǔ)為PNG8會(huì)使得顏色數(shù)量減少，但是有時(shí)就算本身有1000種顏色，當(dāng)你存儲(chǔ)為256種顏色的時(shí)候也看不出什么特別明顯的變化。如下圖,華麗的外衣--IMAGES,JPEG 80品質(zhì)190 KB,華麗的外衣

15、--IMAGES,JPEG 100品質(zhì)351 KB,華麗的外衣--IMAGES,PNG8 114 KB,華麗的外衣--IMAGES,和JPEG相比：當(dāng)圖片很容易因?yàn)閴嚎s產(chǎn)生大色塊并且大色塊變得不可接受時(shí)。如下圖,華麗的外衣--IMAGES,JS優(yōu)化幾則,4種數(shù)據(jù)存儲(chǔ)位置局部變量最快循環(huán)JS與DOM那扯不斷理還亂的關(guān)系,JS優(yōu)化幾則,4種數(shù)據(jù)存儲(chǔ)位置直接量 數(shù)字 字符串 boolen 對(duì)象 數(shù)組 函數(shù) 正則 null undef

16、ined變量 var...數(shù)組元素 數(shù)字為索引對(duì)象成員 字符串為索引直接量和局部變量的訪問速度快于后邊2個(gè)FF3是個(gè)例外，他優(yōu)化了數(shù)組項(xiàng)的存取，但是通常的建議是，如果在乎速度 那么盡量使用直接量或局部變量 減少數(shù)組項(xiàng)和對(duì)象成員的使用。,JS優(yōu)化幾則,局部變量最快每個(gè)JS函數(shù)都是表示為一個(gè)對(duì)象，更確切的說是function對(duì)象的一個(gè)實(shí)例，function對(duì)象同其他對(duì)象一樣，擁有可以編程訪問的屬性，和一些列不能通過代碼僅供JS引

17、擎存取的內(nèi)部屬性。其中一個(gè)內(nèi)部屬性是【scope】?jī)?nèi)部屬性【scope】包含了一個(gè) 函數(shù)被創(chuàng)建的作用域中 對(duì)象的集合，這個(gè)集合被稱為函數(shù)的作用域鏈，它決定哪些數(shù)據(jù)能被函數(shù)訪問。當(dāng)一個(gè)函數(shù)創(chuàng)建后，它的作用域鏈會(huì)被 創(chuàng)建此函數(shù)的作用域中 可訪問的數(shù)據(jù)對(duì)象 所填充。function add(a,b){ var sum = a + b; return sum; }函數(shù)add創(chuàng)建時(shí)，他的作用域鏈中填入了一個(gè)單獨(dú)的可變對(duì)象，這個(gè)全局對(duì)象表示所

18、有全局范圍定義的變量。包含WINDOW,DOCUMENT,NAVIGATOR等等全局對(duì)象。,JS優(yōu)化幾則,局部變量最快下面開始執(zhí)行 var num = add(10,20);執(zhí)行此函數(shù)會(huì)創(chuàng)建一個(gè)稱為 運(yùn)行期上下文 的內(nèi)部對(duì)象。一個(gè)運(yùn)行期上下文定義了一個(gè)函數(shù)執(zhí)行時(shí)的環(huán)境。函數(shù)每次執(zhí)行時(shí)對(duì)應(yīng)的執(zhí)行期上下文都是獨(dú)一無二的，所以多次調(diào)用同一個(gè)函數(shù)就會(huì)導(dǎo)致創(chuàng)建多個(gè)運(yùn)行期上下文。當(dāng)函數(shù)執(zhí)行完畢，對(duì)應(yīng)的運(yùn)行期上下文就被銷毀。每個(gè)運(yùn)行期上下文都有

19、自己的作用域鏈，用于標(biāo)識(shí)符解析。當(dāng)運(yùn)行期上下文被創(chuàng)建時(shí)，它的作用域鏈初始化為當(dāng)前運(yùn)行函數(shù)的[scope]屬性中所包含的對(duì)象。這些值按照他們出現(xiàn)在函數(shù)中的順序，被復(fù)制到運(yùn)行期上下文的作用域鏈中。這個(gè)過程一旦OK，一個(gè)被稱為 活動(dòng)對(duì)象 的新對(duì)象就為運(yùn)行期上下文創(chuàng)建好了?；顒?dòng)對(duì)象作為函數(shù)運(yùn)行期的可變對(duì)象，包含了所有局部變量，命名參數(shù)，參數(shù)集合 以及 this。然后此對(duì)象被推入作用域鏈的前端。當(dāng)運(yùn)行期上下文被銷毀，活動(dòng)對(duì)象也隨之銷毀。,JS優(yōu)化

20、幾則,局部變量最快在函數(shù)執(zhí)行過程中，每遇到一個(gè)變量，都會(huì)經(jīng)歷一次標(biāo)識(shí)符解析過程以決定從哪里獲取或存儲(chǔ)數(shù)據(jù)。該過程搜索運(yùn)行期上下文的作用域鏈，查找同名的表示符。搜索過程從作用域鏈頂部開始，也就是當(dāng)前運(yùn)行函數(shù)的活動(dòng)對(duì)象。如果找到了，就使用這個(gè)標(biāo)識(shí)符對(duì)應(yīng)的變量；如果沒找到，繼續(xù)搜索作用域鏈中的下一個(gè)對(duì)象。搜索過程會(huì)持續(xù)進(jìn)行，直到標(biāo)識(shí)符被找到，或者沒有可用于搜索的對(duì)象為止，這種情況下標(biāo)識(shí)符被認(rèn)定是為定義的。is not defined 。函數(shù)

21、執(zhí)行過程中，每個(gè)標(biāo)識(shí)符都要經(jīng)歷這樣的搜索過程。正是這個(gè)搜索過程影響著他的性能！如果名字相同的2個(gè)變量存在于作用域鏈的不同部分，那么標(biāo)識(shí)符就是遍歷作用域鏈時(shí)最先找到的那個(gè)，也可以說，第一個(gè)找到的遮蔽了第二個(gè)。,JS優(yōu)化幾則,局部變量最快在運(yùn)行期上下文的作用域鏈中，一個(gè)標(biāo)識(shí)符所在的位置越深，它的讀寫速度也就越慢。SO 函數(shù)中讀取局部變量總是最快的，而全局變量是最慢的，因?yàn)槿值目偸谴嬖谟谶\(yùn)行期上下文作用域鏈的最末端！一個(gè)好的經(jīng)驗(yàn)法則就

22、是，如果一個(gè)跨作用域的值在函數(shù)中被引用一次以上，那么就把它存儲(chǔ)到局部變量里。臨時(shí)改變作用域鏈 with與try catch 但是不推薦使用，除非你的項(xiàng)目實(shí)在有需求。,JS優(yōu)化幾則,局部變量最快說了以上這么多 就是想總結(jié)2個(gè)字?。∧蔷褪?JS優(yōu)化幾則,局部變量最快,JS優(yōu)化幾則,循環(huán)著重介紹for while循環(huán)先來了解下2個(gè)循環(huán)的表現(xiàn)看下邊代碼及運(yùn)行時(shí)間,JS優(yōu)化幾則,循環(huán),JS優(yōu)化幾則,循環(huán)總結(jié)就是 在乎先后順序 用for

23、 ++ 不在乎的話用for --,JS優(yōu)化幾則,循環(huán)其他優(yōu)化法則減少迭代的工作量，很明顯，如果一次循環(huán)迭代要花很長(zhǎng)時(shí)間去執(zhí)行，那么多次循環(huán)需要花更多時(shí)間，一個(gè)提升循環(huán)整體速度的好方法是限制循環(huán)中耗時(shí)操作的數(shù)量。for(var i = 0; i < items.length; i++){ //do something; }上述循環(huán)中看似很正常，但是有很嚴(yán)重的性能問題！每次運(yùn)行循環(huán)體時(shí)都會(huì)產(chǎn)生如下操作：一次控制條件中的屬性查

24、找（items.length）一次控制條件中的數(shù)值大小比較（i < items.length）一次控制條件結(jié)果是否為true的比較（i < items.length == true）一次自增操作,JS優(yōu)化幾則,循環(huán)前面我們說過 讀取局部變量是最快的，這個(gè)循環(huán)體的每次運(yùn)行運(yùn)行都要查找items.length 這樣做很耗時(shí)，這樣做很耗時(shí)，因?yàn)檫@個(gè)值在循環(huán)過程中是不變的僅供比較，所以我們把它傳遞到局部變量會(huì)更快也更合情合理

25、。如下：for(var i = 0, l = items.length; i < l; i++){ //do something }重寫后的循環(huán)只在循環(huán)運(yùn)行前對(duì)長(zhǎng)度進(jìn)行一次屬性查找，這使得控制條件可直接讀取局部變量，所以速度更快?？於嗌?？自己測(cè)試，肯定高于你的預(yù)期！,JS優(yōu)化幾則,循環(huán)另一個(gè)方法就是在 順序不是很重要的情況下 可以使用倒序循環(huán) 比如循環(huán)為每個(gè)DOM元素addEventListener。倒序循環(huán)是編程語言中一種

26、通用的優(yōu)化方法。for(var i = items.length; i--;){ //do something }現(xiàn)在每個(gè)控制條件只是簡(jiǎn)單的與0比較。控制條件與true值比較，任何非零數(shù)會(huì)自動(dòng)轉(zhuǎn)換為true,而零值等同于false。實(shí)際上控制條件從2次比較（迭代數(shù)少于總數(shù)嗎？是否為true？）減少到1次（它是處兒?jiǎn)幔浚?。這樣就更進(jìn)一步提高了循環(huán)速度。通過這2個(gè)很不起眼的小辦法就可以看出 循環(huán)速度比最初的提高了50%以上！對(duì)比原始版

27、本 現(xiàn)在每次運(yùn)行循環(huán)體時(shí)只需要如下幾步一次控制條件的比較（i == true）一次減法操作（i--）,JS優(yōu)化幾則,JS與DOM那扯不斷理還亂的關(guān)系用JS腳本來操作DOM的代價(jià)很昂貴，它是富WEB應(yīng)用中最常見的性能瓶頸。關(guān)于JS與DOM的關(guān)系一說，微軟有個(gè)很好的比喻，把DOM與JS各自想象為一個(gè)島嶼，他們之間用高速橋連接，JS每次訪問DOM都要途徑這座橋，并交納過路費(fèi)，訪問DOM的次數(shù)越多，付出的代價(jià)越昂貴，因此，要盡可能的減少過

28、橋的次數(shù)。訪問DOM的代價(jià)已經(jīng)這么昂貴 那就更不用說修改DOM了，但是我們以往的以后的項(xiàng)目又不可完全避免產(chǎn)生這樣的過路費(fèi)，所以有必要掌握以下的常識(shí)！,JS優(yōu)化幾則,1.避免在循環(huán)體中對(duì)DOM元素反復(fù)操作！ for( var i = 0; i < 10; i++){ document.getElementById("a").innerHTML += i; } 這段簡(jiǎn)單的代碼有很嚴(yán)重的性能問

29、題！每次循環(huán)該元素都被訪問2次，1次讀取innerHTML內(nèi)容，1次重寫它。 轉(zhuǎn)變！ var content = ""; for(var i = 0; i < 10; i++){ content += i; } document.getElementById("a").innerHTML = content; 插一句 innerHTML對(duì)比docum

30、ent.createElement 性能相差無幾，在最新版的webkit瀏覽器中 innerHTML略慢 其他情況下建議用innerHTML,JS優(yōu)化幾則,2.重繪重排 重繪重排都是代價(jià)昂貴的操作，他們會(huì)導(dǎo)致WEB應(yīng)用程序和UI反應(yīng)遲鈍，因此應(yīng)該盡量減少這類過程的發(fā)生。 當(dāng)DOM的變化影響了元素的幾何屬性-widht height border，瀏覽器需要重新計(jì)算元素的幾何屬性，同樣其他元素的幾何屬性和位置也會(huì)因此受到影

31、響。瀏覽器會(huì)使渲染樹中受到影響的部分失效，并重新構(gòu)造渲染樹。這個(gè)過程就是重排（Reflow）。完成重排后瀏覽器會(huì)重新繪制受影響的部分到屏幕中，該過程為重繪（Repaint） 并不是所有的DOM變化都會(huì)影響幾何屬性。例如改變一個(gè)元素的background-color，這種情況下只會(huì)發(fā)生一次重繪而不需要重排。因?yàn)樵氐牟季植]有改變。 以下情況會(huì)觸發(fā)重排：,JS優(yōu)化幾則,1.添加刪除可見的DOM元素 2.元素位置改變

32、 3.元素尺寸改變 border-width margin padding width height 4.內(nèi)容改變，文字行數(shù)變化 圖片大小尺寸變化 5.頁面渲染器初始化 6.瀏覽器窗口尺寸改變r(jià)esize(function(){}),JS優(yōu)化幾則,3.如何最大程度的減少重排和重繪 首先。使元素脫離文檔流 其次。對(duì)其應(yīng)用多重改變 最后。把元素帶回文檔中 該過程會(huì)觸發(fā)兩次重排

33、第一步和第三步，如果你忽略這2個(gè)步驟，那么你在第二步里的每一個(gè)修改操作觸發(fā)一次重排。 三種方法可以使DOM脫離文檔 1.隱藏元素，應(yīng)用修改，重新顯示 display:none display:block 2.使用文檔片段，在當(dāng)前DOM之外構(gòu)建一個(gè)子樹，再把它拷貝回文檔。 document.createDocumentFragment() 3.將原始元素拷貝到一個(gè)脫離文檔的節(jié)點(diǎn)中，修改副本，完成后再