Tài liệu này đã đề cập đến quá trình chuẩn bị trước đây nhưng chưa đủ về cách thực hiện việc này. Điều này rất quan trọng, vì bất kể bạn có sử dụng Workbox hay không, việc lưu trước trong bộ nhớ đệm quá nhiều cũng có thể gây lãng phí dữ liệu và băng thông. Bạn nên cẩn thận về mức độ ảnh hưởng của tải trọng lưu vào bộ nhớ đệm trước đó đối với trải nghiệm người dùng.
Khi bạn đọc tài liệu này, hãy hiểu rằng đây là những nguyên tắc chung. Cấu trúc ứng dụng và các yêu cầu của bạn có thể yêu cầu bạn thực hiện những việc khác với những đề xuất ở đây, nhưng những nguyên tắc này sẽ là những nguyên tắc mặc định tốt.
Nên: lưu trước các tài sản tĩnh quan trọng trong bộ nhớ đệm
Những thành phần phù hợp nhất để lưu vào bộ nhớ đệm là những thành phần tĩnh quan trọng, nhưng những thành phần được tính là yếu tố "quan trọng" thành phần không? Từ góc độ nhà phát triển, bạn có thể nghĩ rằng toàn bộ ứng dụng là "quan trọng", nhưng quan điểm của người dùng mới là điều quan trọng nhất. Hãy xem các thành phần quan trọng là những thành phần hoàn toàn cần thiết để cung cấp trải nghiệm người dùng:
- Biểu định kiểu chung.
- Tệp JavaScript cung cấp chức năng chung.
- HTML giao diện ứng dụng, nếu điều đó áp dụng cho kiến trúc của bạn.
Lưu ý: đây là những nguyên tắc chung, không phải là đề xuất cố định. Khi chuẩn bị tài sản vào bộ nhớ đệm, tốt nhất bạn nên lưu ít hơn thay vì thêm nhiều hơn vào bộ nhớ đệm.
Nên: lưu trước dự phòng ngoại tuyến vào bộ nhớ đệm cho các trang web nhiều trang
Đối với các trang web có nhiều trang thông thường, bạn có thể dựa vào chiến lược lưu vào bộ nhớ đệm ưu tiên mạng hoặc chỉ mạng để xử lý các yêu cầu điều hướng.
Trong những trường hợp như vậy, bạn cần đảm bảo trình chạy dịch vụ lưu trước trong bộ nhớ đệm và phản hồi bằng trang dự phòng ngoại tuyến khi người dùng đưa ra yêu cầu điều hướng khi không có kết nối mạng. Bạn có thể thực hiện việc này trong Workbox bằng cách sử dụng chiến lược chỉ dành cho mạng với tính năng dự phòng ngoại tuyến, đồng thời tận dụng tính năng tải trước thao tác:
import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute, Route} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
import * as navigationPreload from 'workbox-navigation-preload';
navigationPreload.enable();
// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);
// The network-only callback should match navigation requests, and
// the handler for the route should use the network-only strategy, but
// fall back to a precached offline page in case the user is offline.
const networkOnlyNavigationRoute = new Route(({request}) => {
return request.mode === 'navigate';
}, new NetworkOnly({
plugins: [
new PrecacheFallbackPlugin({
fallbackURL: '/offline.html'
})
]
}));
registerRoute(networkOnlyNavigationRoute);
Điều này đảm bảo rằng nếu người dùng chuyển sang chế độ ngoại tuyến và điều hướng đến một trang không có trong bộ nhớ đệm, thì ít nhất họ sẽ nhận được một số nội dung ngoại tuyến.
Có thể nên: cân nhắc việc lưu vào bộ nhớ đệm theo suy đoán
"Có thể" lớn lắm đấy nhưng có một lợi ích tiềm năng trong việc lưu trước các tài sản vào bộ nhớ đệm chỉ được dùng trong một số trường hợp nhất định. Hãy nghĩ theo cách này: người dùng sẽ phải trả thêm một số lượt tải xuống dữ liệu trả trước, cùng với lợi ích suy đoán là đẩy nhanh các yêu cầu trong tương lai cho các tài sản đó.
Lưu ý quan trọng: hãy rất cẩn thận nếu bạn quyết định làm việc này. Bạn có thể dễ dàng lãng phí dữ liệu khi làm việc này và bạn nên quyết định dựa trên dữ liệu. Ngoài ra, hãy tránh sử dụng các thành phần thay đổi thường xuyên để lưu vào bộ nhớ đệm theo suy đoán, vì người dùng sẽ phải sử dụng thêm dữ liệu mỗi khi mã lưu vào bộ nhớ đệm phát hiện thấy một bản sửa đổi mới. Quan sát luồng người dùng trong số liệu phân tích của bạn để xem nơi người dùng có xu hướng đi. Nếu bạn có nghi ngờ về việc lưu trước tài sản theo đầu cơ, thì đó có lẽ là một tín hiệu tốt không nên thực hiện việc này.
Có thể không: lưu trước HTML tĩnh
Nguyên tắc này áp dụng nhiều hơn cho các trang web tĩnh nơi các tệp HTML riêng biệt được tạo bằng trình tạo trang web tĩnh hoặc được tạo theo cách thủ công, thay vì được tạo động hoặc do phần phụ trợ của ứng dụng tạo ra. Nếu điều này mô tả cấu trúc của bạn, thì tốt nhất là bạn không nên lưu trước vào bộ nhớ đệm trước mọi tệp HTML cho trang web của mình.
Một vấn đề khi lưu trữ toàn bộ các tệp HTML của toàn bộ trang web vào bộ nhớ đệm là thẻ đánh dấu đã được lưu trước vào bộ nhớ đệm giờ đây sẽ luôn được phân phát từ bộ nhớ đệm sau này cho đến khi trình chạy dịch vụ được cập nhật. Điều này rất tốt về hiệu suất, nhưng có thể dẫn đến nhồi nhét đáng kể vào bộ nhớ đệm nếu HTML của trang web của bạn thường xuyên thay đổi.
Tuy nhiên, có một vài ngoại lệ đối với quy tắc này. Nếu bạn đang triển khai một trang web nhỏ với một vài tệp HTML tĩnh, thì việc lưu trước bộ nhớ đệm tất cả các trang đó vào bộ nhớ đệm để chúng có thể truy cập được khi ngoại tuyến. Nếu bạn có một trang web đặc biệt lớn, hãy cân nhắc việc dự phòng trước một số trang có giá trị cao và dự phòng ngoại tuyến, đồng thời dựa vào tính năng lưu vào bộ nhớ đệm trong thời gian chạy để lưu các trang khác vào bộ nhớ đệm.
Không nên: lưu trước hình ảnh thích ứng hoặc biểu tượng trang web vào bộ nhớ đệm
Đây ít hơn so với một nguyên tắc chung và thiên về quy tắc. Hình ảnh đáp ứng là một giải pháp phức tạp cho một vấn đề phức tạp: bạn có nhiều người dùng trên nhiều thiết bị, mỗi thiết bị có kích thước màn hình, mật độ pixel khác nhau và khả năng hỗ trợ các định dạng thay thế. Nếu bạn lưu trước toàn bộ tập hợp các hình ảnh đáp ứng trong bộ nhớ đệm, bạn có thể lưu trước một số hình ảnh vào bộ nhớ đệm trong khi người dùng chỉ có thể tải xuống một trong số các hình ảnh đó.
Biểu tượng biểu tượng gặp trường hợp tương tự, trong đó các trang web thường triển khai toàn bộ một tập hợp biểu tượng cho các trường hợp khác nhau. Thông thường, chỉ có một biểu tượng trang web được yêu cầu, việc lưu trữ toàn bộ bộ biểu tượng trang web vào bộ nhớ đệm cũng trở nên lãng phí tương tự.
Hãy ưu tiên người dùng của bạn và không lưu trước bộ nhớ đệm hình ảnh thích ứng và bộ biểu tượng trang web. Thay vào đó, hãy chuyển sang lưu vào bộ nhớ đệm trong thời gian chạy. Nếu bạn phải lưu trước hình ảnh vào bộ nhớ đệm, hãy lưu trước vào bộ nhớ đệm những hình ảnh được sử dụng rộng rãi mà không thuộc tập hợp hình ảnh thích ứng hoặc biểu tượng trang web. SVG có ít rủi ro hơn về việc sử dụng dữ liệu, một SVG hiển thị tối ưu bất kể mật độ pixel trên màn hình nhất định là bao nhiêu.
Không nên: chèn sẵn polyfill trong bộ nhớ đệm
Việc thay đổi khả năng hỗ trợ API cho trình duyệt là một thách thức dai dẳng đối với các nhà phát triển web, trong đó mã polyfill là một trong những cách để vượt qua thách thức này. Một cách để giảm thiểu chi phí hiệu suất của polyfill là kiểm tra tính năng và chỉ tải polyfill cho các trình duyệt cần chúng.
Vì việc tải polyfill theo cách có điều kiện xảy ra trong thời gian chạy đối với môi trường hiện tại, nên việc lưu trước các polyfill vào bộ nhớ đệm là một sự can thiệp. Một số người dùng sẽ hưởng lợi từ việc này, trong khi những người khác lại lãng phí băng thông cho những đoạn mã polyfill không cần thiết.
Đừng chèn sẵn polyfill trong bộ nhớ đệm. Dựa vào tính năng lưu vào bộ nhớ đệm trong thời gian chạy để đảm bảo chỉ được lưu vào bộ nhớ đệm trong các trình duyệt yêu cầu để tránh lãng phí dữ liệu.
Kết luận
Việc chuẩn bị trước khi lưu trữ yêu cầu phải xem xét kỹ những tài sản mà người dùng thực sự cần. Tuy nhiên, bạn hoàn toàn có thể chuẩn bị sẵn sàng theo cách ưu tiên hiệu suất và độ tin cậy trong tương lai.
Nếu không chắc chắn về việc có nên lưu trước các thành phần nhất định vào bộ nhớ đệm hay không, thì tốt nhất là bạn nên yêu cầu Workbox loại trừ những thành phần đó và tạo một tuyến lưu vào bộ nhớ đệm trong thời gian chạy để xử lý chúng. Dù bằng cách nào thì việc chuẩn bị lưu trữ cũng sẽ được đề cập chi tiết ở phần sau của tài liệu này, vì vậy, bạn sẽ có thể áp dụng các nguyên tắc này cho logic lưu trữ trước đó trong tương lai.