3

儘管Chrome在網絡標籤中緩存了靜態文件(JS,圖片等),但這些文件需要一些時間,如下圖所示。 enter image description here爲什麼Chrome緩存的請求需要時間?

許多緩存文件的加載時間僅爲0ms。即使文件從緩存中加載,有人可以告訴我,爲什麼他們加載時間大於0ms?

+0

看看這個https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=en http://stackoverflow.com/questions/3401049/chrome -doesnt-cache-images-js-css – Codeone

回答

2

乍看之下,看起來Chrome很花時間下載資源,即使它們來自緩存。這不是從您看到的Web服務器上下載的時間。相反,我相信這是從本地數據庫緩存中下載的時間。

任何數據的檢索都涉及一定數量的成本。這些資源基本上存儲在Chrome的數據庫中,要檢索數據需要查詢,這不是即時的。除了在表中查找數據之外,可能還有一些處理將正確的數據推送到內存中,因爲數據的存儲方式並不完全如此。它很可能被壓縮,並且解壓縮數據可能是一個緩慢的過程。

你可以,雖然它似乎採取0毫秒來獲取一些資源,當你在看計時選項卡,你會看到,它實際上是四捨五入的網絡選項卡看到。例如,在下面的請求中,我看到0.08 ms失速和0.02 ms下載,儘管它在網格中顯示爲0 ms。

Not instant

更新:

我進一步調查了這一點,並發現Chrome擴展似乎對從緩存和Web兩種檢索時間,特別是那些將內容插入效果這一頁。 Adblock似乎是我的一些延遲的原因 - 上面的解釋仍然適用於其餘的。

+0

感謝Gideon的詳細解釋。 – Sriks

+0

對於我來說,如果我從悉尼前往我在阿姆斯特丹的服務器,或者280ms從我的CPU到內存7釐米,我會得到280ms的TTFB。如果這是真的,這個世界確實是一個陌生的地方。 –

+0

@DavidGilbertson是的,從數據庫/處理檢索不能考慮這個時間級別。沒有啓用任何擴展程序,你嘗試運行嗎? –

0

奇怪的是,在Chrome中的時間有點...古怪...時間不純粹是網絡時間。如果JS引擎被莫名其妙地受阻,它是包含在總時間...

enter image description here

如果碰到這個問題去「時間表」選項卡,並記錄完整的時間表。

相關問題