Terima kasih telah menonton Google I/O. Tonton konten secara on-demand.

Halaman ini diterjemahkan oleh Cloud Translation API.

Progressive Web App di situs multi-origin

Tantangan dan solusi untuk membuat Progressive Web App di situs multi-origin.

Demián Renzulli

Dipublikasikan: 19 Agustus 2019

Sebelumnya, ada beberapa keuntungan menggunakan arsitektur multi-origin. Untuk Progressive Web App, pendekatan tersebut menimbulkan banyak tantangan. Khususnya, kebijakan origin yang sama, menerapkan batasan untuk berbagi hal-hal seperti pekerja layanan dan cache, izin, dan untuk mencapai pengalaman mandiri di beberapa origin.

Temukan penggunaan beberapa origin yang baik dan buruk, serta jelaskan tantangan dan solusi untuk membangun Aplikasi Web Progresif di situs multi-origin.

Penggunaan beberapa asal yang baik dan buruk

Ada beberapa alasan yang sah bagi situs untuk menggunakan arsitektur multi-origin, yang sebagian besar terkait dengan penyediaan serangkaian aplikasi web independen, atau untuk menciptakan pengalaman yang benar-benar terisolasi satu sama lain. Ada juga penggunaan yang harus dihindari.

Yang baik

Lihat alasan yang berguna terlebih dahulu:

