前端優(yōu)化

sydMobile 發(fā)布于2019-08-23 17:20 / 529人閱讀

摘要：如果在循環(huán)中需要訪問非本作用域下的變量時(shí)請(qǐng)?jiān)诒闅v之前用局部變量緩存該變量，并在遍歷結(jié)束后再重復(fù)那個(gè)變量，這一點(diǎn)對(duì)全局變量尤其重要，因?yàn)槿肿兞刻幱谧饔糜蜴湹淖铐敹耍L問時(shí)的查找次數(shù)是最多的。

鏈接：前端優(yōu)化

前端優(yōu)化

瀏覽器發(fā)送HTTP請(qǐng)求，服務(wù)器收到請(qǐng)求全文后，返回HTTP響應(yīng)，在瀏覽器接收之后結(jié)束這個(gè)過程。瀏覽器和服務(wù)器只有一次互動(dòng)的機(jī)會(huì)，瀏覽器主動(dòng)發(fā)起，而服務(wù)器被動(dòng)地根據(jù)收到的請(qǐng)求內(nèi)容返回結(jié)果。一個(gè)完整的請(qǐng)求都需要經(jīng)過DNS尋址、與服務(wù)器建立連接、發(fā)送數(shù)據(jù)、等待服務(wù)器響應(yīng)、接收數(shù)據(jù)的過程。

前端優(yōu)化的途徑

頁(yè)面級(jí)別的優(yōu)化，例如HTTP請(qǐng)求數(shù)、腳本的無阻塞加載、內(nèi)聯(lián)腳本的位置優(yōu)化等；

代碼級(jí)別的優(yōu)化，例如JavaScript中的DOM操作優(yōu)化、CSS選擇符優(yōu)化、圖片優(yōu)化以及HTML結(jié)構(gòu)優(yōu)化等。

頁(yè)面級(jí)優(yōu)化 1. 減少HTTP請(qǐng)求數(shù) 減少HTTP請(qǐng)求數(shù)的主要途徑

1、從設(shè)計(jì)實(shí)現(xiàn)層面簡(jiǎn)化頁(yè)面

保持頁(yè)面簡(jiǎn)潔、減少資源的使用是最直接的。能使用CSS替代效果就盡量少使用圖片。

2、合理設(shè)置HTTP緩存

恰當(dāng)?shù)鼐彺嬖O(shè)置可以大大減少HTTP請(qǐng)求。被緩存資源的請(qǐng)求服務(wù)器是304響應(yīng)，只有Header沒有body，沒有節(jié)省帶寬。對(duì)于多個(gè)頁(yè)面都可能使用到的代碼，盡量拆分到同一個(gè)文件中。如果是嵌入頁(yè)面換來的是增大了頁(yè)面的體積，而且無法利用瀏覽器緩存。

3、資源合并和壓縮

如果可以，盡可能將外部的腳本、樣式進(jìn)行合并，多個(gè)合為一個(gè)。另外，CSS、JavaScript、image都可以用相應(yīng)的工具進(jìn)行壓縮。

4、CSS Sprites

合并CSS圖片，減少請(qǐng)求數(shù)的有一個(gè)好辦法。

5、lazy load image

這個(gè)策略實(shí)際上并不一定能減少HTTP請(qǐng)求數(shù)，但是卻能在某些條件下或者頁(yè)面剛加載時(shí)減少HTTP請(qǐng)求數(shù)。對(duì)于圖片而言，在頁(yè)面剛加載時(shí)可以只加載第一屏，當(dāng)用戶繼續(xù)往后滾屏?xí)r才加載后續(xù)的圖片。以前的做法是在加載時(shí)把第一屏之后的圖片地址緩存在textarea標(biāo)簽中，待用戶往下滾屏?xí)r才惰性加載。百度圖片和花瓣網(wǎng)也是用這種流行的瀑布流加載圖片。

2. 將外部腳本置底

