在構建高性能的網站或Web應用程序時，優(yōu)化前端資源的加載速度是至關重要的。一個有效的方法是利用HTTP緩存機制，通過緩存靜態(tài)資源來減少網絡請求，降低服務器負載，并提升用戶體驗。本文將介紹如何使用Nginx配置前端HTTP緩存，以加速網站的加載速度。

什么是HTTP緩存？

HTTP緩存是一種在客戶端（瀏覽器）和服務器之間緩存HTTP響應的機制。當瀏覽器首次請求一個資源時，服務器會返回響應，并在響應中包含緩存指令。這些緩存指令告訴瀏覽器如何處理該資源以及何時再次請求該資源。

Nginx緩存基礎

在Nginx中，緩存是通過proxy_cache_path和proxy_cache指令來配置的。proxy_cache_path定義了緩存的存儲路徑和相關參數，而proxy_cache指令則用于指定哪些請求應該被緩存。

Nginx中的緩存機制

Nginx提供了兩種主要的緩存機制：代理緩存和瀏覽器緩存。代理緩存是指Nginx作為代理服務器，將請求的響應存儲在自身的緩存中，當再次收到相同請求時，可以直接從緩存中提供響應。而瀏覽器緩存則是通過設置HTTP響應頭來指示瀏覽器存儲資源副本。

配置Nginx實現前端HTTP緩存

server {
  # 其他配置項...

  location ~* .(html)$ {
    access_log off;
    add_header  Cache-Control  max-age=no-cache;
  }

  location ~* .(css|js|png|jpg|jpeg|gif|gz|svg|mp4|ogg|ogv|webm|htc|xml|woff)$ {
    access_log off;
    add_header    Cache-Control  max-age=360000;
  }

  # 其他資源類型的配置...
}

在上述配置中，我們使用location指令結合正則表達式匹配不同類型的資源。對于以.html結尾的資源，我們設置了Cache-Control頭部為max-age=no-cache，這告訴瀏覽器不要緩存該資源。而對于以.css、.js、.png等結尾的資源，我們設置了Cache-Control頭部為max-age=360000，這表示瀏覽器可以緩存該資源，并在360000秒（約為100小時）后再次請求。
通過這樣的配置，可以根據不同的資源類型靈活地控制緩存策略，以滿足網站的需求。
下面對Cache-Control中的這兩個參數進行分析一下：

add_header Cache-Control max-age=no-cache; 的含義：html文件不設置強制緩存時間，協商緩存，使用 Last-Modified。no-cache 會發(fā)起往返通信來驗證緩存的響應，但如果資源未發(fā)生變化，則不會下載，返回304。

add_header Cache-Control max-age=360000; 的含義給上面匹配后綴的文件設置強制緩存，且緩存的時間是360000秒，第一次訪問的時候，從服務器請求，當除了第一次以外，再次刷新瀏覽器，會從瀏覽器緩存讀取，那么強制緩存一般是從內存里面先讀取，如果內存沒有，再從硬盤讀取。

緩存時間的選擇

緩存時間的選擇取決于資源的更新頻率。對于不經常變動的資源，如庫文件或圖標，可以設置較長的緩存時間。而對于經常更新的資源，如HTML頁面，可能需要設置較短的緩存時間或不緩存。
瀏覽器中關于Cache的3屬性:

1. Cache-Control:

設置相對過期時間, max-age指明以秒為單位的緩存時間. 若對靜態(tài)資源只緩存一次, 可以設置max-age的值為315360000000 (一萬年). 比如對于提交的訂單，為了防止瀏覽器回退重新提交，可以使用Cache-Control之no-store絕對禁止緩存，即便瀏覽器回退依然請求的是服務器，進而判斷訂單的狀態(tài)給出相應的提示信息！

Http協議的cache-control的常見取值及其組合釋義:
no-cache: 數據內容不能被緩存, 每次請求都重新訪問服務器, 若有max-age, 則緩存期間不訪問服務器.
no-store: 不僅不能緩存, 連暫存也不可以(即: 臨時文件夾中不能暫存該資源).
private(默認): 只能在瀏覽器中緩存, 只有在第一次請求的時候才訪問服務器, 若有max-age, 則緩存期間不訪問服務器.
public: 可以被任何緩存區(qū)緩存, 如: 瀏覽器、服務器、代理服務器等.
max-age: 相對過期時間, 即以秒為單位的緩存時間.
no-cache, private: 打開新窗口時候重新訪問服務器, 若設置max-age, 則緩存期間不訪問服務器.
-  private, 正數的max-age: 后退時候不會訪問服務器.
-  no-cache, 正數的max-age: 后退時會訪問服務器.

