Quản lý hành vi bộ nhớ cache

Firebase Hosting sử dụng CDN toàn cầu mạnh mẽ để cải thiện trang web của bạn nhanh nhất có thể.

Mọi nội dung tĩnh được yêu cầu sẽ tự động được lưu vào bộ đệm trên CDN . Nếu bạn triển khai lại nội dung trang web của mình, Firebase Hosting sẽ tự động xóa tất cả nội dung được lưu trong bộ nhớ đệm trên CDN cho đến khi có yêu cầu tiếp theo.

Tuy nhiên, do các dịch vụ Cloud Functions và Cloud Run tạo ra nội dung một cách linh hoạt nên nội dung của một URL nhất định có thể thay đổi dựa trên những yếu tố như dữ liệu nhập của người dùng hoặc danh tính của người dùng. Để giải quyết vấn đề này, các yêu cầu được xử lý bằng mã phụ trợ sẽ không lưu vào bộ nhớ đệm trên CDN theo mặc định.

Tuy nhiên, bạn có thể định cấu hình hành vi lưu vào bộ nhớ đệm cho nội dung động . Ví dụ: nếu một hàm chỉ tạo nội dung mới theo định kỳ, bạn có thể tăng tốc ứng dụng của mình bằng cách lưu nội dung được tạo vào bộ nhớ đệm trong ít nhất một khoảng thời gian ngắn.

Bạn có thể định cấu hình hành vi lưu vào bộ nhớ đệm theo cách tương tự để có thể giảm chi phí thực thi chức năng vì nội dung được cung cấp từ CDN thay vì từ chức năng được kích hoạt. Đọc thêm về việc tối ưu hóa việc thực thi chức năng và dịch vụ trong tài liệu Chức năng đám mây và Cloud Run .

Ngoại lệ là các yêu cầu trả về lỗi 404. CDN lưu phản hồi 404 của dịch vụ của bạn vào một URL không tồn tại trong 10 phút để các yêu cầu tiếp theo đối với URL đó được phân phát ra khỏi CDN. Nếu bạn thay đổi dịch vụ của mình để nội dung hiện tồn tại tại URL này thì CDN sẽ tiếp tục phân phát mọi lỗi 404 được lưu trong bộ nhớ đệm trong 10 phút (tối đa) và sau đó phân phát nội dung từ URL đó một cách bình thường.

Nếu phản hồi 404 đã chứa các tiêu đề bộ nhớ đệm do dịch vụ Cloud Functions hoặc Cloud Run của bạn đặt, thì chúng sẽ ghi đè mặc định là 10 phút và xác định đầy đủ hành vi bộ nhớ đệm của CDN.

Tìm hiểu thêm về hành vi lưu vào bộ nhớ đệm trong tài liệu dành cho nhà phát triển web của Google.

Đặt kiểm soát bộ đệm

Công cụ chính mà bạn sử dụng để quản lý bộ đệm cho nội dung động là tiêu đề Cache-Control . Bằng cách định cấu hình tiêu đề này, bạn có thể thông báo cho cả trình duyệt và CDN về thời gian nội dung của bạn có thể được lưu vào bộ nhớ đệm. Trong chức năng của bạn, bạn đặt Cache-Control như vậy:

res.set('Cache-Control', 'public, max-age=300, s-maxage=600');

Trong tiêu đề ví dụ này, các lệnh thực hiện ba việc:

  • public - Đánh dấu bộ đệm là public . Điều này có nghĩa là cả trình duyệt và máy chủ trung gian (nghĩa là CDN dành cho Dịch vụ lưu trữ Firebase) đều có thể lưu nội dung vào bộ nhớ đệm.

  • max-age — Cho trình duyệt và CDN biết họ có thể lưu nội dung vào bộ nhớ đệm trong bao nhiêu giây. Khi hết thời gian đã đặt, trình duyệt và CDN phải xác thực lại nội dung với máy chủ gốc. Trong tiêu đề ví dụ, chúng tôi cho phép trình duyệt và CDN lưu nội dung vào bộ nhớ đệm trong năm phút (xem s-maxage bên dưới để biết các biện pháp kiểm soát cụ thể đối với bộ nhớ đệm CDN).

  • s-maxage — Ghi đè chỉ thị max-age chỉ dành cho bộ nhớ đệm CDN; cho CDN biết nội dung có thể lưu vào bộ nhớ đệm trong bao nhiêu giây. Khi hết thời gian đã đặt, CDN phải xác thực lại nội dung với máy chủ gốc. Trong tiêu đề ví dụ, chúng tôi sẽ ghi đè cài đặt về max-age chỉ cho CDN và cho phép CDN lưu nội dung vào bộ nhớ đệm trong mười phút.

