Merespons permintaan navigasi tanpa menunggu jaringan dengan menggunakan pekerja layanan.
Permintaan navigasi adalah permintaan untuk dokumen HTML yang dibuat oleh browser setiap kali Anda memasukkan URL baru di menu navigasi, atau mengikuti link di halaman yang mengarahkan Anda ke URL baru. Di sinilah pekerja layanan memberikan dampak terbesar terhadap performa: jika Anda menggunakan pekerja layanan untuk merespons permintaan navigasi tanpa menunggu jaringan, Anda dapat memastikan bahwa navigasinya cepat dan andal, selain tangguh saat jaringan tidak tersedia. Ini adalah satu-satunya keunggulan performa terbesar yang berasal dari pekerja layanan, dibandingkan dengan apa yang mungkin dilakukan dengan caching HTTP.
Seperti yang dijelaskan dalam panduan Mengidentifikasi resource yang dimuat dari jaringan, permintaan navigasi adalah permintaan pertama dari kemungkinan banyak permintaan yang dibuat dalam "waterfall" traffic jaringan. HTML yang Anda muat melalui permintaan navigasi memulai alur semua permintaan lainnya untuk subresource seperti gambar, skrip, dan gaya.
Di dalam pengendali peristiwa fetch pekerja layanan, Anda dapat menentukan apakah permintaan merupakan
navigasi dengan memeriksa properti request.mode di FetchEvent. Jika ditetapkan ke 'navigate',
maka itu adalah permintaan navigasi.
Sebagai aturan umum, jangan gunakan Cache-Control headers yang berumur panjang untuk meng-cache
respons HTML untuk permintaan navigasi. Proses ini biasanya harus dipenuhi melalui jaringan, dengan
Cache-Control: no-cache, untuk memastikan bahwa HTML, bersama dengan rantai permintaan
jaringan berikutnya, (cukup) baru. Sayangnya, bertentangan dengan jaringan setiap kali pengguna membuka
halaman baru berarti setiap navigasi mungkin lambat. Setidaknya, proses ini
tidak akan dapat diandalkan dengan cepat.
Berbagai pendekatan untuk arsitektur
Mencari tahu cara merespons permintaan navigasi sekaligus menghindari jaringan dapat menjadi hal yang sulit. Pendekatan yang tepat sangat bergantung pada arsitektur situs web Anda dan jumlah URL unik yang mungkin dibuka pengguna.
Meskipun tidak ada solusi tunggal yang cocok untuk semua situasi, panduan umum berikut akan membantu Anda memutuskan pendekatan mana yang paling tepat.
Situs statis kecil
Jika aplikasi web Anda terdiri atas jumlah yang relatif kecil (misalnya: beberapa lusin) URL unik, dan setiap URL tersebut sesuai dengan file HTML statis yang berbeda, satu pendekatan yang tepat adalah cukup dengan menyimpan semua file HTML tersebut ke dalam cache, dan merespons permintaan navigasi dengan HTML yang di-cache yang sesuai.
Dengan menggunakan precaching, Anda dapat meng-cache HTML terlebih dahulu, segera setelah pekerja layanan diinstal, dan memperbarui HTML yang di-cache setiap kali Anda membangun ulang situs dan men-deploy ulang pekerja layanan.
Atau, jika Anda lebih memilih untuk menghindari pracache semua HTML—mungkin karena pengguna cenderung hanya membuka sebagian URL di situs Anda—Anda dapat menggunakan strategi caching runtime stale-temporary-revalidate. Namun, berhati-hatilah dengan pendekatan ini, karena setiap dokumen HTML disimpan dalam cache dan diperbarui secara terpisah. Penggunaan cache runtime untuk HTML paling tepat adalah jika Anda memiliki sejumlah kecil URL yang sering dibuka kembali oleh sekumpulan pengguna yang sama, dan jika Anda merasa nyaman dengan URL tersebut yang divalidasi ulang secara terpisah satu sama lain.
Aplikasi web satu halaman
Arsitektur web satu halaman sering digunakan oleh aplikasi web modern. Di dalamnya, JavaScript sisi klien mengubah HTML sebagai respons terhadap tindakan pengguna. Model ini menggunakan History API untuk mengubah URL saat ini saat pengguna berinteraksi dengan aplikasi web, yang mengarah ke navigasi yang secara efektif merupakan navigasi "simulasi". Meskipun navigasi selanjutnya mungkin "palsu", navigasi awal tersebut nyata, dan masih penting untuk memastikan bahwa navigasi tersebut tidak diblokir di jaringan.
Untungnya, jika Anda menggunakan arsitektur satu halaman, ada pola sederhana yang harus diikuti untuk menayangkan navigasi awal dari cache: shell aplikasi. Dalam model ini, pekerja layanan Anda akan merespons permintaan navigasi dengan menampilkan satu file HTML yang sama dan telah di-pra-cache, terlepas dari URL yang diminta. HTML ini harus sederhana, terdiri dari, mungkin, indikator pemuatan umum atau konten kerangka. Setelah browser memuat HTML ini dari cache, JavaScript sisi klien yang ada akan mengambil alih, dan merender konten HTML yang benar untuk URL dari permintaan navigasi asli.
Workbox menyediakan alat yang Anda perlukan untuk menerapkan pendekatan ini; navigateFallback
option memungkinkan Anda menentukan dokumen HTML mana yang akan digunakan sebagai app shell, beserta daftar izinkan dan tolak opsional untuk membatasi perilaku ini ke sebagian URL.
Aplikasi multi-halaman
Jika server web menghasilkan HTML situs secara dinamis, atau jika Anda memiliki lebih dari beberapa lusin halaman unik, menghindari jaringan saat menangani permintaan navigasi akan jauh lebih sulit. Saran di bagian Lainnya mungkin akan berlaku untuk Anda.
Namun, untuk subset aplikasi multi-halaman tertentu, Anda mungkin dapat menerapkan pekerja layanan yang sepenuhnya mereplikasi logika yang digunakan di server web untuk menghasilkan HTML. Hal ini akan berfungsi optimal jika Anda dapat membagikan perutean dan template informasi antara lingkungan server dan pekerja layanan, dan khususnya, jika server web Anda menggunakan JavaScript (tanpa mengandalkan fitur khusus Node.js, seperti akses sistem file).
Jika server web Anda termasuk dalam kategori tersebut dan Anda ingin mempelajari satu pendekatan untuk memindahkan pembuatan HTML dari jaringan ke pekerja layanan, panduan dalam Lebih dari SPA: arsitektur alternatif untuk PWA dapat membantu Anda memulai.
Semua yang lain
Jika Anda tidak dapat merespons permintaan navigasi dengan HTML yang di-cache, Anda harus mengambil langkah-langkah untuk memastikan bahwa menambahkan pekerja layanan ke situs Anda (untuk menangani permintaan non-HTML lainnya) tidak pada akhirnya memperlambat navigasi. Memulai pekerja layanan tanpa menggunakannya untuk merespons permintaan navigasi akan menimbulkan sedikit latensi (seperti yang dijelaskan dalam Membuat Aplikasi yang Lebih Cepat dan Lebih Tangguh dengan Service Worker). Anda dapat mengurangi overhead ini dengan mengaktifkan
fitur yang disebut pramuat
navigasi, lalu menggunakan
respons
jaringan
yang telah dimuat sebelumnya di dalam pengendali peristiwa fetch.
Workbox menyediakan library pembantu yang mendeteksi apakah pramuat navigasi didukung atau tidak, dan jika ya, akan menyederhanakan proses memberi tahu pekerja layanan Anda untuk menggunakan respons jaringan.
Foto oleh Aaron Burden di Unsplash