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 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 lần yêu cầu tiếp theo.
Tuy nhiên, vì các dịch vụ Cloud Functions và Cloud Run tạo ra nội dung động, thì nội dung của một URL nhất định có thể thay đổi tuỳ theo những điều đó làm hoạt động đầu vào của người dùng 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 định kỳ, bạn có thể tăng tốc ứng dụng của bạn 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.
Bạn cũng 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 hàm chi phí thực thi do nội dung được phân phát từ CDN chứ không phải từ đượ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 Cloud Functions và Cloud Run tài liệu.
Ngoại lệ là các yêu cầu trả về lỗi 404. CDN sẽ 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 để cho URL đó được phân phát ngoài CDN. Nếu bạn thay đổi dịch vụ để nội dung hiện đang tồn tại tại URL này, CDN sẽ tiếp tục phân phát mọi 404 trong 10 phút (tối đa) rồi phân phát nội dung từ URL đó như bình thường.
Nếu phản hồi 404 đã chứa tiêu đề bộ nhớ đệm do Dịch vụ Cloud Functions hoặc Cloud Run, chúng sẽ ghi đè 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ề hoạt động lưu vào bộ nhớ đệm trong tài liệu dành cho nhà phát triển web.
Thiết lập tính năng Kiểm soát bộ nhớ đệm
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ể giao tiếp cả hai với
trình duyệt và CDN khoảng 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 đã thiết lập Cache-Control như sau:
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 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 (có nghĩa là CDN của Firebase Hosting) có thể lưu vào bộ nhớ đệm nội dung.max-age– Cho trình duyệt và CDN biết số giây mà chúng có thể lưu vào bộ nhớ đệm nội dung. 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 bằng 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 (xems-maxagebê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– Chỉ ghi đè lệnhmax-agecho việc lưu vào bộ nhớ đệm của CDN; cho biết số giây mà CDN có thể lưu nội dung vào bộ nhớ đệm. Khi thời gian đã đặt hết hạn, thì 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 đè chế độ cài đặt chomax-agechỉ dành 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 lỗi thời. 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ũng 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.
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 sẽ 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 các 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 một tiêu đề Vary thích hợp trên
cho các tình huống thường gặp. Bạn không cần phải lo lắng trong mọi trường hợp
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. Khi trường hợp đó xảy ra,
bạn có thể đặt tiêu đề Vary cho câu trả lờ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 có yêu cầu
dành cho nội dung động. Điều này đảm bảo rằng mọi uỷ quyền phiên hoặc cookie
tiêu đề mà bạn sử dụng thuộc khoá bộ nhớ đệm. Khoá này giúp ngăn chặn việc vô tình rò rỉ dữ liệu
về nội dung.
Ngoài ra, xin lưu ý:
Chỉ có thể lưu vào bộ nhớ đệm các yêu cầu
GETvà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 cẩn thận khi thêm chế độ cài đặt vào tiêu đề
Vary. Càng nhiều chế độ cài đặt mà bạn thêm, thì càng ít khả năng CDN có thể phân phát nội dung được lưu vào bộ nhớ đệm. Ngoài ra, hãy nhớ rằngVarydự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 sẽ bị xoá khỏi các yêu cầu đến. Chiến dịch này
là cần thiết để cho phép hoạt động lưu trong bộ nhớ đệm của 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.
Cookie __session sẽ tự động trở thành một phần của bộ nhớ đệm (nếu có)
nghĩa là hai người dùng có các cookie khác nhau không thể
nhận phản hồi được lưu vào bộ nhớ đệm của đối tượng khác. Chỉ sử dụng cookie __session nếu
ứng dụng phân phát nội dung khác nhau tuỳ thuộc vào sự cho phép của người dùng.