Đối với max-age và s-maxage , hãy đặt giá trị của chúng thành khoảng thời gian dài nhất mà bạn cảm thấy thoải mái khi người dùng nhận được nội dung cũ. Nếu một trang thay đổi vài giây một lần, hãy sử dụng giá trị thời gian nhỏ. Tuy nhiên, các loại nội dung khác có thể được lưu vào bộ nhớ đệm an toàn trong nhiều giờ, nhiều ngày hoặc thậm chí nhiều tháng.

Bạn có thể tìm hiểu thêm về tiêu đề Cache-Control trên Mạng nhà phát triển Mozilla và trong tài liệu dành cho nhà phát triển web của Google.

Khi nào nội dung được lưu trong bộ nhớ đệm được phân phối?

Trình duyệt và CDN lưu vào bộ nhớ đệm nội dung của bạn dựa trên:

  • Tên máy chủ
  • Con đường
  • Chuỗi truy vấn
  • Nội dung của tiêu đề yêu cầu được chỉ định trong tiêu đề Vary

Tiêu đề khác nhau

Tiêu đề Vary xác định tiêu đề yêu cầu nào sẽ được sử dụng để cung cấp phản hồi thích hợp (liệu nội dung được lưu trong bộ nhớ đệm có hợp lệ hay nội dung đó có cần được xác thực lại với máy chủ gốc hay không).

Firebase Hosting tự động đặt tiêu đề Vary thích hợp trên phản hồi của bạn cho các tình huống phổ biến. Hầu hết thời gian, bạn không cần phải lo lắng về tiêu đề Vary . Tuy nhiên, trong một số trường hợp sử dụng nâng cao, bạn có thể có các tiêu đề khác cần tác động đến bộ nhớ đệm. Trong trường hợp đó, bạn có thể đặt tiêu đề Vary cho phản hồi của mình. Ví dụ:

res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');

Trong trường hợp này, giá trị của tiêu đề Vary là:

vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization

Với các cài đặt này, hai yêu cầu giống hệt nhau với các tiêu đề X-My-Custom-Header khác nhau sẽ được lưu trữ riêng biệt. Lưu ý rằng Hosting thêm Cookie và Authorization vào tiêu đề Vary theo mặc định khi có yêu cầu đối với nội dung động. Điều này đảm bảo rằng bất kỳ tiêu đề ủy quyền phiên hoặc cookie nào bạn sử dụng đều được coi là một phần của khóa bộ nhớ đệm, giúp ngăn ngừa rò rỉ nội dung do vô tình.

Cũng lưu ý:

  • Chỉ các yêu cầu GET và HEAD mới có thể được lưu vào bộ đệm. Các yêu cầu HTTPS sử dụng các phương pháp khác không bao giờ được lưu vào bộ nhớ đệm.

  • Hãy cẩn thận khi thêm cài đặt vào tiêu đề Vary . Bạn càng thêm nhiều cài đặt thì CDN càng ít có khả năng phân phát nội dung được lưu trong bộ nhớ đệm. Cũng nên nhớ rằng Vary dựa trên tiêu đề yêu cầu chứ không phải tiêu đề phản hồi .

Sử dụng cookie

Khi sử dụng Dịch vụ lưu trữ Firebase cùng với Cloud Functions hoặc Cloud Run, cookie thường bị loại bỏ khỏi các yêu cầu gửi đến. Điều này là cần thiết để cho phép hoạt động của bộ đệm CDN hiệu quả. Chỉ cookie __session có tên đặc biệt mới được phép chuyển sang quá trình thực thi ứng dụng của bạn.

Khi xuất hiện, cookie __session sẽ tự động được tạo thành một phần của khóa bộ nhớ đệm, nghĩa là hai người dùng có các cookie khác nhau không thể nhận được phản hồi được lưu trong bộ nhớ đệm của người kia. Chỉ sử dụng cookie __session nếu ứng dụng của bạn phân phát nội dung khác nhau tùy theo ủy quyền của người dùng.