減少http請求合理設置 HTTP緩存

在動態網頁中，我們難免會與后臺服務器交互，減少http請求的數目在性能提升上是十分明顯的。比如我們可以：

1. 簡化步驟，將請求數據盡可能的封裝在少的接口中，當然這是不破壞程序可擴展性及健壯性的情況下。

2. 合并壓縮css與JS等文件，圖片較多的頁面也可以使用 lazyLoad 等技術進行優化。

3. 為不常變化的請求數據設置http緩存

合理放置CSS與JS的位置

瀏覽器會在下載完成全部CSS之后才對整個頁面進行渲染，因此最好的做法是將CSS放在頁面最上面，讓瀏覽器盡快下載CSS。如果將 CSS放在其他地方比如 BODY中，則瀏覽器有可能還未下載和解析到 CSS就已經開始渲染頁面了，這就導致頁面由無 CSS狀態跳轉到 CSS狀態，用戶體驗比較糟糕，所以可以考慮將CSS放在HEAD中。
Javascript則相反，瀏覽器在加載javascript后立即執行，有可能會阻塞整個頁面，造成頁面顯示緩慢，因此javascript最好放在頁面最下面。但如果頁面解析時就需要用到javascript，這時放到底部就不合適了。
Lazy Load Javascript（只有在需要加載的時候加載，在一般情況下并不加載信息內容。）隨著 Javascript框架的流行，越來越多的站點也使用起了框架。不過，一個框架往往包括了很多的功能實現，這些功能并不是每一個頁面都需要的，如果下載了不需要的腳本則算得上是一種資源浪費 -既浪費了帶寬又浪費了執行花費的時間。目前的做法大概有兩種，一種是為那些流量特別大的頁面專門定制一個專用的 mini版框架，另一種則是 Lazy Load。

減少重排與重繪

當DOM的變化影響了元素的幾何屬性（寬或高），瀏覽器需要重新計算元素的幾何屬性，同樣其他元素的幾何屬性和位置也會因此受到影響。瀏覽器會使渲染樹中受到影響的部分失效，并重新構造渲染樹。這個過程稱為重排。完成重排后，瀏覽器會重新繪制受影響的部分到屏幕，該過程稱為重繪。
重排何時發生？
很顯然，每次重排，必然會導致重繪，那么，重排會在哪些情況下發生？
1、添加或者刪除可見的DOM元素
2、元素位置改變
3、元素尺寸改變
4、元素內容改變（例如：一個文本被另一個不同尺寸的圖片替代）
5、頁面渲染初始化（這個無法避免）
6、瀏覽器窗口尺寸改變
這些都是顯而易見的，或許你已經有過這樣的體會，不間斷地改變瀏覽器窗口大小，導致UI反應遲鈍（某些低版本IE下甚至直接掛掉），現在你可能恍然大悟，沒錯，正是一次次的重排重繪導致的！

重排和重繪是DOM編程中耗能的主要原因之一，平時涉及DOM編程時可以參考以下幾點：
1、盡量不要在布局信息改變時做查詢（會導致渲染隊列強制刷新）
2、同一個DOM的多個屬性改變可以寫在一起（減少DOM訪問，同時把強制渲染隊列刷新的風險降為0）
3、如果要批量添加DOM，可以先讓元素脫離文檔流，操作完后再帶入文檔流，這樣只會觸發一次重排（fragment元素的應用）
4、將需要多次重排的元素，position屬性設為absolute或fixed，這樣此元素就脫離了文檔流，它的變化不會影響到其他元素。例如有動畫效果的元素就最好設置為絕對定位。

javascript代碼優化

1、減少dom訪問
對DOM操作的代價是高昂的，這在網頁應用中的通常是一個性能瓶頸。

天生就慢。在《高性能JavaScript》中這么比喻：“把DOM看成一個島嶼，把JavaScript(ECMAScript)看成另一個島嶼，兩者之間以一座收費橋連接”。所以每次訪問DOM都會教一個過橋費，而訪問的次數越多，交的費用也就越多。所以一般建議盡量減少過橋次數。
解決辦法：

修改和訪問DOM元素會造成頁面的Repaint和Reflow，循環對DOM操作更是罪惡的行為。所以請合理的使用JavaScript變量儲存內容，考慮大量DOM元素中循環的性能開銷，在循環結束時一次性寫入。
減少對DOM元素的查詢和修改，查詢時可將其賦值給局部變量。

