PWA專題：第二章 服務器離線緩存技術

最新的 Google Android 用戶行爲分析中，獲得如下幾個數據

• – 若是站點加載時間超過3s，53%的用戶會放棄等待
• – 頁面加載後，用戶指望的平滑的體驗，過渡動畫和快速響應，並不喜歡不斷的頁面跳轉
• – 84%的移動端瀏覽器已經支持PWA
• – 50%的用戶啓用了通知服務

PWA（Progressive Web App）給用戶原生APP的體驗，其實不難發現PWA核心就是創建在離線緩存和後臺數據交互基礎上構建的嶄新的Web app，使其具有了Native App的部分特性。那麼從緩存開始咱們一步步在技術上組裝PWA服務。爲了使本篇教程更多的朋友能舉一反三，咱們技術棧儘可能從淺入深。

前端工程化的發展，意味着產品的重點從原來的功能體驗，愈來愈升級到用戶體驗。從早期的代碼壓縮，到減小http請求，異步加載，經過CDN的內容分發，緩存等技術的綜合應用，從幾十秒到幾十毫秒的優化而費盡心思。這些應用體驗只是爲了「秒開」頁面。

爲了達到秒開的效果，必然要在客戶端作持久的離線緩存，HTML5的離線緩存就是最主要的特性之一，2014年W3C就開始提倡ServiceWorker，爲了更好的理解ServiceWorker咱們就要從離線緩存控制環節一步步揭開它的面紗，先讓咱們回顧一下HTML5控制離線緩存的各類方式吧。

隨着HTTP1.1的協議最先使用的緩存機制，經過HTTP頭來控制用戶代理（瀏覽器）是否把頭對應的文件進行緩存，緩存多長時間。經過HTTP RESPONSE HEADERS屬性來控制頁面加載的元素緩存。

Cache-Control 服務端緩存控制來控制元素的加載

課程中咱們使用Chrome瀏覽器，

