2012-06-28 29 views
23

Bối cảnh:Chrome có bỏ qua Kiểm soát-Bộ nhớ cache: độ tuổi tối đa không?

  • IIS 7
  • ASPNET ứng dụng 3.5 web

công cụ dev Chrome liệt kê 98 yêu cầu cho trang chủ của ứng dụng web (aspx + js + css + hình ảnh). Trong các yêu cầu sau, mã trạng thái là 200 cho tệp css/images. Không có thông tin bộ nhớ cache, trình duyệt sẽ hỏi máy chủ mỗi lần nếu tệp phải được cập nhật. ĐƯỢC.

Trong IIS 7 tôi đặt tiêu đề HTTP cho điều khiển bộ nhớ cache, đặt thành 6 giờ cho thư mục "ressources". Trong Chrome, sử dụng công cụ dev, tôi có thể thấy tiêu đề mà cũng được thiết lập để đáp ứng:

Cache-Control: max-age=21600 

Nhưng tôi vẫn nhận được 98 yêu cầu ... Tôi nghĩ trình duyệt mà không cần phải yêu cầu một ressource nếu ngày hết hạn của nó không đạt được và tôi đang mong đợi số lượng yêu cầu giảm xuống ...

+0

Tôi đang gặp sự cố tương tự. Chrome dường như hoàn toàn bỏ qua các tiêu đề bộ nhớ đệm. –

+0

Tôi đã sử dụng tối đa 10 giây cho mục đích thử nghiệm và * không có gì * từng làm việc, tuy nhiên nếu tôi làm 30 giây thì mọi thứ sẽ hoạt động như mong đợi. Chrome dường như có thời gian bộ nhớ cache tối thiểu, dưới thời gian đó sẽ bị bỏ qua. – user3338098

+1

Tiêu đề của câu hỏi này là sai. Nó phải là "Cache-Control", không phải "Control-Cache";) –

Trả lời

43

Tôi hiểu rồi. Google Chrome bỏ qua Cache-Control hoặc Expires tiêu đề nếu bạn thực hiện một yêu cầu ngay lập tức sau khi một yêu cầu khác với cùng URI trong cùng một tab (bằng cách nhấn vào nút refresh, bấm F5 chìa khóa hoặc nhấn lệnh + R). Nó có thể có một thuật toán để đoán những gì người dùng thực sự muốn làm.

Cách kiểm tra tiêu đề Cache-Control là trả lại tài liệu HTML có liên kết đến chính nó. Khi nhấp vào liên kết, Chrome sẽ phân phối tài liệu từ bộ nhớ cache. Ví dụ, đặt tên sau tài liệu self.html:

<!doctype html> 
<html lang="en"> 
<head> 
    <meta charset="utf-8"> 
    <title>Test Page</title> 
</head> 
<body> 
    <p> 
     <a href="self.html">Link to the same page.</a> 
     If correctly cached, a request should not be made 
     when clicking the link. 
    </p> 
</body> 
</html> 

Một lựa chọn khác là để sao chép URL và dán nó vào cùng một tab hoặc tab khác.

CẬP NHẬT: Trên một Chrome post published on January 26, 2017, nó được mô tả là những gì các hành vi trước và làm thế nào nó được thay đổi bằng cách thực hiện chỉ kiểm tra hợp lệ của tài nguyên chính, nhưng không phải của phụ nguồn:

Người dùng thường tải lại vì trang bị hỏng hoặc nội dung có vẻ cũ. Hành vi tải lại hiện có thường giải quyết các trang bị hỏng, nhưng nội dung cũ không được giải quyết một cách hiệu quả bằng cách tải lại thường xuyên, đặc biệt là trên thiết bị di động. Tính năng này ban đầu được thiết kế vào những thời điểm các trang bị hỏng khá phổ biến, vì vậy việc xử lý cả hai trường hợp sử dụng cùng một lúc là hợp lý. Tuy nhiên, mối quan tâm ban đầu này hiện đã trở nên ít liên quan hơn vì chất lượng của các trang web đã tăng lên. Để cải thiện trường hợp sử dụng nội dung cũ, Chrome hiện có hành vi tải lại đơn giản để chỉ xác thực tài nguyên chính và tiếp tục tải trang thông thường. Hành vi mới này tối đa hóa việc sử dụng lại tài nguyên được lưu trong bộ nhớ cache và dẫn đến độ trễ, mức tiêu thụ năng lượng và mức sử dụng dữ liệu thấp hơn.

Trong một Facebook post also published on January 26, 2017, nó được đề cập rằng họ tìm thấy một piece of code là Chrome làm mất hiệu lực mọi nguồn lực cache sau một yêu cầu POST:

chúng tôi thấy rằng Chrome sẽ hợp lệ lại mọi nguồn lực trên các trang đã được nạp từ làm một yêu cầu POST.Nhóm Chrome cho chúng tôi biết lý do cho điều này là yêu cầu POST có xu hướng là các trang thực hiện thay đổi - như mua hàng hoặc gửi email - và người dùng sẽ muốn có trang cập nhật nhất.

Có vẻ như đây không phải là trường hợp nữa.

Cuối cùng, nó được mô tả rằng Firefox được giới thiệu Cache-Control: immutable hoàn toàn dừng lại kiểm tra hợp lệ các nguồn lực:

