❶ 前端開發，頁面優化，性能優化有哪些方面
常用的優化有兩部分
第一：面向內容的優化
1. 減少 HTTP 請求
2. 減少 DNS 查找
3. 避免重定向
4. 使用 Ajax 緩存
5. 延遲載入組件
6. 預先載入組件
7. 減少 DOM 元素數量
8. 切分組件到多個域
9. 最小化 iframe 的數量
10. 不要出現http 404 錯誤
第二：面向 Server
1. 縮小 Cookie
2. 針對 Web 組件使用域名無關性的
❷ 前端性能優化的具體方法有哪些
解決辦法一：
減少http請求次數：CSS Sprites, JS、CSS源碼壓縮、圖片大小控制合適；網頁Gzip，CDN託管，data緩存 ，圖片伺服器。
前端模板 JS+數據，減少由於HTML標簽導致的帶寬浪費，前端用變數保存AJAX請求結果，每次操作本地變數，不用請求，減少請求次數
用innerHTML代替DOM操作，減少DOM操作次數，優化javascript性能。
當需要設置的樣式很多時設置className而不是直接操作style。
少用全局變數、緩存DOM節點查找的結果。減少IO讀取操作。
避免使用CSS Expression（css表達式)又稱Dynamic properties(動態屬性)。
圖片預載入，將樣式表放在頂部，將腳本放在底部 加上時間戳。
解決辦法二：
減少HTTP請求次數
使用CDN：CDN在前端開發的作用
避免空的src和href
為文件頭指定Expires
使用gzip壓縮內容
把CSS放到頂部
把JS放到底部
避 免使用CSS表達式
將CSS和JS放到外部文件中
避免跳轉
可緩存的AJAX
使用GET來完成AJAX請求
❸ 如何進行前端優化
1.減少 HTTP 請求....
2.使用 HTTP2
3.使用服務端渲染
4.靜態資源使用 CDN
5.將 CSS 放在文件頭部，JavaScript 文件放 ...
6.使用字體圖標 iconfont 代替圖片圖標
7.善用緩存，不重復載入相同的資源
8.壓縮文件
9.圖片優化
(1).圖片延遲載入
(2). 響應式圖片
(3). 調整圖片大小
(4). 降低圖片質量
(5). 盡可能利用 CSS3 效果代替圖片
(6). 使用 webp 格式的圖片
10. 通過 webpack 按需載入代碼，提取第三庫代碼，減少 ES6 轉為 ES5 的冗餘代碼
11. 減少重繪重排
12. 使用事件委託
13. 注意程序的局部性
14. if-else 對比 switch
15. 查找表
16. 避免頁面卡頓
17. 使用 requestAnimationFrame 來實現視覺變化
18. 使用 Web Workers
19. 使用位操作
20. 不要覆蓋原生方法
21. 降低 CSS 選擇器的復雜性
(1). 瀏覽器讀取選擇器，遵循的原則是從選擇器的右邊到左邊讀取。
(2). CSS 選擇器優先順序
22. 使用 flexbox 而不是較早的布局模型
23. 使用 transform 和 opacity 屬性更改來實現動畫
24. 合理使用規則，避免過度優化
性能優化主要分為兩類：
載入時優化
運行時優化
❹ 常見的前端性能優化手段都有哪些都有多大收益
前端是龐大的，包括 HTML、 CSS、 Javascript、Image 、Flash等等各種各樣的資源。前端優化是復雜的，針對方方面面的資源都有不同的方式。那麼，前端優化的目的是什麼 ?
1. 從用戶角度而言，優化能夠讓頁面載入得更快、對用戶的操作響應得更及時，能夠給用戶提供更為友好的體驗。
2. 從服務商角度而言，優化能夠減少頁面請求數、或者減小請求所佔帶寬，能夠節省可觀的資源。
總之，恰當的優化不僅能夠改善站點的用戶體驗並且能夠節省相當的資源利用。
前端優化的途徑有很多，按粒度大致可以分為兩類，第一類是頁面級別的優化，例如 HTTP請求數、腳本的無阻塞載入、內聯腳本的位置優化等 ;第二類則是代碼級別的優化，例如 Javascript中的DOM 操作優化、CSS選擇符優化、圖片優化以及 HTML結構優化等等。另外，本著提高投入產出比的目的，後文提到的各種優化策略大致按照投入產出比從大到小的順序排列。
一、頁面級優化
1. 減少 HTTP請求數
這條策略基本上所有前端人都知道，而且也是最重要最有效的。都說要減少 HTTP請求，那請求多了到底會怎麼樣呢 ?首先，每個請求都是有成本的，既包含時間成本也包含資源成本。一個完整的請求都需要經過 DNS定址、與伺服器建立連接、發送數據、等待伺服器響應、接收數據這樣一個 「漫長」 而復雜的過程。時間成本就是用戶需要看到或者 「感受」 到這個資源是必須要等待這個過程結束的，資源上由於每個請求都需要攜帶數據，因此每個請求都需要佔用帶寬。另外，由於瀏覽器進行並發請求的請求數是有上限的 (具體參見此處 )，因此請求數多了以後，瀏覽器需要分批進行請求，因此會增加用戶的等待時間，會給用戶造成站點速度慢這樣一個印象，即使可能用戶能看到的第一屏的資源都已經請求完了，但是瀏覽器的進度條會一直存在。
減少 HTTP請求數的主要途徑包括：
(1). 從設計實現層面簡化頁面
如果你的頁面像網路首頁一樣簡單，那麼接下來的規則基本上都用不著了。保持頁面簡潔、減少資源的使用時最直接的。如果不是這樣，你的頁面需要華麗的皮膚，則繼續閱讀下面的內容。
(2). 合理設置 HTTP緩存
緩存的力量是強大的，恰當的緩存設置可以大大的減少 HTTP請求。以有啊首頁為例，當瀏覽器沒有緩存的時候訪問一共會發出 78個請求，共 600多 K數據 (如圖 1.1)，而當第二次訪問即瀏覽器已緩存之後訪問則僅有 10個請求，共 20多 K數據 (如圖 1.2)。 (這里需要說明的是，如果直接 F5刷新頁面的話效果是不一樣的，這種情況下請求數還是一樣，不過被緩存資源的請求伺服器是 304響應，只有 Header沒有Body ，可以節省帶寬 )
怎樣才算合理設置 ?原則很簡單，能緩存越多越好，能緩存越久越好。例如，很少變化的圖片資源可以直接通過 HTTP Header中的Expires設置一個很長的過期頭 ;變化不頻繁而又可能會變的資源可以使用 Last-Modifed來做請求驗證。盡可能的讓資源能夠在緩存中待得更久。關於 HTTP緩存的具體設置和原理此處就不再詳述了，有興趣的可以參考下列文章：
HTTP1.1協議中關於緩存策略的描述
Fiddler HTTP Performance中關於緩存的介紹
(3). 資源合並與壓縮
如果可以的話，盡可能的將外部的腳本、樣式進行合並，多個合為一個。另外， CSS、 Javascript、Image 都可以用相應的工具進行壓縮，壓縮後往往能省下不少空間。
(4). CSS Sprites
合並 CSS圖片，減少請求數的又一個好辦法。
(5). Inline Images
使用 data: URL scheme的方式將圖片嵌入到頁面或 CSS中，如果不考慮資源管理上的問題的話，不失為一個好辦法。如果是嵌入頁面的話換來的是增大了頁面的體積，而且無法利用瀏覽器緩存。使用在 CSS中的圖片則更為理想一些。
(6). Lazy Load Images（自己對這一塊的內容還是不了解）
這條策略實際上並不一定能減少 HTTP請求數，但是卻能在某些條件下或者頁面剛載入時減少 HTTP請求數。對於圖片而言，在頁面剛載入的時候可以只載入第一屏，當用戶繼續往後滾屏的時候才載入後續的圖片。這樣一來，假如用戶只對第一屏的內容感興趣時，那剩餘的圖片請求就都節省了。 有啊首頁 曾經的做法是在載入的時候把第一屏之後的圖片地址緩存在 Textarea標簽中，待用戶往下滾屏的時候才 「惰性」 載入。
2. 將外部腳本置底（將腳本內容在頁面信息內容載入後再載入）
前文有談到，瀏覽器是可以並發請求的，這一特點使得其能夠更快的載入資源，然而外鏈腳本在載入時卻會阻塞其他資源，例如在腳本載入完成之前，它後面的圖片、樣式以及其他腳本都處於阻塞狀態，直到腳本載入完成後才會開始載入。如果將腳本放在比較靠前的位置，則會影響整個頁面的載入速度從而影響用戶體驗。解決這一問題的方法有很多，在 這里有比較詳細的介紹 (這里是譯文和 更詳細的例子 )，而最簡單可依賴的方法就是將腳本盡可能的往後挪，減少對並發下載的影響。
3. 非同步執行 inline腳本(其實原理和上面是一樣，保證腳本在頁面內容後面載入。)
inline腳本對性能的影響與外部腳本相比，是有過之而無不及。首頁，與外部腳本一樣， inline腳本在執行的時候一樣會阻塞並發請求，除此之外，由於瀏覽器在頁面處理方面是單線程的，當 inline腳本在頁面渲染之前執行時，頁面的渲染工作則會被推遲。簡而言之， inline腳本在執行的時候，頁面處於空白狀態。鑒於以上兩點原因，建議將執行時間較長的 inline腳本非同步執行，非同步的方式有很多種，例如使用 script元素的defer 屬性(存在兼容性問題和其他一些問題，例如不能使用 document.write)、使用setTimeout ，此外，在HTML5中引入了 Web Workers的機制，恰恰可以解決此類問題。
4. Lazy Load Javascript（只有在需要載入的時候載入，在一般情況下並不載入信息內容。）
隨著 Javascript框架的流行，越來越多的站點也使用起了框架。不過，一個框架往往包括了很多的功能實現，這些功能並不是每一個頁面都需要的，如果下載了不需要的腳本則算得上是一種資源浪費 -既浪費了帶寬又浪費了執行花費的時間。目前的做法大概有兩種，一種是為那些流量特別大的頁面專門定製一個專用的 mini版框架，另一種則是 Lazy Load。YUI 則使用了第二種方式，在 YUI的實現中，最初只載入核心模塊，其他模塊可以等到需要使用的時候才載入。
5. 將 CSS放在 HEAD中
如果將 CSS放在其他地方比如 BODY中，則瀏覽器有可能還未下載和解析到 CSS就已經開始渲染頁面了，這就導致頁面由無 CSS狀態跳轉到 CSS狀態，用戶體驗比較糟糕。除此之外，有些瀏覽器會在 CSS下載完成後才開始渲染頁面，如果 CSS放在靠下的位置則會導致瀏覽器將渲染時間推遲。
6. 非同步請求 Callback（就是將一些行為樣式提取出來，慢慢的載入信息的內容）
在某些頁面中可能存在這樣一種需求，需要使用 script標簽來非同步的請求數據。類似：
Javascript:
function myCallback(info){
//do something here
}
HTML:
cb返回的內容 :
myCallback('Hello world!');
像以上這種方式直接在頁面上寫 <script>對頁面的性能也是有影響的，即增加了頁面首次載入的負擔，推遲了 DOMLoaded和window.onload 事件的觸發時機。如果時效性允許的話，可以考慮在 DOMLoaded事件觸發的時候載入，或者使用 setTimeout方式來靈活的控制載入的時機。
7. 減少不必要的 HTTP跳轉
對於以目錄形式訪問的 HTTP鏈接，很多人都會忽略鏈接最後是否帶 』/'，假如你的伺服器對此是區別對待的話，那麼你也需要注意，這其中很可能隱藏了 301跳轉，增加了多餘請求。具體參見下圖，其中第一個鏈接是以無 』/'結尾的方式訪問的，於是伺服器有了一次跳轉。
8. 避免重復的資源請求
這種情況主要是由於疏忽或頁面由多個模塊拼接而成，然後每個模塊中請求了同樣的資源時，會導致資源的重復請求
二、代碼級優化
1. Javascript
(1). DOM
DOM操作應該是腳本中最耗性能的一類操作，例如增加、修改、刪除 DOM元素或者對 DOM集合進行操作。如果腳本中包含了大量的 DOM操作則需要注意以下幾點：
a. HTML Collection（HTML收集器，返回的是一個數組內容信息）
在腳本中 document.images、document.forms 、getElementsByTagName()返回的都是 HTMLCollection類型的集合，在平時使用的時候大多將它作為數組來使用，因為它有 length屬性，也可以使用索引訪問每一個元素。不過在訪問性能上則比數組要差很多，原因是這個集合並不是一個靜態的結果，它表示的僅僅是一個特定的查詢，每次訪問該集合時都會重新執行這個查詢從而更新查詢結果。所謂的 「訪問集合」 包括讀取集合的 length屬性、訪問集合中的元素。
因此，當你需要遍歷 HTML Collection的時候，盡量將它轉為數組後再訪問，以提高性能。即使不轉換為數組，也請盡可能少的訪問它，例如在遍歷的時候可以將 length屬性、成員保存到局部變數後再使用局部變數。
b. Reflow & Repaint
除了上面一點之外， DOM操作還需要考慮瀏覽器的 Reflow和Repaint ，因為這些都是需要消耗資源的，具體的可以參加以下文章：
如何減少瀏覽器的repaint和reflow?
Understanding Internet Explorer Rendering Behaviour
Notes on HTML Reflow
(2). 慎用 with
with(obj){ p = 1}; 代碼塊的行為實際上是修改了代碼塊中的 執行環境 ，將obj放在了其作用域鏈的最前端，在 with代碼塊中訪問非局部變數是都是先從 obj上開始查找，如果沒有再依次按作用域鏈向上查找，因此使用 with相當於增加了作用域鏈長度。而每次查找作用域鏈都是要消耗時間的，過長的作用域鏈會導致查找性能下降。
因此，除非你能肯定在 with代碼中只訪問 obj中的屬性，否則慎用 with，替代的可以使用局部變數緩存需要訪問的屬性。
(3). 避免使用 eval和 Function
每次 eval 或 Function 構造函數作用於字元串表示的源代碼時，腳本引擎都需要將源代碼轉換成可執行代碼。這是很消耗資源的操作 —— 通常比簡單的函數調用慢 100倍以上。
eval 函數效率特別低，由於事先無法知曉傳給 eval 的字元串中的內容，eval在其上下文中解釋要處理的代碼，也就是說編譯器無法優化上下文，因此只能有瀏覽器在運行時解釋代碼。這對性能影響很大。
Function 構造函數比 eval略好，因為使用此代碼不會影響周圍代碼 ;但其速度仍很慢。
此外，使用 eval和 Function也不利於Javascript 壓縮工具執行壓縮。
(4). 減少作用域鏈查找（這方面設計到一些內容的相關問題）
前文談到了作用域鏈查找問題，這一點在循環中是尤其需要注意的問題。如果在循環中需要訪問非本作用域下的變數時請在遍歷之前用局部變數緩存該變數，並在遍歷結束後再重寫那個變數，這一點對全局變數尤其重要，因為全局變數處於作用域鏈的最頂端，訪問時的查找次數是最多的。
低效率的寫法：
// 全局變數
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次全局變數
在函數中只需要將 globalVar中內容的值賦給localVar 中區
globalVar = localVar;
}
此外，要減少作用域鏈查找還應該減少閉包的使用。
(5). 數據訪問
Javascript中的數據訪問包括直接量 (字元串、正則表達式 )、變數、對象屬性以及數組，其中對直接量和局部變數的訪問是最快的，對對象屬性以及數組的訪問需要更大的開銷。當出現以下情況時，建議將數據放入局部變數：
a. 對任何對象屬性的訪問超過 1次
b. 對任何數組成員的訪問次數超過 1次
另外，還應當盡可能的減少對對象以及數組深度查找。
(6). 字元串拼接
在 Javascript中使用"+" 號來拼接字元串效率是比較低的，因為每次運行都會開辟新的內存並生成新的字元串變數，然後將拼接結果賦值給新變數。與之相比更為高效的做法是使用數組的 join方法，即將需要拼接的字元串放在數組中最後調用其 join方法得到結果。不過由於使用數組也有一定的開銷，因此當需要拼接的字元串較多的時候可以考慮用此方法。
關於 Javascript優化的更詳細介紹請參考：
Write Efficient Javascript(PPT)
Efficient JavaScript
2. CSS選擇符
在大多數人的觀念中，都覺得瀏覽器對 CSS選擇符的解析式從左往右進行的，例如
#toc A { color: #444; }
這樣一個選擇符，如果是從右往左解析則效率會很高，因為第一個 ID選擇基本上就把查找的范圍限定了，但實際上瀏覽器對選擇符的解析是從右往左進行的。如上面的選擇符，瀏覽器必須遍歷查找每一個 A標簽的祖先節點，效率並不像之前想像的那樣高。根據瀏覽器的這一行為特點，在寫選擇符的時候需要注意很多事項，有人已經一一列舉了， 詳情參考此處。
3. HTML
對 HTML本身的優化現如今也越來越多的受人關注了，詳情可以參見這篇 總結性文章 。
4. Image壓縮
圖片壓縮是個技術活，不過現如今這方面的工具也非常多，壓縮之後往往能帶來不錯的效果，具體的壓縮原理以及方法在《 Even Faster Web Sites》第10 章有很詳細的介紹，有興趣的可以去看看。
總結
本文從頁面級以及代碼級兩個粒度對前端優化的各種方式做了一個總結，這些方法基本上都是前端開發人員在開發的過程中可以借鑒和實踐的，除此之外，完整的前端優化還應該包括很多其他的途徑，例如 CDN、 Gzip、多域名、無 Cookie伺服器等等，由於對於開發人員的可操作性並不強大，在此也就不多敘述了，詳細的可以參考 Yahoo和Google 的這些「金科玉律。
❺ 前端如何做好網站性能優化
前端開發需要做的就是網站搭建。網站搭建有2個細節需要注意，一是排版，二是鏈接，排版是為了不讓出現亂碼而做細節優化，鏈接是為了優化網頁之間的關系，就好比城鎮建設，每一座城市都要搭建的好，城與城之間的交通也要完善，這樣才有利於城區發展，網站也是一樣，每個網頁的內容和網頁之間的鏈接做好，網站優化也就好做了。
❻ 前端性能優化什麼意思
如果前端優化得好，他不僅可以為企業節約成本，他還能給用戶帶來更多的用戶，因為增強的用戶體驗。說了這么多，那麼我們應該如何對我們前端的頁面進行性能優化呢？一般說來，web前端指網站業務邏輯之前的部分，包括瀏覽器載入、網站視圖模型、圖片服務、CDN服務等，主要優化手段有瀏覽器訪問、使用反向代理才、CDN等。
❼ 前端性能優化有哪些方法
圖片雪花、懶載入、減少iframe的使用、js文件盡量放到最後載入
❽ 簡單談談前端性能優化
這個話題，賊大。
個人認為：核心在於，HTTP 請求的減少和請求包大小的減少再加上對代碼的重構。
HTTP 請求的減少，瞧瞧現在的前端工程化，工程化的作用之一正是將那些散亂的 js 、css 庫全部都集成起來，壓縮成一個文件，這么多文件壓縮成一個，這請求不就減少了么~還有一個就是」精靈圖技術「也是優化的體現，就不展開了。
請求包大小的減少，這個簡直是能減就減啊，比如以前的時候，我們需要將圖片直接發送到瀏覽器上是吧，現在可以不用！如果只是發生一段代碼到客戶的瀏覽器上，然後客戶用自己的機器生成圖片，這得有多快啊，畢竟一段代碼大還是一張圖片大還是很容易分清的，特別的是 GIF 圖！這時候用上 svg 或是 canvas 技術，就不需要發送巨大的 GIF 圖片了，只需要調用瀏覽器的資源生成圖像即可。
重構，反正不滿意重構就是了，滿意了加功能然後繼續重構就是了。
但這都是還只是皮毛啊這是，如果用到框架，那還要講到框架的優化，因為前端框架的優化同樣是性能優化，那都能寫幾十頁了都......
如果再深入講到瀏覽器自身......啊，要死了死了，技術是無窮的，命是有限的！
❾ 如何對前端性能進行優化
前端開發代碼優化、可維護性、瀏覽器兼容性是非常重要的課題。從實際的工程應用角度出發，最常遇見的前端優化問題。前端性能進行優化規則，基本可以涵蓋現在前端大部分的性能優化原則了，很多更加geek和精細優化方法都是從這些原則裡面延伸出來的。
前端性能進行優化都有哪些規則
減少HTTP請求次數
盡量合並圖片、CSS、JS。比如載入一個頁面有5個css文件的話，把這個5個文件合成一個的話，就只需要發出一次http請求，節省網路請求時間，加快頁面的載入。
2. 使用CDN
網站上靜態資源即css、js全都使用cdn分發，包括圖片
3. 避免空的src和href
當link標簽的href屬性為空、script標簽的src屬性為空的時候，瀏覽器渲染的時候會把當前頁面的URL作為它們的屬性值，從而把頁面的內容載入進來作為它們的值。所以要避免犯這樣的疏忽。
4. 為文件頭指定Expires
Exipres是用來設置文件的過期時間的，一般對css、js、圖片資源有效。 他可以使內容具有緩存性，這樣下回再訪問同樣的資源時就通過瀏覽器緩存區讀取，不需要再發出http請求。如下例子：
新浪微博的這個css文件的Expires時間是2016-5-04 09:14:14.
5. 使用gzip壓縮內容
gzip能夠壓縮任何一個文本類型的響應，包括html，xml，json。大大縮小請求返回的數據量。
6. 把CSS放到頂部
網頁上的資源載入時從上網下順序載入的，所以css放在頁面的頂部能夠優先渲染頁面，讓用戶感覺頁面載入很快。
7. 把JS放到底部
載入js時會對後續的資源造成阻塞，必須得等js載入完才去載入後續的文件 ，所以就把js放在頁面底部最後載入。
8. 避免使用CSS表達式
舉個css表達式的例子
font-color: expression( (new Date()).getHours()%3 ? 「#FFFFFF" : 「#AAAAAA" );
這個表達式會持續的在頁面上計算樣式，影響頁面的性能。並且css表達式只被IE支持。
9. 將CSS和JS放到外部文件中
目的是緩存文件，可以參考原則4。 但有時候為了減少請求，也會直接寫到頁面里，需根據PV和IP的比例權衡。
10. 權衡DNS查找次數
減少主機名可以節省響應時間。但同時，需要注意，減少主機會減少頁面中並行下載的數量。
IE瀏覽器在同一時刻只能從同一域名下載兩個文件。當在一個頁面顯示多張圖片時，IE 用戶的圖片下載速度就會受到影響。所以新浪會搞N個二級域名來放圖片。
下面是新浪微博的圖片域名，我們可以看到他有多個域名，這樣可以保證這些不同域名能夠同時去下載圖片，而不用排隊。不過如果當使用的域名過多時，響應時間就會慢，因為不用響應域名時間不一致。
11. 精簡CSS和JS
這里就涉及到css和js的壓縮了。比如下面的新浪的一個css文件，把空格回車全部去掉，減少文件的大小。現在的壓縮工具有很多，基本主流的前端構建工具都能進行css和js文件的壓縮，如grunt，glup等。
12. 避免跳轉
有種現象會比較坑爹，看起來沒什麼差別，其實多次了一次頁面跳轉。比如當URL本該有斜杠（/）卻被忽略掉時。例如，當我們要訪問http:// .com時，實際上返回的是一個包含301代碼的跳轉，它指向的是http:// .com/（注意末尾的斜杠）。在nginx伺服器可以使用rewrite；Apache伺服器中可以使用Alias 或者 mod_rewrite或者the DirectorySlash來避免。
另一種是不用域名之間的跳轉， 比如訪問http:// .com/bbs跳轉到http:// bbs..com/。那麼可以通過使用Alias或者mod_rewirte建立CNAME（保存一個域名和另外一個域名之間關系的DNS記錄）來替代。
13. 刪除重復的JS和CSS
重復調用腳本，除了增加額外的HTTP請求外，多次運算也會浪費時間。在IE和Firefox中不管腳本是否可緩存，它們都存在重復運算JavaScript的問題。
14. 配置ETags
它用來判斷瀏覽器緩存里的元素是否和原來伺服器上的一致。比last-modified date更具有彈性，例如某個文件在1秒內修改了10次，Etag可以綜合Inode(文件的索引節點(inode)數)，MTime(修改時間)和Size來精準的進行判斷，避開UNIX記錄MTime只能精確到秒的問題。 伺服器集群使用，可取後兩個參數。使用ETags減少Web應用帶寬和負載
15. 可緩存的AJAX
非同步請求同樣的造成用戶等待，所以使用ajax請求時，要主動告訴瀏覽器如果該請求有緩存就去請求緩存內容。如下代碼片段, cache:true就是顯式的要求如果當前請求有緩存的話，直接使用緩存
$.ajax({ url : 'url', dataType : "json", cache: true, success : function(son, status){ }
16. 使用GET來完成AJAX請求
當使用XMLHttpRequest時，瀏覽器中的POST方法是一個「兩步走」的過程：首先發送文件頭，然後才發送數據。因此使用GET獲取數據時更加有意義。
17. 減少DOM元素數量
這是一門大學問，這里可以引申出一堆優化的細節。想要具體研究的可以看後面推薦書籍。總之大原則減少DOM數量，就會減少瀏覽器的解析負擔。
18. 避免404
比如外鏈的css、js文件出現問題返回404時，會破壞瀏覽器的並行載入。
19. 減少Cookie的大小
Cookie裡面別塞那麼多東西，因為每個請求都得帶著他跑。
20. 使用無cookie的域
比如CSS、js、圖片等，客戶端請求靜態文件的時候，減少了 Cookie 的反復傳輸對主域名的影響。
21. 不要使用濾鏡
IE獨有屬性AlphaImageLoader用於修正7.0以下版本中顯示PNG圖片的半透明效果。這個濾鏡的問題在於瀏覽器載入圖片時它會終止內容的呈現並且凍結瀏覽器。在每一個元素（不僅僅是圖片）它都會運算一次，增加了內存開支，因此它的問題是多方面的。
完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式來代替，這種格式能在IE中很好地工作。如果你確實需要使用AlphaImageLoader，請使用下劃線_filter又使之對IE7以上版本的用戶無效。
22. 不要在HTML中縮放圖片
比如你需要的圖片尺寸是50* 50
那就不用用一張500*500的大尺寸圖片，影響載入
23. 縮小favicon.ico並緩存