Lưu vào bộ nhớ đệm trong thời gian chạy đề cập đến việc thêm dần các phản hồi vào bộ nhớ đệm "khi bạn di chuyển". Mặc dù việc lưu vào bộ nhớ đệm trong thời gian chạy không giúp đảm bảo độ tin cậy của lưu lượng truy cập hiện tại thì mã này có thể giúp các yêu cầu trong tương lai cho cùng một URL đáng tin cậy hơn.
Bộ nhớ đệm HTTP của trình duyệt là một ví dụ về việc lưu vào bộ nhớ đệm trong thời gian chạy; quảng cáo chỉ được điền sẵn sau khi yêu cầu một URL nhất định. Tuy nhiên, Service worker cho phép bạn triển khai tính năng lưu vào bộ nhớ đệm trong thời gian chạy vượt xa những gì chỉ riêng bộ nhớ đệm HTTP có thể cung cấp.
Xây dựng chiến lược
Khác với chuẩn bị (luôn cố gắng để phân phối một tập hợp các tệp được xác định trước từ một bộ nhớ đệm), việc lưu vào bộ nhớ đệm trong thời gian chạy có thể kết hợp truy cập mạng và bộ nhớ đệm theo nhiều cách. Mỗi kết hợp thường được gọi là chiến lược lưu vào bộ nhớ đệm. Các chiến lược chính lưu vào bộ nhớ đệm bao gồm:
- Ưu tiên mạng
- Ưu tiên bộ nhớ đệm
- Đã cũ trong khi xác thực lại
Ưu tiên mạng
Trong phương pháp này, trước tiên trình chạy dịch vụ của bạn cố gắng truy xuất phản hồi từ mạng. Nếu yêu cầu mạng thành công thì thật tuyệt! Phản hồi được trả về cho ứng dụng web của bạn và bản sao phản hồi này sẽ được lưu trữ bằng Bộ nhớ đệm API – tạo mục nhập mới hoặc cập nhật mục nhập trước đó cho cùng một mục nhập URL.
Nếu yêu cầu kết nối mạng không thành công hoàn toàn, hoặc mất quá nhiều thời gian để trả về một phản hồi, thì phản hồi gần đây nhất từ bộ nhớ đệm sẽ được trả về thay thế.
Ưu tiên bộ nhớ đệm
Chiến lược ưu tiên bộ nhớ đệm thực sự trái ngược với chiến lược ưu tiên mạng. Trong phần này khi dịch vụ của bạn chặn một yêu cầu, trước tiên trình chạy dịch vụ sẽ sử dụng Bộ nhớ đệm Storage API (API Bộ nhớ) để xem có phản hồi nào được lưu vào bộ nhớ đệm hay không. Nếu có, phản hồi đó được trả về ứng dụng web.
Tuy nhiên, nếu thiếu bộ nhớ đệm thì trình chạy dịch vụ sẽ truy cập mạng và cố gắng truy xuất phản hồi tại đó. Giả sử yêu cầu mạng đó là thành công, nó sẽ được trả về ứng dụng web của bạn và một bản sao sẽ được lưu trong bộ nhớ đệm. Chiến dịch này bản sao đã lưu vào bộ nhớ đệm sẽ được sử dụng để bỏ qua mạng vào lần tiếp theo bạn gửi yêu cầu cho cùng các URL được tạo.
Đã cũ trong khi xác thực lại
Quy trình cũ trong khi xác thực lại là hoạt động kết hợp. Khi sử dụng AdSense, dịch vụ của bạn worker sẽ ngay lập tức kiểm tra phản hồi được lưu vào bộ nhớ đệm và nếu tìm thấy phản hồi đó, hãy chuyển ứng dụng trở lại ứng dụng web của bạn.
Trong thời gian chờ đợi, bất kể có kết quả trùng khớp trong bộ nhớ đệm hay không, dịch vụ của bạn worker cũng kích hoạt một yêu cầu mạng để lấy lại trạng thái "mới" của bạn. Chiến dịch này phản hồi được dùng để cập nhật mọi phản hồi đã lưu vào bộ nhớ đệm trước đó. Nếu bộ nhớ đệm ban đầu việc kiểm tra có bị bỏ sót hay không, một bản sao của phản hồi mạng cũng được chuyển lại cho trang web của bạn .
Tại sao bạn nên sử dụng Workbox?
Những chiến lược lưu vào bộ nhớ đệm này tương đương với những công thức mà bạn thường phải viết lại nhiều lần trong trình chạy dịch vụ của chính bạn. Thay vì dùng đến rằng Workbox cung cấp theo gói thư viện chiến lược, sẵn sàng để bạn chuyển đến trình chạy dịch vụ của mình.
Workbox cũng hỗ trợ tạo phiên bản, cho phép bạn tự động hết hạn các mục nhập đã lưu vào bộ nhớ đệm hoặc thông báo cho ứng dụng web của bạn khi nội dung cập nhật vào mục nhập đã lưu trong bộ nhớ đệm trước đó xảy ra.
Nội dung nào của bạn nên được lưu vào bộ nhớ đệm bằng chiến lược nào?
Việc lưu vào bộ nhớ đệm trong thời gian chạy có thể được coi là một công cụ bổ sung cho việc lưu vào bộ nhớ đệm. Nếu tất cả nội dung đã được lưu trước vào bộ nhớ đệm và vậy là bạn đã hoàn tất – không cần gì được lưu vào bộ nhớ đệm trong thời gian chạy. Có thể đối với bất kỳ ứng dụng web tương đối phức tạp nào, bạn có thể sẽ không lưu mọi thứ vào bộ nhớ đệm.
Tệp nội dung nghe nhìn lớn hơn, nội dung được phân phát từ một máy chủ lưu trữ của bên thứ ba như CDN, hoặc phản hồi của API, đây chỉ là một vài ví dụ về các loại thành phần không được được lưu trước vào bộ nhớ đệm một cách hiệu quả. Sử dụng bảng điều khiển Mạng trong Công cụ cho nhà phát triển để xác định các yêu cầu thuộc danh mục này và đối với mỗi trường hợp, hãy nghĩ xem độ mới mẻ so với độ tin cậy là phù hợp.
Sử dụng tính năng cũ trong khi xác thực lại để ưu tiên độ tin cậy hơn độ mới
Vì chiến lược cũ trong khi xác thực lại sẽ trả về phản hồi đã lưu vào bộ nhớ đệm gần như ngay lập tức—sau khi bộ nhớ đệm đã được điền thông qua yêu cầu đầu tiên—bạn sẽ kết thúc đạt được hiệu suất nhanh đáng tin cậy khi sử dụng chiến lược này. Điều này đi kèm với sự đánh đổi từ việc nhận lại dữ liệu phản hồi có thể lỗi thời so với nội dung nào được truy xuất từ mạng. Sử dụng chiến lược này hiệu quả nhất đối với những thành phần như ảnh hồ sơ người dùng hoặc phản hồi ban đầu của API được dùng để điền sẵn khung hiển thị, khi bạn biết rằng việc hiển thị nội dung nào đó ngay lập tức là quan trọng, thậm chí nếu đó là một giá trị cũ.
Sử dụng phương pháp ưu tiên mạng để ưu tiên độ mới hơn là độ tin cậy
Ở một khía cạnh nào đó, việc áp dụng chiến lược ưu tiên mạng chính là việc chấp nhận thất bại trong trận chiến của mình đối với mạng—nó được ưu tiên, nhưng kèm theo đó là sự không chắc chắn về độ tin cậy. Đối với một số loại nội dung nhất định, việc nhìn thấy phản hồi mới là ưu tiên nhận lại thông tin cũ. Bạn có thể muốn làm mới khi gửi một yêu cầu API cho nội dung của một bài viết được cập nhật thường xuyên, cho thực thể.
Bằng cách sử dụng chiến lược ưu tiên mạng bên trong một trình chạy dịch vụ, thay vì chỉ truy cập trực tiếp vào mạng, bạn có lợi ích là có thể quay lại nội dung nào đó, ngay cả khi đó có thể là phản hồi lỗi thời. Bạn sẽ không nhanh một cách đáng tin cậy, nhưng ít nhất bạn sẽ đáng tin cậy khi không có mạng.
Sử dụng chế độ ưu tiên bộ nhớ đệm cho các URL đã tạo phiên bản
Trong chiến lược ưu tiên bộ nhớ đệm, một khi một mục nhập được lưu vào bộ nhớ đệm, mục nhập đó sẽ không bao giờ được cập nhật. Để làm được việc đó
hãy đảm bảo rằng bạn chỉ sử dụng tài sản đó với những thành phần mà bạn biết là có khả năng sẽ không
thay đổi. Cụ thể, tính năng này hoạt động hiệu quả nhất với những URL có chứa phiên bản
thông tin đó—cũng là một loại URL cũng sẽ được phân phát với
Tiêu đề phản hồi Cache-Control: max-age=31536000.