外鏈腳本在加載時(shí)會(huì)阻塞其他資源，例如在腳本加載完成之前，它后面的圖片、樣式以及其他腳本都處于阻塞狀態(tài)，直到腳本加載完成后才會(huì)開始加載。如果把腳本放在比較靠前的位置，則會(huì)影響整個(gè)頁(yè)面的加載速度從而影響用戶體驗(yàn)。最簡(jiǎn)單可依賴的方法是將腳本盡可能往后挪，減少對(duì)并發(fā)下載的影響。如果時(shí)效性允許的話，可以考慮在DOMLoaded事件觸發(fā)時(shí)加載，或者用setTimeout方式來靈活控制加載的時(shí)機(jī)。

3. 異步執(zhí)行inline腳本

inline腳本對(duì)性能的影響比外部腳本大很多。首先，與外部腳本一樣，inline腳本在執(zhí)行時(shí)也會(huì)阻塞并發(fā)請(qǐng)求，除此之外，由于瀏覽器在頁(yè)面處理方面時(shí)單線程的，當(dāng)inline腳本在頁(yè)面渲染之前執(zhí)行時(shí)，頁(yè)面的渲染工作則會(huì)被推遲。簡(jiǎn)而言之，inline腳本在執(zhí)行時(shí)頁(yè)面處于空白狀態(tài)。

鑒于以上兩點(diǎn)，建議將執(zhí)行時(shí)間較長(zhǎng)的inline腳本異步執(zhí)行。異步執(zhí)行的方式有很多種，例如使用script元素的defer屬性、使用setTimeout，此外，在HTML5中引入了web workers的機(jī)制，恰恰可以解決此類問題。

4. lazy load JavaScript

目前的做法大概有兩種，一種是為流量特別大的頁(yè)面專門定制一個(gè)專用的mini版框架，另一種則是lazy load，最初只加載核心模塊，其他模塊可以等到需要使用的時(shí)候才加載，類似于java的swing，引入需要的組件庫(kù)文件。

5. 將CSS放在head中 6. 減少不必要的HTTP跳轉(zhuǎn)

對(duì)于以目錄形式訪問的HTTP鏈接，很多人都會(huì)忽略鏈接最后是否帶/，假如服務(wù)器對(duì)此區(qū)別對(duì)待，那么其中很可能隱藏了301跳轉(zhuǎn)，增加了多余請(qǐng)求。

代碼級(jí)優(yōu)化 1. JavaScript

1、DOM

DOM操作應(yīng)該是腳本中最耗性能的一類操作，例如增、刪、查、改DOM元素或者對(duì)DOM集合進(jìn)行操作。如果腳本中包含了大量的DOM操作則需要注意html collection。

在腳本中document.images、document.forms、getElementsByTagName()返回的都是HTMLCollection類型的集合，在平時(shí)使用的時(shí)候大多將它作為數(shù)組來使用，因?yàn)樗?b>length屬性，也可以使用索引訪問每一個(gè)元素。不過在訪問性能上則比數(shù)組要差很多，原因這個(gè)集合并不是一個(gè)靜態(tài)的結(jié)果，它表示的僅僅是一個(gè)特定的查詢，每次訪問該集合時(shí)都會(huì)重新執(zhí)行這個(gè)查詢從而更新查詢結(jié)果。所謂的訪問集合包括讀取集合的length屬性、訪問集合中的元素。

因此，當(dāng)你需要遍歷HTML collection時(shí)，盡量將它轉(zhuǎn)為數(shù)組后再訪問，以提高性能。即使不轉(zhuǎn)換為數(shù)組，也請(qǐng)盡可能少地訪問它，例如在遍歷的時(shí)候可以將length屬性、成員保存到局部變量后再使用局部變量。

2、慎用with

with(obj){p=1};代碼塊的行為實(shí)際上是修改了代碼塊中的執(zhí)行環(huán)境，將obj放在了其作用于的最前端，在with代碼塊中訪問非局部變量都是先從obj上開始查找，如果沒有再依次按作用域鏈向上查找，因此使用with相當(dāng)于增加了作用域鏈長(zhǎng)度。而每次查找作用域鏈都是要消耗時(shí)間的，過長(zhǎng)的作用域鏈會(huì)導(dǎo)致查找性能下降。

