可以用JS實現清除瀏覽器緩存，解決方法如下：
1、在靜態頁面也就是以.html，.jsp，.aspx，.php結尾的文件中在<dead></head>中加入以下代碼。
注意事項：
JavaScriptJavaScript基於對象和事件驅動並具有相對安全性的客戶端腳本語言。也是一種廣泛用於客戶端Web開發的腳本語言，常用來給HTML網頁添加動態功能，比如響應用戶的各種操作。
㈡ 前端開發，頁面優化，性能優化有哪些方面
感覺前端的性能確實是很重要的，我談談我在實際項目中的應用。前端的應用主要從以下幾個方面進行優化：
1．減少http請求
HTTP協議是無狀態的應用層協議，意味著每次HTTP請求都需要建立通信鏈路、進行數據傳輸，而在伺服器端，每個HTTP都需要啟動獨立的線程去處理。這些通信和服務的開銷都很昂貴，減少HTTP請求的數目可有效提高訪問性能。減少HTTP的主要手段是合並CSS、合並JavaScript、合並圖片。將瀏覽器一次訪問需要的JavaScript、CSS合並成一個文件，這樣瀏覽器就只需要一次請求。圖片也可以合並，多張圖片合並成一張，如果每張圖片都有不同的超鏈接，可通過CSS偏移響應滑鼠點擊操作，構造不同的URL。
2．使用瀏覽器緩存
對一個網站而言，CSS、JavaScript、Logo、圖標這些靜態資源文件更新的頻率都比較低，而這些文件又幾乎是每次HTTP請求都需要的，如果將這些文件緩存在瀏覽器中，可以極好地改善性能。通過設置HTTP頭中Cache-Control和Expires的屬性，可設定瀏覽器緩存，緩存時間可以是數天，甚至是幾個月。在某些時候，靜態資源文件變化需要及時應用到客戶端瀏覽器，這種情況，可通過改變文件名實現，即更新JavaScript文件並不是更新JavaScript文件內容，而是生成一個新的JS文件並更新HTML文件中的引用。使用瀏覽器緩存策略的網站在更新靜態資源時，應採用批量更新的方法，比如需要更新10個圖標文件，不宜把10個文件一次全部更新，而是應一個文件一個文件逐步更新，並有一定的間隔時間，以免用戶瀏覽器突然大量緩存失效，集中更新緩存，造成伺服器負載驟增、網路堵塞的情況。
3．啟用壓縮
在伺服器端對文件進行壓縮，在瀏覽器端對文件解壓縮，可有效減少通信傳輸的數據量。文本文件的壓縮效率可達80%以上，因此HTML、CSS、JavaScript文件啟用GZip壓縮可達到較好的效果宴襪。但是壓縮對伺服器和瀏覽器產生一定的壓力，在通信帶寬良好，而伺服器資源不足的情況下要權衡考慮。
4．CSS放在頁面最上面、JavaScript放在頁面最下面
瀏覽器會在下載完全部CSS之後才對整個頁面進行渲染，因此最好的做法是將CSS放在頁面最上面，讓瀏覽器盡快下載CSS。JavaScript則相反，瀏覽器在載入JavaScript後立即執行，有可能會阻塞整個頁面，造成頁面顯示緩慢，因此JavaScript最好放在頁面最下面。但如果頁面解析時就需要用到JavaScript，這時放在底閉祥坦部就不合適了。
5．減少Cookie傳輸
Cookie在每次響應請求中，如果太大勢必會影響性能，所以沒必要網cookie放的就不放，針對性的選擇放入cookie的數據。
總之，優化轎桐的方法還很多，我感觸最深的是第4項，有些js文件大引用如果放到最前面對性能損耗很大。
㈢ web前端緩存機制
前端緩存機制有多種，如瀏覽器緩存、CDN緩存、DNS緩存、代理伺服器緩存等。
CDN全稱是Content Delivery Network，即內容分發網路。CDN的原理是將資源存放在各地的緩存伺服器上，當用戶請求資源時，從就近的伺服器上返回緩存的資源，而不需要每次都從源伺服器獲取，減輕源伺服器的壓力，又能提升用戶的訪問速度。
瀏覽器可以將用戶請求的資源進行緩存，存放在本地。瀏覽器緩存一般通過請求頭來設置。
與瀏覽器緩存有關的頭部有：
瀏覽器會將伺服器的域名與IP地址的映射緩存在本地，這樣用戶在訪問網站時，不用每次都去查詢DNS映射表。
在瀏覽器和伺服器之間架設的一個伺服器 ，這個代理伺服器會幫助瀏覽器去請求頁面，然後將頁面進行處理和壓縮(例如壓縮圖片和文件)，使頁面變小，再傳輸給瀏覽器。大部分代理伺服器都有緩存的功能，如果瀏覽器所請求的文件在它本機中存在且是最新的，就不需要再從源伺服器請求數據，提高了瀏覽速度。
在瀏覽某個頁面時，瀏覽器會判斷頁面的關聯內容，進行預載入。用戶在瀏覽A頁面時，就載入好B頁面，這樣當用戶去訪問B頁面時，B頁面很快就出來，提升了用戶體驗。但這個機制有一定的缺陷，就是預判不一定準確，可能會造成流量和資源的浪費。
㈣ 系列分享之瀏覽器、本地DNS緩存篇
我們在使用瀏覽器訪問互聯網資源時,想獲取指定的服務和信息。首先就要了解瀏覽器是如何定位到我們的站點的。輸入一個域名(如:www.jd.com)瀏覽器會首先從自身的緩存中查詢是否有歷史域名對應的IP並且有效，如果有就使用該緩存通過IP直接訪問到指定的站點。如果沒有則查詢本地的Host緩存，如果有就使用本地的緩存直接訪問站點，沒有則向本地DNS伺服器發起請求查詢，如果本地DNS服務也沒有找到，則向公網DNS服務發起查詢請求獲取對應的有效IP，並返回緩存到瀏覽器和本地緩存中，供後續請求使用。
DNS記錄會有一個ttl值(time to live)，單位是秒，意思是這個記錄最大有效期是多少。操作系統緩存會參考ttl值，但是不完全等於ttl值，而瀏覽器DNS緩存的時間跟ttl值無關，每種瀏覽器都使用一個固定值。
DNS查詢請求類型:
1、權威答復：權威答復是返回給客戶的正向答復，並且設置了DNS消息中的權威位。此答復代表從具有權威的DNS伺服器處發出。
2、正向答復：正向答復包含了匹配客戶端解析請求的資源記錄。
3、參考答復：參考答復只在DNS伺服器工作在迭代模式下使用，包含了其他有助於客戶端解析請求的信息。例如，當DNS伺服器不能為客戶端發起的解析請求找到某個匹配值時，則向DNS客戶端發送參考回復，告訴它有助於解析請求的信息。
4、否定答復：否定答復指出權威伺服器在解析客戶端的請求時可能遇到了以下兩種情況之一：
權威DNS伺服器報告客戶端查詢的名字不存在；
權威DNS伺服器報告存在對應的名字,但是不存在指定類型的資源記錄。
DNS伺服器解析返回IP分配策略與客戶端對域名IP選擇策略,無論正向答復還是否定答復，DNS客戶端都將結果保存在自己的本地緩存中
瀏覽器緩存：
瀏覽器在獲取網站域名的實際IP地址後會對其IP進行緩存，減少網路請求的損耗。每種瀏覽器都有一個固定的DNS緩存時間。
參考瀏覽器DNS緩存時間：
本地緩存：
每種操作系統都有自己的DNS緩存時間控制。
1、Windows DNS默認值是MaxCacheTTL，它的默認值是86400s，也就是一天。
2、MacOS遵循DNS協議中的TTL,根據各種網路協議不同對不同的域名採用不同的緩存時間策略。在IPv4包頭中TTL是一個8 bit欄位，它位於IPv4包的第9個位元組。
參考本地DNS緩存時間：
在命令行執行nslookup指令可以看到一個域名對應的IP地址，並且可以幫助我們判斷是否有DNS劫持。隨便解析一個網站，比如
www.jd.com 應該返回的是正常的地址
然後再解析一個不存在的網站，比如123123.aaaa.com.cn如果返回的結果是
DNS request timed out.
timeout was 2 seconds.
那麼證明你的DNS沒有被劫持。
如果返回的結果是一個IP地址，比如說網通的返回地址是230.xxx.xxx.xxx，那麼證明你的DNS被劫持了。
通過了解瀏覽器、本地緩存可以幫助我們更好的為用戶服務。
1、大型的互聯網公司都有IP流量監控，當發生網路故障或劫持時可以第一時間發現。
2、頁面是我們與用戶面對面溝通的渠道和方式，當我們的網頁和服務呈現在用戶面前時，我們要了解我們提供的服務是如何影響到用戶的體驗的，比如我們前端頁面的JS、CSS等文件的動態版本號處理方式結合緩存是如何變化的，每次發版會對什麼樣的用戶有影響，都需要嚴謹。
3、機房內部的各個應用程序服務，比如Zookeeper、Redis、RPC、DB在DNS緩存變化時，可能引起的網路抖動，是否會對用戶請求造成影響，也是我們必須要注意的問題。
㈤ 怎麼在前端頁面設置不讓瀏覽器緩存
你好
HTTP1.0中通過Pragma控制頁面緩存，可以設置：Pragma或no-cache。網上有非常多的文章說明如何控制不讓瀏覽器或中間緩存伺服器緩存頁面，通常設置的值為no- cache，不過這個值不這么保險，通常還加上Expires置為0來達到目的。但是如我們刻意需要瀏覽器或緩存伺服器緩存住我們的頁面這個值則要設置為 Pragma。
HTTP1.1中啟用Cache-Control來控制頁面的緩存與否，這里介紹幾個常用的參數：
no-cache，瀏覽器和緩存伺服器都不應該緩存頁面信息；
public，瀏覽器和緩存伺服器都可以緩存頁面信息；
no-store，請求和響應的信息都不應該被存儲在對方的磁碟系統中；
must-revalidate，對於客戶機的每次請求，代理伺服器必須想伺服器驗證緩存是否過時；
Last-Modified只頁面的最後生成時間，GMT格式；
Expires過時期限值，GMT格式，指瀏覽器或緩存伺服器在該時間點後必須從真正的伺服器中獲取新的頁面信息；
上面兩個值在JSP中設置值為字元型的GMT格式，無法生效，設置long類型才
滿意請採納
㈥ 前端瀏覽器緩存機制
在前端開發中，性能是一個永恆的話題，沒有最好，只有更好。判斷一個網站性能好壞，一個直入眼觀的即是網頁的反應速度，有一個方式就是使用緩存，一個優秀的緩存策略可以縮短網頁請求的時間，減少延遲，並且網頁可以重復利用，還可以減少帶寬，降低網路負荷。
1： 為什麼需要緩存？
a：緩存可以減少用戶等待時間，提升用戶體驗
b：減少網路帶寬消耗
c：降低伺服器壓力
Note：緩存使用不當，也會造成『臟數據』問題
2：常見的緩存類型
強緩存 -
Expires伺服器端設置，表示該資源的過期時間，會有弊端，客戶端時間和伺服器時間不一致的問題。
Cache-Control：max-age表示緩存資源的最大生命周期，單位是秒
所以Expires 結合 Cache-Control 一起使用，大型網站中一般比較適用
協商緩存-
Last-Modified：值為資源的最後更新時間，隨伺服器response返回
If-Modified-Since：通過比較兩個時間來判斷資源在兩次請求期間是否有過修改，如果沒有，則命中協商緩存
Etag：表示資源內容的唯一標識，即資源的消息摘要
If-None-Match：伺服器通過比較請求頭中的If-None-Match與當前資源的Etag是否一致來判斷資源是否在兩次請求期間有過修改
3：緩存流程圖示：
a：瀏覽器會先檢測強緩存類型（Cache-Control 或者 Expires）是否有效；命中直接瀏覽器本地獲取緩存資源
b：未命中。伺服器會根據請求頭Request Header驗證這個資源是否命中協商緩存，稱之為HTTP二次驗證，命中，伺服器返回請求，但返回資源，而是告訴客戶端直接中直接從瀏覽器緩存中獲取
Note：
1.強緩存不會發生請求，協商緩存存在伺服器請求
2.當協商緩存也未命中時，則伺服器會將資源發送到客戶端
3.F5刷新頁面，會跳過強緩存
4.Ctrl+F5刷新頁面，跳過強緩存和協商緩存
5.不會緩存的情況
HTTPS POST請求 根據Cookie獲取認證信息 Request Header Cache-Control：no-cache， max-age=0
6.小故事大道理
上文對整個概念做了闡述，還是不夠形象，我們來通過幾個小故事生動理解一下：
故事一：Last-Modified
瀏覽器：Hi，我需要 jartto.min.js 這個文件，如果是在 Last-Modified: Fri Feb 15 2019 19:57:31 GMT 之後修改過的，請發給我。
伺服器：（檢查文件的修改時間）
伺服器：Oh，這個文件在那個時間之後沒有被修改過，你已經有最新的版本了。
瀏覽器：太好了，那我就顯示給用戶了。
故事二：ETag
瀏覽器：Hi，我需要 jartto.css 這個文件，有沒有不匹配 3c61f-1c1-2aecb436 這個串的
伺服器：（檢查 ETag…）
伺服器：Hey，我這里的版本也是 3c61f-1c1-2aecb436，你已經是最新的版本了
瀏覽器：好，那就可以使用本地緩存了
㈦ ☆前端優化：瀏覽器緩存技術介紹
在前端開發中，性能一直都是被大家所重視的一點，然而判斷一個網站的性能最直觀的就是看網頁打開的速度。 其中提高網頁反應速度的一個方式就是使用緩存 。緩存技術一直一來在WEB技術體系中扮演非常重要角色，是快速且有效地提升性能的手段。
一個優秀的緩存策略可以縮短網頁請求資源的距離，減少延遲，並且由於緩存文件可以重復利用，還可以減少帶寬，降低網路負荷。
所以，緩存技術是無數WEB開發從業人員在工作過程中不可避免的一大問題。 在產品開發的時候我們總是想辦法避免緩存產生，而在產品發布之時又在想策略管理緩存提升網頁的訪問速度 。了解瀏覽器的緩存命中原理，是開發WEB應用的基礎，本文著眼於此，學習瀏覽器緩存的相關知識，總結緩存避免和緩存管理的方法，結合具體的場景說明緩存的相關問題。希望能對有需要的人有所幫助。
在實際WEB開發過程中，緩存技術會涉及到不同層、不同端，比如：用戶層、系統層、代理層、前端、後端、服務端等， 每一層的緩存目標都是一致的，就是盡快返回請求數據、減少延遲 ，但每層使用的技術實現是各有不同，面對不同層、不同端的優劣，選用不同的技術來提升系統響應效率。所以，我們首先看下各層的緩存都有哪些技術，都緩存哪些數據，從整體上，對WEB的緩存技術進行了解，如下圖所示：
本篇文章重點講的就是上面紅色框部分緩存內容。
當瀏覽器請求一個網站的時候，會載入各種各樣的資源，比如：HTML文檔、圖片、CSS和JS等文件。對於一些不經常變的內容，瀏覽器會將他們保存在本地的文件中，下次訪問相同網站的時候，直接載入這些資源，加速訪問。
那麼如何知曉瀏覽器是讀取了緩存還是直接請求伺服器？如下圖網站來做個示例：
第一次打開該網站後，如果再次刷新頁面。會發現瀏覽器載入的眾多資源中，有一部分size有具體數值，然而還有一部分請求，比如圖片、css和js等文件並沒有顯示文件大小，而是顯示了 from dis cache 或者 from memory cache 字樣。這就說明了，該資源直接從本地硬碟或者瀏覽器內存讀取，而並沒有請求伺服器。
瀏覽器啟用緩存至少有兩點顯而易見的好處： （1）減少頁面載入時間；（2）減少伺服器負載；
瀏覽器是否使用緩存、緩存多久，是由伺服器控制的 。准確來說，當瀏覽器請求一個網頁（或者其他資源）時， 伺服器發回的響應的「響應頭」部分的某些欄位指明了有關緩存的關鍵信息 。下面看下，HTTP報文中與緩存相關的首部欄位：
根據上面四種類型的首部欄位不同使用策略， 瀏覽器中緩存可分為強緩存和協商緩存 ：
當瀏覽器對某個資源的請求命中了強緩存時， 返回的HTTP狀態為200 ，在chrome的開發者工具的network裡面 size會顯示為from cache ，比如：京東的首頁里就有很多靜態資源配置了強緩存，用chrome打開幾次，再用f12查看network，可以看到有不少請求就是從緩存中載入的：
Expires是HTTP 1.0提出的一個表示資源過期時間的header，它描述的是一個絕對時間，由伺服器返回，用GMT格式的字元串表示 ，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT，包含了Expires頭標簽的文件，就說明瀏覽器對於該文件緩存具有非常大的控制權。
例如，一個文件的Expires值是2020年的1月1日，那麼就代表，在2020年1月1日之前，瀏覽器都可以直接使用該文件的本地緩存文件，而不必去伺服器再次請求該文件，哪怕伺服器文件發生了變化。
所以， Expires是優化中最理想的情況，因為它根本不會產生請求 ，所以後端也就無需考慮查詢快慢。它的緩存原理，如下：
Expires是較老的強緩存管理header， 由於它是伺服器返回的一個絕對時間 ，在伺服器時間與客戶端時間相差較大時，緩存管理容易出現問題， 比如：隨意修改下客戶端時間，就能影響緩存命中的結果 。所以在HTTP 1.1的時候，提出了一個新的header， 就是Cache-Control，這是一個相對時間，在配置緩存的時候，以秒為單位，用數值表示 ，如：Cache-Control:max-age=315360000，它的緩存原理是：
Cache-Control描述的是一個相對時間 ，在進行緩存命中的時候， 都是利用客戶端時間進行判斷 ，所以相比較Expires，Cache-Control的緩存管理更有效，安全一些。
這兩個header可以只啟用一個，也可以同時啟用， 當response header中，Expires和Cache-Control同時存在時，Cache-Control優先順序高於Expires ：
此外，還可以為 Cache-Control 指定 public 或 private 標記。 如果使用 private，則表示該資源僅僅屬於發出請求的最終用戶，這將禁止中間伺服器（如代理伺服器）緩存此類資源 。對於包含用戶個人信息的文件（如一個包含用戶名的 HTML 文檔），可以設置 private，一方面由於這些緩存對其他用戶來說沒有任何意義，另一方面用戶可能不希望相關文件儲存在不受信任的伺服器上。需要指出的是，private 並不會使得緩存更加安全，它同樣會傳給中間伺服器（如果網站對於傳輸的安全性要求很高，應該使用傳輸層安全措施）。 對於 public，則允許所有伺服器緩存該資源 。通常情況下，對於所有人都可以訪問的資源（例如網站的 logo、圖片、腳本等）， Cache-Control 默認設為 public 是合理的 。
當瀏覽器對某個資源的請求沒有命中強緩存， 就會發一個請求到伺服器，驗證協商緩存是否命中，如果協商緩存命中，請求響應返回的http狀態為304並且會顯示一個Not Modified的字元串 ，比如你打開京東的首頁，按f12打開開發者工具，再按f5刷新頁面，查看network，可以看到有不少請求就是命中了協商緩存的：
查看單個請求的Response Header， 也能看到304的狀態碼和Not Modified的字元串，只要看到這個就可說明這個資源是命中了協商緩存，然後從客戶端緩存中載入的 ，而不是伺服器最新的資源：
【Last-Modified，If-Modified-Since】的控制緩存的原理，如下 ：
【Last-Modified，If-Modified-Since】都是根據伺服器時間返回的header，一般來說， 在沒有調整伺服器時間和篡改客戶端緩存的情況下，這兩個header配合起來管理協商緩存是非常可靠的，但是有時候也會伺服器上資源其實有變化，但是最後修改時間卻沒有變化的情況 ，而這種問題又很不容易被定位出來，而當這種情況出現的時候，就會影響協商緩存的可靠性。 所以就有了另外一對header來管理協商緩存，這對header就是【ETag、If-None-Match】 。它們的緩存管理的方式是：
Etag和Last-Modified非常相似，都是用來判斷一個參數，從而決定是否啟用緩存。 但是ETag相對於Last-Modified也有其優勢，可以更加准確的判斷文件內容是否被修改 ，從而在實際操作中實用程度也更高。
協商緩存跟強緩存不一樣，強緩存不發請求到伺服器， 所以有時候資源更新了瀏覽器還不知道，但是協商緩存會發請求到伺服器 ，所以資源是否更新，伺服器肯定知道。大部分web伺服器都默認開啟協商緩存，而且是同時啟用【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】，比如apache:
如果沒有協商緩存，每個到伺服器的請求，就都得返回資源內容，這樣伺服器的性能會極差。
【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】一般都是同時啟用，這是為了處理Last-Modified不可靠的情況。有一種場景需要注意：
比如，京東頁面的資源請求，返回的repsonse header就只有Last-Modified，沒有ETag：
協商緩存需要配合強緩存使用，上面這個截圖中，除了Last-Modified這個header，還有強緩存的相關header， 因為如果不啟用強緩存的話，協商緩存根本沒有意義 。
如果資源已經被瀏覽器緩存下來，在緩存失效之前，再次請求時，默認會先檢查是否命中強緩存，如果強緩存命中則直接讀取緩存，如果強緩存沒有命中則發請求到伺服器檢查是否命中協商緩存，如果協商緩存命中，則告訴瀏覽器還是可以從緩存讀取，否則才從伺服器返回最新的資源。其瀏覽器判斷緩存的詳細流程圖，如下：
㈧ 瀏覽器緩存 前端頁面獲取存放token
//sessinonStorage只在當前窗口有效 生命隨瀏覽器關閉終止 容量約5M
window.sessionStorage.setItem("name",'男');
//獲取name
console.log(window.sessionStorage.getItem('name'));
//清空Storage
window.sessionStorage.clear();
//刪除數據
window.sessionStorage.removeItem('age')
先打開a頁面儲存name 在打開桌面b獲取時會獲取不到如下圖
但是在a頁點擊a鏈接跳轉b卻可以獲取到
當跳轉到b時修改name,在返回a頁查看name, a頁並沒有發生改變（這說明a和b頁面不是公用的一個sessionStorage，而是在頁面跳轉時a傳給了b）
//localStorage在關閉瀏覽器後依然有效 容量約20M
//放入緩存中
window.localStorage.setItem('userToken', token);
//獲取
console.log(window.localStorage.getItem("userToken"))
//刪除數據
window.sessionStorage.removeItem('userToken')