Dokumentasi ini telah membahas precaching sebelumnya, tetapi tidak cukup tentang cara melakukannya dengan benar. Hal ini penting, karena terlepas dari apakah Anda menggunakan Workbox, sangat mudah melakukan precache terlalu banyak dan berpotensi membuang-buang data dan bandwidth. Anda harus berhati-hati tentang pengaruh payload precache terhadap pengalaman pengguna.
Saat Anda membaca dokumen ini, pahami bahwa berikut adalah pedoman umum. Arsitektur dan persyaratan aplikasi mungkin mengharuskan Anda melakukan sesuatu yang berbeda dari yang disarankan di sini, tetapi panduan ini berfungsi sebagai default yang baik.
Anjuran: melakukan pra-cache pada aset statis penting
Kandidat terbaik untuk melakukan pra-cache adalah aset statis penting, tetapi apa yang dianggap sebagai aset "penting"? Dari perspektif developer, Anda mungkin tergoda untuk menganggap keseluruhan aplikasi sebagai "penting", tetapi perspektif pengguna adalah hal yang paling penting. Pikirkan aset penting sebagai aset yang benar-benar diperlukan untuk memberikan pengalaman pengguna:
- Stylesheet global.
- File JavaScript yang menyediakan fungsi global.
- HTML shell aplikasi, jika itu berlaku untuk arsitektur Anda.
Pengingat: ini adalah pedoman umum, bukan rekomendasi sulit. Saat meng-cache aset, sebaiknya jangan menyimpan preca-caching lebih sedikit daripada lebih banyak.
Anjuran: melakukan pra-cache penggantian offline untuk situs multihalaman
Untuk situs multihalaman pada umumnya, Anda mungkin mengandalkan strategi caching yang mengutamakan jaringan atau khusus jaringan untuk menangani permintaan navigasi.
Dalam kasus seperti itu, Anda dapat memastikan pekerja layanan melakukan pra-cache dan merespons dengan halaman fallback offline ketika pengguna membuat permintaan navigasi saat offline. Salah satu cara untuk melakukannya di Workbox adalah dengan menggunakan strategi khusus jaringan dengan penggantian offline, yang juga memanfaatkan pramuat navigasi:
import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute, Route} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
import * as navigationPreload from 'workbox-navigation-preload';
navigationPreload.enable();
// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);
// The network-only callback should match navigation requests, and
// the handler for the route should use the network-only strategy, but
// fall back to a precached offline page in case the user is offline.
const networkOnlyNavigationRoute = new Route(({request}) => {
return request.mode === 'navigate';
}, new NetworkOnly({
plugins: [
new PrecacheFallbackPlugin({
fallbackURL: '/offline.html'
})
]
}));
registerRoute(networkOnlyNavigationRoute);
Hal ini memastikan bahwa jika pengguna offline dan membuka halaman yang tidak ada dalam cache, pengguna setidaknya akan mendapatkan beberapa konten offline.
Mungkin lakukan: pertimbangkan pra-cache spekulatif
Hal ini "mungkin" besar, tetapi ada manfaat potensial dalam menyimpan aset yang hanya digunakan dalam skenario tertentu dalam cache. Pikirkan tentang hal itu seperti ini: pengguna akan mengeluarkan beberapa download data tambahan di awal, dengan manfaat spekulatif berupa mempercepat permintaan di masa mendatang untuk aset tersebut.
Untuk peringatan besar: sangat hati-hati jika Anda memutuskan untuk melakukannya. Hal ini sangat mudah dibuangkan data, dan ini seharusnya merupakan keputusan berbasis data. Selain itu, hindari melakukan pra-cache aset yang sering berubah secara spekulatif, karena pengguna akan dikenai penggunaan data tambahan setiap kali kode precaching mendeteksi revisi baru. Amati alur pengguna di analisis Anda untuk melihat ke mana pengguna cenderung pergi. Jika Anda ragu tentang menyimpan aset secara spekulatif, itu mungkin pertanda baik untuk tidak melakukannya.
Mungkin jangan lakukan: melakukan precache HTML statis
Pedoman ini lebih berlaku untuk situs statis dengan file HTML terpisah dihasilkan oleh generator situs statis atau dibuat secara manual, alih-alih dibuat secara dinamis atau disediakan oleh backend aplikasi. Jika ini sesuai dengan arsitektur Anda, sebaiknya jangan melakukan precache setiap file HTML untuk situs Anda.
Satu masalah dengan precache untuk seluruh file HTML situs adalah bahwa markup yang sekarang telah di-precache akan selalu disajikan dari cache nanti sampai pekerja layanan diperbarui. Hal ini sangat bagus untuk performa, tetapi dapat menyebabkan churn cache yang signifikan jika HTML situs Anda sering berubah.
Namun, ada beberapa pengecualian untuk aturan ini. Jika Anda men-deploy situs kecil dengan beberapa file HTML statis, mungkin tidak masalah untuk melakukan precache semua halaman tersebut agar tersedia secara offline. Jika Anda memiliki situs yang sangat besar, pertimbangkan untuk melakukan precache beberapa halaman bernilai tinggi dan penggantian offline secara spekulatif, serta mengandalkan penyimpanan cache runtime untuk menyimpan halaman lain dalam cache.
Jangan: melakukan pra-cache gambar responsif atau favicon
Hal ini bukan pedoman umum, melainkan lebih ke aturan. Gambar responsif adalah solusi kompleks untuk masalah yang kompleks: Anda memiliki banyak pengguna di banyak perangkat, masing-masing ukuran layar yang bervariasi, kepadatan piksel, dan dukungan untuk format alternatif. Jika Anda melakukan {i>precache<i} seluruh kumpulan gambar responsif, Anda mungkin menyimpan beberapa gambar terlebih dahulu ke dalam cache bila pengguna mungkin akhirnya hanya mengunduh salah satunya.
Favicon menyajikan situasi yang serupa, yaitu situs sering menerapkan seluruh ikon favicon untuk skenario yang berbeda. Sering kali, hanya satu favicon yang diminta, sehingga membuat pra-caching seluruh kumpulan favicon juga sia-sia.
Bantu pengguna Anda dan jangan melakukan pra-cache kumpulan gambar responsif dan favicon. Andalkan cache runtime. Jika Anda harus melakukan pracache gambar, lakukan pra-cache gambar yang digunakan secara luas yang bukan bagian dari kumpulan gambar responsif atau favicon. SVG kurang berisiko dalam hal penggunaan data, satu SVG dirender secara optimal berapa pun kepadatan piksel layar yang diberikan.
Jangan: melakukan precache polyfill
Memvariasikan dukungan browser untuk API merupakan tantangan yang terus ada bagi developer web, dan polyfill adalah salah satu cara untuk mengatasinya. Salah satu cara untuk meminimalkan biaya performa polyfill adalah dengan melakukan pemeriksaan fitur dan hanya memuat polyfill untuk browser yang membutuhkannya.
Karena polyfill pemuatan bersyarat terjadi selama runtime sehubungan dengan lingkungan saat ini, precaching polyfill termasuk pertaruhan. Sebagian pengguna akan mendapatkan manfaatnya, sementara yang lain pada akhirnya akan membuang-buang bandwidth untuk polyfill yang tidak perlu.
Jangan meng-cache polyfill. Andalkan cache runtime untuk memastikan bahwa file tersebut hanya di-cache di browser yang mengharuskannya untuk menghindari pemborosan data.
Kesimpulan
Precaching membutuhkan pemikiran sebelumnya tentang aset apa yang sebenarnya dibutuhkan pengguna Anda, tetapi Anda pasti bisa melakukannya dengan benar dengan cara yang memprioritaskan performa dan keandalan di masa mendatang.
Jika Anda tidak yakin apakah aset tertentu harus di-precache, pilihan terbaik Anda mungkin adalah memberi tahu Workbox untuk mengecualikan aset tersebut dan membuat rute cache runtime untuk menanganinya. Apa pun itu, precache akan dibahas secara mendetail nanti dalam dokumentasi ini, sehingga Anda dapat menerapkan prinsip-prinsip ini pada logika precaching di masa mendatang.