- 減少http請求數、壓縮js，css等文件
Webpack使用
- 使用CDN
內容分發網絡（Content Delivery Network，CDN）是建立並覆蓋在承載網上，由不同區域的服務器組成的分佈式網絡。將源站資源緩存到全國各地的邊緣服務器，供用戶就近獲取，降低源站壓力，提高web端響應性能。
具體的過程如下圖，下面是阿里雲CDN的工作原理圖，DNS調度系統是阿里雲部署解析IP。
從而，就近獲取訪問網頁的內容，降低源服務器的壓力，也提高了頁面響應速度
- 瀏覽器緩存
瀏覽器緩存是將網頁資源緩存到內存中，訪問資源時直接從內存中讀取而不是從服務端獲取。瀏覽器分爲強緩存和協商緩存。
這裏，我們必須知道的是HttpStatus 200（From Cache）和 304（Not Modified）背後是什麼一種工作模式？
1、首先我先了解一下，瀏覽器在“刷新”下的處理模式：
1）URL回車或者鏈接訪問URL，瀏覽器獲取資源的時候不會設置 Cache-Control:max-age=0，所以如果expire設置的max-age如果仍有效的話會優先從本地cache中獲取。
2）刷新或者強制刷新（mac下的Command+R，win下的F5，Ctrl+F5等），發起Request的時候瀏覽器給 header 裏設置的 Cache-Control:max-age=0，我們都知道一旦max-age爲0，則不會從本地cache獲取數據了，所以會發起一次http請求，服務器根據header裏傳來的If-Modified-Since或者If-None-Match分別與Last-Modified，Etag做對比，從而做出返回304還是200的選擇，而強制刷新是將 header 設置爲 Cache-Control:no-cache，直接返回200，下載資源.
所以我們就知道瀏覽器的一個請求過程了，首先會先根據緩存字段決定讀取緩存還是去請求服務器。
2、強緩存，強緩存不會向服務器發送請求，直接從緩存中讀取資源，在chrome控制檯的Network選項中可以看到該請求返回200的狀態碼，並且Size顯示from disk cache或from memory cache。如下圖所示，強緩存可以通過設置兩種 HTTP Header 實現：Expires 和 Cache-Control
- cache和Expires
cache是http1.1版本的，Expires是http1.0版本的，Expires在使用過程中有某些缺點：
a、指定的時間是以服務端爲準但是客戶端進行過期判斷時是將本地的時間和這個時間進行對比
b、如果客戶端端時間和服務端時間存在差異，則會存在問題
爲了解決 Expires 的缺點，HTTP 1.1 增加了新的 header 字段 Cache-control 來更精準的控制緩存常用的 Cache-control 信息
（2）cache字段解析
public：所有內容都將被緩存（客戶端和代理服務器都可緩存）。具體來說響應可被任何中間節點緩存。
private：所有內容只有客戶端可以緩存，Cache-Control的默認取值。
no-cache：客戶端緩存內容，是否使用緩存則需要經過協商緩存來驗證決定。表示不使用 Cache-Control的緩存控制方式做前置驗證，而是使用 Etag 或者Last-Modified字段來控制緩存。
no-store：所有內容都不會被緩存，即不使用強制緩存，也不使用協商緩存
max-age：max-age=xxx (xxx is numeric)表示緩存內容將在xxx秒後失效
s-maxage（單位爲s)：同max-age作用一樣，只在代理服務器中生效（比如CDN緩存）。比如當s-maxage=60時，在這60秒中，即使更新了CDN的內容，瀏覽器也不會進行請求。max-age用於普通緩存，而s-maxage用於代理緩存。s-maxage的優先級高於max-age。如果存在s-maxage，則會覆蓋掉max-age和Expires header。
max-stale：能容忍的最大過期時間。max-stale指令標示了客戶端願意接收一個已經過期了的響應。如果指定了max-stale的值，則最大容忍時間爲對應的秒數。如果沒有指定，那麼說明瀏覽器願意接收任何age的響應（age表示響應由源站生成或確認的時間與當前時間的差值）。
min-fresh：能夠容忍的最小新鮮度。min-fresh標示了客戶端不願意接受新鮮度不多於當前的age加上min-fresh設定的時間之和的響應。
3、協商緩存，就是在強緩存失效的情況下進行協商緩存判定
瀏覽器請求服務器，服務器響應瀏覽器，並在響應頭裏面加入ETag和Last-modified，瀏覽器再次發出請求時，會把相應的ETag和Last-modified的值寫入請求頭裏的If-Modified-Since和If-None-Match裏，然後在服務器對比結果，ETag是Last-modified的升級，因爲Last-modified可能存在毫秒的誤差，不可感知的時間內修改完成文件。
既然根據文件修改時間來決定是否緩存尚有不足，能否可以直接根據文件內容是否修改來決定緩存策略？所以在 HTTP / 1.1 出現了 ETag 和If-None-Match
- Last-Modified和If-Modified-Since
- ETag和If-None-Match
1）、2）對比，首先在精確度上，Etag要優於Last-Modified。
Last-Modified的時間單位是秒，如果某個文件在1秒內改變了多次，那麼他們的Last-Modified其實並沒有體現出來修改，但是Etag每次都會改變確保了精度；如果是負載均衡的服務器，各個服務器生成的Last-Modified也有可能不一致。
第二在性能上，Etag要遜於Last-Modified，畢竟Last-Modified只需要記錄時間，而Etag需要服務器通過算法來計算出一個hash值。
第三在優先級上，服務器校驗優先考慮Etag