2. Expires:

設置以分鐘為單位的絕對過期時間, 優(yōu)先級比Cache-Control低, 同時設置Expires和Cache-Control則后者生效. 也就是說要注意一點: Cache-Control的優(yōu)先級高于Expires
expires起到控制頁面緩存的作用，合理配置expires可以減少很多服務器的請求, expires的配置可以在http段中或者server段中或者location段中. 比如控制圖片等過期時間為30天, 可以配置如下:

location ~ .(gif|jpg|jpeg|png|bmp|ico)$ {
    root /var/www/img/`;`
    expires 30d;
}
再比如:
location ~ .(wma|wmv|asf|mp3|mmf|zip|rar|swf|flv)$ {
    root /var/www/upload/`;`
    expires max;
}

3. Last-Modified:

該資源的最后修改時間, 在瀏覽器下一次請求資源時, 瀏覽器將先發(fā)送一個請求到服務器上, 并附上If-Unmodified-Since頭來說明瀏覽器所緩存資源的最后修改時間, 如果服務器發(fā)現沒有修改, 則直接返回304(Not Modified)回應信息給瀏覽器(內容很少), 如果服務器對比時間發(fā)現修改了, 則照常返回所請求的資源.
需要注意:

• Last-Modified屬性通常和Expires或Cache-Control屬性配合使用, 因為即使瀏覽器設置緩存, 當用戶點擊”刷新”按鈕時, 瀏覽器會忽略緩存繼續(xù)向服務器發(fā)送請求, 這時Last-Modified將能夠很好的減小回應開銷.
• ETag將返回給瀏覽器一個資源ID, 如果有了新版本則正常發(fā)送并附上新ID, 否則返回304， 但是在服務器集群情況下, 每個服務器將返回不同的ID, 因此不建議使用ETag.
  以上描述的客戶端瀏覽器緩存是指存儲位置在客戶端瀏覽器, 但是對客戶端瀏覽器緩存的實際設置工作是在服務器上的資源中完成的. 雖然上面介紹了有關于客戶端瀏覽器緩存的屬性, 但是實際上對這些屬性的設置工作都需要在服務器的資源中做設置. 通常有兩種操作手段對瀏覽器緩存進行設置, 一個是通過頁面指令聲明來設置, 另外一個是通過編程方式來設置.
  下面是相關頁面設置Cache-Control頭信息的幾個簡單配置:
  例一:

if ($request_uri ~* "^/$|^/search/.+/|^/company/.+/"`) {`
    add_header    Cache-Control  max-age=3600;
}

個人理解的max-age意思是：客戶端本地的緩存，在配置的生存時間內的，客戶端可以直接使用，超出生存時間的，到服務器上取新數據。當然這些還要看客戶端瀏覽器的設置。
例二:

location ~ .*.(css|js|swf|php|htm|html )$ {
    add_header Cache-Control no-store;
}

例三:

location ~ .*.(js|css)$ {
    expires 10d;
}

例四: 將html結尾的請求加上no-cache

location / {
    access_log /data/nginx/log/xxx`.log api;`
    root /home/www/html`;`
    if ($request_filename ~ .*.(htm|html)$)
{
    add_header Cache-Control no-cache;
    }
}

注意事項

確保緩存策略不適用于所有資源。例如，對于用戶個人信息或動態(tài)內容，應該始終設置為不緩存。
使用ETag或Last-Modified頭部可以進一步提高緩存效率，這些頭部可以幫助瀏覽器識別資源的更新情況。

結論

通過合理配置Nginx的客戶端緩存策略，我們可以有效地提升前端資源的加載速度，減少服務器負載，從而提升整個Web應用的性能，可以顯著提高Web應用的性能和用戶體驗。在配置緩存時，我們需要根據資源的更新頻率和重要性來調整緩存時間，確保用戶總是獲取到最新的內容，同時減少不必要的服務器請求。通過細致的配置和優(yōu)化，Nginx可以成為提升Web應用性能的強大工具。

到此這篇關于Ningx配置前端http緩存的實現的文章就介紹到這了,更多相關Ningx配置http緩存內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論