Buộc hết thời gian chờ mạng

Đôi khi bạn có kết nối mạng, nhưng kết nối đó quá chậm hoặc kết nối nói dối với bạn rằng bạn đang trực tuyến. Trong những trường hợp như vậy khi một trình chạy dịch vụ nằm trong danh sách kết hợp, chiến lược lưu vào bộ nhớ đệm ưu tiên mạng có thể mất quá nhiều thời gian để nhận được phản hồi từ mạng hoặc yêu cầu sẽ bị treo và vòng quay tải sẽ quay liên tục cho đến khi bạn nhận được trang lỗi.

Cho dù trong tình huống nào, có những trường hợp trong đó việc quay lại phản hồi được lưu vào bộ nhớ đệm gần đây nhất cho một nội dung hoặc trang sau một khoảng thời gian nhất định sẽ được ưu tiên hơn — nhưng cũng có một vấn đề khác mà Workbox có thể trợ giúp.

Sử dụng networkTimeoutSeconds

Bạn có thể buộc các yêu cầu mạng hết thời gian chờ khi sử dụng các chiến lược NetworkFirst hoặc NetworkOnly. Các chiến lược này cung cấp tuỳ chọn networkTimeoutSeconds. Tuỳ chọn này chỉ định số giây mà trình chạy dịch vụ phải chờ cho đến khi phản hồi mạng đến trước khi thoát và trả về phiên bản lưu vào bộ nhớ đệm gần đây nhất:

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

// Only wait for three seconds before returning the last
// cached version of the requested page.
const navigationRoute = new NavigationRoute(new NetworkFirst({
  networkTimeoutSeconds: 3,
  cacheName: 'navigations'
}));

registerRoute(navigationRoute);

Mã ở trên hướng dẫn trình chạy dịch vụ của bạn tránh mọi yêu cầu điều hướng ưu tiên mạng và sử dụng phiên bản được lưu vào bộ nhớ đệm gần đây nhất sau 3 giây. Khi được sử dụng cùng với các yêu cầu điều hướng, tính năng này đảm bảo quyền truy cập vào phản hồi gần đây nhất được lưu vào bộ nhớ đệm của mọi trang đã truy cập trước đó.

Tuy nhiên, điều gì sẽ xảy ra nếu trang bạn đang truy cập không có phản hồi cũ trong bộ nhớ đệm? Trong những trường hợp như vậy, bạn có thể thiết lập phản hồi dự phòng cho trang HTML ngoại tuyến chung:

import {registerRoute, NavigationRoute} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';

// Hardcode the fallback cache name and the offline
// HTML fallback's URL for failed responses
const FALLBACK_CACHE_NAME = 'offline-fallback';
const FALLBACK_HTML = '/offline.html';

// Cache the fallback HTML during installation.
self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(FALLBACK_CACHE_NAME).then((cache) => cache.add(FALLBACK_HTML)),
  );
});

// Apply a network-only strategy to navigation requests.
// If offline, or if more than five seconds pass before there's a
// network response, fall back to the cached offline HTML.
const networkWithFallbackStrategy = new NetworkOnly({
  networkTimeoutSeconds: 5,
  plugins: [
    {
      handlerDidError: async () => {
        return await caches.match(FALLBACK_HTML, {
          cacheName: FALLBACK_CACHE_NAME,
        });
      },
    },
  ],
});

// Register the route to handle all navigations.
registerRoute(new NavigationRoute(networkWithFallbackStrategy));

Điều này hiệu quả vì khi bạn sử dụng networkTimeoutSeconds trong chiến lược NetworkFirst, trình xử lý của bạn sẽ trả về phản hồi lỗi nếu hết thời gian chờ và không có kết quả khớp trong bộ nhớ đệm cho URL. Trong trường hợp đó, trình bổ trợ Hộp công việc handlerDidError có thể cung cấp phản hồi chung làm phương án dự phòng.

Chờ bao lâu thì quá lâu?

Khi buộc thời gian chờ cho các yêu cầu (đặc biệt là các yêu cầu chỉ đường) bạn nên cân bằng giữa việc không để người dùng chờ quá lâu và không cho hết thời gian quá nhanh. Việc chờ quá lâu và bạn có thể gặp rủi ro khiến người dùng gặp phải tình trạng kết nối chậm bị thoát trước khi hết thời gian chờ. Hết thời gian chờ quá nhanh và bạn có thể kết thúc việc phân phối nội dung cũ từ bộ nhớ đệm một cách không cần thiết.

Câu trả lời đúng là "còn tuỳ". Nếu bạn đang chạy một trang web, chẳng hạn như blog và không cập nhật nội dung quá thường xuyên, thì câu trả lời đúng có thể là không nên đợi quá nhiều, vì mọi nội dung trong bộ nhớ đệm đều có thể là "mới" đủ. Tuy nhiên, đối với các trang web và ứng dụng web có tính tương tác cao hơn, tốt nhất bạn nên chờ thêm một chút và tránh phân phát quá nhanh dữ liệu cũ từ bộ nhớ đệm của trình chạy dịch vụ.

Nếu bạn đang ghi lại các chỉ số trong trường, hãy xem phân vị thứ 75 của Thời gian cho đến byte đầu tiên (TTFB) và điểm Hiển thị nội dung đầu tiên (FCP) để biết cơ sở người dùng của bạn có thể phải chờ lâu hơn để yêu cầu điều hướng. Điều đó có thể giúp bạn hiểu rõ hơn về vị trí cần vẽ.