Firefox thực hiện một đề nghị từ một trong những kỹ sư của chúng tôi để thêm một tiêu đề bộ nhớ cache-điều khiển mới cho một số tài nguyên để nói với trình duyệt rằng tài nguyên này sẽ không bao giờ được xác nhận lại. Ý tưởng đằng sau tiêu đề này là nó là một lời hứa thêm từ nhà phát triển cho trình duyệt rằng tài nguyên này sẽ không bao giờ thay đổi trong suốt thời gian tối đa. Firefox đã chọn để thực hiện chỉ thị này dưới dạng điều khiển bộ nhớ cache: tiêu đề không thay đổi.

Tôi hy vọng điều này sẽ giúp gỡ rối các bí ẩn tải lại.

+0

Đó không phải là mục đích của bộ nhớ đệm? –

+4

Một cách dễ dàng hơn để kiểm tra sẽ là sao chép URL của bạn vào một tab mới :) –

+0

Chrome chỉ tải từ bộ nhớ cache trong khi ở chế độ ẩn danh, nhưng không phải là trình duyệt khác, điều này cực kỳ kỳ lạ! – WoLfPwNeR

5

Nếu Công cụ nhà phát triển Chrome đang mở (F12), Chrome thường sẽ tắt bộ nhớ đệm.

Có thể điều khiển trong cài đặt Công cụ dành cho nhà phát triển - biểu tượng Bánh răng ở bên phải thanh trên cùng của công cụ tìm kiếm.

+2

Tôi đã bỏ chọn hộp đó và nó vẫn không lưu vào bộ đệm đúng cách . Hộp đó nói rằng: "Vô hiệu hóa bộ nhớ cache (trong khi DevTools đang mở)". – slm

11

Chrome dường như bỏ qua cài đặt Cache-Control của bạn nếu bạn đang tải lại trong cùng một tab. Nếu bạn sao chép URL vào một tab mới và tải nó ở đó, Chrome sẽ tôn trọng thẻ kiểm soát bộ nhớ cache và sử dụng lại nội dung từ bộ nhớ cache.

Như một ví dụ tôi có này ứng dụng của Ruby Sinatra:

#!/usr/bin/env ruby 

require 'sinatra' 

before do 
    content_type :txt 
end 

get '/' do 
    headers "Cache-Control" => "public, must-revalidate, max-age=3600", 
      "Expires" => Time.at(Time.now.to_i + (60 * 60)).to_s 
    "This page rendered at #{Time.now}." 
end 

Khi tôi liên tục nạp lại nó trong tab Chrome cùng nó sẽ hiển thị thời gian mới.

This page rendered at 2014-10-08 13:36:46 -0400. 
This page rendered at 2014-10-08 13:36:48 -0400. 

Các tiêu đề trông như thế này:

< HTTP/1.1 200 OK 
< Content-Type: text/plain;charset=utf-8 
< Cache-Control: public, must-revalidate, max-age=3600 
< Expires: 2014-10-08 13:36:46 -0400 
< Content-Length: 48 
< X-Content-Type-Options: nosniff 
< Connection: keep-alive 
* Server thin is not blacklisted 
< Server: thin 

Tuy nhiên truy cập vào cùng một URL, http://localhost:4567/ từ nhiều tab mới sẽ tái chế các kết quả trước đó từ bộ nhớ cache.

+1

Đó chỉ là câu trả lời tôi cần. Hãy tìm kiếm Chrome trong một giờ để tìm cách kết hợp đúng tiêu đề Cache, sau đó tìm thấy bài đăng này và bam, không cần phải lo lắng. –

7

Sau khi thực hiện một số xét nghiệm với Cache-Control:max-age=xxx:

  • Nhấn nút tải lại: tiêu đề lờ
  • Bước cùng url bất kỳ tab (hiện tại hay không): vinh dự
  • Sử dụng JS (window.location.reload()) : bỏ qua
  • Sử dụng Công cụ dành cho nhà phát triển (với Tắt bộ nhớ cache chưa được chọn) hoặc trong cognito không ảnh hưởng đến

Vì vậy, lựa chọn tốt nhất khi phát triển là đặt con trỏ vào thanh địa chỉ và nhấn Enter thay vì nút refresh.

Lưu ý: nhấp chuột phải vào biểu tượng làm mới sẽ hiển thị tùy chọn làm mới (Bình thường, Cứng, Bộ nhớ cache trống). Đáng kinh ngạc, không ai trong số này ảnh hưởng đến các tiêu đề này.

0

Một mẹo:

Đừng quên để xác minh "Ngày" tiêu đề - nếu máy chủ có sai ngày/giờ (hoặc nằm ở múi giờ khác) - Chrome sẽ tiếp tục yêu cầu tài nguyên một lần nữa và một lần nữa.

+0

Điều đó không có ý nghĩa. Khi một người từ Hoa Kỳ đi trên một trang web có múi giờ khác, bộ nhớ đệm vẫn hoạt động. – timmyRS

+0

Nó làm cho rất nhiều ý nghĩa để kiểm tra cho máy chủ đồng hồ nghiêng. Nhưng trước hết phải xác minh rằng tất cả thời gian là UTC. Múi giờ không phải là một vấn đề. – moodboom

Các vấn đề liên quan