Sử dụng một trình chạy dịch vụ để phản hồi các yêu cầu điều hướng mà không phải chờ trên mạng.
Yêu cầu điều hướng là các yêu cầu đối với tài liệu HTML do trình duyệt đưa ra mỗi khi bạn nhập URL mới vào thanh điều hướng hoặc đi theo một đường liên kết trên trang đưa bạn đến một URL mới. Đây là nơi trình chạy dịch vụ tác động lớn nhất đến hiệu suất: nếu sử dụng trình chạy dịch vụ để phản hồi các yêu cầu điều hướng mà không cần chờ mạng, bạn có thể đảm bảo rằng hoạt động điều hướng trở nên nhanh chóng và ổn định, bên cạnh khả năng phục hồi khi không có mạng. Đây là hiệu suất lớn nhất mà trình chạy dịch vụ mang lại, so với tính năng lưu vào bộ nhớ đệm HTTP.
Như đã trình bày chi tiết trong hướng dẫn Xác định tài nguyên được tải qua mạng, yêu cầu điều hướng là yêu cầu đầu tiên trong số nhiều yêu cầu có thể được thực hiện trong "thác nước" của lưu lượng truy cập mạng. HTML mà bạn tải thông qua yêu cầu điều hướng sẽ bắt đầu luồng tất cả các yêu cầu khác cho các tài nguyên phụ như hình ảnh, tập lệnh và kiểu.
Bên trong trình xử lý sự kiện fetch của trình chạy dịch vụ, bạn có thể xác định xem yêu cầu có phải là điều hướng hay không bằng cách kiểm tra thuộc tính request.mode trên FetchEvent. Nếu bạn đặt thành 'navigate', thì đó sẽ là một yêu cầu điều hướng.
Theo nguyên tắc chung, không sử dụng Cache-Control headers tồn tại lâu dài để lưu phản hồi HTML vào bộ nhớ đệm cho một yêu cầu điều hướng. Thường thì các API này phải được đáp ứng thông qua mạng, bằng Cache-Control: no-cache, để đảm bảo rằng HTML, cùng với chuỗi các yêu cầu mạng tiếp theo, được làm mới (hợp lý). Việc vi phạm mạng mỗi lần người dùng chuyển đến một trang mới rất tiếc có thể khiến từng thao tác điều hướng có thể bị chậm. Ít nhất, điều này có nghĩa là thiết bị sẽ không nhanh đáng tin cậy.
Các phương pháp khác nhau cho cấu trúc
Việc tìm ra cách phản hồi các yêu cầu điều hướng trong khi tránh mạng có thể là một việc khó khăn. Phương pháp phù hợp phụ thuộc rất nhiều vào cấu trúc của trang web và số lượng URL riêng biệt mà người dùng có thể chuyển đến.
Mặc dù không có giải pháp chung cho mọi trường hợp, nhưng các nguyên tắc chung sau đây sẽ giúp bạn quyết định phương pháp nào là khả thi nhất.
Trang web tĩnh nhỏ
Nếu ứng dụng web của bạn bao gồm một số lượng tương đối nhỏ (ví dụ: vài chục) URL duy nhất và mỗi URL trong số đó tương ứng với một tệp HTML tĩnh khác nhau, thì có một phương pháp khả thi là chỉ cần lưu tất cả các tệp HTML đó vào bộ nhớ đệm và phản hồi các yêu cầu điều hướng bằng HTML đã lưu vào bộ nhớ đệm thích hợp.
Bằng cách sử dụng tính năng chuẩn bị, bạn có thể lưu HTML HTML vào bộ nhớ đệm trước ngay sau khi cài đặt trình chạy dịch vụ và cập nhật HTML được lưu vào bộ nhớ đệm mỗi khi tạo lại trang web và triển khai lại trình chạy dịch vụ.
Ngoài ra, nếu bạn không muốn lưu trước tất cả HTML vào bộ nhớ đệm (có thể là vì người dùng có xu hướng chỉ chuyển đến một số URL trên trang web của bạn), thì bạn có thể sử dụng chiến lược lưu vào bộ nhớ đệm trong thời gian chạy đã lỗi thời trong khi xác thực lại. Tuy nhiên, hãy thận trọng về phương pháp này, vì mỗi tài liệu HTML riêng lẻ sẽ được lưu vào bộ nhớ đệm và cập nhật riêng. Việc sử dụng tính năng lưu vào bộ nhớ đệm trong thời gian chạy cho HTML là phù hợp nhất nếu bạn có một số ít URL được cùng một nhóm người dùng truy cập thường xuyên và nếu bạn cảm thấy thoải mái về việc các URL đó được xác thực lại độc lập với nhau.
Ứng dụng trang đơn
Các ứng dụng web hiện đại thường sử dụng cấu trúc trang đơn. Trong đó, JavaScript phía máy khách sửa đổi HTML để phản hồi thao tác của người dùng. Mô hình này sử dụng API Lịch sử để sửa đổi URL hiện tại khi người dùng tương tác với ứng dụng web, dẫn đến việc điều hướng "được mô phỏng" một cách hiệu quả. Mặc dù các thao tác điều hướng tiếp theo có thể là "giả", nhưng các thao tác điều hướng ban đầu là thực và bạn vẫn cần đảm bảo rằng thao tác này không bị chặn trên mạng.
May mắn là nếu đang sử dụng cấu trúc trang đơn, bạn nên tuân theo một mẫu đơn giản để phân phát thao tác điều hướng ban đầu từ bộ nhớ đệm: shell ứng dụng. Trong mô hình này, trình chạy dịch vụ của bạn phản hồi các yêu cầu điều hướng bằng cách trả về cùng một tệp HTML duy nhất đã được lưu trước vào bộ nhớ đệm, bất kể URL được yêu cầu là gì. HTML này phải là khung, có thể bao gồm một chỉ báo tải chung hoặc nội dung bộ khung. Sau khi trình duyệt tải HTML này từ bộ nhớ đệm, JavaScript phía máy khách hiện tại của bạn sẽ tiếp quản và hiển thị nội dung HTML chính xác cho URL từ yêu cầu điều hướng ban đầu.
Workbox cung cấp các công cụ mà bạn cần để triển khai phương pháp này; navigateFallback
option cho phép bạn chỉ định tài liệu HTML nào cần sử dụng làm giao diện ứng dụng, cùng với danh sách cho phép và danh sách từ chối (không bắt buộc) để giới hạn hành vi này ở một nhóm nhỏ URL.
Ứng dụng nhiều trang
Nếu máy chủ web của bạn tạo HTML cho trang web của bạn theo phương thức động hoặc nếu bạn có hơn vài chục trang riêng biệt, thì sẽ khó hơn nhiều để tránh dùng mạng khi xử lý các yêu cầu điều hướng. Lời khuyên trong Mọi thứ khác có thể áp dụng cho bạn.
Tuy nhiên, đối với một số ứng dụng nhiều trang, bạn có thể triển khai một trình chạy dịch vụ sao chép hoàn toàn logic dùng trong máy chủ web của bạn để tạo HTML. Cách này hiệu quả nhất nếu bạn có thể chia sẻ thông tin định tuyến và tạo mẫu giữa môi trường máy chủ và trình chạy dịch vụ, cụ thể là nếu máy chủ web của bạn sử dụng JavaScript (mà không cần dựa vào tính năng cụ thể của Node.js, chẳng hạn như quyền truy cập vào hệ thống tệp).
Nếu máy chủ web của bạn thuộc danh mục đó và bạn muốn tìm hiểu một phương pháp để di chuyển chế độ tạo HTML ra khỏi mạng và đưa vào trình chạy dịch vụ, hãy tham khảo hướng dẫn trong bài viết Ngoài SPA: kiến trúc thay thế cho PWA có thể giúp bạn bắt đầu.
Mọi thứ khác
Nếu không thể phản hồi các yêu cầu điều hướng bằng HTML đã lưu vào bộ nhớ đệm, thì bạn phải thực hiện các bước để đảm bảo rằng việc thêm trình chạy dịch vụ vào trang web (để xử lý các yêu cầu khác, không phải HTML) không làm chậm quá trình điều hướng của bạn. Việc khởi động trình chạy dịch vụ mà không sử dụng trình chạy này để phản hồi yêu cầu điều hướng sẽ tạo ra độ trễ nhỏ (như giải thích trong bài viết Xây dựng ứng dụng nhanh hơn, linh hoạt hơn bằng Trình chạy dịch vụ). Bạn có thể giảm thiểu mức hao tổn này bằng cách bật tính năng tải trước điều hướng, sau đó sử dụng phản hồi mạng đã được tải trước bên trong trình xử lý sự kiện fetch.
Workbox cung cấp một thư viện trợ giúp có tính năng phát hiện xem tính năng tải trước điều hướng có được hỗ trợ hay không. Nếu có, thì sẽ đơn giản hoá quá trình yêu cầu trình chạy dịch vụ sử dụng phản hồi mạng.
Ảnh chụp của Aaron Burden trên Unsplash