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à các yêu cầu đối với tài liệu HTML do trình duyệt của bạn thực hiện bất cứ khi nào bạn nhập URL mới vào thanh điều hướng hoặc đi theo 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ụ 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, thì bạn có thể đảm bảo rằng các thao tác điều hướng diễn ra nhanh một cách đáng tin cậy, đồng thời phải ổn định khi không có mạng. Đây là thành tích tốt nhất về hiệu suất mà trình chạy dịch vụ đạt được so với khả năng của khả năng lưu vào bộ nhớ đệm HTTP.
Như đã nêu chi tiết trong hướng dẫn Xác định các 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 đưa ra 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ẽ khởi động quy trình của tất cả các yêu cầu khác đối với 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 một 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à một thành phần đ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.
Quy tắc chung là không sử dụng Cache-Control headers dài hạn để 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 mã 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 yêu cầu mạng tiếp theo luôn mới (hợp lý). Rất tiếc, việc truy cập vào mạng mỗi khi người dùng điều hướng đến một trang mới có nghĩa là mỗi lần điều hướng có thể bị chậm. Ít nhất, điều này cũng có nghĩa là tốc độ của ứng dụng sẽ không đáng tin cậy.
Các phương pháp xây dựng 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ể 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 của bạn 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 nào là phù hợp 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 phù hợp nhất.
Trang web tĩnh nhỏ
Nếu ứng dụng web của bạn có một số lượng tương đối nhỏ (ví dụ: khoảng vài chục) URL duy nhất, và mỗi URL đó tương ứng với một tệp HTML tĩnh riêng biệt, thì bạn có thể 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 lưu trước vào bộ nhớ đệm, bạn có thể lưu trước HTML vào bộ nhớ đệm ngay sau khi cài đặt trình chạy dịch vụ, đồ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 muốn tránh lưu trước tất cả HTML của mình (có thể là vì người dùng có xu hướng chỉ điều hướng đến một tập hợp con các URL trên trang web của bạn), bạn có thể sử dụng chiến lược lưu vào bộ nhớ đệm thời gian chạy lỗi thời trong khi xác thực lại. Tuy nhiên, hãy cẩn thận về phương pháp này, vì mỗi tài liệu HTML riêng lẻ đượ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 lại thường xuyên và nếu bạn cảm thấy thoải mái về việc các URL đó cần được xác thực lại một cách độc lập.
Ứng dụng trang đơn
Cấu trúc trang đơn thường được các ứng dụng web hiện đại sử dụng. 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 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 hoạt động điều hướng "được mô phỏng" hiệu quả. Mặc dù các thành phần điều hướng tiếp theo có thể là "giả mạo", nhưng thao tác điều hướng ban đầu là có thực và vẫn quan trọng là phải đảm bảo rằng các thành phần điều hướng đó 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 có thể làm theo một mẫu đơn giản sau đây để phân phát thao tác đ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ụ 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 đang được yêu cầu. HTML này phải thô, có thể bao gồm một 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 hiện có phía máy khách của bạn sẽ tiếp quản và hiển thị nội dung HTML chính xác cho URL trong yêu cầu điều hướng ban đầu.
Workbox cung cấp các công cụ cần thiết để triển khai phương pháp này; navigateFallback
option cho phép bạn chỉ định tài liệu HTML sẽ 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 cho một nhóm nhỏ URL.
Ứng dụng nhiều trang
Nếu máy chủ web của bạn tự động tạo HTML cho trang web hoặc nếu bạn có hơn vài chục trang riêng biệt, thì sẽ khó tránh mạ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 tập hợp con các ứng dụng nhiều trang nhất định, bạn có thể triển khai một trình chạy dịch vụ sao chép hoàn toàn logic được sử dụng trong máy chủ web của bạn để tạo HTML. Cách này hiệu quả nhất khi 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 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 tìm hiểu một phương pháp để di chuyển tính năng tạo HTML ra khỏi mạng và đưa vào trình chạy dịch vụ, thì bạn có thể bắt đầu theo hướng dẫn trong bài viết Beyond SPA: kiến trúc thay thế cho PWA.
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 nhằm đảm bảo rằng việc thêm một trình chạy dịch vụ vào trang web của mình (để xử lý các yêu cầu khác, không phải HTML) không làm chậm tốc độ điều hướng. Việc khởi động trình chạy dịch vụ mà không sử dụng trình chạy đó để phản hồi yêu cầu điều hướng sẽ khiến trình chạy có độ 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 một tính năng có tên là 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ó, sẽ đơ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.
Ảnh chụp của Aaron Burden trên Unsplash