Menangani permintaan navigasi

Merespons permintaan navigasi tanpa menunggu jaringan dengan menggunakan service worker.

Permintaan navigasi adalah permintaan untuk dokumen HTML yang dibuat oleh browser Anda 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 pada performa: jika Anda menggunakan pekerja layanan untuk merespons permintaan navigasi tanpa menunggu jaringan, Anda dapat memastikan bahwa navigasi dapat diandalkan dengan cepat, selain tangguh saat jaringan tidak tersedia. Ini adalah satu-satunya peningkatan 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 yang pertama dari banyak permintaan yang mungkin dibuat dalam "waterfall" traffic jaringan. HTML yang Anda muat melalui permintaan navigasi memulai alur semua permintaan lain untuk subresource seperti gambar, skrip, dan gaya.

Di dalam pengendali peristiwa fetch service worker, Anda dapat menentukan apakah permintaan adalah navigasi dengan memeriksa properti request.mode di FetchEvent. Jika ditetapkan ke 'navigate', maka permintaan tersebut 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, bersama dengan rantai permintaan jaringan berikutnya, (cukup) baru. Sayangnya, mengakses jaringan setiap kali pengguna membuka halaman baru berarti setiap navigasi mungkin lambat. Setidaknya, hal ini berarti bahwa performanya tidak akan selalu 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 mungkin dibuka pengguna.

Meskipun tidak ada satu solusi yang cocok untuk semua, panduan umum berikut akan membantu Anda memutuskan pendekatan mana yang paling layak.

Situs statis kecil

Jika aplikasi web Anda terdiri dari sejumlah kecil (misalnya: beberapa lusin) URL unik, dan setiap URL tersebut sesuai dengan file HTML statis yang berbeda, salah satu pendekatan yang layak adalah dengan menyimpan semua file HTML tersebut ke dalam cache, dan merespons permintaan navigasi dengan HTML yang di-cache yang sesuai.

Dengan menggunakan pra-cache, Anda dapat meng-cache HTML terlebih dahulu, segera setelah service worker diinstal, dan memperbarui HTML yang di-cache setiap kali Anda membangun ulang situs dan men-deploy ulang service worker.

Atau, jika Anda tidak ingin melakukan precaching pada semua HTML—mungkin karena pengguna cenderung hanya membuka sebagian URL di situs Anda—Anda dapat menggunakan strategi caching runtime stale-while-revalidate. Namun, berhati-hatilah dengan pendekatan ini, karena setiap dokumen HTML di-cache dan diperbarui secara terpisah. Menggunakan caching runtime untuk HTML paling sesuai jika Anda memiliki sejumlah kecil URL yang sering dikunjungi kembali oleh kumpulan pengguna yang sama, dan jika Anda merasa nyaman URL tersebut divalidasi ulang secara independen 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 yang secara efektif "disimulasikan". Meskipun navigasi berikutnya mungkin "palsu", navigasi awal adalah nyata, dan tetap penting untuk memastikan bahwa navigasi tersebut tidak diblokir di jaringan.

Untungnya, jika Anda menggunakan arsitektur satu halaman, ada pola yang mudah diikuti untuk menyajikan navigasi awal dari cache: application shell. Dalam model ini, service worker Anda merespons permintaan navigasi dengan menampilkan file HTML tunggal yang sama yang telah di-precache—terlepas dari URL yang diminta. HTML ini harus sederhana, mungkin terdiri dari indikator pemuatan umum atau konten skeleton. 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 yang akan digunakan sebagai app shell, beserta daftar izinkan dan tolak opsional untuk membatasi perilaku ini ke subset 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 dalam Hal lainnya kemungkinan akan berlaku untuk Anda.

Namun, untuk subset aplikasi multi-halaman tertentu, Anda mungkin dapat menerapkan pekerja layanan yang mereplikasi sepenuhnya logika yang digunakan di server web Anda untuk menghasilkan HTML. Cara ini paling efektif 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 ke dalam pekerja layanan, panduan dalam Selain 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 Anda (untuk menangani permintaan non-HTML lainnya) tidak akan memperlambat navigasi Anda. Memulai pekerja layanan tanpa menggunakannya untuk merespons permintaan navigasi akan menimbulkan sedikit latensi (seperti yang dijelaskan dalam Membangun Aplikasi yang Lebih Cepat dan Lebih Tangguh dengan Pekerja Layanan). Anda dapat mengurangi overhead ini dengan mengaktifkan fitur yang disebut pemuatan pra-pemuatan navigasi, lalu menggunakan respons jaringan yang telah dimuat sebelumnya di dalam pengendali peristiwa fetch Anda.

Workbox menyediakan library bantuan yang mendeteksi fitur apakah pramuat navigasi didukung, dan jika ya, menyederhanakan proses memberi tahu pekerja layanan Anda untuk menggunakan respons jaringan.