Câu chuyện về những gì đã vận chuyển, cách đo lường tác động và những đánh đổi được đưa ra.
Thông tin khái quát
Tìm kiếm mọi chủ đề trên Google và bạn sẽ thấy một trang có thể nhận ra ngay là kết quả có ý nghĩa và liên quan. Trong một số trường hợp, có thể bạn không nhận ra rằng trang kết quả tìm kiếm này được phân phát bởi một mảng công nghệ web mạnh mẽ có tên là trình chạy dịch vụ.
Triển khai dịch vụ hỗ trợ trình chạy dịch vụ cho Google Tìm kiếm mà không làm ảnh hưởng tiêu cực đến hiệu suất, cần đến hàng chục kỹ sư làm việc tại nhiều nhóm. Đây là câu chuyện về những gì đã vận chuyển, cách đo lường hiệu suất và những gì đánh đổi.
Các lý do chính để tìm hiểu trình chạy dịch vụ
Khi thêm trình chạy dịch vụ vào ứng dụng web (giống như thực hiện bất kỳ thay đổi nào về cấu trúc đối với trang web), bạn nên thực hiện với một bộ mục tiêu rõ ràng. Đối với nhóm Google Tìm kiếm, có một vài lý do chính khiến việc thêm trình chạy dịch vụ đáng để khám phá.
Lưu kết quả tìm kiếm vào bộ nhớ đệm có giới hạn
Nhóm Google Tìm kiếm nhận thấy rằng người dùng thường tìm kiếm cùng một cụm từ nhiều lần trong một khoảng thời gian ngắn. Thay vì kích hoạt một yêu cầu phụ trợ mới chỉ để nhận được những kết quả có thể tương tự, nhóm Tìm kiếm muốn tận dụng việc lưu vào bộ nhớ đệm và thực hiện các yêu cầu lặp lại đó ngay trên cục bộ.
Bạn không thể đánh giá tầm quan trọng của độ mới mẻ và đôi khi người dùng tìm kiếm cùng một cụm từ nhiều lần vì đây là một chủ đề không ngừng phát triển và họ muốn nhận được kết quả mới. Việc sử dụng trình chạy dịch vụ cho phép Nhóm Tìm kiếm triển khai logic chi tiết để kiểm soát toàn thời gian của các kết quả tìm kiếm được lưu vào bộ nhớ đệm trên máy và đạt được sự cân bằng chính xác giữa tốc độ và độ mới mà họ cho rằng sẽ phục vụ người dùng tốt nhất.
Trải nghiệm ngoại tuyến có ý nghĩa
Ngoài ra, nhóm Google Tìm kiếm muốn mang đến một trải nghiệm ngoại tuyến có ý nghĩa. Khi người dùng muốn tìm hiểu về một chủ đề, họ muốn truy cập thẳng vào trang Google Tìm kiếm và bắt đầu tìm kiếm mà không phải lo lắng về kết nối Internet đang hoạt động.
Nếu không có trình chạy dịch vụ, việc truy cập trang tìm kiếm của Google khi không có mạng sẽ chỉ dẫn đến trang lỗi mạng chuẩn của trình duyệt và người dùng sẽ phải nhớ quay lại và thử lại khi kết nối trở lại. Với trình chạy dịch vụ, bạn có thể phân phát phản hồi HTML ngoại tuyến tuỳ chỉnh và cho phép người dùng nhập cụm từ tìm kiếm ngay lập tức.
Kết quả sẽ không có sẵn cho đến khi có kết nối Internet, nhưng trình chạy dịch vụ sẽ cho phép trì hoãn hoạt động tìm kiếm và gửi đến các máy chủ của Google ngay khi thiết bị có kết nối mạng trở lại bằng API đồng bộ hoá nền.
Lưu và phân phát JavaScript thông minh hơn vào bộ nhớ đệm
Một động lực khác là tối ưu hoá việc lưu vào bộ nhớ đệm và tải mã JavaScript được mô-đun hoá hỗ trợ nhiều loại tính năng trên trang kết quả tìm kiếm. Việc tạo gói JavaScript mang lại một số lợi ích có ý nghĩa khi không có sự tham gia của nhân viên dịch vụ, vì vậy, nhóm Tìm kiếm không muốn đơn giản là dừng việc nhóm hoàn toàn.
Bằng cách sử dụng khả năng tạo phiên bản và lưu các đoạn chi tiết của JavaScript vào bộ nhớ đệm của trình chạy dịch vụ trong thời gian chạy, Nhóm Tìm kiếm nghi ngờ rằng họ có thể giảm số lượng tình trạng nhồi nhét bộ nhớ đệm và đảm bảo rằng JavaScript sử dụng lại trong tương lai có thể được lưu vào bộ nhớ đệm một cách hiệu quả. Logic bên trong trình chạy dịch vụ có thể phân tích một yêu cầu HTTP gửi đi cho một gói chứa nhiều mô-đun JavaScript và thực hiện yêu cầu đó bằng cách ghép nhiều mô-đun được lưu vào bộ nhớ đệm cục bộ một cách hiệu quả khi có thể. Điều này giúp tiết kiệm băng thông người dùng và cải thiện khả năng phản hồi tổng thể.
Ngoài ra, việc sử dụng JavaScript đã lưu vào bộ nhớ đệm do trình chạy dịch vụ phân phát cũng mang lại nhiều lợi ích về hiệu suất: trong Chrome, một bản trình bày mã byte được phân tích cú pháp của JavaScript đó được lưu trữ và sử dụng lại, giúp giảm bớt lượng công việc cần thực hiện trong thời gian chạy để thực thi JavaScript trên trang.
Thách thức và giải pháp
Dưới đây là một vài trở ngại cần vượt qua để đạt được các mục tiêu đã nêu của nhóm. Mặc dù một số thách thức trong số này chỉ ảnh hưởng đến Google Tìm kiếm, nhưng nhiều thách thức trong số này có thể áp dụng cho nhiều trang web có thể đang cân nhắc việc triển khai trình chạy dịch vụ.
Vấn đề: mức hao tổn của trình chạy dịch vụ
Thách thức lớn nhất (và là một yếu tố cản trở thực sự đối với việc chạy một trình chạy dịch vụ trên Google Tìm kiếm) là đảm bảo rằng trình chạy này không làm gì có thể làm tăng độ trễ mà người dùng nhận thấy. Google Tìm kiếm rất coi trọng hiệu suất và trước đây đã chặn các hoạt động ra mắt chức năng mới nếu chức năng này đóng góp thêm độ trễ thậm chí là hàng chục mili giây cho một nhóm người dùng nhất định.
Khi đội ngũ bắt đầu thu thập dữ liệu hiệu suất trong các thử nghiệm ban đầu, rõ ràng là đã xảy ra sự cố. HTML được trả về để phản hồi các yêu cầu điều hướng cho trang kết quả tìm kiếm là động và thay đổi đáng kể tuỳ thuộc vào logic cần chạy trên các máy chủ web của Tìm kiếm. Hiện tại, trình chạy dịch vụ không có cách nào để sao chép logic này và trả về ngay HTML đã lưu vào bộ nhớ đệm. Điều tốt nhất có thể làm là chuyển các yêu cầu điều hướng đến máy chủ web phụ trợ (cần có yêu cầu mạng).
Nếu không có trình chạy dịch vụ, yêu cầu mạng này sẽ xảy ra ngay khi người dùng thao tác. Khi được đăng ký, một trình xử lý dịch vụ luôn cần được khởi động và có cơ hội thực thi trình xử lý sự kiện fetch, ngay cả khi không có khả năng các trình xử lý tìm nạp đó sẽ làm bất cứ việc gì ngoài việc truy cập vào mạng. Khoảng thời gian cần thiết để khởi động và chạy mã trình chạy dịch vụ là mức hao tổn thuần tuý được thêm vào bên cạnh mọi hoạt động điều hướng:
Điều này khiến việc triển khai trình chạy dịch vụ gặp quá nhiều bất lợi về độ trễ để biện minh cho bất kỳ lợi ích nào khác. Ngoài ra, nhóm phát hiện ra rằng, dựa trên việc đo lường thời gian khởi động của trình chạy dịch vụ trên các thiết bị thực tế, thời gian khởi động có sự phân bố rộng, trong đó một số thiết bị di động cấp thấp mất gần như nhiều thời gian để khởi động trình chạy dịch vụ so với việc thực hiện yêu cầu mạng cho HTML của trang kết quả.
Giải pháp: sử dụng tính năng tải trước thao tác điều hướng
Tính năng duy nhất và quan trọng nhất giúp nhóm Google Tìm kiếm có thể triển khai trình chạy dịch vụ là tải trước thành phần điều hướng. Việc sử dụng tính năng tải trước điều hướng là một yếu tố quan trọng giúp thu hút hiệu suất đối với bất kỳ trình chạy dịch vụ nào cần sử dụng phản hồi từ mạng để đáp ứng các yêu cầu điều hướng. Phương thức này đưa ra gợi ý để trình duyệt bắt đầu thực hiện yêu cầu điều hướng ngay lập tức, cùng lúc khi trình chạy dịch vụ khởi động:
Miễn là khoảng thời gian cần để trình chạy dịch vụ khởi động ít hơn khoảng thời gian cần thiết để nhận lại phản hồi từ mạng, thì sẽ không có bất kỳ hao tổn về độ trễ nào do trình chạy dịch vụ đưa ra.
Nhóm Tìm kiếm cũng cần tránh sử dụng trình chạy dịch vụ trên các thiết bị di động cấp thấp vì thời gian khởi động trình chạy dịch vụ có thể vượt quá yêu cầu điều hướng. Vì không có quy tắc cố định nào đối với những yếu tố cấu thành một thiết bị "cấp thấp", nên họ đã đưa ra phương pháp phỏng đoán kiểm tra tổng dung lượng RAM đã cài đặt trên thiết bị. Bất kỳ thiết bị nào có dung lượng bộ nhớ dưới 2 gigabyte đều thuộc danh mục thiết bị cấp thấp của họ, trong đó thời gian khởi động trình chạy dịch vụ sẽ không được chấp nhận.
Không gian lưu trữ còn trống là một yếu tố khác cần cân nhắc, vì toàn bộ tài nguyên được lưu vào bộ nhớ đệm để sử dụng trong tương lai có thể lên đến vài megabyte. Giao diện navigator.storage cho phép trang Google Tìm kiếm biết trước liệu nỗ lực lưu dữ liệu vào bộ nhớ đệm có nguy cơ không thực hiện được do lỗi hạn mức bộ nhớ hay không.
Điều này khiến nhóm Tìm kiếm có nhiều tiêu chí mà họ có thể sử dụng để xác định xem có nên sử dụng trình chạy dịch vụ hay không: nếu người dùng truy cập vào trang Google Tìm kiếm bằng trình duyệt hỗ trợ tải trước thành phần điều hướng và có ít nhất 2 gigabyte RAM cũng như đủ không gian lưu trữ trống, thì trình chạy dịch vụ đã được đăng ký. Các trình duyệt hoặc thiết bị không đáp ứng tiêu chí đó sẽ không được đưa vào trình chạy dịch vụ, nhưng họ sẽ vẫn thấy trải nghiệm Google Tìm kiếm giống như mọi khi.
Một lợi ích phụ của quy trình đăng ký có chọn lọc này là bạn có thể truyền một trình chạy dịch vụ nhỏ hơn, hiệu quả hơn. Việc nhắm mục tiêu đến các trình duyệt khá hiện đại để chạy mã trình chạy dịch vụ giúp loại bỏ hao tổn tài nguyên hàm và polyfill cho các trình duyệt cũ. Việc này đã giúp cắt giảm khoảng 8 kilobyte mã JavaScript không nén khỏi tổng kích thước triển khai của trình chạy dịch vụ.
Vấn đề: phạm vi của trình chạy dịch vụ
Khi nhóm Tìm kiếm đã chạy đủ thử nghiệm độ trễ và tự tin rằng việc sử dụng tính năng tải trước điều hướng đã mang lại cho họ một đường dẫn khả thi, không có độ trễ để sử dụng trình chạy dịch vụ, một số vấn đề thực tế đã bắt đầu được đưa lên hàng đầu. Một trong những vấn đề đó là do quy tắc xác định phạm vi của trình chạy dịch vụ. Phạm vi của trình chạy dịch vụ xác định những trang mà trình chạy dịch vụ có thể kiểm soát.
Phạm vi hoạt động dựa trên tiền tố đường dẫn URL. Đối với những miền lưu trữ một ứng dụng web, đây không phải là vấn đề, vì bạn thường chỉ sử dụng một trình chạy dịch vụ có phạm vi tối đa là /, có thể kiểm soát bất kỳ trang nào trong miền đó.
Tuy nhiên, cấu trúc URL của Google Tìm kiếm phức tạp hơn một chút.
Nếu được cấp phạm vi tối đa của /, trình chạy dịch vụ có thể kiểm soát mọi trang được lưu trữ trong www.google.com (hoặc tương đương theo khu vực) và có những URL trong miền đó không liên quan gì đến Google Tìm kiếm. Một phạm vi hạn chế và hợp lý hơn sẽ là /search. Điều này ít nhất sẽ loại bỏ các URL hoàn toàn không liên quan đến kết quả tìm kiếm.
Thật không may, ngay cả đường dẫn URL /search cũng được chia sẻ giữa nhiều phiên bản của kết quả Google Tìm kiếm, với các tham số truy vấn URL xác định loại kết quả tìm kiếm cụ thể sẽ xuất hiện. Một số phiên bản đó sử dụng cơ sở mã hoàn toàn khác so với trang kết quả tìm kiếm trên web truyền thống. Ví dụ: cả Tìm kiếm hình ảnh và Tìm kiếm mua sắm đều được phân phát trong đường dẫn URL /search với các tham số truy vấn khác nhau, nhưng cả hai giao diện đó đều chưa sẵn sàng cung cấp trải nghiệm trình chạy dịch vụ của riêng mình.
Giải pháp: tạo một khung điều phối và định tuyến
Mặc dù có một số đề xuất cho phép chức năng mạnh hơn tiền tố đường dẫn URL để xác định phạm vi của trình chạy dịch vụ, nhưng nhóm Google Tìm kiếm vẫn gặp khó khăn khi triển khai một trình chạy dịch vụ mà không làm gì đối với tập hợp con các trang mà họ kiểm soát.
Để giải quyết vấn đề này, nhóm Google Tìm kiếm đã xây dựng một khung điều phối và định tuyến riêng có thể được định cấu hình để kiểm tra các tiêu chí như tham số truy vấn của trang khách và sử dụng các tiêu chí đó để xác định đường dẫn mã cụ thể sẽ gặp sự cố. Thay vì mã hoá cứng các quy tắc, hệ thống được xây dựng để trở nên linh hoạt và cho phép các nhóm chia sẻ không gian URL, như Tìm kiếm hình ảnh và Tìm kiếm mua sắm, giảm logic trình chạy dịch vụ của riêng họ nếu họ quyết định triển khai.
Vấn đề: kết quả và chỉ số được cá nhân hoá
Người dùng có thể đăng nhập vào Google Tìm kiếm bằng Tài khoản Google và trải nghiệm kết quả tìm kiếm của họ có thể được tuỳ chỉnh dựa trên dữ liệu tài khoản cụ thể của họ. Người dùng đã đăng nhập được xác định bằng các cookie trình duyệt cụ thể. Đây là một tiêu chuẩn phổ biến và được hỗ trợ rộng rãi.
Tuy nhiên, một nhược điểm của việc sử dụng cookie của trình duyệt là chúng không bị lộ bên trong trình chạy dịch vụ và không có cách nào để tự động kiểm tra các giá trị của chúng, cũng như đảm bảo rằng các giá trị đó không thay đổi do người dùng đăng xuất hoặc chuyển đổi tài khoản. (Chúng tôi đang nỗ lực để cung cấp quyền truy cập cookie cho trình thực thi dịch vụ, nhưng tại thời điểm viết bài này, phương pháp này đang thử nghiệm và không được hỗ trợ rộng rãi.)
Nếu chế độ xem của trình chạy dịch vụ về người dùng hiện đang đăng nhập và người dùng thực tế đã đăng nhập vào giao diện web của Google Tìm kiếm, chế độ xem của trình chạy dịch vụ không khớp với nhau có thể dẫn đến việc kết quả tìm kiếm được cá nhân hoá không chính xác hoặc ghi nhận các chỉ số và ghi nhận sai. Bất kỳ tình huống thất bại nào trong số đó đều sẽ là vấn đề nghiêm trọng đối với nhóm Google Tìm kiếm.
Giải pháp: gửi cookie bằng postMessage
Thay vì đợi các API thử nghiệm khởi chạy và cung cấp quyền truy cập trực tiếp vào cookie của trình duyệt bên trong trình chạy dịch vụ, nhóm Google Tìm kiếm đã áp dụng giải pháp tạm dừng: bất cứ khi nào một trang do trình chạy dịch vụ kiểm soát được tải, trang sẽ đọc các cookie liên quan và sử dụng postMessage() để gửi chúng đến trình chạy dịch vụ.
Sau đó, trình chạy dịch vụ sẽ kiểm tra giá trị cookie hiện tại với giá trị mà nó mong đợi và nếu không khớp, sẽ thực hiện các bước để xoá hoàn toàn mọi dữ liệu của người dùng cụ thể khỏi bộ nhớ rồi tải lại trang kết quả tìm kiếm mà không có bất kỳ hoạt động cá nhân hoá nào không chính xác.
Các bước cụ thể mà trình chạy dịch vụ thực hiện để đặt lại mọi thứ về một đường cơ sở sẽ phù hợp với các yêu cầu của Google Tìm kiếm. Tuy nhiên, phương pháp chung tương tự có thể hữu ích cho các nhà phát triển khác xử lý dữ liệu được cá nhân hoá bị khoá từ cookie của trình duyệt.
Vấn đề: thí nghiệm và tính năng động
Như đã đề cập, nhóm Google Tìm kiếm chủ yếu dựa vào việc chạy các thử nghiệm trong phiên bản chính thức cũng như kiểm thử tác động của mã và tính năng mới trong thế giới thực trước khi bật chúng theo mặc định. Đây có thể là một chút khó khăn với một trình chạy dịch vụ tĩnh hoạt động dựa nhiều vào dữ liệu đã lưu vào bộ nhớ đệm, vì việc chọn người dùng tham gia và không tham gia thử nghiệm thường yêu cầu phải giao tiếp với máy chủ phụ trợ.
Giải pháp: tập lệnh trình chạy dịch vụ được tạo động
Giải pháp mà nhóm triển khai là sử dụng một tập lệnh trình chạy dịch vụ được tạo động, do máy chủ web tuỳ chỉnh cho từng người dùng riêng lẻ, thay vì một tập lệnh trình chạy dịch vụ tĩnh duy nhất được tạo trước đó. Thông tin về các thử nghiệm có thể ảnh hưởng đến hành vi của trình chạy dịch vụ hoặc các yêu cầu về mạng nói chung được đưa trực tiếp vào các tập lệnh của trình chạy dịch vụ tuỳ chỉnh này. Việc thay đổi nhóm trải nghiệm đang hoạt động cho người dùng được thực hiện thông qua kết hợp các kỹ thuật truyền thống, chẳng hạn như cookie của trình duyệt, cũng như việc phân phát mã cập nhật trong URL của trình chạy dịch vụ đã đăng ký.
Việc sử dụng tập lệnh trình chạy dịch vụ được tạo động cũng giúp bạn dễ dàng đưa ra phương án giải quyết trong trường hợp hiếm gặp là quá trình triển khai trình chạy dịch vụ gặp lỗi nghiêm trọng cần phải tránh. Phản hồi của trình chạy máy chủ động có thể là cách triển khai không hoạt động, vô hiệu hoá hiệu quả trình chạy dịch vụ cho một số hoặc tất cả người dùng hiện tại.
Vấn đề: điều phối thông tin cập nhật
Một trong những thách thức khó khăn nhất mà phải đối mặt với quá trình triển khai trình chạy dịch vụ trong thực tế là phải đưa ra phương án đánh đổi hợp lý giữa việc tránh sử dụng mạng để ưu tiên bộ nhớ đệm, đồng thời đảm bảo người dùng hiện tại nhận được các bản cập nhật và thay đổi quan trọng ngay sau khi triển khai chính thức. Sự cân bằng phù hợp phụ thuộc vào nhiều yếu tố:
- Liệu ứng dụng web của bạn có phải là một ứng dụng một trang tồn tại lâu dài mà người dùng duy trì hoạt động vô thời hạn mà không cần chuyển đến các trang mới hay không.
- Tần suất triển khai áp dụng cho các bản cập nhật cho máy chủ web phụ trợ.
- Liệu người dùng thông thường có chấp nhận việc sử dụng một phiên bản hơi lỗi thời của ứng dụng web hay không, hoặc liệu độ mới có phải là ưu tiên hàng đầu hay không.
Trong khi thử nghiệm với trình chạy dịch vụ, nhóm Google Tìm kiếm đã đảm bảo duy trì các thử nghiệm chạy trên một số bản cập nhật phụ trợ theo lịch, để đảm bảo rằng các chỉ số và trải nghiệm người dùng phù hợp hơn với những gì mà người dùng cũ sẽ thấy trong thực tế.
Giải pháp: cân bằng việc làm mới và sử dụng bộ nhớ đệm
Sau khi thử nghiệm một số lựa chọn cấu hình, nhóm Google Tìm kiếm nhận thấy rằng cách thiết lập sau đây mang đến sự cân bằng phù hợp giữa việc làm mới và sử dụng bộ nhớ đệm.
URL tập lệnh của trình chạy dịch vụ được phân phát cùng với tiêu đề phản hồi Cache-Control: private, max-age=1500 (1500 giây hoặc 25 phút) và được đăng ký với updateViaCache được đặt thành "all" để đảm bảo tiêu đề được tuân thủ. Như bạn có thể tưởng tượng, phần phụ trợ web của Google Tìm kiếm là một tập hợp máy chủ lớn, được phân phối trên toàn cầu và cần thời gian hoạt động càng gần 100% càng tốt. Triển khai một thay đổi sẽ ảnh hưởng đến nội dung của tập lệnh trình chạy dịch vụ được thực hiện theo phương thức luân phiên.
Nếu người dùng truy cập vào một phần phụ trợ đã cập nhật, sau đó nhanh chóng chuyển đến một trang khác gặp phải một phần phụ trợ chưa nhận được trình chạy dịch vụ đã cập nhật, thì họ sẽ phải lật giữa các phiên bản nhiều lần. Do đó, việc yêu cầu trình duyệt chỉ bận tâm đến việc kiểm tra tập lệnh cập nhật nếu 25 phút đã trôi qua kể từ lần kiểm tra gần nhất không có nhược điểm đáng kể nào. Ưu điểm của việc chọn sử dụng hành vi này sẽ làm giảm đáng kể lưu lượng truy cập mà điểm cuối tạo tập lệnh trình chạy dịch vụ theo phương thức động.
Ngoài ra, tiêu đề ETag được đặt trên phản hồi HTTP của tập lệnh trình chạy dịch vụ, đảm bảo rằng khi quá trình kiểm tra bản cập nhật được thực hiện sau 25 phút, máy chủ có thể phản hồi hiệu quả bằng phản hồi HTTP 304 nếu chưa có bất kỳ nội dung cập nhật nào cho trình chạy dịch vụ được triển khai trong thời gian tạm thời.
Mặc dù một số hoạt động tương tác trong ứng dụng web Google Tìm kiếm sử dụng thao tác điều hướng kiểu ứng dụng trang đơn (tức là qua API lịch sử), nhưng đối với hầu hết hoạt động, Google Tìm kiếm là một ứng dụng web truyền thống sử dụng thao tác điều hướng "thực". Điều này được đưa ra khi nhóm quyết định sử dụng 2 tuỳ chọn giúp tăng tốc vòng đời cập nhật của trình chạy dịch vụ: clients.claim() và skipWaiting().
Khi nhấp vào giao diện của Google Tìm kiếm, thường thì bạn sẽ được chuyển đến các tài liệu HTML mới. Việc gọi skipWaiting đảm bảo rằng một trình chạy dịch vụ được cập nhật sẽ có cơ hội xử lý các yêu cầu điều hướng mới đó ngay sau khi cài đặt. Tương tự, việc gọi clients.claim() có nghĩa là trình chạy dịch vụ đã cập nhật có cơ hội bắt đầu kiểm soát mọi trang đang mở của Google Tìm kiếm mà không được kiểm soát, sau khi trình chạy dịch vụ được kích hoạt.
Phương pháp mà Google Tìm kiếm sử dụng không nhất thiết là một giải pháp phù hợp với tất cả mọi người. Đó là kết quả của việc thử nghiệm A/B kỹ lưỡng nhiều kiểu kết hợp tuỳ chọn phân phát cho đến khi tìm ra cách phù hợp nhất.
Các nhà phát triển có cơ sở hạ tầng phụ trợ cho phép triển khai bản cập nhật nhanh hơn có thể muốn trình duyệt kiểm tra tập lệnh trình chạy dịch vụ được cập nhật thường xuyên nhất có thể, bằng cách luôn bỏ qua bộ nhớ đệm HTTP.
Nếu bạn đang tạo một ứng dụng trang đơn mà người dùng có thể duy trì sử dụng trong một thời gian dài, thì việc sử dụng skipWaiting() có thể không phải là lựa chọn phù hợp với bạn — bạn sẽ có nguy cơ gặp phải tình trạng không nhất quán trong bộ nhớ đệm nếu bạn cho phép trình chạy dịch vụ mới kích hoạt trong khi có nhiều ứng dụng tồn tại lâu dài.
Những điểm chính cần ghi nhớ
Theo mặc định, trình chạy dịch vụ không có hiệu suất trung bình
Việc thêm trình chạy dịch vụ vào ứng dụng web có nghĩa là chèn thêm một đoạn JavaScript cần được tải và thực thi trước khi ứng dụng web của bạn nhận được phản hồi cho các yêu cầu của mình. Nếu những phản hồi đó đến từ bộ nhớ đệm cục bộ thay vì từ mạng, thì chi phí chạy trình chạy dịch vụ thường không đáng kể so với việc chiến thắng nhờ ưu tiên bộ nhớ đệm. Tuy nhiên, nếu bạn biết rằng trình chạy dịch vụ luôn phải tham khảo ý kiến mạng khi xử lý các yêu cầu điều hướng, thì việc sử dụng tính năng tải trước điều hướng sẽ là một yếu tố quan trọng giúp cải thiện hiệu suất.
Trình chạy dịch vụ (vẫn!) là một cải tiến tăng dần
Câu chuyện về hỗ trợ của trình chạy dịch vụ ngày hôm nay sáng sủa hơn nhiều so với một năm trước. Tất cả các trình duyệt hiện đại hiện đều có ít nhất một số hỗ trợ trình chạy dịch vụ, nhưng rất tiếc, một số tính năng của trình chạy dịch vụ nâng cao như đồng bộ hoá nền và tải trước điều hướng chưa được triển khai rộng rãi. Việc kiểm tra tính năng cho tập hợp con các tính năng cụ thể mà bạn biết mình cần và chỉ đăng ký trình chạy dịch vụ khi có các tính năng đó, vẫn là một phương pháp hợp lý.
Tương tự, nếu bạn đã chạy thử nghiệm ngoài trời và biết rằng các thiết bị cấp thấp kết thúc hoạt động kém với mức hao tổn bổ sung của một trình chạy dịch vụ, thì bạn cũng có thể tránh đăng ký một trình chạy dịch vụ trong những trường hợp đó.
Bạn nên tiếp tục coi trình chạy dịch vụ là một tính năng nâng cao tiến bộ được thêm vào ứng dụng web khi đáp ứng tất cả các điều kiện tiên quyết và trình chạy dịch vụ bổ sung một số thông tin tích cực cho trải nghiệm người dùng cũng như hiệu suất tải tổng thể.
Đo lường mọi thứ
Cách duy nhất để bạn có thể tìm hiểu xem việc vận chuyển một trình chạy dịch vụ có tác động tích cực hay tiêu cực đến trải nghiệm của người dùng là thử nghiệm và đo lường kết quả.
Thông tin cụ thể về việc thiết lập các phép đo có ý nghĩa phụ thuộc vào loại trình cung cấp phân tích bạn đang sử dụng và cách bạn thường tiến hành thử nghiệm trong quá trình thiết lập triển khai. Một phương pháp tiếp cận là sử dụng Google Analytics để thu thập chỉ số, sẽ được trình bày chi tiết trong nghiên cứu điển hình này dựa trên kinh nghiệm sử dụng trình chạy dịch vụ trong ứng dụng web Google I/O.
Không phải mục tiêu
Mặc dù nhiều người trong cộng đồng phát triển web liên kết nhân viên dịch vụ với Ứng dụng web tiến bộ, nhưng không phải là mục tiêu ban đầu của họ nên việc tạo "PWA Google Tìm kiếm". Ứng dụng web Google Tìm kiếm hiện không cung cấp siêu dữ liệu thông qua tệp kê khai ứng dụng web, cũng như không khuyến khích người dùng thực hiện quy trình Thêm vào Màn hình chính. Hiện tại, nhóm Tìm kiếm hài lòng với người dùng truy cập vào ứng dụng web của họ thông qua điểm truy cập truyền thống của Google Tìm kiếm.
Thay vì cố gắng biến trải nghiệm trên web của Google Tìm kiếm thành trải nghiệm tương đương với những gì bạn mong đợi từ một ứng dụng cần cài đặt, trọng tâm trong lần ra mắt ban đầu là tăng dần trang web hiện có.
Xác nhận
Cảm ơn toàn bộ nhóm phát triển web của Google Tìm kiếm về công việc của họ trong việc triển khai trình chạy dịch vụ, cũng như chia sẻ tài liệu nền tảng đã viết nên bài viết này. Xin gửi lời cảm ơn đặc biệt đến Philippe Golle, Rajesh Jagannathan, R. Samuel Klatchko, Andy Martone, Leonardo Peña, Rachel Shearer, Greg Terrono và Clay Woolam.
Bản cập nhật (Tháng 10 năm 2021): Kể từ khi bài viết này xuất bản lần đầu, nhóm Google Tìm kiếm đã đánh giá lại các lợi ích và điểm đánh đổi của cấu trúc trình chạy dịch vụ hiện tại. Nhân viên dịch vụ được mô tả ở trên sắp nghỉ hưu. Khi cơ sở hạ tầng web của Google Tìm kiếm phát triển, nhóm có thể xem lại thiết kế trình chạy dịch vụ của họ.