Trình chạy dịch vụ là một công cụ mạnh mẽ cho phép trang web hoạt động ngoại tuyến và tạo các quy tắc lưu vào bộ nhớ đệm chuyên biệt cho chính mình. Trình xử lý fetch của worker dịch vụ sẽ xem mọi yêu cầu từ trang mà trình xử lý đó kiểm soát và có thể quyết định xem có muốn phân phát phản hồi cho yêu cầu đó từ bộ nhớ đệm của worker dịch vụ hay không, hoặc thậm chí ghi lại URL để tìm nạp một phản hồi hoàn toàn khác, ví dụ: dựa trên lựa chọn ưu tiên của người dùng cục bộ.
Tuy nhiên, trình chạy dịch vụ có thể phải trả giá về hiệu suất khi một trang được tải lần đầu tiên sau một thời gian và trình chạy dịch vụ kiểm soát hiện không chạy. Vì tất cả các lần tìm nạp đều cần phải thực hiện thông qua worker dịch vụ, nên trình duyệt phải đợi worker dịch vụ khởi động và chạy để biết nội dung cần tải. Chi phí khởi động này có thể nhỏ nhưng đáng kể đối với các nhà phát triển sử dụng worker dịch vụ để cải thiện hiệu suất thông qua các chiến lược lưu vào bộ nhớ đệm.
Tải trước điều hướng là một phương pháp để giải quyết vấn đề này – cho phép thực hiện các yêu cầu điều hướng qua mạng song song với việc khởi động trình chạy dịch vụ – nhưng phương pháp này chỉ giới hạn ở các yêu cầu điều hướng ban đầu và vẫn bao gồm trình chạy dịch vụ trong đường dẫn quan trọng. Kể từ khi tính năng tải trước điều hướng ra mắt, đã có nhiều nỗ lực để phát triển một giải pháp chung hơn cho không gian vấn đề, bao gồm cả cách để một số yêu cầu không bị chặn khi khởi động trình chạy dịch vụ.
API định tuyến tĩnh của Worker dịch vụ
Kể từ Chrome 116, API định tuyến tĩnh của Worker thử nghiệm sẽ có sẵn để kiểm thử bước đầu tiên của giải pháp như vậy. Khi được cài đặt, trình chạy dịch vụ có thể sử dụng API định tuyến tĩnh của trình chạy dịch vụ để khai báo cách tìm nạp một số đường dẫn tài nguyên nhất định.
Trong phiên bản ban đầu của API, bạn có thể khai báo các đường dẫn để luôn được phân phát từ mạng, chứ không phải từ trình chạy dịch vụ. Khi một URL được kiểm soát được tải sau, trình duyệt có thể bắt đầu tìm nạp tài nguyên từ các đường dẫn đó trước khi worker dịch vụ hoàn tất quá trình khởi động. Thao tác này sẽ xoá trình chạy dịch vụ khỏi các đường dẫn mà bạn biết là không cần trình chạy dịch vụ.
Để sử dụng API, worker dịch vụ sẽ gọi event.registerRouter trên sự kiện install bằng một bộ quy tắc:
self.addEventListener('install', event => {
if (event.registerRouter) {
// Go straight to the network and bypass invoking "fetch" handlers for all
// same-origin URLs that start with '/form/'.
event.registerRouter([{
condition: {
urlPattern: {pathname: '/form/*'},
},
source: 'network',
}]);
}
});
Mỗi quy tắc thường có hai thuộc tính:
condition: chỉ định thời điểm áp dụng quy tắc bằng cách sử dụng API Mẫu URL để so khớp đường dẫn tài nguyên. Thuộc tính này có thể lấy một thực thểURLPatternhoặc đối tượng thuần tuý tương đương tương thích với việc được truyền vào hàm khởi tạoURLPattern(ví dụ:new URLPattern({pathname: '*.jpg'})hoặc chỉ{pathname: '*.jpg'}).Tính linh hoạt của Mẫu URL có nghĩa là quy tắc có thể so khớp một nội dung đơn giản như bất kỳ tài nguyên nào trong một đường dẫn, với các điều kiện rất cụ thể và chi tiết. Các mẫu này thường quen thuộc với người dùng các thư viện định tuyến phổ biến.
source: chỉ định cách tải các tài nguyên khớp vớicondition. Hiện tại, chúng tôi chỉ hỗ trợ giá trị'network'(bỏ qua worker dịch vụ để tải tài nguyên trực tiếp qua mạng), nhưng dự định là mở rộng giá trị này sang các giá trị khác trong tương lai.
Trường hợp sử dụng
Như đã giải thích, phiên bản ban đầu của API về cơ bản là một lối thoát khỏi chế độ kiểm soát worker dịch vụ cho một số đường dẫn. Việc sử dụng tính năng này sẽ phụ thuộc vào cách bạn sử dụng worker dịch vụ và cách người dùng di chuyển trên trang web của bạn.
Ví dụ: nếu trang web của bạn sử dụng chiến lược ưu tiên bộ nhớ đệm (sử dụng mạng khi không có bộ nhớ đệm), nhưng có một số nội dung hiếm khi được truy cập đến mức nội dung đó hầu như không có giá trị nào trong bộ nhớ đệm (chẳng hạn như nội dung được lưu trữ hoặc nguồn cấp dữ liệu RSS). Bạn chỉ có thể thiết lập chế độ hạn chế các đường dẫn này được tìm nạp từ mạng trong worker dịch vụ, nhưng worker dịch vụ vẫn phải khởi động và chạy để quyết định cách xử lý các yêu cầu đó.
Ngược lại, API định tuyến tĩnh bỏ qua hoàn toàn trình chạy dịch vụ bằng một vài dòng khai báo:
self.addEventListener('install', event => {
if (event.registerRouter) {
event.registerRouter([{
condition: {
urlPattern: {pathname: '/feeds/*.xml'},
},
source: 'network',
}, {
condition: {
urlPattern: {pathname: '/archives/*'},
},
source: 'network',
}]);
}
});
Khi API định tuyến tĩnh của Worker dịch vụ phát triển, kế hoạch là cấu hình này sẽ linh hoạt hơn và hỗ trợ nhiều trường hợp hơn, chẳng hạn như khai báo chạy đua tìm nạp mạng và khởi động worker dịch vụ. Hãy xem nội dung khám phá của phần giải thích thông số kỹ thuật về "bản dạng cuối cùng" tiềm năng của API để biết thêm thông tin chi tiết.
Thử nghiệm API định tuyến tĩnh của Worker
API định tuyến tĩnh của Worker dịch vụ có trong Chrome kể từ phiên bản 116, dựa trên một thử nghiệm gốc, cho phép nhà phát triển thử nghiệm API trên trang web của họ với người dùng thực để đo lường hiệu quả. Hãy xem bài viết "Bắt đầu dùng thử phiên bản gốc" để biết thông tin cơ bản về phiên bản gốc.
Để kiểm thử cục bộ, bạn có thể bật API định tuyến tĩnh của Worker dịch vụ bằng cờ tại chrome://flags/#service-worker-static-router hoặc bằng cách chạy Chrome từ lệnh như với --enable-features=ServiceWorkerStaticRouter.
Ý kiến phản hồi và định hướng trong tương lai
API định tuyến tĩnh của Worker dịch vụ đang được phát triển tích cực và vẫn đang được định hình. Nếu bạn thấy API này có thể hữu ích, vui lòng dùng thử thông qua thử nghiệm gốc và cung cấp ý kiến phản hồi về API, cách triển khai và chức năng hiện có.