Firebase Hosting sử dụng một CDN toàn cầu mạnh mẽ để 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 trên trang web, Firebase Hosting sẽ tự động xoá tất cả nội dung được lưu vào bộ nhớ đệm trên CDN cho đến khi có 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 hoạt, nên nội dung cho 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 vào hoặc danh tính của người dùng. Để giải thích điều này, theo mặc định, các yêu cầu do mã phụ trợ xử lý 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 để có thể 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à các dịch vụ trong tài liệu Cloud Functions và Cloud Run.
Ngoại lệ là những yêu cầu trả về lỗi 404. CDN lưu vào bộ nhớ đệm phản hồi 404 của dịch vụ đối với 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 từ 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 đã 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 đè giá trị mặc định là 10 phút và hoàn toàn xác định 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 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ể truyền đạt cho cả trình duyệt và CDN biết thời gian nội dung của bạn có thể được lưu 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 đề ví dụ này, các chỉ thị thực hiện 3 việc sau:
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 số giây mà chúng có thể lưu nội dung vào bộ nhớ đệm. Khi hết thời gian đã đặt, trình duyệt và CDN phải xác thực lại nội dung bằng máy chủ gốc. Trong tiêu đề ví dụ, 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 (xems-maxage
bên dưới để biết các chế độ kiểm soát cụ thể đối với việc lưu nội dung vào bộ nhớ đệm của CDN).s-maxage
– Ghi đè chỉ thịmax-age
chỉ để lưu vào bộ nhớ đệm của CDN; cho CDN biết số giây mà CDN có thể lưu nội dung vào bộ nhớ đệm. 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 ta đang ghi đè chế độ cài đặt chomax-age
chỉ đối với 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 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 sau mỗi vài giây, 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 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 lưới 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 trong 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
Tiêu đề Vary
Tiêu đề Vary
xác định tiêu đề yêu cầu nào sẽ được dùng để cung cấp phản hồi phù 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ó nên được xác thực lại bằng máy chủ gốc hay không).
Firebase Hosting tự động đặt tiêu đề Vary
thích hợp cho phản hồi của bạn trong các trường hợp phổ biến. Trong hầu hết các 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ó các tiêu đề khác cần ảnh hưở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 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 có yêu cầu về nội dung động. Điều này đảm bảo rằng mọi tiêu đề uỷ quyền cookie hoặc phiên mà bạn sử dụng đều là một phần của khoá bộ nhớ đệm, giúp ngăn chặn tình trạng vô tình rò rỉ nội dung.
Ngoài ra, hãy lưu ý:
Bạn chỉ có thể lưu vào bộ nhớ đệm các yêu cầu
GET
vàHEAD
. 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 thận trọng 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 được lưu vào bộ nhớ đệm. Ngoài ra, hãy nhớ rằngVary
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 lưu vào bộ nhớ đệm hiệu quả của CDN.
Chỉ cookie __session
có tên đặc biệt mới được phép truyền đến quá trình thực thi ứng dụng của bạn.
Khi có mặt, cookie __session
sẽ tự động trở thành một phần của khoá bộ nhớ đệm, tức 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 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 tuỳ thuộc vào việc người dùng có được uỷ quyền hay không.