提高前端性能的方法（提高前端性能的方法有）

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關(guān)于提高前端性能的方法的問題，以下是小編對(duì)此問題的歸納整理，讓我們一起來看看吧。

開始之前先推薦一個(gè)非常厲害的Ai人工智能工具，一鍵生成原創(chuàng)文章、方案、文案、工作計(jì)劃、工作報(bào)告、論文、代碼、作文、做題和對(duì)話答疑等等

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準(zhǔn)，寫出的就越詳細(xì)，有微信小程序端、在線網(wǎng)頁版、PC客戶端

官網(wǎng)：https://ai.de1919.com。

創(chuàng)意嶺作為行業(yè)內(nèi)優(yōu)秀的企業(yè)，服務(wù)客戶遍布全球各地，如需了解SEO相關(guān)業(yè)務(wù)請(qǐng)撥打電話175-8598-2043，或添加微信：1454722008

本文目錄:

• 1、常見的前端性能優(yōu)化手段都有哪些？都有多大收益

• 2、你有用過哪些前端性能優(yōu)化的方法？

• 3、常見的前端性能優(yōu)化手段都有哪些？都有多大收益

• 4、前端性能優(yōu)化-傳輸加載優(yōu)化

一、常見的前端性能優(yōu)化手段都有哪些？都有多大收益

前端是龐大的，包括 HTML、 CSS、 Javascript、Image 、Flash等等各種各樣的資源。前端優(yōu)化是復(fù)雜的，針對(duì)方方面面的資源都有不同的方式。那么，前端優(yōu)化的目的是什么 ?

1. 從用戶角度而言，優(yōu)化能夠讓頁面加載得更快、對(duì)用戶的操作響應(yīng)得更及時(shí)，能夠給用戶提供更為友好的體驗(yàn)。

2. 從服務(wù)商角度而言，優(yōu)化能夠減少頁面請(qǐng)求數(shù)、或者減小請(qǐng)求所占帶寬，能夠節(jié)省可觀的資源。

總之，恰當(dāng)?shù)膬?yōu)化不僅能夠改善站點(diǎn)的用戶體驗(yàn)并且能夠節(jié)省相當(dāng)?shù)馁Y源利用。

前端優(yōu)化的途徑有很多，按粒度大致可以分為兩類，第一類是頁面級(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)化等等。另外，本著提高投入產(chǎn)出比的目的，后文提到的各種優(yōu)化策略大致按照投入產(chǎn)出比從大到小的順序排列。

一、頁面級(jí)優(yōu)化

1. 減少 HTTP請(qǐng)求數(shù)

這條策略基本上所有前端人都知道，而且也是最重要最有效的。都說要減少 HTTP請(qǐng)求，那請(qǐng)求多了到底會(huì)怎么樣呢 ?首先，每個(gè)請(qǐng)求都是有成本的，既包含時(shí)間成本也包含資源成本。一個(gè)完整的請(qǐng)求都需要經(jīng)過 DNS尋址、與服務(wù)器建立連接、發(fā)送數(shù)據(jù)、等待服務(wù)器響應(yīng)、接收數(shù)據(jù)這樣一個(gè) “漫長” 而復(fù)雜的過程。時(shí)間成本就是用戶需要看到或者 “感受” 到這個(gè)資源是必須要等待這個(gè)過程結(jié)束的，資源上由于每個(gè)請(qǐng)求都需要攜帶數(shù)據(jù)，因此每個(gè)請(qǐng)求都需要占用帶寬。另外，由于瀏覽器進(jìn)行并發(fā)請(qǐng)求的請(qǐng)求數(shù)是有上限的 (具體參見此處 )，因此請(qǐng)求數(shù)多了以后，瀏覽器需要分批進(jìn)行請(qǐng)求，因此會(huì)增加用戶的等待時(shí)間，會(huì)給用戶造成站點(diǎn)速度慢這樣一個(gè)印象，即使可能用戶能看到的第一屏的資源都已經(jīng)請(qǐng)求完了，但是瀏覽器的進(jìn)度條會(huì)一直存在。

減少 HTTP請(qǐng)求數(shù)的主要途徑包括：

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

如果你的頁面像百度首頁一樣簡單，那么接下來的規(guī)則基本上都用不著了。保持頁面簡潔、減少資源的使用時(shí)最直接的。如果不是這樣，你的頁面需要華麗的皮膚，則繼續(xù)閱讀下面的內(nèi)容。

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