Pelokalan / Bahasa: Menggunakan domain level teratas kode negara, untuk memisahkan situs yang akan ditayangkan di berbagai negara (misalnya, https://www.google.com.ar), atau menggunakan subdomain untuk membagi situs yang ditargetkan ke berbagai lokasi (misalnya: https://newyork.craigslist.org) atau untuk menawarkan konten dalam bahasa tertentu (misalnya https://en.wikipedia.org).
Aplikasi web independen: Menggunakan subdomain yang berbeda untuk memberikan pengalaman yang tujuannya sangat berbeda dari situs di origin utama. Misalnya, di situs berita, aplikasi web teka-teki silang dapat disajikan secara sengaja dari https://crosswords.example.com, serta diinstal dan digunakan sebagai PWA independen, tanpa harus membagikan resource atau fungsi apa pun dengan situs utama.

Yang buruk

Jika Anda tidak melakukan salah satu hal ini, kemungkinan besar penggunaan arsitektur multi-origin akan menjadi kerugian saat membangun Progressive Web App.

Meskipun demikian, banyak situs terus disusun dengan cara ini tanpa alasan tertentu, atau karena alasan 'lama'. Salah satu contohnya adalah menggunakan subdomain untuk memisahkan bagian situs yang seharusnya menjadi bagian dari pengalaman terpadu secara sewenang-wenang.

Misalnya, pola berikut sangat tidak dianjurkan:

Bagian situs: Memisahkan berbagai bagian situs di subdomain. Di situs berita, tidak jarang kita melihat halaman beranda di: https://www.example.com, sementara bagian olahraga ada di https://sports.example.com, politik di https://politics.example.com, dan sebagainya. Dalam kasus situs e-commerce, gunakan sesuatu seperti https://category.example.com untuk kategori produk, https://product.example.com untuk halaman produk, dll.
Alur Pengguna: Pendekatan lain yang tidak disarankan adalah memisahkan berbagai bagian kecil situs, seperti halaman untuk alur login atau pembelian di subdomain. Misalnya, menggunakan https://login.example.com, dan https://checkout.example.com.

Untuk kasus di mana migrasi ke satu origin tidak memungkinkan, berikut adalah daftar tantangan, dan (jika memungkinkan), solusi yang dapat dipertimbangkan saat membangun Progressive Web App.

Tantangan dan Solusi untuk PWA di berbagai origin

Saat membangun situs di beberapa origin, memberikan pengalaman PWA terpadu menjadi sulit, terutama karena kebijakan origin yang sama, yang memberlakukan sejumlah batasan. Mari kita lihat satu per satu.

Service worker

Origin URL skrip pekerja layanan harus sama dengan origin halaman yang memanggil register(). Artinya, misalnya, halaman di https://www.example.com tidak dapat memanggil register() dengan URL pekerja layanan di https://section.example.com.

Pertimbangan lainnya adalah bahwa pekerja layanan hanya dapat mengontrol halaman yang dihosting di bawah asal dan jalur yang menjadi miliknya. Artinya, jika pekerja layanan dihosting di https://www.example.com, pekerja layanan hanya dapat mengontrol URL dari origin tersebut (sesuai dengan jalur yang ditentukan dalam parameter cakupan), tetapi tidak akan mengontrol halaman apa pun di subdomain lain seperti, misalnya, yang ada di https://section.example.com.

Dalam hal ini, satu-satunya solusi adalah menggunakan beberapa pekerja layanan (satu per origin).

Menyimpan ke cache

Objek Cache, indexedDB, dan localStorage juga dibatasi ke satu origin. Artinya, cache yang dimiliki https://www.example.com tidak dapat diakses dari, misalnya: https://www.section.example.com.

Berikut beberapa hal yang dapat Anda lakukan untuk mengelola cache dengan benar dalam skenario seperti ini:

Manfaatkan caching browser: Sebaiknya selalu gunakan praktik terbaik caching browser tradisional. Teknik ini memberikan manfaat tambahan berupa penggunaan ulang resource yang di-cache di seluruh origin, yang tidak dapat dilakukan dengan cache service worker. Untuk mengetahui praktik terbaik tentang cara menggunakan Cache HTTP dengan pekerja layanan, Anda dapat melihat postingan ini.
Jaga agar penginstalan pekerja layanan tetap ringan: Jika Anda mengelola beberapa pekerja layanan, hindari membuat pengguna membayar biaya penginstalan yang besar setiap kali mereka membuka origin baru. Dengan kata lain: hanya lakukan pra-cache pada resource yang benar-benar diperlukan.

Izin

Izin juga dicakup ke origin. Artinya, jika pengguna memberikan izin tertentu ke origin https://section.example.com, izin tersebut tidak akan diteruskan ke origin lain, seperti https://www.example.com.

Karena tidak ada cara untuk membagikan izin di seluruh origin, satu-satunya solusi di sini adalah meminta izin di setiap subdomain tempat fitur tertentu diperlukan (misalnya, lokasi). Untuk hal-hal seperti push web, Anda dapat mempertahankan cookie untuk melacak apakah izin telah diterima oleh pengguna di subdomain lain, untuk menghindari permintaan izin lagi.

Penginstalan

Untuk menginstal PWA, setiap origin harus memiliki manifesnya sendiri dengan start_url yang relatif terhadap dirinya sendiri. Artinya, pengguna yang menerima perintah penginstalan di origin tertentu (yaitu: https://section.example.com) tidak akan dapat menginstal PWA dengan start_url di origin lain (yaitu: https://www.example.com). Dengan kata lain, pengguna yang menerima perintah penginstalan di subdomain hanya akan dapat menginstal PWA untuk subhalaman, bukan untuk URL utama aplikasi.

Ada juga masalah bahwa pengguna yang sama dapat menerima beberapa perintah penginstalan saat menjelajahi situs, jika setiap subdomain memenuhi kriteria penginstalan, dan meminta pengguna untuk menginstal PWA.

Untuk mengurangi masalah ini, Anda dapat memastikan bahwa perintah hanya ditampilkan di origin utama. Saat pengguna mengunjungi subdomain yang memenuhi kriteria penginstalan:

Dengarkan peristiwa beforeinstallprompt.
Mencegah munculnya perintah, dengan memanggil event.preventDefault().

Dengan begitu, Anda memastikan perintah tidak ditampilkan di bagian situs yang tidak diinginkan, sementara Anda dapat terus menampilkannya, misalnya, di origin utama (mis. Halaman beranda).

Mode Mandiri

Saat menjelajah di jendela mandiri, browser akan berperilaku berbeda saat pengguna bergerak di luar cakupan yang ditetapkan oleh manifes PWA. Perilaku ini bergantung pada setiap versi dan vendor browser. Misalnya, versi Chrome terbaru membuka Tab Kustom Chrome, saat pengguna keluar dari cakupan dalam mode mandiri.

Dalam sebagian besar kasus, tidak ada solusi untuk masalah ini, tetapi solusi sementara dapat diterapkan untuk sebagian kecil pengalaman yang dihosting di subdomain (misalnya: alur kerja login):

URL baru, https://login.example.com, dapat dibuka di dalam iframe layar penuh.
Setelah tugas selesai di dalam iframe (misalnya, proses login), postMessage() dapat digunakan untuk meneruskan informasi yang dihasilkan dari iframe kembali ke halaman induk.
Sebagai langkah terakhir, setelah pesan diterima oleh halaman utama, pemroses dapat dibatalkan pendaftarannya, dan iframe akhirnya dihapus dari DOM.

Kesimpulan

Kebijakan origin yang sama memberlakukan banyak batasan untuk situs yang dibangun di atas beberapa origin yang ingin mencapai pengalaman PWA yang koheren. Oleh karena itu, untuk memberikan pengalaman terbaik kepada pengguna, sebaiknya jangan membagi situs ke dalam origin yang berbeda.

Untuk situs yang sudah dibuat dengan cara ini, akan sulit untuk membuat PWA multi-origin berfungsi dengan benar, tetapi kami telah mempelajari beberapa solusi potensial. Setiap pendekatan dapat memiliki konsekuensi, jadi gunakan penilaian Anda saat memutuskan pendekatan mana yang akan diterapkan di situs Anda.

Saat mengevaluasi strategi jangka panjang atau desain ulang situs, pertimbangkan untuk bermigrasi ke satu origin, kecuali jika ada alasan penting untuk mempertahankan arsitektur multi-origin.

Terima kasih banyak atas ulasan dan saran teknis mereka: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle, dan Andre Bandarra.