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