1. 打開 [baidu.com](https://baidu.com)

2. 打開開發者工具 Ctrl+Shift+i

3. 點擊頂部NetWork

4. 選擇下面的加載列表

能夠看到頁面加載的全部URI資源的屬性，固然咱們如今更關注的是緩存，那麼請注意右側的Cache-Control的屬性：

Cache-Control 屬性告訴用戶代理緩存機制是否能夠緩存及哪一種類型。他包含如下值：

– public 全部內容都將被緩存(客戶端和代理服務器均可緩存)

– private 內容只緩存到私有緩存中(僅客戶端能夠緩存，瀏覽器不可緩存)

– no-cache 不緩存

– no-store 全部內容都不會被緩存

– must-revalidation/proxy-revalidation 若是緩存的內容失效，請求必須發送到服務器/代理以進行從新驗證

– max-age=xxx (xxx is numeric) 緩存的內容將在 xxx 秒後失效

1. `Cache-Control:max-age=315160000 //10年後過時`

咱們能夠發現百度首頁把經常使用的資源，都進行了緩存，咱們經過選擇左側的屬性列表也能夠看到幾個不緩存的案例。固然Cache-Control屬性不止這些，推薦你們閱讀如下文檔更多的理解Cache-Control

一、百度百科：[https://baike.baidu.com/item/Cache-control/1885913?fr=aladdin](https://baike.baidu.com/item/Cache-control/1885913?fr=aladdin)
二、MDN: [https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Cache-Control](https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Cache-Control)

擴展

1. `strict-transport-security: max-age=31536000`

咱們若是查看Google或者Facebook等國外站點不難發現headers頭部沒有cache-control屬性，而變成了strict-transport-security。其實這也是緩存的一種機制，更有利https緩存介入，國內從去年剛剛纔大量普及https，可是用戶習慣輸入http，服務器通常直接作了強制跳轉https資源，這樣存在中間人攻擊潛在威脅，跳轉過程可能被惡意網站利用來直接接觸用戶信息，而不是原來的加密信息。網站經過HTTP Strict Transport Security通知瀏覽器，這個資源禁止使用HTTP方式加載，瀏覽器應該自動把全部嘗試使用HTTP的請求自動替換爲HTTPS請求。

爲了更好的兼容性考慮，如建議使用：

1. `cache-control: public, max-age=31536000`

固然在常常修改的內容上咱們也能夠加入這樣的方式進行緩存

1. Cache-Control: must-revalidate, max-age=60
2. //一分鐘內不須要從新認證，超過一分鐘就須要從新認證

但使用這種方式必定要注意，緩存時間是服務器時間，並非用戶代理（瀏覽器）時間。因此若是多個資源都使用了從新加載，咱們沒法保證在同一時間某個資源是沒有被加載的。多個資源間不匹配。頁面崩塌。固然咱們繼續學習下去，後續咱們學習serviceWorker就能夠杜絕這個問題出現。

當下多數公司網站的圖片,js,css等文件的緩存會選擇Nginx的web緩存服務。Nginx的Web緩存服務主要由proxy_cache相關指令集和fastcgi_cache相關指令集構成。
1. proxy_cache相關指令集用於反向代理時,對後端內容源服務器進行緩存.Nginx的proxy_cache緩存功能,十分穩定。
2. fastcgi相關指令集主要用於對FastCGI的動態程序進行緩存.二者功能基本同樣.

proxy_cache相關指令集

1. proxy_cache

1. proxy_cache zone_name
2. # 從一個指定的地址獲取內容，而後緩存。當下次訪問時，nginx會自動判斷有沒有緩存文件？若是有的話緩存文件是否是已通過期.

2. proxy_cache_path

1. proxy_cache_path /www/nginx/proxy_cache levels=1:2 keys_zone=cache_one:500m inactive=1d max_size=10g ;
2. # path 表示存放目錄
3. # levels 表示指定該緩存空間有兩層hash目錄,第一層目錄爲1個字母,第二層目錄爲2個字母,
4. # 保存的文件名會相似/www/nginx/proxy_cache/a/11/**** ;
5. # keys_zone參數用來爲這個緩存區起名.
6. # 500m 指內存緩存空間大小爲 500MB
7. # inactive的1d指若是緩存數據在1天內沒有被訪問(支持單位m/y/d/w)將被刪除。至關於expires過時時間的配置；
8. # max_size的10g是指硬盤緩存空間爲10G

3. proxy_cache_methods

1. proxy_cache_methods GET POST HEAD DELETE;
2. # 用於設置緩存哪些HTTP方法,默認緩存HTTP GET/HEAD方法,不緩存HTTP POST 方法,經過設置名稱緩存不一樣方法

4. proxy_cache_min_uses

1. proxy_cache_min_uses 1000
2. # 設置緩存的最小使用次數,默認值爲1

5. proxy_cache_valid

1. proxy_cache_valid 200 302 10m ;
2. proxy_cache_valid 404 1m ;
3. 設置200,302狀態的URL緩存10分鐘,404狀態的URL緩存1分鐘.

6. proxy_cache_key

1. proxy_cache_key $uri ;
2. 定義緩存惟一key,經過惟一key來進行HASH存取

固然咱們最後一個問題，這個Headers是怎麼配置的，若是你是前端工程師，你必定會選用Nginx+node的反向代理和負載均衡的方式處理你的業務。一個簡單KOA2的header的配置吧，只須要set一下就ok了，你能夠經過nginx的反向代理控制服務器緩存。甚至咱們會把須要緩存的資源獨立一個Koa進行處理，這樣能發揮更多CDN的能力。

1. const Koa = require('koa');
2. const app = new Koa();
3.  
4. app.use(async ctx => {
5. ctx.set('Cache-Control', "public, max-age=31536000")
6. ctx.response.type = "text"
7. ctx.response.body = "Hello World"
8. });
9.  
10. app.listen(3000);

轉載: https://wosclass.com/2019/03/07/%E7%AC%AC%E4%BA%8C%E7%AB%A0-%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%A6%BB%E7%BA%BF%E7%BC%93%E5%AD%98%E6%8A%80%E6%9C%AF/