緩存的力量是強(qiáng)大的，恰當(dāng)?shù)木彺嬖O(shè)置可以大大的減少 HTTP請(qǐng)求。以有啊首頁為例，當(dāng)瀏覽器沒有緩存的時(shí)候訪問一共會(huì)發(fā)出 78個(gè)請(qǐng)求，共 600多 K數(shù)據(jù) (如圖 1.1)，而當(dāng)?shù)诙卧L問即瀏覽器已緩存之后訪問則僅有 10個(gè)請(qǐng)求，共 20多 K數(shù)據(jù) (如圖 1.2)。 (這里需要說明的是，如果直接 F5刷新頁面的話效果是不一樣的，這種情況下請(qǐng)求數(shù)還是一樣，不過被緩存資源的請(qǐng)求服務(wù)器是 304響應(yīng)，只有 Header沒有Body ，可以節(jié)省帶寬 )

怎樣才算合理設(shè)置 ?原則很簡單，能緩存越多越好，能緩存越久越好。例如，很少變化的圖片資源可以直接通過 HTTP Header中的Expires設(shè)置一個(gè)很長的過期頭 ;變化不頻繁而又可能會(huì)變的資源可以使用 Last-Modifed來做請(qǐng)求驗(yàn)證。盡可能的讓資源能夠在緩存中待得更久。關(guān)于 HTTP緩存的具體設(shè)置和原理此處就不再詳述了，有興趣的可以參考下列文章：

HTTP1.1協(xié)議中關(guān)于緩存策略的描述

Fiddler HTTP Performance中關(guān)于緩存的介紹

(3). 資源合并與壓縮

如果可以的話，盡可能的將外部的腳本、樣式進(jìn)行合并，多個(gè)合為一個(gè)。另外， CSS、 Javascript、Image 都可以用相應(yīng)的工具進(jìn)行壓縮，壓縮后往往能省下不少空間。

(4). CSS Sprites

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

(5). Inline Images

使用 data: URL scheme的方式將圖片嵌入到頁面或 CSS中，如果不考慮資源管理上的問題的話，不失為一個(gè)好辦法。如果是嵌入頁面的話換來的是增大了頁面的體積，而且無法利用瀏覽器緩存。使用在 CSS中的圖片則更為理想一些。

(6). Lazy Load Images（自己對(duì)這一塊的內(nèi)容還是不了解）

這條策略實(shí)際上并不一定能減少 HTTP請(qǐng)求數(shù)，但是卻能在某些條件下或者頁面剛加載時(shí)減少 HTTP請(qǐng)求數(shù)。對(duì)于圖片而言，在頁面剛加載的時(shí)候可以只加載第一屏，當(dāng)用戶繼續(xù)往后滾屏的時(shí)候才加載后續(xù)的圖片。這樣一來，假如用戶只對(duì)第一屏的內(nèi)容感興趣時(shí)，那剩余的圖片請(qǐng)求就都節(jié)省了。 有啊首頁 曾經(jīng)的做法是在加載的時(shí)候把第一屏之后的圖片地址緩存在 Textarea標(biāo)簽中，待用戶往下滾屏的時(shí)候才 “惰性” 加載。

2. 將外部腳本置底（將腳本內(nèi)容在頁面信息內(nèi)容加載后再加載）

前文有談到，瀏覽器是可以并發(fā)請(qǐng)求的，這一特點(diǎn)使得其能夠更快的加載資源，然而外鏈腳本在加載時(shí)卻會(huì)阻塞其他資源，例如在腳本加載完成之前，它后面的圖片、樣式以及其他腳本都處于阻塞狀態(tài)，直到腳本加載完成后才會(huì)開始加載。如果將腳本放在比較靠前的位置，則會(huì)影響整個(gè)頁面的加載速度從而影響用戶體驗(yàn)。解決這一問題的方法有很多，在 這里有比較詳細(xì)的介紹 (這里是譯文和 更詳細(xì)的例子 )，而最簡單可依賴的方法就是將腳本盡可能的往后挪，減少對(duì)并發(fā)下載的影響。

3. 異步執(zhí)行 inline腳本(其實(shí)原理和上面是一樣，保證腳本在頁面內(nèi)容后面加載。)