因此，除非你能肯定在with代碼中只放obj中的屬性，否則慎用with，替代的可以使用局部變量緩存需要訪問的屬性。

3、避免使用eval和Function

每次eval或Function構(gòu)造函數(shù)作用于字符串表示的源代碼時(shí)，腳本引擎都需要將源代碼轉(zhuǎn)換為可執(zhí)行代碼。這是很消耗資源的操作——通常比簡(jiǎn)單的函數(shù)調(diào)用慢100倍以上。

eval函數(shù)效率特別低，由于事先無法知曉傳給eval的字符串中的內(nèi)容，eval在其上下文中解析要處理的代碼，也就是說編譯器無法優(yōu)化上下文，因此只能有瀏覽器在運(yùn)行時(shí)解析代碼，這對(duì)性能影響很大。

Function構(gòu)造函數(shù)比eval略好，因?yàn)槭褂么舜a不會(huì)影響周圍代碼，但其速度仍很慢。

此外，使用eval和Function不利于JavaScript壓縮工具執(zhí)行壓縮。

4、減少作用域鏈查找

作用域鏈查找問題，這一點(diǎn)在循環(huán)中尤其需要注意。如果在循環(huán)中需要訪問非本作用域下的變量時(shí)請(qǐng)?jiān)诒闅v之前用局部變量緩存該變量，并在遍歷結(jié)束后再重復(fù)那個(gè)變量，這一點(diǎn)對(duì)全局變量尤其重要，因?yàn)槿肿兞刻幱谧饔糜蜴湹淖铐敹耍L問時(shí)的查找次數(shù)是最多的。

此外，要減少作用域鏈查找還應(yīng)該減少閉包的使用。閉包的變量可能保存到內(nèi)存中，內(nèi)存消耗很大，解決方法是在退出函數(shù)前，將不使用的局部變量刪除。

5、數(shù)據(jù)訪問

JavaScript中的數(shù)據(jù)訪問包括直接量（字符串、正則表達(dá)式）、變量、對(duì)象屬性以及數(shù)組，其中對(duì)直接量和局部變量的訪問是最快的，對(duì)對(duì)象屬性以及數(shù)組的訪問需要更大的開銷。當(dāng)出現(xiàn)以下情況時(shí)，建議將數(shù)據(jù)放入局部變量：

對(duì)任何對(duì)象屬性的訪問超過1次

對(duì)任何數(shù)組成員的訪問次數(shù)超過1次

另外，還應(yīng)當(dāng)盡可能的減少對(duì)對(duì)象以及數(shù)組深度查找。

6、字符串拼接

在JavaScript中使用+號(hào)來拼接字符串效率是比較低的，因?yàn)槊看芜\(yùn)行都會(huì)開辟新的內(nèi)存并生成新的字符串變量，然后拼接結(jié)果賦值給新變量。之前使用jQuery+Ajax交互頁(yè)面，很多時(shí)候都是將后臺(tái)傳輸過來的數(shù)據(jù)和前端HTML結(jié)構(gòu)拼接成字符串，然后呈現(xiàn)在頁(yè)面HTML容器里。

與之相比更為高效的做法是使用數(shù)組的join方法，即將需要拼接的字符串放在數(shù)組中最后調(diào)用其join方法得到結(jié)果。不過由于使用數(shù)組也有一定的開銷，因此當(dāng)需要拼接的字符串較多時(shí)可以考慮使用此方法。

2. CSS選擇符

在大多數(shù)人的觀念中，都覺得瀏覽器對(duì)CSS選擇符的解析是從左往右進(jìn)行的。

如果是從右往左解析則效率會(huì)很高，因?yàn)榈谝粋€(gè)ID選擇基本上就把查找的范圍限定了，但實(shí)際上瀏覽器對(duì)選擇符的解析是從右往左進(jìn)行的。#tag A {color: "#ccc";}，瀏覽器必須遍歷查找每一個(gè)A標(biāo)簽的祖先節(jié)點(diǎn)，效率并不像之前想象的那么高。根據(jù)瀏覽器的這一行為特點(diǎn)，在寫選擇符的時(shí)候需要注意很多事項(xiàng)。