Việc truyền bá những việc nên làm và việc không nên làm

Tài liệu này đã đề cập đến tính năng lưu vào bộ nhớ đệm trước đây, nhưng không đủ để giải thích cách làm đúng. Đ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 quá nhiều vào bộ nhớ đệm rất dễ dàng và có khả năng lãng phí dữ liệu cũng như băng thông. Bạn nên lưu ý đến ảnh hưởng của việc tải trọng tải trước vào bộ nhớ đệm đối với trải nghiệm người dùng.

Khi bạn đọc tài liệu này, xin 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 các thao tác khác so với đề xuất ở đây, nhưng những nguyên tắc này được coi là những chế độ mặc định phù hợp.

Nên: lưu trước vào bộ nhớ đệm các tài sản tĩnh quan trọng

Những tài sản phù hợp nhất để lưu trước vào bộ nhớ đệm là những tài sản tĩnh quan trọng, nhưng những tài sản nào được coi là tài sản "quan trọng"? Từ góc độ nhà phát triển, có thể việc coi toàn bộ ứng dụng là "quan trọng", nhưng quan điểm của người dùng là điều quan trọng nhất. Hãy coi các thành phần thiết yếu là những thành phần hoàn toàn cần thiết để mang lại trải nghiệm người dùng:

  • Biểu định kiểu chung.
  • Các tệp JavaScript cung cấp chức năng chung.
  • Ứng dụng shell HTML, nếu đó áp dụng cho cấu trúc của bạn.

Lưu ý: đây là những nguyên tắc chung, không phải những đề xuất cứng nhắc. Khi lưu trước tài sản vào bộ nhớ đệm, tốt nhất là bạn nên ưu tiên thu thập ít hơn thay vì quá nhiều.

Nên: lưu trước vào bộ nhớ đệm bản dự phòng ngoại tuyến cho các trang web nhiều trang

Đối với các trang web thông thường có nhiều trang, 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ỉ sử dụng 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 service worker của mình lưu trước vào 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ó mạng. Một cách để thực hiện việc này trong Workbox là sử dụng chiến lược chỉ mạng với tính năng dự phòng ngoại tuyến, cũng như tận dụng tính năng tải trước điều hướng:

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à chuyển đến một trang không có trong bộ nhớ đệm của họ, thì ít nhất họ sẽ nhận được một số nội dung ngoại tuyến.

Việc nên làm: hãy cân nhắc việc lưu trước trên bộ nhớ đệm

Điều này "có thể" rất quan trọng, nhưng việc lưu trước tài sản chỉ được dùng trong một số trường hợp nhất định lại có một lợi ích tiềm năng. 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 dữ liệu trả trước xuống, với lợi ích suy đoán là việc đẩy nhanh các yêu cầu trong tương lai đối với những 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 điều này. Bạn có thể dễ dàng lãng phí dữ liệu khi làm việc này. Đây nên là quyết định dựa trên dữ liệu. Ngoài ra, hãy tránh lưu trước vào bộ nhớ đệm một cách thường xuyên các tài sản thay đổi thường xuyên, vì người dùng sẽ phải sử dụng thêm dữ liệu mỗi khi mã có thể lưu vào bộ nhớ đệm phát hiện ra 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 để xem người dùng có xu hướng đi đâu. Nếu bạn có bất kỳ nghi ngờ nào về việc lưu trước tài sản theo cách suy đoán, thì đó có thể là một dấu hiệu tốt không nên làm như vậy.

Không nên: lưu trước vào bộ nhớ đệm HTML tĩnh

Nguyên tắc này áp dụng nhiều hơn cho các trang web tĩnh, trong đó các tệp HTML riêng biệt được tạo bởi trình tạo trang web tĩnh hoặc được tạo theo cách thủ công, thay vì được tạo theo phương thức động hoặc do một phần phụ trợ ứng dụng cung cấp. Nếu phần này mô tả cấu trúc của bạn thì có lẽ bạn không nên lưu trước vào bộ nhớ đệm mọi tệp HTML của trang web.

Một vấn đề với việc lưu trước toàn bộ giá trị tệp HTML của trang web là mã đá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 cho hiệu suất, nhưng có thể dẫn đến tình trạng rời bỏ đáng kể bộ nhớ đệm nếu HTML của trang web của bạn thay đổi thường xuyên.

Tuy nhiên, có một vài ngoại lệ đối với quy tắc này. Nếu đang triển khai một trang web nhỏ có một vài tệp HTML tĩnh, thì bạn cũng nên lưu trước tất cả các trang đó vào bộ nhớ đệm để chúng có thể truy cập được khi không có mạng. Nếu bạn có một trang web đặc biệt lớn, hãy cân nhắc đưa trước vào bộ nhớ đệm một vài 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 hoặc biểu tượng trang web thích ứng vào bộ nhớ đệm

Đây ít là một nguyên tắc chung và mang nhiều quy tắc hơn. Hình ảnh thích ứ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ị lại có kích thước màn hình, mật độ pixel và khả năng hỗ trợ các định dạng thay thế. Nếu bạn lưu trước toàn bộ hình ảnh thích ứng vào bộ nhớ đệm, có thể bạn đang lưu trước một vài hình ảnh khi người dùng chỉ có thể tải một trong số chúng xuống.

Biểu tượng trang web có một tình huống tương tự, trong đó các trang web thường triển khai toàn bộ một bộ biểu tượng trang web cho nhiều tình huống. Thông thường, chỉ một biểu tượng trang web được yêu cầu, khiến việc lưu trước toàn bộ biểu tượng trang web trở nên lãng phí tương tự.

Ưu tiên cho người dùng của bạn và đừng lưu trước vào bộ nhớ đệm các bộ hình ảnh và biểu tượng trang web thích ứng. Thay vào đó, hãy sử dụng chức năng 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 không thuộc tập hợp hình ảnh thích ứng hoặc biểu tượng trang web. SVG ít rủi ro hơn về mức sử dụng dữ liệu, một SVG duy nhất hiển thị tối ưu bất kể mật độ pixel của màn hình nhất định.

Không nên: chèn trước các đoạn mã polyfill vào bộ nhớ đệm

Sự khác biệt về hỗ trợ trình duyệt cho API là một thách thức dai dẳng đối với các nhà phát triển web và polyfill là một trong những cách mà thách thức này được đáp ứng. 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 những trình duyệt cần đến polyfill.

Vì việc tải polyfill có điều kiện xảy ra trong thời gian chạy so 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 trò cờ bạc. Một số người dùng sẽ được hưởng lợi, 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 trước các đoạn mã polyfill vào bộ nhớ đệm. Sử dụng tính năng lưu vào bộ nhớ đệm trong thời gian chạy để đảm bảo chúng 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 lưu trước vào bộ nhớ đệm đòi hỏi phải cân nhắc trước những tài sản mà người dùng thực sự cần. Tuy nhiên, bạn chắc chắn có thể xác định chính xác những tài sản đó theo cách ưu tiên hiệu suất và độ tin cậy trong tương lai.

Nếu không chắc về việc một số thành phần có nên được lưu trước vào bộ nhớ đệm hay không, tốt nhất bạn nên yêu cầu Workbox loại trừ các thành phần đó rồi 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 lưu trước vào bộ nhớ đệm sẽ được đề cập chi tiết ở phần sau của tài liệu này, vì vậy, sau này bạn vẫn có thể áp dụng các nguyên tắc này vào logic giới thiệu trước.