Merespons permintaan navigasi tanpa menunggu jaringan 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 navigasi berjalan sangat cepat, selain tangguh saat jaringan tidak tersedia. Hal ini adalah satu-satunya keuntungan performa terbesar yang berasal dari pekerja layanan, dibandingkan dengan yang dimungkinkan oleh cache 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 akan memulai alur semua permintaan lainnya untuk subresource seperti gambar, skrip, dan gaya.
Di dalam pengendali peristiwa fetch pekerja layanan, Anda dapat menentukan apakah suatu permintaan merupakan navigasi dengan memeriksa properti request.mode di FetchEvent. Jika disetel 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, (secara wajar) baru. Sayangnya, setiap kali pengguna menavigasi ke
halaman baru, setiap navigasi mungkin akan menjadi lambat. Setidaknya, artinya tidak akan andal cepat.
Berbagai pendekatan untuk arsitektur
Mencari tahu cara merespons permintaan navigasi sambil menghindari jaringan bisa menjadi hal yang rumit. Pendekatan yang tepat sangat bergantung pada arsitektur situs Anda dan jumlah URL unik yang mungkin dibuka pengguna.
Meskipun tidak ada solusi tunggal yang cocok untuk semua, panduan umum berikut dapat membantu Anda memutuskan pendekatan mana yang paling layak.
Situs statis kecil
Jika aplikasi web Anda terdiri dari sejumlah kecil URL unik (misalnya: puluhan) URL unik, dan masing-masing URL tersebut terkait dengan file HTML statis yang berbeda, salah satu pendekatan yang tepat adalah dengan meng-cache semua file HTML tersebut, dan merespons permintaan navigasi dengan HTML yang di-cache dan 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 membuat ulang situs dan men-deploy ulang pekerja layanan.
Atau, jika Anda lebih memilih untuk menghindari meng-cache semua HTML Anda terlebih dahulu—mungkin karena pengguna cenderung hanya menavigasi ke subkumpulan URL di situs—Anda dapat menggunakan strategi penyimpanan dalam cache pada waktu proses yang tidak berlaku saat validasi ulang. Namun, berhati-hatilah dengan pendekatan ini, karena setiap dokumen HTML individual akan disimpan dalam cache dan diperbarui secara terpisah. Penggunaan cache runtime untuk HTML paling tepat digunakan jika Anda memiliki sedikit URL yang sering dikunjungi kembali oleh sekelompok pengguna yang sama, dan jika Anda merasa tidak keberatan dengan URL tersebut divalidasi ulang secara terpisah satu sama lain.
Aplikasi web satu halaman
Arsitektur 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, sehingga menghasilkan navigasi "simulasi". Meskipun navigasi berikutnya mungkin "palsu", navigasi awal itu nyata, dan tetap penting untuk memastikan bahwa navigasi tidak diblokir di jaringan.
Untungnya, jika Anda menggunakan arsitektur satu halaman, ada pola yang mudah diikuti untuk menyajikan navigasi awal dari cache: shell aplikasi. Dalam model ini, pekerja layanan Anda merespons permintaan navigasi dengan menampilkan satu file HTML yang sama yang telah di-precache, terlepas dari URL yang diminta. HTML ini harus sederhana, terdiri dari, mungkin, indikator pemuatan generik 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 diperlukan untuk menerapkan pendekatan ini; navigateFallback
option
memungkinkan Anda menentukan dokumen HTML yang akan digunakan sebagai shell aplikasi, beserta daftar izinkan dan
tolak opsional untuk membatasi perilaku ini pada subkumpulan URL.
Aplikasi multi-halaman
Jika server web Anda menghasilkan HTML situs secara dinamis, atau jika Anda memiliki lebih dari beberapa halaman unik, akan jauh lebih sulit untuk menghindari jaringan saat menangani permintaan navigasi. Saran di Lainnya mungkin akan berlaku untuk Anda.
Namun, untuk subkumpulan aplikasi multi-halaman tertentu, Anda mungkin dapat menerapkan pekerja layanan yang sepenuhnya mereplikasi logika yang digunakan di server web Anda untuk menghasilkan HTML. Ini akan berfungsi optimal jika Anda dapat membagikan informasi pemilihan rute dan template 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 dan masuk ke pekerja layanan Anda, panduan dalam Lebih dari SPA: arsitektur alternatif untuk PWA dapat membantu Anda memulai.
Lainnya
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 (untuk menangani permintaan non-HTML lainnya) tidak akan 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 dipramuat di dalam pengendali peristiwa fetch Anda.
Workbox menyediakan library helper yang mendeteksi apakah pramuat navigasi didukung, dan jika demikian, akan menyederhanakan proses memberi tahu pekerja layanan Anda untuk menggunakan respons jaringan.
Foto oleh Aaron Burden di Unsplash