Phản hồi các yêu cầu điều hướng mà không cần chờ mạng bằng cách sử dụng trình chạy dịch vụ.
Yêu cầu điều hướng là yêu cầu về tài liệu HTML do trình duyệt của bạn đưa ra bất cứ khi nào bạn nhập một URL mới vào thanh điều hướng hoặc nhấp vào một đường liên kết trên một trang để chuyển đến một URL mới. Đây là nơi trình chạy dịch vụ có 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 các thao tác điều hướng luôn nhanh chóng và ổn định, ngoài ra còn có khả năng thích ứng khi không có mạng. Đây là lợi ích lớn nhất về hiệu suất mà trình chạy dịch vụ mang lại so với những gì có thể đạt được bằng bộ nhớ đệm HTTP.
Như được trình bày chi tiết trong hướng dẫn Xác định tài nguyên được tải từ 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" 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 của tất cả các yêu cầu khác đối với 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 một yêu cầu có phải là yêu cầu đ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 được đặt thành 'navigate', thì đó là yêu cầu điều hướng.
Theo nguyên tắc chung, đừng sử dụng Cache-Control headers có thời gian hoạt động 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ường, các yêu cầu này sẽ được đáp ứng qua mạng, bằng Cache-Control: no-cache, để đảm bảo rằng HTML, cùng với chuỗi yêu cầu mạng tiếp theo, là (hợp lý) mới. Rất tiếc, việc truy cập vào mạng mỗi khi người dùng chuyển đến một trang mới có nghĩa là mỗi lần chuyển trang có thể sẽ chậm. Ít nhất, điều này có nghĩa là ứng dụng sẽ không nhanh một cách đáng tin cậy.
Các phương pháp tiếp cận 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ể rất khó khăn. Phương pháp phù hợp phụ thuộc rất nhiều vào cấu trúc trang web và số lượng URL riêng biệt mà người dùng có thể truy cập.
Mặc dù không có giải pháp chung cho tất cả, 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 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ỏ (khoảng vài chục) URL riêng biệt và mỗi URL đó tương ứng với một tệp HTML tĩnh khác nhau, thì một phương pháp khả thi là chỉ 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 thích hợp được lưu vào bộ nhớ đệm.
Bằng cách sử dụng tính năng lưu trước vào bộ nhớ đệm, bạn có thể lưu trước HTML vào bộ nhớ đệm ngay khi trình chạy dịch vụ được cài đặt, đồng thời cập nhật HTML đã lưu vào bộ nhớ đệm mỗi khi bạn 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ể 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 stale-while-revalidate. Tuy nhiên, hãy cẩn thận với phương pháp này vì mỗi tài liệu HTML riêng lẻ đều được lưu vào bộ nhớ đệm và cập nhật riêng biệt. 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 lại thường xuyên và nếu bạn cảm thấy thoải mái khi các URL đó được xác thực lại độc lập với nhau.
Ứng dụng một trang
Các ứng dụng web hiện đại thường sử dụng cấu trúc một trang. Trong đó, JavaScript phía máy khách sẽ sửa đổi HTML để phản hồi hành động của người dùng. Mô hình này sử dụng API Nhật ký để 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 "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 thao tác điều hướng ban đầu là thật 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 một trang, bạn có thể làm theo một mẫu đơn giản để phân phát thành phần điều hướng ban đầu từ bộ nhớ đệm: giao diện ứng dụng. Trong mô hình này, trình chạy dịch vụ của bạn sẽ 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à HTML cơ bản, có thể bao gồm chỉ báo tải chung hoặc nội dung 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 có của bạn sẽ tiếp quản và kết xuất 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ụ 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 sẽ dùng làm giao diện ứng dụng, cùng với danh sách cho phép và 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 của trang web một cách linh động hoặc nếu bạn có nhiều hơn một vài chục trang riêng biệt, thì việc tránh mạng khi xử lý các yêu cầu điều hướng sẽ khó hơn nhiều. Lời khuyên trong phần Mọi thứ khác có thể sẽ á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 để 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 biệt là nếu máy chủ web của bạn sử dụng JavaScript (mà không dựa vào các tính năng dành riêng cho 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 khám phá một phương pháp để di chuyển tạo HTML ra khỏi mạng và vào trình chạy dịch vụ của bạn, hướng dẫn trong 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 được lưu vào bộ nhớ đệm, bạn phải thực hiện các bước để đảm bảo rằng việc thêm một trình chạy dịch vụ vào trang web của bạn (để 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. Việc khởi động trình chạy dịch vụ mà không dùng trình chạy đó để phản hồi yêu cầu điều hướng sẽ gây ra một chút độ trễ (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 bớt mức hao tổn này bằng cách bật một tính năng có tên là tải trước hoạt động đ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 giúp phát hiện tính năng xem liệu tính năng tải trước điều hướng có được hỗ trợ hay không và nếu có, hãy đơn giản hoá quy trình yêu cầu trình chạy dịch vụ sử dụng phản hồi mạng.