inline腳本對(duì)性能的影響與外部腳本相比，是有過之而無不及。首頁，與外部腳本一樣， inline腳本在執(zhí)行的時(shí)候一樣會(huì)阻塞并發(fā)請(qǐng)求，除此之外，由于瀏覽器在頁面處理方面是單線程的，當(dāng) inline腳本在頁面渲染之前執(zhí)行時(shí)，頁面的渲染工作則會(huì)被推遲。簡而言之， inline腳本在執(zhí)行的時(shí)候，頁面處于空白狀態(tài)。鑒于以上兩點(diǎn)原因，建議將執(zhí)行時(shí)間較長的 inline腳本異步執(zhí)行，異步的方式有很多種，例如使用 script元素的defer 屬性(存在兼容性問題和其他一些問題，例如不能使用 document.write)、使用setTimeout ，此外，在HTML5中引入了 Web Workers的機(jī)制，恰恰可以解決此類問題。

4. Lazy Load Javascript（只有在需要加載的時(shí)候加載，在一般情況下并不加載信息內(nèi)容。）

隨著 Javascript框架的流行，越來越多的站點(diǎn)也使用起了框架。不過，一個(gè)框架往往包括了很多的功能實(shí)現(xiàn)，這些功能并不是每一個(gè)頁面都需要的，如果下載了不需要的腳本則算得上是一種資源浪費(fèi) -既浪費(fèi)了帶寬又浪費(fèi)了執(zhí)行花費(fèi)的時(shí)間。目前的做法大概有兩種，一種是為那些流量特別大的頁面專門定制一個(gè)專用的 mini版框架，另一種則是 Lazy Load。YUI 則使用了第二種方式，在 YUI的實(shí)現(xiàn)中，最初只加載核心模塊，其他模塊可以等到需要使用的時(shí)候才加載。

5. 將 CSS放在 HEAD中

如果將 CSS放在其他地方比如 BODY中，則瀏覽器有可能還未下載和解析到 CSS就已經(jīng)開始渲染頁面了，這就導(dǎo)致頁面由無 CSS狀態(tài)跳轉(zhuǎn)到 CSS狀態(tài)，用戶體驗(yàn)比較糟糕。除此之外，有些瀏覽器會(huì)在 CSS下載完成后才開始渲染頁面，如果 CSS放在靠下的位置則會(huì)導(dǎo)致瀏覽器將渲染時(shí)間推遲。

6. 異步請(qǐng)求 Callback（就是將一些行為樣式提取出來，慢慢的加載信息的內(nèi)容）

在某些頁面中可能存在這樣一種需求，需要使用 script標(biāo)簽來異步的請(qǐng)求數(shù)據(jù)。類似：

Javascript:

function myCallback(info){

//do something here

}

HTML:

cb返回的內(nèi)容 :

myCallback('Hello world!');

像以上這種方式直接在頁面上寫 <script>對(duì)頁面的性能也是有影響的，即增加了頁面首次加載的負(fù)擔(dān)，推遲了 DOMLoaded和window.onload 事件的觸發(fā)時(shí)機(jī)。如果時(shí)效性允許的話，可以考慮在 DOMLoaded事件觸發(fā)的時(shí)候加載，或者使用 setTimeout方式來靈活的控制加載的時(shí)機(jī)。

7. 減少不必要的 HTTP跳轉(zhuǎn)

對(duì)于以目錄形式訪問的 HTTP鏈接，很多人都會(huì)忽略鏈接最后是否帶 ’/'，假如你的服務(wù)器對(duì)此是區(qū)別對(duì)待的話，那么你也需要注意，這其中很可能隱藏了 301跳轉(zhuǎn)，增加了多余請(qǐng)求。具體參見下圖，其中第一個(gè)鏈接是以無 ’/'結(jié)尾的方式訪問的，于是服務(wù)器有了一次跳轉(zhuǎn)。

8. 避免重復(fù)的資源請(qǐng)求

這種情況主要是由于疏忽或頁面由多個(gè)模塊拼接而成，然后每個(gè)模塊中請(qǐng)求了同樣的資源時(shí)，會(huì)導(dǎo)致資源的重復(fù)請(qǐng)求

二、代碼級(jí)優(yōu)化

1. Javascript

(1). DOM

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

a. HTML Collection（HTML收集器，返回的是一個(gè)數(shù)組內(nèi)容信息）

在腳本中 document.images、document.forms 、getElementsByTagName()返回的都是 HTMLCollection類型的集合，在平時(shí)使用的時(shí)候大多將它作為數(shù)組來使用，因?yàn)樗?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屬性、成員保存到局部變量后再使用局部變量。