2、減少作用域鏈查找
作用域查找也是消耗一定時間的，所以我們可以將要使用的對象用變量保存在局部變量中，避免作用域的全局查找。此外，要減少作用域鏈查找還應該減少閉包的使用。

3、慎用 with　
with(obj){ p = 1}; 代碼塊的行為實際上是修改了代碼塊中的執行環境 ，將obj放在了其作用域鏈的最前端，在 with代碼塊中訪問非局部變量是都是先從 obj上開始查找，如果沒有再依次按作用域鏈向上查找，因此使用 with相當于增加了作用域鏈長度。而每次查找作用域鏈都是要消耗時間的，過長的作用域鏈會導致查找性能下降。
　　因此，除非你能肯定在 with代碼中只訪問 obj中的屬性，否則慎用 with，替代的可以使用局部變量緩存需要訪問的屬性。
4、 避免使用 eval和 Function
每次 eval 或Function 構造函數作用于字符串表示的源代碼時，腳本引擎都需要將源代碼轉換成可執行代碼。這是很消耗資源的操作 —— 通常比簡單的函數調用慢 100倍以上。
　　eval 函數效率特別低，由于事先無法知曉傳給 eval 的字符串中的內容，eval在其上下文中解釋要處理的代碼，也就是說編譯器無法優化上下文，因此只能有瀏覽器在運行時解釋代碼。這對性能影響很大。
　　Function 構造函數比 eval略好，因為使用此代碼不會影響周圍代碼 ;但其速度仍很慢。
　　此外，使用 eval和 Function也不利于Javascript 壓縮工具執行壓縮。
　　
5、優化循環，妙用算法
減少循環的次數對性能的提升效果也是顯著的。特別是在循環次數很多的時候，優化循環次數是很有必要的。有些時候算法可以取到事半功倍的效果。

作為一個前端工程師，性能優化是很有必要的。好的用戶體驗能一定程度上決定產品的命運。而提升用戶體驗有很多方面，比如，界面設計，操作設計，網頁加載性能等。。。
提升性能我們可以從如下幾個方面考慮：

減少http請求合理設置 HTTP緩存

在動態網頁中，我們難免會與后臺服務器交互，減少http請求的數目在性能提升上是十分明顯的。比如我們可以：

1. 簡化步驟，將請求數據盡可能的封裝在少的接口中，當然這是不破壞程序可擴展性及健壯性的情況下。

2. 合并壓縮css與JS等文件，圖片較多的頁面也可以使用 lazyLoad 等技術進行優化。

3. 為不常變化的請求數據設置http緩存

合理放置CSS與JS的位置

瀏覽器會在下載完成全部CSS之后才對整個頁面進行渲染，因此最好的做法是將CSS放在頁面最上面，讓瀏覽器盡快下載CSS。如果將 CSS放在其他地方比如 BODY中，則瀏覽器有可能還未下載和解析到 CSS就已經開始渲染頁面了，這就導致頁面由無 CSS狀態跳轉到 CSS狀態，用戶體驗比較糟糕，所以可以考慮將CSS放在HEAD中。
Javascript則相反，瀏覽器在加載javascript后立即執行，有可能會阻塞整個頁面，造成頁面顯示緩慢，因此javascript最好放在頁面最下面。但如果頁面解析時就需要用到javascript，這時放到底部就不合適了。
Lazy Load Javascript（只有在需要加載的時候加載，在一般情況下并不加載信息內容。）隨著 Javascript框架的流行，越來越多的站點也使用起了框架。不過，一個框架往往包括了很多的功能實現，這些功能并不是每一個頁面都需要的，如果下載了不需要的腳本則算得上是一種資源浪費 -既浪費了帶寬又浪費了執行花費的時間。目前的做法大概有兩種，一種是為那些流量特別大的頁面專門定制一個專用的 mini版框架，另一種則是 Lazy Load。

減少重排與重繪

