Xử lý yêu cầu chỉ đường

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 thực hiện 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 trang đưa bạn đến một URL mới. Đây là nơi trình chạy dịch vụ tác động nhiều 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 diễn ra nhanh chóng và đáng tin cậy, ngoài việc có khả năng phục hồi 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 tính năng lưu vào bộ nhớ đệm HTTP.

Như đã nêu 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 "dòng thác" lưu lượng truy cập mạng. HTML mà bạn tải 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 worker, bạn có thể xác định xem một yêu cầu có phải là thao tác đ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, 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ường, các yêu cầu này sẽ được đáp ứng qua mạng, với 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, là mới (hợp lý). Việc chống lại 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 thao tác điều hướng có thể bị chậm. Ít nhất, điều này có nghĩa là tốc độ sẽ không đáng tin cậy.

Các phương pháp khác nhau cho cấu trúc

Việc tìm hiểu 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á phức tạp. 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 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ỏ (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ì 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 đã lưu vào bộ nhớ đệm thích hợp.

Khi 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 cài đặt trình chạy dịch vụ và cập nhật HTML đã 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 muốn tránh lưu trước tất cả HTML (có thể là do người dùng chỉ có xu hướng truy cập vào một số ít 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ới 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 biệt. Việc sử dụng bộ nhớ đệm thời gian chạy cho HTML là phù hợp nhất nếu bạn có một số ít URL mà cùng một nhóm người dùng thường xuyên truy cập lại 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 trang đơn. Trong đó, JavaScript phía máy khách sẽ sửa đổi HTML để phản hồi các 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 việc điều hướng "mô phỏng" 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 thay, nếu bạn đang sử dụng cấu trúc một trang, thì có một mẫu đơn giản để làm theo nhằm phân phát thao tác điều hướng ban đầu từ bộ nhớ đệm: vỏ ứng dụng. Trong mô hình này, worker của 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 đã được lưu vào bộ nhớ đệm trước, bất kể URL đang được yêu cầu là gì. HTML này phải ở dạng 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ó 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 sẽ dùng làm vỏ ứ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 số URL.

Ứng dụng nhiều trang

Nếu máy chủ web tạo HTML của trang web một cách linh động hoặc nếu bạn có hơn vài chục trang riêng biệt, thì việc tránh mạng sẽ khó khăn hơn nhiều khi xử lý các yêu cầu điều hướng. Bạn có thể áp dụng lời khuyên trong phần Mọi thứ khác.

Tuy nhiên, đối với một số ứng dụng đa trang nhất định, bạn có thể triển khai một trình chạy dịch vụ sao chép đầy đủ logic được dùng trong máy chủ web để tạo HTML. Cách này hoạt động 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áy chủ và môi trường worker dịch vụ, 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 tìm hiểu một phương pháp để di chuyển quá trình tạo HTML ra khỏi mạng và vào trình worker dịch vụ, thì hướng dẫn trong bài viết Không chỉ 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 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) sẽ không làm chậm các thao 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 dịch vụ đó để phản hồi yêu cầu điều hướng sẽ gây ra một độ trễ nhỏ (như được giải thích trong phần Tạo ứ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 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ình trợ giúp phát hiện tính năng tải trước điều hướng có được hỗ trợ hay không. Nếu có, thư viện này 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