b. Reflow & Repaint

除了上面一點(diǎn)之外， DOM操作還需要考慮瀏覽器的 Reflow和Repaint ，因?yàn)檫@些都是需要消耗資源的，具體的可以參加以下文章：

如何減少瀏覽器的repaint和reflow?

Understanding Internet Explorer Rendering Behaviour

Notes on HTML Reflow

(2). 慎用 with

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

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

(3). 避免使用 eval和 Function

每次 eval 或 Function 構(gòu)造函數(shù)作用于字符串表示的源代碼時(shí)，腳本引擎都需要將源代碼轉(zhuǎn)換成可執(zhí)行代碼。這是很消耗資源的操作 —— 通常比簡單的函數(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). 減少作用域鏈查找（這方面設(shè)計(jì)到一些內(nèi)容的相關(guān)問題）

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

低效率的寫法：

// 全局變量

var globalVar = 1;

function myCallback(info){

for( var i = 100000; i--;){

//每次訪問 globalVar 都需要查找到作用域鏈最頂端，本例中需要訪問 100000 次

globalVar += i;

}

}

更高效的寫法：

// 全局變量

var globalVar = 1;

function myCallback(info){

//局部變量緩存全局變量

var localVar = globalVar;

for( var i = 100000; i--;){

//訪問局部變量是最快的

localVar += i;

}

//本例中只需要訪問 2次全局變量

在函數(shù)中只需要將 globalVar中內(nèi)容的值賦給localVar 中區(qū)

globalVar = localVar;

}

此外，要減少作用域鏈查找還應(yīng)該減少閉包的使用。

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

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

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

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

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

(6). 字符串拼接

在 Javascript中使用"+" 號(hào)來拼接字符串效率是比較低的，因?yàn)槊看芜\(yùn)行都會(huì)開辟新的內(nèi)存并生成新的字符串變量，然后將拼接結(jié)果賦值給新變量。與之相比更為高效的做法是使用數(shù)組的 join方法，即將需要拼接的字符串放在數(shù)組中最后調(diào)用其 join方法得到結(jié)果。不過由于使用數(shù)組也有一定的開銷，因此當(dāng)需要拼接的字符串較多的時(shí)候可以考慮用此方法。

關(guān)于 Javascript優(yōu)化的更詳細(xì)介紹請(qǐng)參考：

Write Efficient Javascript(PPT)

Efficient JavaScript

2. CSS選擇符

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

#toc A { color: #444; }

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

3. HTML

對(duì) HTML本身的優(yōu)化現(xiàn)如今也越來越多的受人關(guān)注了，詳情可以參見這篇 總結(jié)性文章 。

4. Image壓縮

圖片壓縮是個(gè)技術(shù)活，不過現(xiàn)如今這方面的工具也非常多，壓縮之后往往能帶來不錯(cuò)的效果，具體的壓縮原理以及方法在《 Even Faster Web Sites》第10 章有很詳細(xì)的介紹，有興趣的可以去看看。

總結(jié)

本文從頁面級(jí)以及代碼級(jí)兩個(gè)粒度對(duì)前端優(yōu)化的各種方式做了一個(gè)總結(jié)，這些方法基本上都是前端開發(fā)人員在開發(fā)的過程中可以借鑒和實(shí)踐的，除此之外，完整的前端優(yōu)化還應(yīng)該包括很多其他的途徑，例如 CDN、 Gzip、多域名、無 Cookie服務(wù)器等等，由于對(duì)于開發(fā)人員的可操作性并不強(qiáng)大，在此也就不多敘述了，詳細(xì)的可以參考 Yahoo和Google 的這些“金科玉律。

二、你有用過哪些前端性能優(yōu)化的方法？

這個(gè)是面試常問的問題了。

我來簡單說下幾個(gè)方面：

1.減少http請(qǐng)求：在YUI35規(guī)則中也有提到，主要是優(yōu)化js、css和圖片資源三個(gè)方面，因?yàn)閔tml是沒有辦法避免的。因此，我們可以做一下的幾項(xiàng)操作：

• 合并js文件

• 合并css文件

• 雪碧圖的使用(css sprite)

• 使用base64表示簡單的圖片

2.減少資源體積

• 壓縮css

• 壓縮js

• 壓縮圖片

3.圖片加載處理：