當DOM的變化影響了元素的幾何屬性（寬或高），瀏覽器需要重新計算元素的幾何屬性，同樣其他元素的幾何屬性和位置也會因此受到影響。瀏覽器會使渲染樹中受到影響的部分失效，并重新構造渲染樹。這個過程稱為重排。完成重排后，瀏覽器會重新繪制受影響的部分到屏幕，該過程稱為重繪。
重排何時發生？
很顯然，每次重排，必然會導致重繪，那么，重排會在哪些情況下發生？
1、添加或者刪除可見的DOM元素
2、元素位置改變
3、元素尺寸改變
4、元素內容改變（例如：一個文本被另一個不同尺寸的圖片替代）
5、頁面渲染初始化（這個無法避免）
6、瀏覽器窗口尺寸改變
這些都是顯而易見的，或許你已經有過這樣的體會，不間斷地改變瀏覽器窗口大小，導致UI反應遲鈍（某些低版本IE下甚至直接掛掉），現在你可能恍然大悟，沒錯，正是一次次的重排重繪導致的！

重排和重繪是DOM編程中耗能的主要原因之一，平時涉及DOM編程時可以參考以下幾點：
1、盡量不要在布局信息改變時做查詢（會導致渲染隊列強制刷新）
2、同一個DOM的多個屬性改變可以寫在一起（減少DOM訪問，同時把強制渲染隊列刷新的風險降為0）
3、如果要批量添加DOM，可以先讓元素脫離文檔流，操作完后再帶入文檔流，這樣只會觸發一次重排（fragment元素的應用）
4、將需要多次重排的元素，position屬性設為absolute或fixed，這樣此元素就脫離了文檔流，它的變化不會影響到其他元素。例如有動畫效果的元素就最好設置為絕對定位。

javascript代碼優化

1、減少dom訪問
對DOM操作的代價是高昂的，這在網頁應用中的通常是一個性能瓶頸。

天生就慢。在《高性能JavaScript》中這么比喻：“把DOM看成一個島嶼，把JavaScript(ECMAScript)看成另一個島嶼，兩者之間以一座收費橋連接”。所以每次訪問DOM都會教一個過橋費，而訪問的次數越多，交的費用也就越多。所以一般建議盡量減少過橋次數。
解決辦法：

修改和訪問DOM元素會造成頁面的Repaint和Reflow，循環對DOM操作更是罪惡的行為。所以請合理的使用JavaScript變量儲存內容，考慮大量DOM元素中循環的性能開銷，在循環結束時一次性寫入。
減少對DOM元素的查詢和修改，查詢時可將其賦值給局部變量。

2、減少作用域鏈查找
作用域查找也是消耗一定時間的，所以我們可以將要使用的對象用變量保存在局部變量中，避免作用域的全局查找。此外，要減少作用域鏈查找還應該減少閉包的使用。

3、慎用 with　
with(obj){ p = 1}; 代碼塊的行為實際上是修改了代碼塊中的執行環境 ，將obj放在了其作用域鏈的最前端，在 with代碼塊中訪問非局部變量是都是先從 obj上開始查找，如果沒有再依次按作用域鏈向上查找，因此使用 with相當于增加了作用域鏈長度。而每次查找作用域鏈都是要消耗時間的，過長的作用域鏈會導致查找性能下降。
　　因此，除非你能肯定在 with代碼中只訪問 obj中的屬性，否則慎用 with，替代的可以使用局部變量緩存需要訪問的屬性。
4、 避免使用 eval和 Function
每次 eval 或Function 構造函數作用于字符串表示的源代碼時，腳本引擎都需要將源代碼轉換成可執行代碼。這是很消耗資源的操作 —— 通常比簡單的函數調用慢 100倍以上。
　　eval 函數效率特別低，由于事先無法知曉傳給 eval 的字符串中的內容，eval在其上下文中解釋要處理的代碼，也就是說編譯器無法優化上下文，因此只能有瀏覽器在運行時解釋代碼。這對性能影響很大。
　　Function 構造函數比 eval略好，因為使用此代碼不會影響周圍代碼 ;但其速度仍很慢。
　　此外，使用 eval和 Function也不利于Javascript 壓縮工具執行壓縮。
　　
5、優化循環，妙用算法
減少循環的次數對性能的提升效果也是顯著的。特別是在循環次數很多的時候，優化循環次數是很有必要的。有些時候算法可以取到事半功倍的效果。

以上就是web前端性能優化方法的詳細內容，更多請關注php中文網其它相關文章！