Lưu tài nguyên vào bộ nhớ đệm trong thời gian chạy

Một số nội dung trong ứng dụng web của bạn có thể không được sử dụng thường xuyên, rất lớn hoặc thay đổi dựa trên thiết bị của người dùng (chẳng hạn như hình ảnh thích ứng) hoặc ngôn ngữ. Đây là những trường hợp mà tính năng lưu trước vào bộ nhớ đệm có thể là một giải pháp chống lại mô hình và bạn nên sử dụng tính năng lưu vào bộ nhớ đệm trong thời gian chạy.

Trong Workbox, bạn có thể xử lý việc lưu vào bộ nhớ đệm trong thời gian chạy cho các thành phần bằng cách sử dụng mô-đun workbox-routing để khớp các tuyến và xử lý chiến lược lưu vào bộ nhớ đệm cho các thành phần đó bằng mô-đun workbox-strategies.

Chiến lược lưu vào bộ nhớ đệm

Bạn có thể xử lý hầu hết các tuyến đối với tài sản bằng một trong các chiến lược lưu tích hợp sẵn vào bộ nhớ đệm. Những tính năng này đã được đề cập chi tiết ở phần trước trong tài liệu này, nhưng sau đây là một số điểm đáng tóm tắt:

  • Cũ trong khi xác thực lại sử dụng phản hồi đã lưu vào bộ nhớ đệm cho một yêu cầu nếu có và cập nhật bộ nhớ đệm ở chế độ nền bằng phản hồi từ mạng. Do đó, nếu nội dung không được lưu vào bộ nhớ đệm, thì hệ thống sẽ đợi phản hồi mạng và sử dụng nội dung đó. Đây là một chiến lược khá an toàn vì chiến lược này thường xuyên cập nhật các mục trong bộ nhớ đệm dựa trên chiến lược này. Nhược điểm là tính năng này luôn yêu cầu nội dung từ mạng trong nền.
  • Tính năng Network First (Ưu tiên mạng) sẽ cố gắng nhận phản hồi từ mạng trước. Nếu nhận được phản hồi, phản hồi đó sẽ được chuyển đến trình duyệt và lưu vào bộ nhớ đệm. Nếu yêu cầu mạng không thành công, phản hồi được lưu vào bộ nhớ đệm gần đây nhất sẽ được sử dụng, cho phép truy cập ngoại tuyến vào tài sản.
  • Bộ nhớ đệm trước tiên sẽ kiểm tra bộ nhớ đệm để tìm phản hồi trước tiên rồi sử dụng phản hồi đó nếu có. Nếu yêu cầu không có trong bộ nhớ đệm thì mạng sẽ được sử dụng và mọi phản hồi hợp lệ sẽ được thêm vào bộ nhớ đệm trước khi được chuyển đến trình duyệt.
  • Chế độ Chỉ mạng buộc phản hồi phải đến từ mạng.
  • Chế độ Chỉ bộ nhớ đệm buộc phản hồi phải đến từ bộ nhớ đệm.

Bạn có thể áp dụng các chiến lược này cho một số yêu cầu bằng các phương thức do workbox-routing cung cấp.

Áp dụng chiến lược lưu vào bộ nhớ đệm bằng tính năng so khớp tuyến

workbox-routing hiển thị phương thức registerRoute để so khớp các tuyến và xử lý các tuyến đó bằng chiến lược lưu vào bộ nhớ đệm. registerRoute chấp nhận đối tượng Route chấp nhận hai đối số:

  1. Một chuỗi, biểu thức chính quy hoặc lệnh gọi lại so khớp để chỉ định tiêu chí so khớp tuyến.
  2. Trình xử lý cho tuyến (thường là một chiến lược do workbox-strategies cung cấp).

Các lệnh gọi lại so khớp được ưu tiên để so khớp các tuyến vì chúng cung cấp một đối tượng ngữ cảnh bao gồm đối tượng Request, chuỗi URL yêu cầu, sự kiện tìm nạp và giá trị boolean cho biết yêu cầu có phải là yêu cầu cùng nguồn gốc hay không.

Sau đó, trình xử lý sẽ xử lý tuyến trùng khớp. Trong ví dụ sau, một tuyến mới được tạo khớp với các yêu cầu hình ảnh cùng nguồn gốc sắp tới, áp dụng bộ nhớ đệm trước, sau đó quay lại chiến lược mạng.

// sw.js
import { registerRoute, Route } from 'workbox-routing';
import { CacheFirst } from 'workbox-strategies';

// A new route that matches same-origin image requests and handles
// them with the cache-first, falling back to network strategy:
const imageRoute = new Route(({ request, sameOrigin }) => {
  return sameOrigin && request.destination === 'image'
}, new CacheFirst());

// Register the new route
registerRoute(imageRoute);