• 圖片預(yù)加載

• 圖片懶加載

• 首屏加載時(shí)進(jìn)度條的顯示

就簡單說這些，特別詳細(xì)的可以網(wǎng)上看下。

三、常見的前端性能優(yōu)化手段都有哪些？都有多大收益

規(guī)則01：盡量減少HTTP請(qǐng)求

前端優(yōu)化的黃金準(zhǔn)則指導(dǎo)著前端頁面的優(yōu)化策略：只有10%-20%的最終用戶響應(yīng)時(shí)間花在接受請(qǐng)求的HTML文檔上，剩下的80%-90%時(shí)間花在為HTML文檔所引用的所有組件（圖片、腳本、樣式表等）進(jìn)行的HTTP請(qǐng)求上。因此，改善響應(yīng)時(shí)間的最簡單途徑就是減少組件的數(shù)量，并由此減少HTTP請(qǐng)求的數(shù)量。當(dāng)然很多人就會(huì)說，既然這樣，那我們就減少頁面組件的數(shù)量不就OK了嗎？那你試試，你會(huì)掀起一場(chǎng)性能優(yōu)化和產(chǎn)品設(shè)計(jì)之間的大PK。

所以，我們要減少HTTP請(qǐng)求是要平衡性能和設(shè)計(jì)的。如果找到這個(gè)平衡點(diǎn)呢？書中從以下幾個(gè)方面做了介紹，我逐一說明：

① 圖片地圖

初看“圖片地圖”四個(gè)字，對(duì)非專業(yè)的前端人員來說一頭霧水，我的第一印象就是這樣的，咱們以京東的移動(dòng)站點(diǎn)為例，右側(cè)用戶和購物車的圖標(biāo)，正常實(shí)現(xiàn)我會(huì)選擇如下方式：

<a href=”用戶跳轉(zhuǎn)頁面URL”>

<div class=”定義用戶icon顯示的樣式表”></div>

</a>

<a href=”購物車跳轉(zhuǎn)頁面URL”>

<div class=” 定義用戶icon顯示的樣式表”></div>

</a>

這種方式無可厚非的，但是兩張圖片就有兩個(gè)HTTP請(qǐng)求，這明顯是增加了頁面中的HTTP請(qǐng)求。那么我們可以把這兩個(gè)HTTP請(qǐng)求變成一個(gè)嗎？

答案當(dāng)然是可以的，這就是圖片地圖：允許在一張圖片上關(guān)聯(lián)多個(gè)URL，而目標(biāo)URL的選擇取決于用戶單擊了圖片上的哪個(gè)位置。

這樣上面京東兩個(gè)圖標(biāo)合并成一張圖片，這樣圖片的HTTP請(qǐng)求就減少了一個(gè)。

示例代碼如下：

<img src=合并后的圖片>

<map name=”map1”>

<areashape=”rect” coords=”0,0,40,40” href=”用戶跳轉(zhuǎn)頁面URL”>

<areashape=”rect” coords=”50,0,90,40” href=”購物車跳轉(zhuǎn)頁面URL”>

</map>

不過圖片地圖只支持矩形形狀，其他形狀不支持。

② 請(qǐng)CSS喝“雪碧”（CSS Sprites）CSS Sprites一句話：將多個(gè)圖片合并到一張單獨(dú)的圖片，這樣就大大減少了頁面中圖片的HTTP請(qǐng)求。

③ 內(nèi)聯(lián)圖片和腳本使用data:URL（Base64編碼）模式直接將圖片包含在Web頁面中而無需進(jìn)行HTTP請(qǐng)求。但是此種方法存在明顯缺陷：- 不受IE的歡迎；- 圖片太大不宜采用這種方式，因?yàn)锽ase64編碼之后會(huì)增加圖片大小，這樣頁面整體的下載量會(huì)變大；- 內(nèi)聯(lián)圖片在頁面跳轉(zhuǎn)的時(shí)候不會(huì)被緩存。（大圖片可以使用瀏覽器的本地緩存，在首次訪問的時(shí)候保存到瀏覽器緩存中，典型的是HTML5的manifest緩存機(jī)制以及LocalStorage等）。

④ 樣式表的合并將頁面樣式定義、腳本、頁面本身代碼嚴(yán)格區(qū)分開，但是樣式表、腳本也不是分割越細(xì)越好，因?yàn)闆]多引用一個(gè)樣式表就增加一次HTPP請(qǐng)求，能合并的樣式表盡量合并。一個(gè)網(wǎng)站有一個(gè)公用樣式表定義，每個(gè)頁面只要有一個(gè)樣式表就OK啦。

