正文

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

發(fā)布時間：2023-04-21 19:34:21 稿源：創(chuàng)意嶺閱讀： 50

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

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

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

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

創(chuàng)意嶺作為行業(yè)內(nèi)優(yōu)秀的企業(yè)，服務(wù)客戶遍布全球各地，如需了解SEO相關(guān)業(yè)務(wù)請撥打電話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ù)雜的，針對方方面面的資源都有不同的方式。那么，前端優(yōu)化的目的是什么 ?

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

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

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

前端優(yōu)化的途徑有很多，按粒度大致可以分為兩類，第一類是頁面級別的優(yōu)化，例如 HTTP請求數(shù)、腳本的無阻塞加載、內(nèi)聯(lián)腳本的位置優(yōu)化等 ;第二類則是代碼級別的優(yōu)化，例如 Javascript中的DOM 操作優(yōu)化、CSS選擇符優(yōu)化、圖片優(yōu)化以及 HTML結(jié)構(gòu)優(yōu)化等等。另外，本著提高投入產(chǎn)出比的目的，后文提到的各種優(yōu)化策略大致按照投入產(chǎn)出比從大到小的順序排列。

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

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

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

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

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

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

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

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

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

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

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

(3). 資源合并與壓縮

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

(4). CSS Sprites

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

(5). Inline Images

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

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

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

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

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

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

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

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

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

5. 將 CSS放在 HEAD中

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

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

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

Javascript:

function myCallback(info){

//do something here

}

HTML:

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

myCallback('Hello world!');

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

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

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

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

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

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

1. Javascript

(1). DOM

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

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

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

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

b. Reflow & Repaint

除了上面一點之外， DOM操作還需要考慮瀏覽器的 Reflow和Repaint ，因為這些都是需要消耗資源的，具體的可以參加以下文章：

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

Understanding Internet Explorer Rendering Behaviour

Notes on HTML Reflow

(2). 慎用 with

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

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

(3). 避免使用 eval和 Function

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

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

Function 構(gòu)造函數(shù)比 eval略好，因為使用此代碼不會影響周圍代碼 ;但其速度仍很慢。

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

(4). 減少作用域鏈查找（這方面設(shè)計到一些內(nèi)容的相關(guān)問題）

前文談到了作用域鏈查找問題，這一點在循環(huán)中是尤其需要注意的問題。如果在循環(huán)中需要訪問非本作用域下的變量時請在遍歷之前用局部變量緩存該變量，并在遍歷結(jié)束后再重寫那個變量，這一點對全局變量尤其重要，因為全局變量處于作用域鏈的最頂端，訪問時的查找次數(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ù)訪問包括直接量 (字符串、正則表達式 )、變量、對象屬性以及數(shù)組，其中對直接量和局部變量的訪問是最快的，對對象屬性以及數(shù)組的訪問需要更大的開銷。當(dāng)出現(xiàn)以下情況時，建議將數(shù)據(jù)放入局部變量：

a. 對任何對象屬性的訪問超過 1次

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

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

(6). 字符串拼接

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

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

Write Efficient Javascript(PPT)

Efficient JavaScript

2. CSS選擇符

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

#toc A { color: #444; }

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

3. HTML

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

4. Image壓縮

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

總結(jié)

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

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

這個是面試常問的問題了。

我來簡單說下幾個方面：

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

合并js文件
合并css文件
雪碧圖的使用(css sprite)
使用base64表示簡單的圖片

2.減少資源體積

壓縮css
壓縮js
壓縮圖片

3.圖片加載處理：

圖片預(yù)加載
圖片懶加載
首屏加載時進度條的顯示

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

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

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

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

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

① 圖片地圖

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

</a>

</a>

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

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

這樣上面京東兩個圖標合并成一張圖片，這樣圖片的HTTP請求就減少了一個。

示例代碼如下：

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

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

</map>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

規(guī)則10：精簡javascript

如何精簡？

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

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

高級一點的精簡方式就是：混淆。

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

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

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

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

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

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

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

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

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

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

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

規(guī)則13：配置ETag

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

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

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

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

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

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

強制緩存和協(xié)商緩存

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

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

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

HTTP2優(yōu)勢

多路復(fù)用

二進制分幀

首部壓縮

服務(wù)推送

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

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