Quản lý hoạt động của bộ nhớ đệm

Firebase Hosting sử dụng một CDN toàn cầu mạnh mẽ để giúp trang web của bạn hoạt động nhanh nhất có thể.

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

Tuy nhiên, vì các dịch vụ Cloud Functions và Cloud Run tạo nội dung một cách linh động, 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 người dùng nhập hoặc danh tính của người dùng. Để tính đến điều này, theo mặc định, các yêu cầu do mã phụ trợ xử lý sẽ không lưu vào bộ nhớ đệm trên CDN.

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 bằng cách lưu nội dung đã tạo vào bộ nhớ đệm trong ít nhất một khoảng thời gian ngắn.

Tương tự, bạn có thể định cấu hình hành vi lưu vào bộ nhớ đệm để giảm chi phí thực thi hàm vì nội dung được phân phát từ CDN thay vì từ một hàm được kích hoạt. Đọc thêm về cách tối ưu hoá việc thực thi hàm và dịch vụ trong tài liệu về Cloud Functions 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ụ vào bộ nhớ đệm cho một URL không tồn tại trong 10 phút, để các yêu cầu tiếp theo cho URL đó được phân phát qua CDN. Nếu bạn thay đổi dịch vụ để nội dung hiện có tại URL này, thì CDN sẽ tiếp tục phân phát mọi lỗi 404 được lưu vào bộ nhớ đệm trong tối đa 10 phút, sau đó phân phát nội dung từ URL đó như bình thường.

Nếu phản hồi 404 đã chứa các tiêu đề lưu vào bộ nhớ đệm do dịch vụ Cloud Functions hoặc Cloud Run của bạn đặt, thì các tiêu đề này sẽ ghi đè thời gian mặc định là 10 phút và xác định đầy đủ hành vi lưu vào 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 Cache-Control

Công cụ chính mà bạn sử dụng để quản lý bộ nhớ đệ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 lượng lưu nội dung vào bộ nhớ đệm. Trong hàm, bạn đặt Cache-Control như sau:

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

Trong tiêu đề mẫu này, các lệnh thực hiện 3 việc:

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

  • max-age – Cho trình duyệt và CDN biết thời lượng mà chúng có thể lưu nội dung vào bộ nhớ đệm. Khi thời gian đã đặt hết hạn, 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 đề mẫu, chúng ta cho phép trình duyệt và CDN lưu nội dung vào bộ nhớ đệm trong 5 phút (xem s-maxage bên dưới để biết các chế độ kiểm soát cụ thể cho việc lưu nội dung vào bộ nhớ đệm CDN).

  • s-maxage – Ghi đè lệnh max-age chỉ dành cho tính năng lưu vào bộ nhớ đệm CDN; cho CDN biết thời lượng lưu nội dung vào bộ nhớ đệm là bao nhiêu giây. Khi thời gian đã đặt hết hạn, 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 ta sẽ ghi đè chế độ cài đặt cho max-age chỉ dành cho CDN và cho phép CDN lưu nội dung vào bộ nhớ đệm trong 10 phút.

Đối với max-age và s-maxage, hãy đặt giá trị của các thuộc tính này thành khoảng thời gian dài nhất mà bạn cho phép người dùng nhận nội dung cũ. Nếu một trang thay đổi sau vài giây, hãy sử dụng một 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 một cách 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 vào bộ nhớ đệm được phân phát?

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

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

Thay đổi tiêu đề

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 vào bộ nhớ đệm có hợp lệ hay không hoặc liệu 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 trong các trường hợp phổ biến. Trong hầu hết trường hợp, bạn không cần 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ần các tiêu đề khác để ảnh hưởng đến bộ nhớ đệm. Trong trường hợp đó, bạn có thể đặt tiêu đề Vary trên phản hồi. 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 chế độ cài đặt này, hai yêu cầu giống hệt nhau nhưng có tiêu đề X-My-Custom-Header khác nhau sẽ được lưu vào bộ nhớ đệm riêng biệt. Xin lưu ý rằng Hosting sẽ thêm Cookie và Authorization vào tiêu đề Vary theo mặc định khi một yêu cầu được thực hiện cho nội dung động. Điều này đảm bảo rằng mọi tiêu đề uỷ quyền phiên hoặc cookie mà bạn sử dụng đều được đưa vào khoá bộ nhớ đệm, giúp ngăn chặn việc rò rỉ nội dung do nhầm lẫn.

Ngoài ra, hãy lưu ý:

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

  • Hãy cẩn thận khi thêm chế độ cài đặt vào tiêu đề Vary. Bạn càng thêm nhiều chế độ cài đặt thì CDN càng ít có khả năng phân phát nội dung đã lưu vào bộ nhớ đệm. Ngoài ra, hãy 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 Firebase Hosting cùng với Cloud Functions hoặc Cloud Run, cookie thường bị xoá khỏi các yêu cầu đến. Điều này là cần thiết để cho phép hành vi bộ nhớ đệm CDN hiệu quả. Chỉ cookie __session được đặt tên đặc biệt mới được phép chuyển đến quá trình thực thi ứng dụng.

Khi có, cookie __session sẽ tự động trở thành một phần của khoá bộ nhớ đệm, nghĩa là hai người dùng có cookie khác nhau không thể nhận được phản hồi được lưu vào bộ nhớ đệm của người dùng khác. 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 tuỳ thuộc vào quyền uỷ quyền của người dùng.