Dokumentasi ini telah membahas precaching sebelumnya, tetapi tidak cukup membahas cara melakukannya dengan benar. Ini penting, karena terlepas dari apakah Anda menggunakan Workbox atau tidak, mudah untuk melakukan pra-cache terlalu banyak dan berpotensi membuang-buang data dan bandwidth. Anda harus berhati-hati tentang bagaimana payload precaching dapat memengaruhi pengalaman pengguna.
Saat Anda membaca dokumen ini, pahami bahwa ini adalah pedoman umum. Arsitektur dan persyaratan aplikasi mungkin mengharuskan Anda melakukan sesuatu secara berbeda dari yang disarankan di sini, tetapi panduan ini berfungsi sebagai default yang baik.
Lakukan: melakukan pra-cache aset statis penting
Kandidat terbaik untuk pra-cache adalah aset statis penting, tetapi aset yang dianggap sebagai aset "penting" aset? Dari perspektif developer, mungkin tergoda untuk menganggap keseluruhan aplikasi sebagai "kritis", tetapi perspektif pengguna adalah yang paling penting. Aset penting adalah aset yang sangat diperlukan untuk memberikan pengalaman pengguna:
- Stylesheet global.
- File JavaScript yang menyediakan fungsi global.
- HTML shell aplikasi, jika berlaku untuk arsitektur Anda.
Pengingat: ini adalah pedoman umum, bukan rekomendasi yang sulit. Saat melakukan pra-cache aset, sebaiknya lakukan lebih sedikit untuk melakukan precache, bukan lebih banyak.
Lakukan: melakukan precache penggantian offline untuk situs multihalaman
Untuk situs multihalaman biasa, Anda mungkin mengandalkan strategi penyimpanan dalam cache yang mengutamakan jaringan atau khusus jaringan untuk menangani permintaan navigasi.
Dalam kasus tersebut, sebaiknya pastikan pekerja layanan melakukan pra-cache dan merespons dengan halaman fallback offline saat pengguna membuat permintaan navigasi saat offline. Salah satu cara untuk melakukannya di Workbox adalah dengan menggunakan strategi khusus jaringan dengan penggantian offline, dengan 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 di cache, mereka akan mendapatkan setidaknya beberapa konten offline.
Mungkin lakukan: pertimbangkan untuk melakukan pra-cache spekulatif
Itu adalah "mungkin" besar di atas, tetapi ada potensi manfaat dari menyimpan aset sebelumnya yang hanya digunakan dalam skenario tertentu. Pikirkanlah seperti ini: pengguna akan dikenai beberapa download data tambahan di awal, dengan manfaat spekulatif yaitu mempercepat permintaan aset tersebut di masa mendatang.
Yang perlu diwaspadai: berhati-hatilah jika Anda memutuskan untuk melakukan hal ini. Hal ini dapat dengan mudah membuang data, dan seharusnya ini merupakan keputusan berbasis data. Selain itu, hindari melakukan precache aset secara spekulatif yang sering berubah, karena pengguna akan dikenai penggunaan data tambahan setiap kali kode precaching mendeteksi revisi baru. Amati alur penggunaan di analisis Anda untuk melihat ke mana pengguna cenderung pergi. Jika Anda ragu untuk melakukan pra-cache aset secara spekulatif, sebaiknya jangan melakukannya.
Mungkin jangan: lakukan pra-cache HTML statis
Pedoman ini berlaku lebih banyak pada situs statis di mana file HTML terpisah dihasilkan oleh generator situs statis atau dibuat secara manual, bukan dibuat secara dinamis atau disediakan oleh backend aplikasi. Jika hal ini sesuai dengan arsitektur Anda, sebaiknya jangan melakukan precache setiap file HTML untuk situs.
Satu masalah melakukan precache file HTML untuk seluruh situs adalah bahwa markup yang kini dipra-cache akan selalu disajikan dari cache nanti hingga pekerja layanan diperbarui. Hal ini bagus untuk performa, tetapi dapat menyebabkan churn cache yang signifikan jika HTML situs Anda sering berubah.
Meskipun demikian, ada beberapa pengecualian untuk aturan ini. Jika Anda menerapkan situs kecil dengan beberapa file HTML statis, tidak masalah untuk melakukan pra-cache semua halaman tersebut agar tersedia secara offline. Jika Anda memiliki situs yang sangat besar, pertimbangkan untuk melakukan precache secara spekulatif beberapa halaman bernilai tinggi dan penggantian offline, serta mengandalkan caching runtime untuk meng-cache halaman lain.
Jangan: lakukan pra-cache gambar atau favicon responsif
Ini bukan sekadar pedoman umum, tetapi lebih merupakan aturan. Gambar responsif adalah solusi yang kompleks untuk masalah yang kompleks: Anda memiliki banyak pengguna di banyak perangkat, masing-masing memiliki ukuran layar, kepadatan piksel, dan dukungan untuk format alternatif yang bervariasi. Jika Anda melakukan precache seluruh kumpulan gambar responsif, Anda mungkin melakukan precache beberapa gambar saat pengguna mungkin hanya mendownload salah satunya.
Favicon menyajikan situasi serupa. Situs sering kali men-deploy seluruh kumpulan favicon untuk skenario yang berbeda. Sering kali, hanya satu favicon yang diminta, sehingga melakukan precache seluruh kumpulan favicon sama-sama sia-sia.
Bantu pengguna Anda dan jangan melakukan pra-cache kumpulan gambar responsif dan favicon. Andalkan cache runtime. Jika Anda harus melakukan precache gambar, lakukan pra-cache gambar yang digunakan secara luas yang bukan bagian dari kumpulan gambar atau favicon responsif. SVG tidak terlalu berisiko dalam hal penggunaan data, SVG tunggal merender secara optimal terlepas dari kepadatan piksel layar tertentu.
Jangan: melakukan precache polyfill
Memvariasikan dukungan browser untuk API merupakan tantangan persisten bagi developer web, dan polyfilling adalah salah satu cara memenuhi tantangan tersebut. Salah satu cara untuk meminimalkan biaya performa polyfill adalah dengan melakukan pemeriksaan fitur dan hanya memuat polyfill untuk browser yang membutuhkannya.
Karena memuat polyfill secara bersyarat terjadi selama runtime sehubungan dengan lingkungan saat ini, membuat polyfill sebelumnya menjadi pertaruhan. Beberapa pengguna akan mendapatkan manfaat dari fitur ini, sementara yang lain akan membuang-buang bandwidth untuk polyfill yang tidak perlu.
Jangan melakukan pra-cache polyfill. Andalkan cache runtime untuk memastikan cache hanya di-cache di browser yang mengharuskan mereka menghindari pemborosan data.
Kesimpulan
Precaching memerlukan beberapa perencanaan tentang aset apa yang sebenarnya dibutuhkan pengguna sebelumnya, tetapi Anda pasti dapat melakukannya dengan tepat dengan cara yang memprioritaskan performa dan keandalan di masa mendatang.
Jika Anda tidak yakin apakah aset tertentu harus di-pra-cache atau tidak, sebaiknya beri tahu Workbox agar mengecualikan aset tersebut dan membuat rute caching runtime untuk menanganinya. Apa pun itu, precaching akan dibahas secara mendetail nanti dalam dokumentasi ini, sehingga Anda dapat menerapkan prinsip-prinsip ini pada logika pra-cache di masa mendatang.