通過以上四個(gè)努力之后，你會(huì)發(fā)現(xiàn)你的網(wǎng)頁響應(yīng)時(shí)間最多能減少一半，這不是作者說大話，也不是我狂吹，我親手用我的移動(dòng)網(wǎng)站首頁做了一個(gè)嘗試，本地測(cè)試之后響應(yīng)時(shí)間能減少40%左右。所以減少頁面HTTP請(qǐng)求數(shù)量，是一個(gè)很重要的原則。遵循此原則可以同時(shí)改善首次訪問和后續(xù)訪問的響應(yīng)時(shí)間，而每一個(gè)網(wǎng)站的首次響應(yīng)時(shí)間會(huì)決定用戶之后還來不來的重要原因。

規(guī)則02：使用內(nèi)容發(fā)布網(wǎng)絡(luò)（CDN的使用）

什么叫內(nèi)容發(fā)布網(wǎng)絡(luò)（CDN）？它是一組分布在多個(gè)不同地理位置的Web服務(wù)器，用于更加有效地向用戶發(fā)布內(nèi)容。主要用于發(fā)布頁面靜態(tài)資源：圖片、css文件、js文件等。如此，能輕易地提高響應(yīng)速度。關(guān)于CDN的具體詳細(xì)原理以及優(yōu)缺點(diǎn)，各位可以自行詢問度娘或者google。

規(guī)則03：添加Expires頭

瀏覽器使用緩存來減少HTTP請(qǐng)求的數(shù)據(jù)，并減小HTTP響應(yīng)的大小，使頁面加載更快。Web服務(wù)器使用Expires頭來告訴瀏覽器它可以使用一個(gè)組件的當(dāng)前副本，直到指定的deadline為止。HTTP規(guī)范中稱此頭為：在這一時(shí)間之后響應(yīng)被認(rèn)為失效。個(gè)人對(duì)這塊表示不想使用，其實(shí)就是一句話，把一些css、js、圖片在首次訪問的時(shí)候全部緩存到瀏覽器本地，從我做移動(dòng)網(wǎng)站的過程中發(fā)現(xiàn)，其實(shí)沒有這么復(fù)雜，完全可以使用HTML5提供的本地緩存機(jī)制就OK了。關(guān)于HTML5本地緩存機(jī)制，各位可以查閱相關(guān)資料。后續(xù)我也會(huì)對(duì)HTML5的緩存機(jī)制進(jìn)行介紹的。

規(guī)則04：壓縮組件（使用Gzip方式）

書中關(guān)于壓縮從gzip壓縮方式到如何壓縮講了很多，我想直接跳過，對(duì)于做PC網(wǎng)站或者移動(dòng)網(wǎng)站來說，急需要壓縮的是css文件和js文件，至于如何壓縮，網(wǎng)上有很多在線工具，去挑選一個(gè)自己用的順手看的順眼的就好，當(dāng)然也有人選擇對(duì)HTML進(jìn)行壓縮，這樣也可以。但是實(shí)際工作中我沒有這么做。之所謂沒有這么做，是因?yàn)槲矣X得很麻煩。不要鄙視我，畢竟我不是一個(gè)真正意義上的前端工程師，哈哈！

規(guī)則05：將CSS樣式表放在頂部

如果將css樣式定義放在頁面中或者頁面底部，會(huì)出現(xiàn)短暫白屏或者某一區(qū)域短暫白板的情況，這和瀏覽器的運(yùn)營機(jī)制有關(guān)的，不管頁面如何加載，頁面都是逐步呈現(xiàn)的。所以在每做一個(gè)頁面的時(shí)候，用Link標(biāo)簽把每一個(gè)樣式表定義放在head中。

規(guī)則06：將javascript腳本放在底部

瀏覽器在加載css文件時(shí)，頁面逐步呈現(xiàn)會(huì)被阻止，直到所有css文件加載完畢，所以要把css文件的引用放到head中去，這樣在加載css文件時(shí)不會(huì)組織頁面的呈現(xiàn)。但是對(duì)于js文件，在使用的時(shí)候，它下面所有也頁面內(nèi)容的呈現(xiàn)都會(huì)被阻塞，將腳本放在頁面越靠下的地方，就意味著越多的內(nèi)容能夠逐步呈現(xiàn)。

