Trình chạy dịch vụ là một công cụ mạnh mẽ giúp cho phép các trang web hoạt động khi không có mạng và tạo các quy tắc lưu trữ chuyên biệt cho chính trang web đó vào bộ nhớ đệm. Trình xử lý fetch của trình chạy dịch vụ sẽ xem mọi yêu cầu trên một trang mà trình xử lý này 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 trình chạy dịch vụ hay không, hay thậm chí là ghi lại URL để tìm nạp hoàn toàn một phản hồi khác, chẳng hạn như dựa trên lựa chọn ưu tiên của người dùng trên máy.
Tuy nhiên, có thể phát sinh chi phí hiệu suất đối với trình chạy dịch vụ khi trang được tải lần đầu tiên trong một khoảng 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 phải xảy ra thông qua trình chạy dịch vụ, nên trình duyệt phải đợi trình chạy dịch vụ này 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 trình chạy dịch vụ để cải thiện hiệu suất thông qua 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 đề – cho phép thực hiện các yêu cầu điều hướng qua mạng song song với quá trình khởi động trình chạy dịch vụ – nhưng bị giới hạn ở các yêu cầu điều hướng ban đầu và vẫn đưa trình chạy dịch vụ vào đường dẫn quan trọng. Kể từ khi ra mắt tính năng tải trước điều hướng, chúng tôi đã nỗ lực phát triển một giải pháp chung hơn cho không gian sự cố, 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 Service Worker
Kể từ Chrome 116, bạn có thể sử dụng API định tuyến tĩnh Service Worker để kiểm thử bước đầu tiên cho giải pháp như vậy. Khi được cài đặt, một trình chạy dịch vụ có thể sử dụng API Định tuyến tĩnh của Service Worker để 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 trình chạy dịch vụ 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 chạy trình chạy dịch vụ.
Để sử dụng API, trình chạy dịch vụ này 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 với các đườ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 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 các mẫu URL có nghĩa là quy tắc có thể khớp một thứ gì đó đơ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ủa các thư viện định tuyến phổ biến.
source: chỉ định cách tải những tài nguyên khớp vớicondition. Hiện tại, chỉ giá trị'network'được hỗ trợ (bỏ qua trình chạy dịch vụ để tải trực tiếp tài nguyên qua mạng), nhưng dự định sẽ mở rộng giá trị này cho 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 giải pháp thoát khỏi chế độ điều khiển trình chạy dịch vụ cho một số đường dẫn. Trường hợp sử dụng hợp lý sẽ phụ thuộc vào cách bạn sử dụng trình chạy dịch vụ và cách người dùng đi qua trang web của bạn.
Một ví dụ có thể là nếu trang web của bạn sử dụng chiến lược ưu tiên bộ nhớ đệm (quay lại mạng), nhưng có một số nội dung hiếm khi truy cập đến mức có ít hoặc không có giá trị trong bộ nhớ đệm (như nội dung đã lưu trữ hoặc nguồn cấp dữ liệu RSS). Hạn chế để tìm nạp các đường dẫn này từ mạng chỉ có thể thiết lập trong trình chạy dịch vụ, nhưng trình chạy 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 sẽ bỏ qua hoàn toàn trình chạy dịch vụ chỉ với 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 Service Worker phát triển, gói cấu hình này sẽ linh hoạt hơn và hỗ trợ được nhiều tình huống hơn, chẳng hạn như khai báo chạy đua tìm nạp mạng và khởi động trình chạy dịch vụ. Hãy xem dữ liệu khám phá trong phần giải thích đặc tả về "biểu mẫu cuối cùng" tiềm năng của API để biết thêm thông tin chi tiết.
Dùng thử API định tuyến tĩnh của Service Worker
API Định tuyến tĩnh Service Worker có trong Chrome kể từ phiên bản 116, nằm trong bản dùng thử theo nguyên gốc, cho phép nhà phát triển kiểm thử API trên trang web của họ với người dùng thực để đo lường hiệu ứng. Xem "Bắt đầu sử dụng bản dùng thử theo nguyên gốc" để biết thông tin cơ bản về bản dùng thử theo nguyên gốc.
Để kiểm thử cục bộ, bạn có thể bật API Định tuyến tĩnh Service Worker bằng cờ tại chrome://flags/#service-worker-static-router hoặc bằng cách chạy Chrome qua lệnh như --enable-features=ServiceWorkerStaticRouter.
Phản hồi và hướng dẫn trong tương lai
API định tuyến tĩnh của Service Worker đang trong quá trình phát triển và vẫn đang trong quá trình định hình. Nếu thấy tính năng này có thể hữu ích cho bạn, vui lòng dùng thử thông qua bản dùng thử theo nguyên gốc và đưa ra ý kiến phản hồi về API, cách triển khai và chức năng hiện có.