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 của bạn cho bạn biết 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ụ đang 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 đang tải sẽ quay liên tục — cho đến khi bạn nhận được một trang lỗi.

Dù trong tình huống nào thì có những trường hợp bạn nên 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. Tuy nhiên, Workbox vẫn có thể giúp giải quyết một vấn đề khác.

Sử dụng networkTimeoutSeconds

Bạn có thể buộc hết thời gian chờ cho các yêu cầu mạng khi sử dụng 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à worker sẽ chờ cho phản hồi mạng đến trước khi giải cứu và trả về phiên bản được 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 xử lý 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, chức năng này đảm bảo quyền truy cập vào phản hồi được lưu vào bộ nhớ đệm gần đây nhất 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ũ hơn 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));

Cách này hiệu quả vì khi bạn sử dụng networkTimeoutSeconds trong chiến lược NetworkFirst, trình xử lý 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 với bộ nhớ đệm cho URL. Nếu điều đó xảy ra, trình bổ trợ Workbox handlerDidError có thể cung cấp phản hồi chung dưới dạng một phương án dự phòng.

Mất bao lâu để đợi?

Khi buộc thiết lập thời gian chờ cho các yêu cầu (đặc biệt là yêu cầu điều hướng), bạn muốn tạo sự cân bằng hợp lý giữa việc không để người dùng chờ quá lâu cũng như không hết thời gian chờ quá nhanh. Hãy chờ quá lâu, có nguy cơ người dùng trên các kết nối chậm bị trả lại trước khi hết thời gian chờ. 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 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 chờ đợi quá nhiều, vì bất kỳ nội dung nào trong bộ nhớ đệm đều có thể đã đủ "mới". Tuy nhiên, đối với các ứng dụng web và trang web có tính tương tác cao hơn, tốt nhất bạn nên đợi thêm một chút và tránh phân phát dữ liệu cũ từ bộ nhớ đệm của trình chạy dịch vụ quá sớm.

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 điểm Thời gian đến byte đầu tiên (TTFB) và Thời gian hiển thị nội dung đầu tiên (FCP) để biết cơ sở người dùng của bạn có thể có thời gian chờ lâu hơn cho các yêu cầu điều hướng. Điều này có thể giúp bạn hiểu rõ hơn về nơi cần vẽ.