規(guī)則07：避免使用CSS表達(dá)式

CSS表達(dá)式是動(dòng)態(tài)玩CSS的一種很強(qiáng)大的方式，但是強(qiáng)大的同時(shí)也存在很高的危險(xiǎn)性。因?yàn)閏ss表達(dá)式的頻繁求值會(huì)導(dǎo)致css表達(dá)式性能低下。如果真想玩css表達(dá)式，可以選用只求值一次的表達(dá)式或者使用事件處理來改變css的值。

規(guī)則08：使用外部javascript和CSS內(nèi)聯(lián)js和css其實(shí)比外部文件有更快的響應(yīng)速度，那為什么還要用外部呢？因?yàn)槭褂猛獠康膉s和css可以讓瀏覽器緩存他們，這樣不僅HTML文檔大小減少，而且不會(huì)增加HTTP請(qǐng)求數(shù)量。另外，使用外部js和css可以提高組件的可復(fù)用性。

規(guī)則09：減少DNS查詢

DNS查詢有時(shí)間開銷，通常一個(gè)瀏覽器查找一個(gè)給定主機(jī)名的IP地址需要20-120ms。緩存DNS：緩存DNS查詢可以很好地提高網(wǎng)頁性能，一旦緩存了DNS查詢，之后對(duì)于相同主機(jī)名的請(qǐng)求就無需進(jìn)行再次的DNS查找，至少短時(shí)間內(nèi)不需要。所以在使用頁面中URL、圖片、js文件、css文件等時(shí)，不要使用過多不同的主機(jī)名。

規(guī)則10：精簡javascript

如何精簡？

其實(shí)W3Cfuns已經(jīng)給大家準(zhǔn)備好精簡JS所需的所有工具“前端神器”，這點(diǎn)W3Cfuns為大家做的很不錯(cuò)，在這個(gè)規(guī)則里我們就用到“JS壓縮/混淆/美化工具”

最初始的精簡方式：就是移除不必要的字符減小js文件大小，改善加載時(shí)間。包括所有的注釋、不必要的空白字符。

高級(jí)一點(diǎn)的精簡方式就是：混淆。

它不但會(huì)移除不必要的字符，還會(huì)改寫代碼，比如函數(shù)和變量的名字會(huì)被改成很短的字符串，這樣使js代碼更簡練更難閱讀。

但是我一般很少使用混淆，一個(gè)現(xiàn)在互聯(lián)網(wǎng)時(shí)代，代碼沒有必要整的那么神秘，大可以大家一起share，天下代碼一起抄，只要抄出自己的特色就ok了。

而且一旦使用混淆，對(duì)于js代碼的維護(hù)和調(diào)試都很復(fù)雜，因?yàn)橛袝r(shí)候混淆之后的js代碼完全看不懂。其實(shí)實(shí)際開發(fā)過程中，從文件大小和代碼可復(fù)用性來說，不僅僅是js代碼需要精簡，css代碼一樣也很需要精簡。

規(guī)則11：避免重定向

重定向的英文是Redirect，用于將用戶從一個(gè)URL重新跳轉(zhuǎn)到另一個(gè)URL。

最常見的Redirect就是301和302兩種。

關(guān)于重定向的性能影響這里就不說了，自行查閱相關(guān)資料吧。

在我們實(shí)際開發(fā)中避免重定向最簡單也最容易被忽視的一個(gè)問題就是，設(shè)置URL的時(shí)候，最后的“/”，有些人有時(shí)候會(huì)忽略，其實(shí)你少了“/”，這時(shí)候的URL就被重定向了，所以在給頁面鏈接加URL的時(shí)候切記最后的“/”不可丟。

規(guī)則12：刪除重復(fù)腳本

重復(fù)的js代碼除了有不必要的HTTP請(qǐng)求之外，還會(huì)浪費(fèi)執(zhí)行js的時(shí)間。

將你使用的js代碼模塊化，可以很好地避免這個(gè)問題，至于js模塊化如何實(shí)現(xiàn)，現(xiàn)在有很多可以使用的開源框架，我用的比較多的是我們公司玉伯的Sea.js。

規(guī)則13：配置ETag

