Lưu nội dung ứng dụng vào bộ nhớ đệm

Cloud CDN là một phần quan trọng trong dịch vụ hỗ trợ của App Hosting cho ứng dụng web của bạn. Mọi yêu cầu đến phần phụ trợ của bạn đề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 lập tức cho người dùng, bỏ qua 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 CDN cơ bản trên đám mây do App Hosting thiết lập và không thể chỉnh sửa, nhưng bạn có thể làm một số việc để tối ưu hoá việc lưu vào bộ nhớ đệm nhằm tăng tốc độ tải trang, giảm nội dung không được lưu vào bộ nhớ đệm nhưng vẫn bị tính phí và giảm thiểu lưu lượng truy cập đến 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Ả điều kiện sau đây đều đúng:

  1. Yêu cầu là GET

  2. Phản hồi có mã trạng thái là 200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451 hoặc 501.

  3. Phản hồi có tiêu đề Cache-Control với lệnh max-age hoặc s-maxage hoặc tiêu đề Expires có dấu thời gian trong tương lai.

  4. Phản hồi có tiêu đề Age hoặc tiêu đề Cache-Control với lệnh public rõ ràng.

  5. Phản hồi có kích thước nhỏ hơn hoặc bằng 10 MiB.

KHÔNG CÓ điều kiện nào sau đây là đúng:

  1. Phản hồi có tiêu đề Set-Cookie

  2. Phản hồi có tiêu đề Vary với giá trị khác với Accept, 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ặc Next-Router-Segment-Prefetch.

  3. Phản hồi có tiêu đề Cache-Control với lệnh no-store hoặc private.

  4. Yêu cầu có tiêu đề Cache-Control với lệnh no-store.

  5. 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 đặt các lệnh kiểm soát bộ nhớ đệm một cách ngầm dựa trên một số yếu tố. Tuy nhiên, bạn có thể ghi đè các giá trị này bằng cách thiết lập tiêu đề theo cách thủ công trong tệp 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ể thêm tiêu đề của riêng mình bằng cách chỉ định tiêu đề kiểm soát bộ nhớ đệm trong các tuyến máy chủ. Ví dụ: để cho phép Cloud CDN lưu tất cả các trang vào bộ nhớ đệm 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',
    }
  }
];

Lệnh được tôn trọng

Phiên bản CDN trên đám mây của App Hosting Firebase tuân theo các lệnh điều khiển bộ nhớ đệm sau:

Chỉ thị Yêu cầu Phản hồi
no-store Khi có trong một 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 không được lưu vào bộ nhớ đệm.
no-cache Lệnh yêu cầu no-cache bị bỏ qua để ngăn ứng dụng có thể bắt đầu hoặc buộc xác thực lại nguồn gốc. Phản hồi có no-cache được lưu vào bộ nhớ đệm nhưng phải được xác thực lại bằng nguồn gốc trước khi phân phát.
public Không áp dụng Bạn không bắt buộc phải sử dụng lệnh này để có thể lưu vào bộ nhớ đệm, nhưng tốt nhất là bạn nên sử dụng lệnh này cho nội dung mà proxy sẽ lưu vào bộ nhớ đệm.
private Không áp dụng Cloud CDN không lưu phản hồi có lệnh private vào bộ nhớ đệm, ngay cả khi phản hồi đó được coi là có thể lưu vào bộ nhớ đệm. Ứ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. 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. Hệ thống sẽ trả về phản hồi đã lưu trong bộ nhớ đệm như thể tiêu đề này không có trong yêu cầu. Phản hồi có lệnh max-age được lưu vào bộ nhớ đệm trong vòng SECONDS đã xác định.
s-maxage=SECONDS Không áp dụng Phản hồi có lệnh s-maxage được lưu vào bộ nhớ đệm trong vòng SECONDS đã xác định. Nếu cả max-ages-maxage đều có, 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 cũ. s-max-age (hai dấu gạch nối) không hợp lệ cho mục đích lưu vào bộ nhớ đệm.
max-stale=SECONDS Chỉ thị yêu cầu max-stale chỉ đị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ũ trong bộ nhớ đệm nếu độ cũ 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 đượ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 Sau khi hết hạn, phản hồi có must-revalidate sẽ được xác thực lại với máy chủ gốc. Các phản hồi có lệnh này sẽ không được phân phát cũ.
proxy-revalidate Sau khi hết hạn, phản hồi có proxy-revalidate sẽ được xác thực lại với máy chủ gốc. Các phản hồi có lệnh này sẽ không được phân phát cũ.
no-transform Không áp dụng Cloud CDN không áp dụng bất kỳ phép biến đổi nào.

Đo lường lưu lượng truy cập được lưu vào bộ nhớ đệm và không được lưu vào bộ nhớ đệm

Biểu đồ "Cloud CDN – Băng thông đi" trong thẻ Sử dụng của bảng điều khiển App Hosting cho biết số byte được lưu vào bộ nhớ đệm và không đượ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 mức độ hiệu quả của các nỗ lực tối ưu hoá bộ nhớ đệm.