Sử dụng nhiều bộ nhớ đệm

Workbox cho phép bạn nhóm các phản hồi đã lưu vào bộ nhớ đệm vào các thực thể Cache riêng biệt bằng cách sử dụng tuỳ chọn cacheName có trong các chiến lược đi kèm.

Trong ví dụ sau, hình ảnh sử dụng chiến lược cũ trong khi xác thực lại, trong khi nội dung CSS và JavaScript sử dụng chiến lược ưu tiên bộ nhớ đệm để quay lại chiến lược mạng. Tuyến cho mỗi tài sản đặt các phản hồi vào các bộ nhớ đệm riêng biệt bằng cách thêm thuộc tính cacheName.

// sw.js
import { registerRoute, Route } from 'workbox-routing';
import { CacheFirst, StaleWhileRevalidate } from 'workbox-strategies';

// Handle images:
const imageRoute = new Route(({ request }) => {
  return request.destination === 'image'
}, new StaleWhileRevalidate({
  cacheName: 'images'
}));

// Handle scripts:
const scriptsRoute = new Route(({ request }) => {
  return request.destination === 'script';
}, new CacheFirst({
  cacheName: 'scripts'
}));

// Handle styles:
const stylesRoute = new Route(({ request }) => {
  return request.destination === 'style';
}, new CacheFirst({
  cacheName: 'styles'
}));

// Register routes
registerRoute(imageRoute);
registerRoute(scriptsRoute);
registerRoute(stylesRoute);
Ảnh chụp màn hình danh sách các thực thể của Bộ nhớ đệm trong thẻ ứng dụng của Công cụ cho nhà phát triển của Chrome. Có ba bộ nhớ đệm riêng biệt được hiển thị: một bộ nhớ đệm có tên "scripts", còn một bộ nhớ khác có tên "styles" (kiểu) và bộ nhớ cuối cùng có tên là "images".
Trình xem bộ nhớ đệm trong Bảng điều khiển ứng dụng của Công cụ của Chrome cho nhà phát triển. Phản hồi cho các loại nội dung khác nhau được lưu trữ trong bộ nhớ đệm riêng biệt.

Đặt ngày hết hạn cho các mục trong bộ nhớ đệm

Lưu ý đến hạn mức bộ nhớ khi quản lý(các) bộ nhớ đệm của trình chạy dịch vụ. ExpirationPlugin đơn giản hoá việc bảo trì bộ nhớ đệm và được workbox-expiration hiển thị. Để sử dụng công cụ này, hãy chỉ định trong cấu hình cho chiến lược lưu vào bộ nhớ đệm:

// sw.js
import { registerRoute, Route } from 'workbox-routing';
import { CacheFirst } from 'workbox-strategies';
import { ExpirationPlugin } from 'workbox-expiration';

// Evict image cache entries older thirty days:
const imageRoute = new Route(({ request }) => {
  return request.destination === 'image';
}, new CacheFirst({
  cacheName: 'images',
  plugins: [
    new ExpirationPlugin({
      maxAgeSeconds: 60 * 60 * 24 * 30,
    })
  ]
}));

// Evict the least-used script cache entries when
// the cache has more than 50 entries:
const scriptsRoute = new Route(({ request }) => {
  return request.destination === 'script';
}, new CacheFirst({
  cacheName: 'scripts',
  plugins: [
    new ExpirationPlugin({
      maxEntries: 50,
    })
  ]
}));

// Register routes
registerRoute(imageRoute);
registerRoute(scriptsRoute);

Việc tuân thủ hạn mức bộ nhớ có thể phức tạp. Bạn nên xem xét những người dùng có thể đang bị áp lực về bộ nhớ hoặc muốn sử dụng bộ nhớ một cách hiệu quả nhất. Các cặp ExpirationPlugin của Workbox có thể giúp bạn đạt được mục tiêu đó.

Những điểm cần lưu ý trên nhiều nguồn gốc

Sự tương tác giữa trình chạy dịch vụ và thành phần trên nhiều nguồn gốc khác biệt đáng kể so với thành phần có cùng nguồn gốc. Tính năng Chia sẻ tài nguyên trên nhiều nguồn gốc (CORS) rất phức tạp và sự phức tạp đó còn kéo dài sang cách bạn xử lý tài nguyên trên nhiều nguồn gốc trong một trình chạy dịch vụ.

Phản hồi mờ

Khi gửi yêu cầu trên nhiều nguồn gốc ở chế độ no-cors, phản hồi có thể được lưu trữ trong bộ nhớ đệm của trình chạy dịch vụ và thậm chí được trình duyệt sử dụng trực tiếp. Tuy nhiên, chính nội dung phản hồi sẽ không được đọc qua JavaScript. Đây được gọi là phản hồi mờ.