Etag（Entity Tag），實(shí)體標(biāo)簽，是Web服務(wù)器和瀏覽器用戶確認(rèn)緩存組件的有效性的一種機(jī)制。寫的很復(fù)雜，對(duì)我這種非專業(yè)的前端開發(fā)人員來說，有點(diǎn)過了，關(guān)于這個(gè)原則有興趣的自己看吧。

規(guī)則14：使Ajax可緩存

針對(duì)頁面中主動(dòng)的Ajax請(qǐng)求返回的數(shù)據(jù)要緩存到本地，當(dāng)然這個(gè)是針對(duì)短期內(nèi)不會(huì)變化的數(shù)據(jù)。如果不確定數(shù)據(jù)變化周期的話，可以增加一個(gè)修改標(biāo)識(shí)的判斷，我正常處理過程中會(huì)給一些Ajax請(qǐng)求返回的數(shù)據(jù)增加一個(gè)MD5值的判斷，每次請(qǐng)求會(huì)判斷當(dāng)前MD5是否變化，如果變化了取最新的數(shù)據(jù)，如果不變化，則不變。

四、前端性能優(yōu)化-傳輸加載優(yōu)化

Nginx開啟Gzip壓縮功能， 可以使網(wǎng)站的css、js 、xml、html 文件在傳輸時(shí)進(jìn)行壓縮，提高訪問速度, 進(jìn)而優(yōu)化Nginx性能! Web網(wǎng)站上的圖片，視頻等其它多媒體文件以及大文件，因?yàn)閴嚎s效果不好，所以對(duì)于圖片沒有必要支壓縮，如果想要優(yōu)化，可以圖片的生命周期設(shè)置長一點(diǎn)，讓客戶端來緩存。 開啟Gzip功能后，Nginx服務(wù)器會(huì)根據(jù)配置的策略對(duì)發(fā)送的內(nèi)容, 如css、js、xml、html等靜態(tài)資源進(jìn)行壓縮, 使得這些內(nèi)容大小減少，在用戶接收到返回內(nèi)容之前對(duì)其進(jìn)行處理，以壓縮后的數(shù)據(jù)展現(xiàn)給客戶。這樣不僅可以節(jié)約大量的出口帶寬，提高傳輸效率，還能提升用戶快的感知體驗(yàn), 一舉兩得; 盡管會(huì)消耗一定的cpu資源，但是為了給用戶更好的體驗(yàn)還是值得的。

Nginx關(guān)于keepalive連接保持的特性，實(shí)際上就是在一次TCP連接中，可以持續(xù)處理多個(gè)客戶請(qǐng)求，而不斷開連接。通過該機(jī)制可以減少TCP連接的建立次數(shù)，減少TIME_WAIT的狀態(tài)連接。從而增加服務(wù)的吞吐量和整體服務(wù)質(zhì)量。

強(qiáng)制緩存和協(xié)商緩存

推薦閱讀： https://www.jianshu.com/p/037a4478c504

Service worker 提供了很多新的能力，使得 web app 擁有與 nativeapp 相同的離線體驗(yàn)、消息推送體驗(yàn)。

推薦閱讀: https://www.jianshu.com/p/768be2733872

HTTP2優(yōu)勢(shì)

多路復(fù)用

二進(jìn)制分幀

首部壓縮

服務(wù)推送

推薦閱讀: https://www.jianshu.com/p/8ac6baf4728c

SSR是Server Side Render簡稱；頁面上的內(nèi)容是通過服務(wù)端渲染生成的，瀏覽器直接顯示服務(wù)端返回的html就可以了。

推薦閱讀: https://www.jianshu.com/p/10b6074d772c

以上就是關(guān)于提高前端性能的方法相關(guān)問題的回答。希望能幫到你，如有更多相關(guān)問題，您也可以聯(lián)系我們的客服進(jìn)行咨詢，客服也會(huì)為您講解更多精彩的知識(shí)和內(nèi)容。

推薦閱讀：

流量網(wǎng)速卡怎么提高網(wǎng)速（流量網(wǎng)速卡怎么提高網(wǎng)速的方法）

怎么提高搜索詞的權(quán)重（怎么提高搜索詞的權(quán)重和效率）

怎么樣提高產(chǎn)品的搜索權(quán)重（怎么樣提高產(chǎn)品的搜索權(quán)重的方法）

一個(gè)200萬的粉絲號(hào)多少錢（一個(gè)200萬的粉絲號(hào)多少錢?。?/a>

香港零食品牌排行榜（香港零食品牌排行榜前十）