Thách thức và giải pháp tạm thời để xây dựng Ứng dụng web tiến bộ trong các trang web có nhiều nguồn gốc.
Ngày xuất bản: 19 tháng 8 năm 2019
Trước đây, việc sử dụng cấu trúc nhiều nguồn gốc mang lại một số lợi thế. Đối với Ứng dụng web tiến bộ, phương pháp này có nhiều thách thức. Cụ thể, chính sách cùng nguồn áp đặt các hạn chế đối với việc chia sẻ những thứ như trình chạy dịch vụ và bộ nhớ đệm, quyền cũng như để đạt được trải nghiệm độc lập trên nhiều nguồn.
Khám phá những trường hợp sử dụng tốt và không tốt của nhiều nguồn gốc, đồng thời giải thích những thách thức và giải pháp thay thế để tạo Ứng dụng web tiến bộ trong các trang web có nhiều nguồn gốc.
Trường hợp sử dụng nhiều nguồn phù hợp và không phù hợp
Có một số lý do chính đáng để các trang web sử dụng cấu trúc nhiều nguồn gốc, chủ yếu liên quan đến việc cung cấp một bộ ứng dụng web độc lập hoặc tạo ra những trải nghiệm hoàn toàn tách biệt với nhau. Ngoài ra, bạn cũng nên tránh một số trường hợp sử dụng.
Ưu điểm
Trước tiên, hãy xem xét những lý do hữu ích:
Bản địa hoá / Ngôn ngữ: Sử dụng miền cấp cao nhất theo mã quốc gia để tách các trang web sẽ được phân phát ở nhiều quốc gia (ví dụ:
https://www.google.com.ar) hoặc sử dụng miền con để phân chia các trang web nhắm đến nhiều vị trí (ví dụ:https://newyork.craigslist.org) hoặc để cung cấp nội dung cho một ngôn ngữ cụ thể (ví dụ:https://en.wikipedia.org).Ứng dụng web độc lập: Sử dụng các miền con khác nhau để cung cấp những trải nghiệm có mục đích khác biệt đáng kể so với trang web trên nguồn gốc chính. Ví dụ: trong một trang web tin tức, ứng dụng web ô chữ có thể được phân phát có chủ đích từ
https://crosswords.example.com, đồng thời được cài đặt và sử dụng dưới dạng một PWA độc lập mà không cần chia sẻ bất kỳ tài nguyên hoặc chức năng nào với trang web chính.
Không tốt
Nếu bạn không làm bất kỳ điều nào trong số này, thì có khả năng việc sử dụng cấu trúc nhiều nguồn gốc sẽ là một điểm bất lợi khi tạo Ứng dụng web tiến bộ.
Mặc dù vậy, nhiều trang web vẫn tiếp tục được cấu trúc theo cách này mà không có lý do cụ thể hoặc vì lý do "truyền thống". Một ví dụ là việc sử dụng miền con để tách tuỳ ý các phần của một trang web lẽ ra phải là một phần của trải nghiệm hợp nhất.
Ví dụ: bạn không nên sử dụng các mẫu sau:
Phần trang web: Tách các phần khác nhau của một trang web trên các miền phụ. Trong các trang web tin tức, không hiếm khi bạn thấy trang chủ ở:
https://www.example.com, trong khi phần thể thao ởhttps://sports.example.com, chính trị ởhttps://politics.example.com, v.v. Trong trường hợp trang web thương mại điện tử, hãy sử dụng một số ký tự nhưhttps://category.example.comcho danh mục sản phẩm,https://product.example.comcho trang sản phẩm, v.v.Luồng người dùng: Một phương pháp khác không được khuyến khích là tách các phần nhỏ khác nhau của trang web, chẳng hạn như các trang cho quy trình đăng nhập hoặc mua hàng trong miền con. Ví dụ: sử dụng
https://login.example.comvàhttps://checkout.example.com.
Đối với những trường hợp không thể di chuyển sang một nguồn duy nhất, sau đây là danh sách các thách thức và (nếu có thể) các giải pháp thay thế mà bạn có thể cân nhắc khi xây dựng Ứng dụng web tiến bộ.
Thách thức và giải pháp cho PWA trên nhiều nguồn
Khi xây dựng một trang web trên nhiều nguồn gốc, việc cung cấp trải nghiệm PWA hợp nhất là một thách thức, chủ yếu là do chính sách cùng nguồn gốc. Chính sách này áp đặt một số hạn chế. Hãy cùng xem xét từng loại một.
Trình chạy dịch vụ
Nguồn gốc của URL tập lệnh trình chạy dịch vụ phải giống với nguồn gốc của trang gọi register(). Điều này có nghĩa là, ví dụ: một trang tại https://www.example.com không thể gọi register() bằng URL trình chạy dịch vụ tại https://section.example.com.
Một điểm cần lưu ý khác là trình chạy dịch vụ chỉ có thể kiểm soát các trang được lưu trữ theo nguồn gốc và đường dẫn mà trình chạy đó thuộc về. Điều này có nghĩa là nếu trình chạy dịch vụ được lưu trữ tại https://www.example.com, thì trình chạy này chỉ có thể kiểm soát các URL từ nguồn đó (theo đường dẫn được xác định trong tham số phạm vi), nhưng sẽ không kiểm soát bất kỳ trang nào trong các miền con khác, chẳng hạn như các trang trong https://section.example.com.
Trong trường hợp này, giải pháp duy nhất là sử dụng nhiều worker dịch vụ (mỗi worker cho một nguồn).
Lưu vào bộ nhớ đệm
Đối tượng Bộ nhớ đệm, indexedDB và localStorage cũng bị giới hạn ở một nguồn gốc duy nhất. Điều này có nghĩa là bạn không thể truy cập vào bộ nhớ đệm thuộc về https://www.example.com, chẳng hạn như từ https://www.section.example.com.
Sau đây là một số việc bạn có thể làm để quản lý bộ nhớ đệm đúng cách trong những trường hợp như thế này:
Tận dụng tính năng lưu vào bộ nhớ đệm của trình duyệt: Bạn nên sử dụng các phương pháp hay nhất truyền thống để lưu vào bộ nhớ đệm của trình duyệt. Kỹ thuật này mang lại lợi ích bổ sung là sử dụng lại các tài nguyên được lưu vào bộ nhớ đệm trên nhiều nguồn, điều này không thể thực hiện được với bộ nhớ đệm của worker dịch vụ. Để biết các phương pháp hay nhất về cách sử dụng Bộ nhớ đệm HTTP với các worker dịch vụ, bạn có thể xem bài đăng này.
Giữ cho quá trình cài đặt service worker ở mức tối thiểu: Nếu bạn đang duy trì nhiều service worker, hãy tránh để người dùng phải trả một khoản phí cài đặt lớn mỗi khi họ chuyển đến một nguồn gốc mới. Nói cách khác: chỉ lưu trước vào bộ nhớ đệm những tài nguyên thực sự cần thiết.
Quyền
Các quyền cũng được giới hạn trong các nguồn gốc. Điều này có nghĩa là nếu người dùng cấp một quyền nhất định cho nguồn gốc https://section.example.com, thì quyền đó sẽ không được chuyển sang các nguồn gốc khác, chẳng hạn như https://www.example.com.
Vì không có cách nào để chia sẻ quyền trên các nguồn gốc, nên giải pháp duy nhất ở đây là yêu cầu cấp quyền trên mỗi miền phụ nơi cần có một tính năng nhất định (ví dụ: vị trí). Đối với những thứ như thông báo đẩy trên web, bạn có thể duy trì một cookie để theo dõi xem người dùng đã chấp nhận quyền trong một miền con khác hay chưa, để tránh yêu cầu lại quyền đó.
Cài đặt
Để cài đặt một PWA, mỗi nguồn gốc phải có tệp kê khai riêng với một start_url tương ứng với chính nó. Điều này có nghĩa là người dùng nhận được lời nhắc cài đặt trên một nguồn gốc nhất định (tức là https://section.example.com) sẽ không thể cài đặt PWA có start_url trên một nguồn gốc khác (tức là https://www.example.com). Nói cách khác, người dùng nhận được lời nhắc cài đặt trong một miền con sẽ chỉ có thể cài đặt PWA cho các trang con, chứ không thể cài đặt cho URL chính của ứng dụng.
Ngoài ra, cũng có vấn đề là cùng một người dùng có thể nhận được nhiều lời nhắc cài đặt khi điều hướng trang web, nếu mỗi miền con đáp ứng tiêu chí cài đặt và nhắc người dùng cài đặt PWA.
Để giảm thiểu vấn đề này, bạn có thể đảm bảo rằng lời nhắc chỉ xuất hiện trên nguồn gốc chính. Khi người dùng truy cập vào một miền con đáp ứng tiêu chí cài đặt:
- Lắng nghe sự kiện
beforeinstallprompt. - Ngăn lời nhắc xuất hiện, gọi
event.preventDefault().
Bằng cách đó, bạn có thể đảm bảo rằng lời nhắc không xuất hiện ở những phần không mong muốn của trang web, đồng thời bạn có thể tiếp tục hiển thị lời nhắc này, chẳng hạn như trong nguồn gốc chính (ví dụ: Trang chủ).
Chế độ độc lập
Khi điều hướng trong một cửa sổ độc lập, trình duyệt sẽ hoạt động khác khi người dùng di chuyển ra ngoài phạm vi do tệp kê khai của PWA đặt. Hành vi này phụ thuộc vào từng phiên bản trình duyệt và nhà cung cấp. Ví dụ: các phiên bản Chrome mới nhất sẽ mở một Thẻ Chrome tuỳ chỉnh khi người dùng thoát khỏi phạm vi ở chế độ độc lập.
Trong hầu hết các trường hợp, không có giải pháp nào cho vấn đề này, nhưng bạn có thể áp dụng một giải pháp tạm thời cho những phần nhỏ của trải nghiệm được lưu trữ trong các miền con (ví dụ: quy trình đăng nhập):
- URL mới,
https://login.example.com, có thể mở trong một iframe toàn màn hình. - Sau khi hoàn tất tác vụ trong iframe (ví dụ: quy trình đăng nhập), bạn có thể dùng postMessage() để truyền mọi thông tin thu được từ iframe trở lại trang gốc.
- Bước cuối cùng, sau khi trang chính nhận được thông báo, bạn có thể huỷ đăng ký trình nghe và cuối cùng xoá iframe khỏi DOM.
Kết luận
Chính sách cùng nguồn gốc áp đặt nhiều hạn chế đối với những trang web được xây dựng dựa trên nhiều nguồn gốc muốn đạt được trải nghiệm nhất quán của PWA. Vì lý do đó, để mang lại trải nghiệm tốt nhất cho người dùng, bạn không nên chia các trang web thành nhiều nguồn gốc.
Đối với những trang web hiện có đã được xây dựng theo cách này, việc làm cho PWA nhiều nguồn gốc hoạt động chính xác có thể là một thách thức, nhưng chúng tôi đã khám phá một số giải pháp tiềm năng. Mỗi phương pháp đều có ưu và nhược điểm, vì vậy, hãy suy xét kỹ khi quyết định chọn phương pháp nào cho trang web của bạn.
Khi đánh giá chiến lược dài hạn hoặc thiết kế lại trang web, hãy cân nhắc việc di chuyển sang một nguồn duy nhất, trừ phi có lý do quan trọng để duy trì cấu trúc nhiều nguồn.
Xin chân thành cảm ơn Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle và Andre Bandarra vì những ý kiến đề xuất và đánh giá kỹ thuật của họ.