Phản hồi mờ là biện pháp bảo mật nhằm ngăn chặn việc kiểm tra tài sản trên nhiều nguồn gốc. Bạn vẫn có thể gửi yêu cầu cho các thành phần trên nhiều nguồn gốc và thậm chí là lưu chúng vào bộ nhớ đệm, nhưng chỉ có điều bạn không thể đọc nội dung phản hồi hay thậm chí đọc mã trạng thái của nội dung đó!

Hãy nhớ chọn sử dụng chế độ CORS

Ngay cả khi bạn tải các thành phần trên nhiều nguồn gốc có đặt các tiêu đề CORS được phép đọc để đọc phản hồi, thì phần nội dung của phản hồi trên nhiều nguồn gốc vẫn có thể bị mờ. Ví dụ: HTML sau đây sẽ kích hoạt các yêu cầu no-cors dẫn đến phản hồi mờ bất kể tiêu đề CORS nào được thiết lập:

<link rel="stylesheet" href="https://example.com/path/to/style.css">
<img src="https://example.com/path/to/image.png">

Để kích hoạt một cách rõ ràng một yêu cầu cors sẽ tạo ra phản hồi không mờ, bạn cần chọn sử dụng chế độ CORS một cách rõ ràng bằng cách thêm thuộc tính crossorigin vào HTML của mình:

<link crossorigin="anonymous" rel="stylesheet" href="https://example.com/path/to/style.css">
<img crossorigin="anonymous" src="https://example.com/path/to/image.png">

Điều này rất quan trọng cần ghi nhớ thời điểm các tuyến trong tài nguyên phụ của trình chạy dịch vụ lưu vào bộ nhớ đệm được tải trong thời gian chạy.

Hộp công việc không thể lưu các phản hồi mờ vào bộ nhớ đệm

Theo mặc định, Workbox áp dụng phương pháp thận trọng để lưu các phản hồi không rõ ràng vào bộ nhớ đệm. Vì không thể kiểm tra mã phản hồi để tìm phản hồi mờ, việc lưu phản hồi lỗi vào bộ nhớ đệm có thể khiến trải nghiệm liên tục bị hỏng nếu sử dụng chiến lược ưu tiên bộ nhớ đệm hoặc chỉ lưu vào bộ nhớ đệm.

Nếu cần lưu một phản hồi mờ vào bộ nhớ đệm trong Workbox, bạn nên sử dụng chiến lược ưu tiên mạng hoặc lỗi thời trong khi xác thực để xử lý phản hồi đó. Có, điều này có nghĩa là mạng lưới sẽ vẫn yêu cầu thành phần mỗi lần, nhưng thành phần này đảm bảo rằng phản hồi không thành công sẽ không tồn tại và cuối cùng sẽ được thay thế bằng phản hồi hữu dụng.

Nếu bạn sử dụng một chiến lược lưu vào bộ nhớ đệm khác và một phản hồi không rõ ràng được trả về, Workbox sẽ cảnh báo bạn rằng phản hồi này không được lưu vào bộ nhớ đệm khi ở chế độ phát triển.

Buộc lưu các phản hồi mờ vào bộ nhớ đệm

Nếu hoàn toàn chắc chắn rằng bạn muốn lưu một phản hồi mờ vào bộ nhớ đệm bằng chiến lược ưu tiên bộ nhớ đệm hoặc chỉ lưu vào bộ nhớ đệm, bạn có thể buộc Workbox thực hiện việc này bằng mô-đun workbox-cacheable-response:

import {Route, registerRoute} from 'workbox-routing';
import {NetworkFirst, StaleWhileRevalidate} from 'workbox-strategies';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';

const cdnRoute = new Route(({url}) => {
  return url === 'https://cdn.google.com/example-script.min.js';
}, new CacheFirst({
  plugins: [
    new CacheableResponsePlugin({
      statuses: [0, 200]
    })
  ]
}))

registerRoute(cdnRoute);

Phản hồi Opaque và API navigator.storage

Để tránh rò rỉ thông tin trên nhiều miền, sẽ có khoảng đệm đáng kể được thêm vào kích thước của phản hồi mờ dùng để tính giới hạn hạn mức bộ nhớ. Điều này ảnh hưởng đến cách API navigator.storage báo cáo hạn mức bộ nhớ.

Khoảng đệm này khác nhau tuỳ theo trình duyệt, nhưng đối với Chrome, kích thước tối thiểu mà bất kỳ phản hồi mờ đục nào được lưu vào bộ nhớ đệm đóng góp vào tổng bộ nhớ được sử dụng là khoảng 7 megabyte. Bạn nên lưu ý điều này khi xác định số lượng phản hồi mờ mà bạn muốn lưu vào bộ nhớ đệm, vì bạn có thể dễ dàng vượt quá hạn mức bộ nhớ sớm hơn nhiều so với dự kiến.