問題描述

如圖所示，發(fā)現(xiàn)預(yù)加載圖片后，重復(fù)調(diào)用圖片的時(shí)候觸發(fā)了重復(fù)的圖片資源（ 確定圖片資源路徑是一致的 ）加載。

在手機(jī)端沒有發(fā)現(xiàn)這樣的情況，但是在 chrome 上很容易出現(xiàn)類似的情況，每次重復(fù)加載的圖片資源不相同。

重復(fù)請(qǐng)求一兩次后，便不會(huì)再重復(fù)請(qǐng)求。

請(qǐng)問是什么原因?qū)е铝诉@樣的情況出現(xiàn)？

html 頭部

<meta name='viewport' content='width=device-width, initial-scale=1.0, user-scalable=0, minimum-scale=1.0, maximum-scale=1.0'><meta name='format-detection' content='telephone=no, date=no, address=no, email=no, url=no'><meta http-equiv='Cache-Control' content='no-cache, no-store, must-revalidate'><meta http-equiv='Pragma' content='no-cache'><meta http-equiv='Expires' content='0'>

stackoverflow 上相同問題：https://stackoverflow.com/que...

問題解答

http請(qǐng)求是304，實(shí)際上這張圖片是從瀏覽器緩存里面加載的

引用： 對(duì) HTTP 304 的理解

最近和同事一起看Web的Cache問題，又進(jìn)一步理解了 HTTP 中的 304 又有了一些了解。 304 的標(biāo)準(zhǔn)解釋是：Not Modified 客戶端有緩沖的文檔并發(fā)出了一個(gè)條件性的請(qǐng)求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務(wù)器告訴客戶，原來(lái)緩沖的文檔還可以繼續(xù)使用。 如 果客戶端在請(qǐng)求一個(gè)文件的時(shí)候，發(fā)現(xiàn)自己緩存的文件有 Last Modified ，那么在請(qǐng)求中會(huì)包含 If Modified Since ，這個(gè)時(shí)間就是緩存文件的 Last Modified 。因此，如果請(qǐng)求中包含 If Modified Since，就說(shuō)明已經(jīng)有緩存在客戶端。只要判斷這個(gè)時(shí)間和當(dāng)前請(qǐng)求的文件的修改時(shí)間就可以確定是返回 304 還是 200 。對(duì)于靜態(tài)文件，例如：CSS、圖片，服務(wù)器會(huì)自動(dòng)完成 Last Modified 和 If Modified Since 的比較，完成緩存或者更新。但是對(duì)于動(dòng)態(tài)頁(yè)面，就是動(dòng)態(tài)產(chǎn)生的頁(yè)面，往往沒有包含 Last Modified 信息，這樣瀏覽器、網(wǎng)關(guān)等都不會(huì)做緩存，也就是在每次請(qǐng)求的時(shí)候都完成一個(gè) 200 的請(qǐng)求。 因此，對(duì)于動(dòng)態(tài)頁(yè)面做緩存加速，首先要在 Response 的 HTTP Header 中增加 Last Modified 定義，其次根據(jù) Request 中的 If Modified Since 和被請(qǐng)求內(nèi)容的更新時(shí)間來(lái)返回 200 或者 304 。雖然在返回 304 的時(shí)候已經(jīng)做了一次數(shù)據(jù)庫(kù)查詢，但是可以避免接下來(lái)更多的數(shù)據(jù)庫(kù)查詢，并且沒有返回頁(yè)面內(nèi)容而只是一個(gè) HTTP Header，從而大大的降低帶寬的消耗，對(duì)于用戶的感覺也是提高。 當(dāng)這些緩存有效的時(shí)候，通過(guò) HttpWatch 查看一個(gè)請(qǐng)求會(huì)得到這樣的結(jié)果：