Merancang aplikasi Anda untuk memaksimalkan teknologi yang membuat PWA andal, dapat diinstal, dan mampu dimulai dengan memahami aplikasi Anda dan batasannya, dan memilih arsitektur yang tepat untuk keduanya.
SPA versus MPA
Saat ini, ada dua pola arsitektur utama dalam pengembangan web: aplikasi web satu halaman, atau SPA, dan aplikasi web multi-halaman, atau MPA.
Aplikasi web satu halaman ditentukan dengan memiliki JavaScript sisi klien yang mengontrol sebagian besar atau semua rendering HTML halaman berdasarkan data yang diambil oleh atau diberikan ke aplikasi. Aplikasi akan mengganti navigasi bawaan browser, dan menggantinya dengan fungsi pemilihan rute dan penanganan tampilan.
Aplikasi multi-halaman biasanya memiliki HTML pra-render yang dikirim langsung ke browser, sering kali ditingkatkan dengan JavaScript sisi klien setelah browser selesai memuat HTML, dan mengandalkan mekanisme navigasi bawaan browser untuk menampilkan tampilan berikutnya.
Kedua arsitektur tersebut dapat digunakan untuk membuat PWA.
Masing-masing memiliki kelebihan dan kekurangan, dan memilih yang tepat untuk kasus penggunaan dan konteks Anda adalah kunci untuk memberikan pengalaman yang cepat dan andal bagi pengguna.
Aplikasi web satu halaman
- Sebagian besar pembaruan dalam halaman yang bersifat atomik.
- Dependensi sisi klien yang dimuat saat memulai.
- Pemuatan berikutnya akan cepat, karena penggunaan cache.
- Biaya pemuatan awal yang tinggi.
- Performa bergantung pada hardware perangkat dan koneksi jaringan.
- Kompleksitas aplikasi tambahan diperlukan.
Aplikasi web satu halaman adalah pilihan arsitektur yang tepat jika:
- Interaksi pengguna terutama berfokus pada pembaruan atomik data yang saling terhubung yang ditampilkan di halaman yang sama, misalnya, dasbor data real-time atau aplikasi pengeditan video.
- Aplikasi Anda memiliki dependensi inisialisasi khusus sisi klien, misalnya, penyedia autentikasi pihak ketiga dengan biaya startup yang sangat tinggi.
- Data yang diperlukan agar tampilan dimuat bergantung pada konteks khusus sisi klien, misalnya, menampilkan kontrol untuk hardware yang terhubung.
- Aplikasi ini cukup kecil dan sederhana sehingga ukuran dan kompleksitasnya tidak berdampak pada kekurangan yang tercantum di atas.
SPA mungkin bukan pilihan arsitektur yang baik jika:
- Performa pemuatan awal sangat penting. SPA biasanya perlu memuat lebih banyak JavaScript untuk menentukan apa yang akan dimuat dan cara menampilkannya. Waktu penguraian dan eksekusi JavaScript ini, yang dikombinasikan dengan pengambilan konten, lebih lambat daripada mengirim HTML yang dirender.
- Aplikasi Anda sebagian besar berjalan di perangkat dengan daya rendah hingga sedang. Karena SPA bergantung pada JavaScript untuk rendering, pengalaman pengguna bergantung jauh lebih signifikan pada kemampuan perangkat tertentu mereka daripada di MPA.
Karena SPA perlu mengganti navigasi bawaan browser dengan perutean, SPA memerlukan tingkat kompleksitas minimum untuk memperbarui tampilan saat ini secara efisien, mengelola perubahan navigasi, dan membersihkan tampilan sebelumnya yang akan ditangani oleh browser, sehingga secara keseluruhan lebih sulit dikelola dan lebih membebani perangkat pengguna.
Aplikasi multi-halaman
- Sebagian besar pembaruan satu halaman penuh.
- Kecepatan rendering awal sangat penting.
- Pembuatan skrip sisi klien dapat menjadi peningkatan.
- Tampilan sekunder memerlukan panggilan server lain.
- Konteks tidak diterapkan antar-tampilan.
- Memerlukan server atau pra-rendering.
Aplikasi multi-halaman adalah pilihan arsitektur yang baik jika:
- Interaksi pengguna terutama berpusat pada tampilan satu bagian data dengan data berbasis konteks opsional, misalnya, aplikasi berita atau e-commerce.
- Kecepatan render awal sangat penting, karena mengirim HTML yang telah dirender ke browser lebih cepat daripada menyusunnya dari permintaan data setelah memuat, mengurai, dan menjalankan alternatif berbasis JavaScript.
- Interaktivitas atau konteks sisi klien dapat disertakan sebagai peningkatan setelah pemuatan awal, misalnya, menempatkan profil ke halaman yang dirender atau menambahkan komponen sekunder yang bergantung pada konteks sisi klien.
MPA mungkin bukan pilihan arsitektur yang baik jika:
- Mendownload ulang, mengurai ulang, dan mengeksekusi ulang JavaScript atau CSS Anda sangat mahal. Kekurangan ini dimitigasi di PWA dengan pekerja layanan.
- Konteks sisi klien, seperti lokasi pengguna, tidak terbawa dengan lancar di antara tampilan, dan mendapatkan kembali konteks tersebut mungkin mahal. Rekaman aktivitas ini perlu diambil dan diambil, atau diminta ulang di antara penayangan.
Karena setiap tampilan perlu dirender secara dinamis oleh server atau dipra-render sebelum akses, hal ini berpotensi membatasi hosting atau menambahkan kompleksitas data.
Mana yang harus dipilih?
Meskipun memiliki kelebihan dan kekurangan ini, kedua arsitektur tersebut valid untuk membuat PWA Anda. Anda bahkan dapat mencampurkannya untuk berbagai bagian aplikasi, bergantung pada kebutuhannya, misalnya, membuat listingan Play Store mengikuti arsitektur MPA dan alur checkout mengikuti arsitektur SPA.
Terlepas dari pilihannya, langkah berikutnya adalah memahami cara terbaik menggunakan pekerja layanan untuk memberikan pengalaman terbaik.
Kekuatan pekerja layanan
Pekerja layanan memiliki banyak kekuatan di luar perutean dan pengiriman respons yang di-cache dan jaringan. Kita dapat membuat algoritma kompleks yang dapat meningkatkan pengalaman dan performa pengguna.
Service worker includes (SWI)
Pola yang muncul untuk menggunakan pekerja layanan sebagai bagian integral dari arsitektur situs adalah menyertakan pekerja layanan (SWI).
SWI membagi setiap aset, biasanya halaman HTML, menjadi beberapa bagian berdasarkan kebutuhan penyimpanan dalam cache-nya, lalu menggabungkannya kembali di pekerja layanan untuk meningkatkan konsistensi, performa, dan keandalan, sekaligus mengurangi ukuran cache.
Gambar ini adalah contoh halaman web. Halaman ini memiliki lima bagian berbeda yang membagi halaman menjadi:
- Tata letak secara keseluruhan.
- Header global (panel gelap atas).
- Area konten (garis dan gambar kiri tengah).
- Sidebar (kolom tinggi berwarna gelap sedang di kanan tengah).
- Footer (bilah bawah gelap).
Tata letak keseluruhan
Tata letak secara keseluruhan kemungkinan tidak sering berubah dan tidak memiliki dependensi. Opsi ini adalah kandidat yang baik untuk precaching.
Tajuk dan tampilan bawah
Header dan footer global berisi hal-hal seperti menu atas dan footer situs, serta menghadirkan tantangan tertentu: jika halaman di-cache secara keseluruhan, hal ini dapat berubah di antara pemuatan halaman, bergantung pada waktu halaman tertentu di-cache.
Dengan memisahkannya dan meng-cache-nya secara terpisah dari konten, Anda dapat memastikan bahwa pengguna akan selalu mendapatkan versi yang sama, terlepas dari kapan versi tersebut di-cache. Karena jarang diupdate, skrip ini juga merupakan kandidat yang baik untuk precaching. Namun, modul tersebut memiliki dependensi: CSS dan JavaScript situs.
CSS dan JavaScript
Idealnya, CSS dan JavaScript situs harus di-cache dengan strategi yang usang saat memvalidasi ulang untuk memungkinkan update inkremental tanpa perlu memperbarui pekerja layanan, seperti yang terjadi dengan aset yang telah disimpan sebelumnya. Namun, keduanya juga harus disimpan dalam versi minimum setiap kali pekerja layanan diupdate dengan header atau footer global baru. Oleh karena itu, cache-nya juga harus diperbarui dengan versi aset terbaru saat pekerja layanan diinstal.
Area konten
Berikutnya adalah area konten. Bergantung pada frekuensi pembaruan, jaringan terlebih dahulu atau sudah tidak berlaku saat memvalidasi ulang adalah strategi yang baik di sini. Gambar harus di-cache dengan strategi cache first, seperti yang telah dibahas sebelumnya.
Bilah sisi
Terakhir, dengan asumsi bahwa konten sidebar berisi konten sekunder seperti tag dan item terkait, konten tersebut tidak cukup penting untuk diambil dari jaringan. Strategi yang sudah tidak berlaku saat memvalidasi ulang akan berfungsi untuk hal ini.
Sekarang, setelah melakukan semua itu, Anda mungkin berpikir bahwa Anda hanya dapat melakukan jenis penyimpanan dalam cache per bagian ini untuk aplikasi web satu halaman. Namun, dengan mengadopsi pola yang terinspirasi oleh edge side includes atau server side includes di service worker Anda, dengan beberapa fitur service worker lanjutan, Anda dapat melakukannya untuk kedua arsitektur tersebut.
Cobalah sendiri
Anda dapat mencoba yang disertakan pekerja layanan dengan codelab berikutnya:
Respons aliran data
Halaman sebelumnya dapat dibuat menggunakan model shell aplikasi di dunia SPA, tempat shell aplikasi di-cache, lalu ditayangkan, dan konten dimuat di sisi klien. Dengan diperkenalkannya dan ketersediaan Streams API yang luas, shell aplikasi dan konten dapat digabungkan dalam pekerja layanan dan di-streaming ke browser, sehingga memberi Anda fleksibilitas penyimpanan app shell dalam kecepatan MPA.
Hal ini dilakukan karena:
- Streaming dapat dibuat secara asinkron, sehingga berbagai bagian streaming dapat berasal dari sumber lain.
- Pemohon aliran data dapat mulai mengerjakan respons segera setelah bagian data pertama tersedia, bukan menunggu seluruh item selesai.
- Parser yang dioptimalkan untuk streaming, termasuk browser, dapat menampilkan konten streaming secara bertahap sebelum selesai, sehingga mempercepat performa respons yang dirasakan.
Berkat tiga properti streaming ini, arsitektur yang dibuat di sekitar streaming biasanya memiliki performa yang dirasakan lebih cepat daripada yang tidak.
Menggunakan Streams API dapat menjadi tantangan karena kompleks dan level rendah. Untungnya, ada modul Workbox yang dapat membantu menyiapkan respons streaming untuk pekerja layanan Anda.
Domain, origin, dan cakupan PWA
Web worker, termasuk service worker, penyimpanan, bahkan jendela PWA yang diinstal, semuanya diatur oleh salah satu mekanisme keamanan yang paling penting di web: kebijakan origin yang sama. Dalam origin yang sama, izin diberikan, data dapat dibagikan, dan pekerja layanan dapat berkomunikasi dengan klien yang berbeda. Di luar origin yang sama, izin tidak diberikan secara otomatis dan data akan diisolasi serta tidak dapat diakses di antara origin yang berbeda.
Kebijakan origin yang sama
Dua URL didefinisikan memiliki asal yang sama persis jika protokol, port, dan host sama.
Misalnya: https://squoosh.app, dan https://squoosh.app/v2 memiliki asal yang sama, tetapi http://squoosh.app, https://squoosh.com, https://app.squoosh.app, dan https://squoosh.app:8080 berasal dari tempat yang berbeda. Lihat referensi MDN kebijakan origin yang sama untuk mengetahui informasi dan contoh selengkapnya.
Mengubah subdomain bukanlah satu-satunya cara yang dapat diubah oleh host. Setiap host terdiri dari domain level teratas (TLD), domain level sekunder (SLD), dan nol atau beberapa label (terkadang disebut subdomain), yang dipisahkan oleh titik di antaranya dan dibaca dari kanan ke kiri di URL. Perubahan pada salah satu item akan menghasilkan host yang berbeda.
Di modul pengelolaan jendela, kita telah melihat tampilan browser dalam aplikasi saat pengguna membuka origin yang berbeda dari PWA yang diinstal.
Browser dalam aplikasi tersebut akan muncul meskipun situs memiliki TLD dan SLD yang sama, tetapi dengan label yang berbeda, karena situs tersebut dianggap berasal dari tempat yang berbeda.
Salah satu aspek utama origin dalam konteks penjelajahan web adalah cara kerja penyimpanan dan izin. Satu origin memiliki banyak fitur di antara semua konten dan PWA di dalamnya, termasuk:
- Kuota dan data penyimpanan (IndexedDB, cookie, web storage, penyimpanan cache).
- Pendaftaran pekerja layanan.
- Izin yang diberikan atau ditolak (seperti push web, geolokasi, sensor).
- Pendaftaran web push.
Saat Anda berpindah dari satu origin ke origin lainnya, semua akses sebelumnya akan dicabut, sehingga izin harus diberikan lagi, dan PWA Anda tidak dapat mengakses semua data yang disimpan di penyimpanan.