Cloud CDN là một phần quan trọng trong việc hỗ trợ của App Hosting cho ứng dụng web của bạn. Mọi yêu cầu gửi đến phần phụ trợ đều phải đi qua Cloud CDN trước. Nội dung đã được lưu vào bộ nhớ đệm trong CDN sẽ được phân phát ngay cho người dùng, bỏ qua một lượt truy cập vào dịch vụ Cloud Run đang chạy mã máy chủ của ứng dụng web. Bạn có thể tìm hiểu thêm về các lợi ích chung của CDN tại web.dev.
Mặc dù cấu hình Cloud CDN cơ bản do App Hosting thiết lập và không thể sửa đổi, nhưng bạn có thể thực hiện một số việc để tối ưu hoá bộ nhớ đệm nhằm tăng tốc độ tải trang, giảm nội dung chưa được lưu vào bộ nhớ đệm bị tính phí và giảm thiểu lưu lượng truy cập vào Cloud Run.
Nội dung có thể lưu vào bộ nhớ đệm
Cloud CDN lưu trữ các phản hồi trong bộ nhớ đệm nếu TẤT CẢ các điều kiện sau đây đều đúng:
Yêu cầu là GET
Phản hồi có mã trạng thái là
200,203,204,206,300,301,302,307,308,404,405,410,421,451hoặc501.Phản hồi có tiêu đề
Cache-Controlvới lệnhmax-agehoặcs-maxage, hoặc tiêu đềExpirescó dấu thời gian trong tương lai.Phản hồi có tiêu đề
Agehoặc tiêu đềCache-Controlvới lệnhpublicrõ ràng.Phản hồi có kích thước nhỏ hơn hoặc bằng 10 MiB.
và KHÔNG CÓ điều kiện nào sau đây đúng:
Phản hồi có tiêu đề
Set-CookiePhản hồi có tiêu đề
Varyvới giá trị khácAccept,Accept-Encoding,Access-Control-Request-Headers,Access-Control-Request-Method,Origin,Sec-Fetch-Dest,Sec-Fetch-Mode,Sec-Fetch-Site,X-Goog-Allowed-Resources,X-Origin,RSC,Next-Router-State-Tree,Next-Router-Prefetch, hoặcNext-Router-Segment-Prefetch.Phản hồi có tiêu đề
Cache-Controlvới lệnhno-storehoặcprivate.Yêu cầu có tiêu đề
Cache-Controlvới lệnhno-store.Yêu cầu có tiêu đề
Authorization, trừ phi phản hồi có lệnh kiểm soát bộ nhớ đệm rõ ràng.
Tuỳ chỉnh hành vi bằng các lệnh kiểm soát bộ nhớ đệm
Next.js
Next.js ngầm đặt các lệnh kiểm soát bộ nhớ đệm dựa trên một số
yếu tố. Tuy nhiên, bạn có thể
ghi đè các lệnh này bằng cách đặt tiêu đề theo cách thủ công trong tệp của bạn
next.config.js. Ví dụ: để đảm bảo một trang không được lưu vào bộ nhớ đệm trong Cloud CDN:
/** @type {import('next').NextConfig} */
const nextConfig = {
headers: async () => [{
source: "/YOUR_PRIVATE_PAGE",
headers: [{
key: "Cache-Control",
value: "private"
}],
}],
};
Angular
Angular SSR không đặt các lệnh kiểm soát bộ nhớ đệm rõ ràng ngay từ đầu. Bạn có thể tự thêm bằng cách chỉ định các tiêu đề kiểm soát bộ nhớ đệm trong các tuyến đường máy chủ. Ví dụ: để cho phép Cloud CDN lưu vào bộ nhớ đệm tất cả các trang trong một giờ:
import { RenderMode, ServerRoute } from '@angular/ssr';
export const serverRoutes: ServerRoute[] = [
{
path: '**',
renderMode: RenderMode.Prerender,
headers: {
'Cache-Control': 'public, max-age=3600',
}
}
];
Hoặc để đảm bảo một trang cụ thể không được lưu vào bộ nhớ đệm:
import { RenderMode, ServerRoute } from '@angular/ssr';
export const serverRoutes: ServerRoute[] = [
// ... other routes
{
path: 'YOUR_PRIVATE_PAGE',
renderMode: RenderMode.Server,
headers: {
'Cache-Control': 'private',
}
}
];
Các lệnh được tôn trọng
Thực thể Cloud CDN của Firebase App Hosting tuân thủ các lệnh kiểm soát bộ nhớ đệm sau đây:
| Lệnh | Yêu cầu | Phản hồi |
|---|---|---|
no-store |
Khi có trong yêu cầu, phản hồi sẽ không được lưu vào bộ nhớ đệm. | Phản hồi có no-store sẽ không được lưu vào bộ nhớ đệm. |
no-cache |
Lệnh yêu cầu no-cache sẽ bị bỏ qua để ngăn các ứng dụng có khả năng bắt đầu hoặc buộc xác thực lại nguồn gốc. |
Phản hồi có no-cache sẽ được lưu vào bộ nhớ đệm nhưng phải được xác thực lại với nguồn gốc trước khi được phân phát. |
public |
Không áp dụng | Bạn không bắt buộc phải có lệnh này để lưu vào bộ nhớ đệm, nhưng tốt nhất là bạn nên đưa lệnh này vào nội dung mà proxy cần lưu vào bộ nhớ đệm. |
private |
Không áp dụng | Phản hồi có lệnh private sẽ không được Cloud CDN lưu vào bộ nhớ đệm, ngay cả khi phản hồi đó được coi là có thể lưu vào bộ nhớ đệm. Các ứng dụng (chẳng hạn như trình duyệt) vẫn có thể lưu kết quả vào bộ nhớ đệm. Hãy sử dụng no-store để ngăn tất cả các phản hồi được lưu vào bộ nhớ đệm. |
max-age=SECONDS |
Lệnh yêu cầu max-age sẽ bị bỏ qua. Phản hồi được lưu vào bộ nhớ đệm sẽ được trả về như thể tiêu đề này không có trong yêu cầu. |
Phản hồi có lệnh max-age sẽ được lưu vào bộ nhớ đệm tối đa là SECONDS đã xác định. |
s-maxage=SECONDS |
Không áp dụng | Phản hồi có lệnh s-maxage sẽ được lưu vào bộ nhớ đệm tối đa là SECONDS đã xác định. Nếu bạn cung cấp cả max-age và s-maxage, thì Cloud CDN sẽ sử dụng s‑maxage. Các phản hồi có lệnh này sẽ không được phân phát khi đã lỗi thời. s-max-age (hai dấu gạch ngang) không hợp lệ cho mục đích lưu vào bộ nhớ đệm. |
max-stale=SECONDS |
Lệnh yêu cầu max-stale quy định mức độ lỗi thời tối đa (tính bằng giây) mà ứng dụng sẵn sàng chấp nhận. Cloud CDN tuân thủ điều này và chỉ trả về phản hồi được lưu vào bộ nhớ đệm đã lỗi thời nếu mức độ lỗi thời của phản hồi nhỏ hơn lệnh max-stale. Nếu không, hệ thống sẽ xác thực lại trước khi phân phát yêu cầu. |
Không áp dụng |
stale-while-revalidate=SECONDS |
Không áp dụng | Phản hồi có stale-while-revalidate sẽ được phân phát cho ứng dụng trong tối đa SECONDS trong khi quá trình xác thực lại diễn ra không đồng bộ. |
must-revalidate |
Không áp dụng | Phản hồi có must-revalidate sẽ được xác thực lại với máy chủ gốc sau khi hết hạn. Các phản hồi có lệnh này sẽ không được phân phát khi đã lỗi thời. |
proxy-revalidate |
Phản hồi có proxy-revalidate sẽ được xác thực lại với máy chủ gốc sau khi hết hạn. Các phản hồi có lệnh này sẽ không được phân phát khi đã lỗi thời. |
|
no-transform |
Không áp dụng | Cloud CDN không áp dụng bất kỳ quá trình chuyển đổi nào. |
Đo lường lưu lượng truy cập được lưu vào bộ nhớ đệm và chưa được lưu vào bộ nhớ đệm
Trong thẻ App Hosting > Mức sử dụng trong bảng điều khiển Firebase, biểu đồ "Cloud CDN – Băng thông gửi đi" cho thấy các byte được lưu vào bộ nhớ đệm và chưa được lưu vào bộ nhớ đệm đã được phân phát, đồng thời có một dấu cho mỗi lần triển khai. Bạn có thể sử dụng biểu đồ này để đo lường hiệu quả của các nỗ lực tối ưu hoá bộ nhớ đệm.
Bạn cũng có thể xem tỷ lệ kết quả tìm kiếm trong bộ nhớ cache cho các tuyến đường cụ thể trong ứng dụng web của mình bằng tính năng Giám sát dựa trên tuyến đường.