Warning: error_log(/data/www/wwwroot/hmttv.cn/caches/error_log.php): failed to open stream: Permission denied in /data/www/wwwroot/hmttv.cn/phpcms/libs/functions/global.func.php on line 537 Warning: error_log(/data/www/wwwroot/hmttv.cn/caches/error_log.php): failed to open stream: Permission denied in /data/www/wwwroot/hmttv.cn/phpcms/libs/functions/global.func.php on line 537
對于緩存我們都已經很熟悉了,緩存分為很多種,瀏覽器緩存、試圖緩存、服務器緩存、數據庫緩存等等一些,那今天我們先介紹一下視圖緩存和MemoryCache內存緩存的概念和用法:
在老的版本的MVC里面,有一種可以緩存視圖的特性(OutputCache),可以保持同一個參數的請求,在N段時間內,直接從mvc的緩存中讀取,不去走視圖的邏輯。
在Asp.Net core 2.1中,官方文檔上稱:響應緩存可減少客戶端或代理對 web 服務器的請求數。 響應緩存還可減少量工作的 web 服務器執行程序生成響應。 響應緩存由標頭,指定你希望客戶端、 代理和緩存響應的中間件如何控制。
在Asp.Net Core 2.1 中,沒有了OutputCache,換成了ResponseCache,ResponseCache必須帶一個參數:Duration 單位為秒,最少設置一秒鐘
然后再瀏覽器請求這個視圖
在瀏覽器的響應頭的Cache-Control 中出現max-age=5, Http協議對此的解釋是
客戶端將不會接受其保留時間大于指定的秒數的響應。 示例: max-age=60 (60 秒), max-age=2592000 (1 個月)
如果在瀏覽器中禁用緩存,那么ResponseCache不會有任何效果
Vary過濾
關于vary在Http響應頭的作用就是:告訴緩存服務器或者CDN,我還是同一個瀏覽器的請求,你給我緩存就行了,如果你換個瀏覽器去請求,那么vary的值肯定為空,那么緩存服務器就會認為你是一個新的請求,就會去讀取最新的數據給瀏覽器
參考資料:http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
在Http中 :no-store,請求和響應的信息都不應該被存儲在對方的磁盤系統中
ResponseCacheLocation.None是在Cache-Control設置一個no-cache屬性,讓瀏覽器不緩存當前這個URL
緩存配置(CacheProfiles)
在一個正常的項目中,肯定有很多個控制器,但是不可能每個控制器的緩存策略都一樣,這時候,我們就需要一個緩存的配置來靈活應對這個問題
在mvc的服務注入的時候,我們可以在option里面注入進我們的緩存策略
然后我們在使用的時候,直接使用配置策略的名稱就好了
這樣我們就能和之前在特性后邊配置一樣了,這是視圖緩存,下面我們就來看看MemoryCache 是個什么東東
如果回到老版本的.NET,說到內存緩存大家可能立馬想到了HttpRuntime.Cache,它位于System.Web命名空間下,但是在ASP.NET Core中System.Web已經不復存在。今兒個就簡單的聊聊如何在ASP.NET Core中使用內存緩存
有幾個問題我們需要先進行了解:
1.什么時候需要用到緩存?
一般將經常訪問但是又不是經常改變的數據放進緩存是再好不過了,這樣可以明顯提高應用程序的性能。
2.緩存的好處?
建議百度
不同于 ASP.NET Web 窗體和 ASP.NET MVC,ASP.NET Core 沒有內置的 Cache 對象,可以拿來在控制器里面直接使用。 這里,內存緩存時通過依賴注入來啟用的,因此第一步就是在 Startup 類中注冊內存緩存的服務。如此,就得打開 Startup 類然后定位到 ConfigureServices() 方法,像下面這樣修改 ConfigureServices() 方法:
①首先需要在ConfigureServices中注冊緩存服務
services.AddMemoryCache()
為了向你的應用程序加入內存緩存能力,你需要在服務集合上調用 AddMemoryCache() 方法。采用這種辦法就可以讓一個內存緩存(它是一個 IMemoryCache 對象)的默認實現可以被注入到控制器中去。
②在下面的代碼中從Home控制器的構造函中獲取IMemoryCache實例(內存緩存使用依賴注入來注入緩存對象)
如你所見,上述代碼聲明了一個 ImemoryCache 的私有變量。該變量會被構造器中被賦值。構造器會通過 DI(依賴注入)接收到緩存參數,然后被存儲在本地變量總,提供后續使用。
③關于緩存的使用常用的就是Set Get Remove,一般有以下幾種做法可以參考:
⑴可以使用 Set() 方法來在緩存中存東西
等你有了這個 IMemoryCache 對象,就可以讀取或者向它寫入數據了。向緩存寫入數據項是相當直接的
上述代碼在 Index() 這個 action 中設置了一個緩存項。這是通過使用 IMemoryCache 的 Set<T>() 來完成的。Set() 方法的第一個參數是鍵名,用來標識該數據項。第二個參數是鍵的取值。在此例中,我們存儲一個字符串的鍵和一個字符串的值,而你也可以存儲其它類型 (原生以及自定義的類型) 的鍵值對。
⑵可以使用 Get 方法來從緩存中獲取到一個數據項
等你向緩存中添加好了數據,也許會想要在應用程序的其它地方去獲取到該數據,可以用 Get() 來做到。如下代碼會告訴你如何來做這件事情。
上述代碼從 HomeController 的另外一個action(Show)那里獲取到了一個緩存的數據項。Get() 方法會指定數據項的類型以及它的鍵名。如果該數據項存在的話,就會被返回并且被賦值給 timestamp 這個字符串變量。然后這個 timestamp 的值就會被傳遞給 Show 視圖。
Show 視圖只是簡單地輸出了 timestamp 的值,如下所示:
如果你觀察前面的示例,會發現每次你導航至 /Home/Index 的時候, 都會有一個新的 timestamp 被賦值給了緩存項。這是因為我們并沒有對此進行檢查,規定只有在數據項不存在的時候才賦值。許多時候你都會想要這樣做的。這里有兩種辦法可以在 Index() 這個 action 里面來做這樣的檢查。我們把兩種辦法都在下面列了出來
可以使用 TryGet() 來檢查緩存中是否存在特定的鍵值
第一種辦法使用了你早先用過的同一個 Get() 方法,這一次它被拿來跟 if 塊一起用。如果 Get() 不能在緩存中找到指定的數據項,IsNullOrEmpty() 就會返回 true。而只有這時候 Set() 才會被調用,一次來添加數據項。
第二種辦法更加優雅一點。它使用 TryGet() 方法來獲取一個數據項。TryGet() 方法會返回一個布爾值來指明數據項有沒有被找到。實際的數據項可以使用一個輸出參數拉取出來。如果 TryGet() 返回false,Set() 就會被用來添加數據。
如果不存在的話,可以使用 GetOrCreate() 來添加一項
有時你需要從緩存中檢索現有項。如果該項目不存在,則希望添加該項。這兩個任務 - 如果它存在獲取值,否則創建之 - 可以使用 GetOrCreate() 方法來實現。修改后的 Show() 方法展示了如何實現的
Show() 動作現在使用 GetOrCreate() 方法。 GetOrCreate() 方法將檢查時間戳的鍵值是否存在。如果是,現有值將被賦值給局部變量。否則,將根據第二個參數中指定的邏輯創建一個新條目并將其添加到緩存中。
在緩存的數據項上面設置絕對和滾動的過期時間
一個緩存項只要被添加到緩存就會一直存儲,除非它被明確地使用 Remove() 從緩存中移除。你也可以在一個緩存項上面設置一個絕對和滾動的過期時間。一個絕對的過期設置意味著該緩存項會在嚴格指定的日期和時間點被移除,而滾動過期設置則意味著它在給定的一段時間量處于空閑狀態(也就是沒人去訪問)之后被移除。
為了能在一個緩存項上面設置這兩種過期策略,你要用到 MemoryCacheEntryOptions 對象。如下代碼向你展示了如何去使用。
上述代碼來自于修改過的 Index() action,它創建了一個 MemoryCacheEntryOptions 的對象,然后將它的 AbsoluteExpiration 屬性設置為從此刻到一分鐘之后的一個 DateTime 值,它還將 SlidingExpiration 屬性設置為一分鐘。這些值都指定了該緩存項會在一分鐘之后從緩存移除,不管其是否會被訪問。此外,如果該緩存項如初持續空閑了有一分鐘,它也會被從緩存中移除。
等你將 AbsoluteExpiration 和 SlidingExpiration 的值設置后, Set() 方法就可以被用來將一個數據項添加到緩存。這一次 MemoryCacheEntryOptions 對象會被作為第三個參數傳遞給 Set() 方法。
當緩存項會被移除時,可以連接回調
有時你會想要在緩存項從緩存中被移除時收到通知。可能會有多種原因需要從緩存中移除數據項。例如,因為明確地執行了 Remove() 方法而移除了一個緩存項, 也有可能是因為它的 AbsoluteExpiration 和 SlidingExpiration 值已經到期而被移除,諸如此類的原因。
為了能知道項目是何時從緩存移除的,你需要編寫一個緩存函數。如下代碼向你展示了如何去做這件事情
請仔細觀察這段代碼。 MyCallback() 是 HomeController 類里面的一個私有靜態函數,它有四個參數。前面兩個參數表示剛剛刪除的緩存項的鍵和值,第三個參數表示的是該數據項被刪除的原因。EvictionReason 是一個枚舉類型,它維護者各種可能的刪除原因,如過期,刪除以及替換。
在回調函數的內部,我們會基于刪除的原因構造一個字符串消息。我們想要將此消息設置成另外一個緩存項。這樣做的話就需要訪問 HomeController 的緩存對象,此時狀態參數就可以排上用場了。使用狀態對象,你可以對 HomeController 的緩存對象進行控制,并使用 Set() 增加一個 callbackMessage 緩存項。
你可以通過 Show() 這個 action 來訪問到 callbackMessage,如下所示:
最后就可以在 Show 視圖中顯示出來了:
一些建議,像上面提到的設置緩存數據項的過期時間那塊,如果一個項目中所有的緩存過期時間是一致的,我們可以有更簡單的做法,而不是每個地方都去寫一堆這個:
可以在頭部定義一個共有的
Cache是自定義的一個緩存類,其中GetMemoryCacheEntryOptions就是獲取當前緩存設置項的,代碼如下:
這里面我們將過期時間放到配置文件中。
這樣,我們的寫法就可以簡寫很多,當然,剛才提到了是使用的 IMemoryCache 的 Set<T>() 來完成的,所以,這里我們不僅可以傳String,還可以按需傳遞,比如:
到這里,你已經大概知道了MemoryCache 的簡單使用方式,剩下的就自行研究吧~
出處:https://www.cnblogs.com/zhangxiaoyong/p/9472637.html 作者:瀟十一郎
nderer
這貌似是360瀏覽器專用,兼容360的利器啊,,360默認是用IE7去渲染頁面的,不管你的系統裝了多高版本的IE,這種行為真是業界毒瘤啊。
"renderer" content="webkit">//默認webkit內核
"renderer" content="ie-comp">//默認IE兼容模式
"renderer" content="ie-stand">//默認IE標準模式
Expires (期限)
說明:指定網頁在緩存中的過期時間,一旦網頁過期,必須到服務器上重新調閱。
用法:
注意:必須使用GMT的時間格式,或直接設為0(數字表示多少時間后過期)。
Pragma (cach模式)
說明:禁止瀏覽器從本地機的緩存中調閱頁面內容。
用法:
注意:網頁不保存在緩存中,每次訪問都刷新頁面。這樣設定,訪問者將無法脫機瀏覽。
Set-Cookie (cookie設定)
說明:瀏覽器訪問某個頁面時會將它存在緩存中,下次再次訪問時就可從緩存中讀取,以提高速度。
當你希望訪問者每次都刷新你廣告的圖標,或每次都刷新你的計數器,就要禁用緩存了。
通常HTML文件沒有必要禁用緩存,對于ASP等頁面,就可以使用禁用緩存,因為每次看到的頁面都是在服務器動態生成的,緩存就失去意義。如果網頁過期,那么存盤的cookie將被刪除。
Window-target (顯示窗口的設定)
說明:強制頁面在當前窗口以獨立頁面顯示。
用法:
注意:這個屬性是用來防止別人在框架里調用你的頁面。Content選項:_blank、_top、_self、_parent
Pics-label (網頁RSAC等級評定)
說明:在IE的Internet選項中有一項內容設置,可以防止瀏覽一些受限制的網站,而網站的限制級
別就是通過該參數來設置的。
用法:I gen comment ‘RSACi North America Sever’ by
for ‘http://www.microsoft.com’ on ‘1997.06.30T14:21-0500′ r(n0 s0 v0 l0))">
注意:不要將級別設置的太高。RSAC的評估系統提供了一種用來評價Web站點內容的標準。
用戶可以設置Microsoft Internet Explorer(IE3.0以上)來排除包含有色情和暴力內容的站點。
上面這個例子中的HTML取自Microsoft的主頁。代碼中的(n 0 s 0 v 0 l 0)表示該站點不包含不健康內容。
級別的評定是由RSAC,即美國娛樂委員會的評級機構評定的,如果你想進一步了解RSAC評估系統的等級內容,或者你需要評價自己的網站,可以訪問RSAC的站點:http://www.rsac.org/。
Content-Script-Type (腳本相關)
說明:這是近來W3C的規范,指明頁面中腳本的類型。
RSS 網站地圖-Sitemap
復制代碼保存到一個sitemap.xml(或者ror.xml)文件中,然后上傳到你應用的根目錄下。
并且把下面代碼增加到你站點主頁的 標簽中,主要是為了方便搜索引擎來讀取。
如果你的站點地圖文件名是ror.xml,記得要把代碼中的href改成href="ror.xml"
Content-Type和Content-Language (顯示字符集的設定)
說明:設定頁面使用的字符集,用以說明主頁制作所使用的文字已經語言,
瀏覽器會根據此來調用相應的字符集顯示page內容。
注意:
該meta標簽定義了HTML頁面所使用的字符集為GB2132,就是國標漢字碼。
如果將其中的“charset=GB2312"替換成“BIG5",則該頁面所用的字符集就是繁體中文Big5碼。
當你瀏覽一些國外的站點時,IE瀏覽器會提示你要正確顯示該頁面需要下載xx語支持。
這個功能就是通過讀取HTML頁面meta標簽的Content-Type屬性而得知需要使用哪種字符集顯示該頁面的。
如果系統里沒有裝相應的字符集,則IE就提示下載。
其他的語言也對應不同的charset,比如日文的字符集是“iso-2022-jp ",韓文的是“ks_c_5601"。
Content-Type的Content還可以是:text/xml等文檔類型;
Charset選項:
ISO-8859-1(英文)、BIG5、UTF-8、SHIFT-Jis、Euc、Koi8-2、us-ascii,
x-mac-roman, iso-8859-2, x-mac-ce, iso-2022-jp, x-sjis, x-euc-jp,euc-kr,
iso-2022-kr, gb2312, gb_2312-80, x-euc-tw, x-cns11643-1,x-cns11643-2等字符集;
Content-Language的Content還可以是:EN、FR等語言代碼。
webapp里主要的mate用途
添加到主屏幕后,全屏顯示。
這meta的作用就是刪除默認的蘋果工具欄和菜單欄。content有兩個值”yes”和”no”,當我們需要顯示工具欄和菜單欄時,這個行meta就不用加了,默認就是顯示。
默認值為default(白色),可以定為black(黑色)和black-translucent(灰色半透明)。
注意: 若值為“black-translucent”將會占據頁面px位置,浮在頁面上方(會覆蓋頁面20px高度–iphone4和itouch4的Retina屏幕為40px)。
在iOS中有兩個meta值,apple-mobile-web-app-capable和apple-mobile-web-app-status-bar-style,這兩個會讓網頁內容以應用程序風格顯示,并使狀態欄透明。
說明: 這個link就是設置web app的放置主屏幕上icon文件路徑。
圖片尺寸可以設定為57*57(px)或者Retina可以定為114*114(px),ipad尺寸為72*72(px)
apple-touch-icon
iOS用rel="apple-touch-icon",android 用rel="apple-touch-icon-precomposed"。這樣就能在用戶把網頁存為書簽時,在手機HOME界面創建應用程序樣式的圖標。
name="sharecontent" data-msg-img="縮略圖地址" data-msg-title="標題" data-msg-content="簡介" data-msg-callBack="" data-line-img="縮略圖地址" data-line-title="標題" data-line-callBack=""/>
ps:
告訴瀏覽器以什么版本的IE的兼容模式來顯示網頁
其中最后一行是永遠以最新的IE版本模式來顯示網頁的。
另外加上Emulate模式
Emulate模式后則更重視
(細心的人會注意到,用IE9去訪問帶有x-ua-compatible的頁面時是不會出現兼容視圖按鈕的)
防止所有搜索引擎將網站中的網頁編入索引
<meta name="robots" content="noindex">
們知道,在使用瀏覽器的后退和前進按鈕時,瀏覽器會使用緩存來優化您的頁面加載過程。它顯著改善了用戶的瀏覽體驗——尤其是那些網絡或設備較慢的用戶。作為 Web 開發人員,了解如何在所有瀏覽器中針對這種緩存優化頁面至關重要,這樣您的用戶才能獲得收益。
回退前進緩存是一種內存緩存,用于在用戶導航離開時存儲頁面(包括 JavaScript 堆)的完整快照。 整個頁面都在內存中,如果用戶決定返回,瀏覽器可以快速輕松地恢復它。比如當點擊返回時,在那一刻,該緩存可以對上一個頁面的加載速度產生很大的影響:
下面是有緩存和沒緩存的加載回退頁面的過程:
回退前進緩存是如何工作的
回退前進緩存使用的“緩存”不同于 HTTP 緩存(它對于加快重復導航也很有用)。 回退前進緩存是在內存緩存中整個頁面的快照(包括 JavaScript 堆),而 HTTP 緩存僅包含對先前發出的請求的響應。由于加載頁面所需的所有請求都可以從 HTTP 緩存中完成是非常罕見的,因此使用回退前進緩存恢復的重復訪問總是比優化得最好的非回退前進緩存導航更快。
然而,在內存中創建頁面快照涉及到如何最好地保存正在進行的代碼方面的一些復雜性。例如,當頁面在回退前進緩存中時,如何處理超時的 setTimeout() 調用?
答案是瀏覽器暫停運行任何掛起的計時器或未解決的Promise——就是說會掛起所有任務隊列中的任務——并在當從回退前進緩存恢復頁面時恢復處理任務。
在某些情況下,這是相當低的風險(例如,setTimeout或Promise),但在其他情況下,它可能會導致非常混亂或意外的行為。例如,如果瀏覽器暫停了作為 IndexedDB 事務的一部分所需的任務,它可能會影響同一源中的其他打開的選項卡(因為多個選項卡可以同時訪問相同的 IndexedDB 數據庫)。因此,瀏覽器通常不會嘗試在 IndexedDB 事務的中間緩存頁面或使用可能影響其他頁面的 API。
可以觀察回退前進緩存的API
雖然回退前進緩存是瀏覽器自動進行的優化,但對于開發人員來說,知道它何時發生仍然很重要,這樣他們就可以優化他們的頁面并相應地調整任何指標或性能測量。
用于觀察回退前進緩存的主要事件是頁面轉換事件——pageshow 和 pagehide——它們在回退前進緩存存在的時候就已經存在,并且在當今使用的幾乎所有瀏覽器中都得到了支持。較新的頁面生命周期事件(freeze和resume)也會在頁面進出回退前進緩存時以及在某些其他情況下調度。
觀察何時從回退前進緩存恢復頁面:
pageshow 事件在頁面初始加載時以及頁面從緩存恢復時的 load 事件之后立即觸發。 pageshow 事件有一個persisted屬性,如果頁面從緩存恢復,則該屬性為 true(如果不是,則為 false)。 您可以使用持久化屬性來區分常規頁面加載和緩存恢復。 例如:
觀察頁面什么時候進入回退前進緩存
pagehide 是 pageshow 事件的對應事件。 pageshow 事件在頁面正常加載或從緩存恢復時觸發。 pagehide 事件在頁面正常卸載或瀏覽器嘗試將其放入緩存時觸發。
pagehide 事件也有一個persisted屬性,如果它是假的,那么你可以確信頁面不會進入回退前進緩存。 但是,如果persisted 屬性為真,則不能保證頁面會被緩存。 這意味著瀏覽器打算緩存該頁面,但可能存在無法緩存的因素。下面會解釋幾種原因,導致它可能仍然不能進入緩存并被丟棄。
為回退前進緩存優化你的頁面
并非所有頁面都存儲在回退前進緩存中,即使頁面確實存儲在那里,它也不會無限期地留在那里。 開發人員必須了解是什么使頁面符合(和不符合)使用緩存的條件,以最大限度地提高其緩存命中率。以下部分概述了使瀏覽器盡可能緩存您的頁面的最佳實踐。
不要使用 unload 事件
在所有瀏覽器中優化回退前進緩存的最重要方法是永遠不要使用 unload 事件。
unload 事件對瀏覽器來說是有問題的,在 unload 事件觸發后頁面將不會繼續存在。這提出了一個挑戰,因為其中許多頁面也是在假設用戶導航離開時會觸發 unload 事件的假設下構建的,這不再是真的(并且很長一段時間都不是真的)。所以瀏覽器面臨兩難境地,他們必須在可以改善用戶體驗的東西之間做出選擇——但也可能會冒著破壞頁面的風險。
如果 Chrome 和 Firefox 添加了卸載偵聽器,則選擇使頁面不符合回退前進緩存的條件,這樣風險較小,但也會取消許多頁面被緩存的資格。 Safari 將嘗試使用 unload 事件偵聽器緩存某些頁面,但為了減少潛在的損壞,它不會在用戶導航離開時運行 unload 事件,這使得該事件非常不可靠。
不要使用 unload 事件,而是使用 pagehide 事件。 pagehide 事件在當前觸發 unload 事件的所有情況下觸發,并且當頁面放入回退前進緩存時也會觸發。
事實上,Lighthouse v6.2.0 添加了一個 no-unload-listeners 審計,如果他們的頁面上的任何 JavaScript(包括來自第三方庫的 JavaScript)添加了 unload 事件監聽器,它將警告開發人員。
正確的做法:
避免 window.opener 引用
在某些瀏覽器(包括基于 Chromium 的瀏覽器)中,如果頁面是使用 window.open() 或(在 88 版之前基于 Chromium 的瀏覽器中)從帶有 target=_blank 的鏈接打開的——沒有指定 rel="noopener"——那么 打開頁面將引用打開頁面的窗口對象。
除了存在安全風險之外,具有非空 window.opener 引用的頁面不能安全地放入緩存,因為這可能會破壞任何試圖訪問它的頁面。
因此,最好盡可能避免使用 rel="noopener" 創建 window.opener 引用。 如果您的站點需要打開一個窗口并通過 window.postMessage() 或直接引用 window 對象來控制它,則打開的窗口和打開器都沒有資格使用緩存。
始終在用戶導航離開之前關閉打開的連接
如上所述,當頁面被放入緩存時,所有計劃的 JavaScript 任務都會暫停,然后在頁面從緩存中取出時恢復。如果這些計劃好的 JavaScript 任務僅訪問 DOM API(或僅與當前頁面隔離的其他 API),那么在頁面對用戶不可見時暫停這些任務不會導致任何問題。
但是,如果這些任務連接到的 API 也可以從同一來源的其他頁面訪問(例如:IndexedDB、Web Locks、WebSockets 等),這可能會出現問題,因為暫停這些任務可能會阻止其他選項卡中的代碼運行.
因此,某些瀏覽器在以下情況下不會嘗試將頁面放入緩存:
如果您的頁面使用這些 API 中的任何一個,最好在 pagehide 或 freeze 事件期間始終關閉連接并刪除或斷開觀察者。這將允許瀏覽器安全地緩存頁面,而不會影響其他打開的選項卡。然后,如果頁面從緩存恢復,您可以重新打開或重新連接到這些 API(在 pageshow 或 resume 事件中)。
以下示例顯示了如何在使用 IndexedDB 時通過關閉 pagehide 事件偵聽器中的打開連接來確保您的頁面符合緩存條件:
緩存恢復后更新陳舊或敏感數據
如果您的站點保留用戶狀態(尤其是任何敏感的用戶信息),則需要在從回退前進緩存恢復頁面后更新或清除該數據。例如,如果用戶導航到結帳頁面然后更新他們的購物車,如果從緩存恢復過時的頁面,則返回導航可能會顯示過時的信息。
另一個更關鍵的示例是,如果用戶在公共計算機上退出站點,并且下一個用戶單擊后退按鈕。 這可能會暴露用戶在注銷時認為已清除的私人數據。為避免此類情況,如果 event.persisted 為 true,則最好在 pageshow 事件之后始終更新頁面。
以下代碼檢查 pageshow 事件中是否存在特定于站點的 cookie,如果未找到 cookie,則重新加載:
測試一下保證你的頁面會被緩存
Chrome DevTools 可以幫助您測試您的頁面,以確保它們針對回退前進緩存進行了優化,并確定可能阻止它們符合條件的任何問題。
要測試特定頁面,請在 Chrome 中導航到該頁面,然后在 DevTools 中轉到 Application > Back-forward Cache。 接下來單擊 Run Test 按鈕,DevTools 將嘗試導航并返回以確定頁面是否可以從回退前進緩存恢復。
如果成功,則會顯示從緩存恢復成功,失敗也有提示,并告訴你原因。
成功
比如百度使用了unload導致緩存失敗 :)
結語:
回退前進緩存對提高性能,及用戶體驗很有幫助。大家要寫正確的代碼來使自己的頁面盡量被緩存,這樣你們的網站才能大大獲益。
*請認真填寫需求信息,我們會在24小時內與您取得聯系。