Respons 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 terbesarnya terhadap performa: jika Anda menggunakan pekerja layanan untuk merespons permintaan navigasi tanpa menunggu jaringan, Anda dapat memastikan bahwa navigasi cepat dan andal, selain tangguh saat jaringan tidak tersedia. Ini adalah satu-satunya peningkatan performa terbesar yang berasal dari pekerja layanan, dibandingkan dengan yang mungkin dilakukan dengan cache HTTP.
Seperti yang dijelaskan dalam panduan Mengidentifikasi resource yang dimuat dari jaringan, permintaan navigasi adalah permintaan pertama dari banyak permintaan yang mungkin dibuat dalam "waterfall" traffic jaringan. HTML yang Anda muat melalui permintaan navigasi akan memulai alur semua permintaan lainnya untuk sub-resource 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',
ini adalah permintaan navigasi.
Sebagai aturan umum, jangan gunakan Cache-Control headers yang berumur panjang untuk meng-cache respons HTML untuk permintaan navigasi. Biasanya, permintaan ini harus dipenuhi melalui jaringan, dengan
Cache-Control: no-cache, untuk memastikan bahwa HTML, beserta rantai permintaan jaringan
berikutnya, (cukup) baru. Sayangnya, melawan jaringan setiap kali pengguna membuka
halaman baru berarti setiap navigasi mungkin lambat. Setidaknya, hal ini
berarti tidak akan andal dan cepat.
Berbagai pendekatan untuk arsitektur
Mencari tahu cara merespons permintaan navigasi sambil menghindari jaringan bisa jadi rumit. Pendekatan yang tepat sangat bergantung pada arsitektur situs Anda dan jumlah URL unik yang dapat diakses pengguna.
Meskipun tidak ada solusi yang cocok untuk semua, panduan umum berikut akan membantu Anda memutuskan pendekatan mana yang paling sesuai.
Situs statis kecil
Jika aplikasi web Anda terdiri dari sejumlah kecil URL unik (misalnya: beberapa lusin), dan setiap URL tersebut sesuai dengan file HTML statis yang berbeda, salah satu pendekatan yang dapat dilakukan adalah dengan meng-cache semua file HTML tersebut, dan merespons permintaan navigasi dengan HTML yang di-cache yang sesuai.
Dengan menggunakan pra-caching, Anda dapat meng-cache HTML terlebih dahulu, segera setelah pekerja layanan diinstal, dan mengupdate HTML yang di-cache setiap kali Anda mem-build ulang situs dan men-deploy ulang pekerja layanan.
Atau, jika Anda lebih memilih untuk tidak melakukan pra-caching semua HTML—mungkin karena pengguna cenderung membuka hanya sebagian URL di situs Anda—Anda dapat menggunakan strategi cache runtime stale-while-revalidate. Namun, berhati-hatilah dengan pendekatan ini karena setiap dokumen HTML di-cache dan diupdate secara terpisah. Menggunakan cache runtime untuk HTML paling sesuai jika Anda memiliki sedikit URL yang sering dikunjungi oleh kumpulan pengguna yang sama, dan jika Anda merasa nyaman dengan URL tersebut yang divalidasi ulang secara terpisah.
Aplikasi web satu halaman
Arsitektur web satu halaman sering digunakan oleh aplikasi web modern. Di dalamnya, JavaScript sisi klien akan 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 "simulasi" yang efektif. Meskipun navigasi berikutnya mungkin "palsu", navigasi awal adalah nyata, dan penting untuk memastikan bahwa navigasi tersebut tidak diblokir di jaringan.
Untungnya, jika Anda menggunakan arsitektur single-page, ada pola sederhana yang harus diikuti untuk menyalurkan navigasi awal dari cache: shell aplikasi. Dalam model ini, pekerja layanan Anda merespons permintaan navigasi dengan menampilkan satu file HTML yang sama yang telah dipra-cache, apa pun URL yang diminta. HTML ini harus sederhana, yang mungkin terdiri dari 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 shell aplikasi, beserta daftar izin dan
penolakan opsional untuk membatasi perilaku ini ke sebagian URL Anda.
Aplikasi multi-halaman
Jika server web Anda membuat HTML situs secara dinamis, atau jika Anda memiliki lebih dari beberapa lusin halaman unik, akan jauh lebih sulit untuk menghindari jaringan saat menangani permintaan navigasi. Saran di bagian Yang lainnya kemungkinan akan berlaku untuk Anda.
Namun, untuk subset aplikasi multi-halaman tertentu, Anda mungkin dapat menerapkan pekerja layanan yang mereplikasi logika yang digunakan di server web sepenuhnya untuk membuat HTML. Hal ini berfungsi paling baik jika Anda dapat membagikan informasi pemilihan rute dan pembuatan template antara server dan lingkungan pekerja layanan, dan secara khusus, 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 salah satu pendekatan untuk memindahkan pembuatan HTML dari jaringan ke pekerja layanan, panduan di Beyond SPAs: alternative architectures for PWA dapat membantu Anda memulai.
Lainnya
Jika 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 menyebabkan sedikit latensi (seperti yang dijelaskan dalam Mem-build Aplikasi yang Lebih Cepat dan Lebih Tangguh
dengan Pekerja Layanan). Anda dapat mengurangi overhead ini dengan mengaktifkan
fitur yang disebut pramuat
navigasi, lalu menggunakan
respons
jaringan
yang telah dipramuat di dalam pengendali peristiwa fetch.
Workbox menyediakan library helper yang mendeteksi fitur apakah pramuat navigasi didukung, dan jika demikian, menyederhanakan proses memberi tahu pekerja layanan Anda untuk menggunakan respons jaringan.
Foto oleh Aaron Burden di Unsplash