Petunjuk dan konteks
Setelah rilis PWA, beberapa pengguna masih dikontrol oleh Service Worker lama dan memuat JavaScript lama dengan HTML baru, yang menyebabkan ChunkLoadError. Jelaskan siklus hidup, versi cache, tab yang terbuka, skipWaiting, clientsClaim, dan konsekuensi trade-off dari rollback.
Pertanyaan ini cocok untuk posisi frontend, web-platform, dan full-stack. Ini menguji keamanan deployment dan pengalaman pengguna tanpa memerlukan framework tertentu. Tingkat kesalahan dan rasio cache basi adalah data latihan, bukan ambang batas universal.
Apa yang sedang diuji oleh pewawancara
Siklus hidup
Kandidat harus menjelaskan install, waiting, activate, dan kontrol halaman, terutama mengapa worker yang diperbarui berstatus waiting saat klien lama masih terbuka.
Konsistensi aset
Pisahkan HTML, JavaScript yang di-hash, data API runtime, dan entri precache. Menghapus cache lama tidak boleh merusak halaman yang masih mereferensikan aset-aset tersebut.
Strategi adopsi
skipWaiting dapat mempercepat adopsi tetapi dapat beralih kontrol di tengah-tengah masa aktif halaman. Jawaban yang kuat mengevaluasi kompatibilitas dan izin pengguna.
Rollback dan observabilitas
ID versi, jendela kedaluwarsa, pemantauan error, dan no-op worker menyediakan cara untuk menghentikan peluncuran yang bermasalah.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah HTML dan aset statis menggunakan hash konten?
- Apakah URL dan scope Service Worker stabil?
- Apakah pengguna dapat membiarkan halaman terbuka selama berjam-jam atau memiliki state yang belum disimpan?
- Apakah API kompatibel ke belakang (backward compatible) dengan kedua versi klien?
- Bisakah produk meminta refresh pada momen yang aman?
- Bisakah platform melakukan rollback script worker dan manifes aset dengan cepat?
Jawaban 30 detik
“Worker yang diperbarui biasanya terinstal dan masuk ke status waiting saat worker lama mengontrol halaman yang terbuka. Pertama, saya akan membuat HTML, aset yang di-hash, dan kontrak API kompatibel antarversi, lalu memutuskan apakah skipWaiting dapat diterima. Saya akan menggunakan entri precache dengan revisi dan hanya menghapus cache yang sudah dipastikan lama saat activate.
Halaman akan mengamati updatefound dan controllerchange, meminta refresh saat aman, serta mencatat versi worker, ChunkLoadError, dan waktu aktivasi. Untuk rilis yang buruk, saya akan menghentikan peluncuran atau merilis no-op worker sambil mempertahankan aset sebelumnya, kemudian memperbaiki dan melanjutkannya secara bertahap.”
Jawaban mendalam langkah demi langkah
Langkah 1: Gambarkan siklus hidupnya
Registrasi menghasilkan worker yang berstatus installing. Setelah install, worker menjadi waiting; worker lama masih mengontrol halaman yang ada. Begitu klien lama ditutup atau bernavigasi, worker baru akan activate dan mengambil alih kontrol.
Langkah 2: Buat aset kompatibel
HTML harus mereferensikan aset yang di-hash, dan API harus mentoleransi field lama selama jendela migrasi. Hanya mengubah nama cache tidak akan membantu jika halaman lama meminta chunk yang telah dihapus.
Langkah 3: Rancang pemeriksaan pembaruan
Pertahankan kestabilan URL worker. Browser memeriksa perubahan byte saat navigasi dan registrasi; sesi yang berjalan lama dapat memanggil registration.update secara eksplisit, tetapi tidak boleh melakukan polling secara agresif.
~~~js const registration = await navigator.serviceWorker.ready; await registration.update(); ~~~
Langkah 4: Tangani status waiting dan konfirmasi pengguna
Status waiting adalah yang paling aman secara default. Jika adopsi langsung diperlukan, periksa state yang belum disimpan dan kompatibilitas protokol, tanyakan kepada pengguna, lalu kirim skipWaiting melalui pesan terkontrol. Tangani controllerchange tanpa membuat loop refresh.
Langkah 5: Bersihkan cache dan lakukan rollback
Selama activate, hapus hanya cache di luar allowlist. Pertahankan jendela aset sebelumnya untuk rollback. Jika ada rilis yang buruk, lakukan rollback pada entry point atau kirim no-op worker alih-alih menghapus setiap cache.
Langkah 6: Amati dan verifikasi
Catat versi worker, cache hit, waktu aktivasi, controllerchange, error 404 aset, dan ChunkLoadError. Uji tab lama dan baru, startup offline, refresh, peluncuran bertahap (staged rollout), dan rollback.
Contoh jawaban model
“ChunkLoadError dapat terjadi saat worker lama mengontrol halaman sementara deployment telah menghapus chunk yang direferensikan oleh halaman tersebut. Worker baru berstatus waiting secara default, jadi saya tidak akan langsung memanggil skipWaiting secara global.
Saya akan menjaga URL worker tetap stabil, menggunakan aset yang di-hash, dan mempertahankan jendela kompatibilitas API. Revisi precache akan dikelola secara eksplisit, dan activate hanya akan menghapus cache lama yang masuk daftar yang diizinkan untuk dihapus. Halaman akan mendeteksi worker yang waiting dan menawarkan refresh saat tidak ada state yang belum disimpan; peralihan langsung memerlukan kompatibilitas dan penanganan controllerchange yang cermat.
Saya akan melakukan rilis bertahap serta memantau versi worker, error 404 aset, dan ChunkLoadError. Jika versinya buruk, hentikan peluncuran entry-point atau deploy no-op worker sambil tetap mempertahankan aset lama. Pemulihan harus mencakup multi-tab, startup offline, refresh, dan rollback penuh.”
Kesalahan umum
- Mengasumsikan bahwa install langsung mengontrol setiap halaman.
- Menimpa JavaScript tanpa hash secara langsung di tempat yang sama.
- Memanggil skipWaiting tanpa syarat dan mencampur versi di tengah halaman.
- Menghapus semua cache saat activate.
- Mengubah nama script worker untuk memaksakan pembaruan.
- Hanya menguji halaman yang baru dibuka, bukan tab yang sudah lama berjalan.
- Merusak API saat hanya melakukan rollback pada entry frontend.
- Tidak memiliki telemetri versi worker atau rollback no-op.
Pertanyaan lanjutan
Pertanyaan lanjutan 1: Mengapa worker baru harus berstatus waiting?
Worker lama masih mengontrol klien yang terbuka. Siklus hidup default menunggu klien tersebut ditutup atau bernavigasi sehingga kontrol tidak berpindah secara tiba-tiba.
Pertanyaan lanjutan 2: Kapan skipWaiting wajar digunakan?
Ketika aset dan API kompatibel ke belakang, tidak ada state penting yang belum disimpan, dan refresh langsung dapat diterima. Jika tidak, tunggu izin pengguna atau navigasi.
Pertanyaan lanjutan 3: Bagaimana cara mencegah pertumbuhan cache tanpa batas?
Gunakan allowlist versi atau revisi dan hapus hanya cache yang tidak terpakai saat activate. Pertahankan rilis sebelumnya untuk jendela rollback yang telah ditentukan.
Pertanyaan lanjutan 4: Bagaimana cara menghentikan worker yang bermasalah?
Hentikan peluncuran entry, dan jika diperlukan, deploy no-op worker atau pulihkan script yang sudah terbukti stabil. Pastikan aset lama tetap tersedia saat memperbaiki rilis tersebut.
Pertanyaan lanjutan 5: Bagaimana Anda membuktikan bahwa pembaruan aman?
Uji beberapa tab, startup offline, HTML lama dengan aset baru, refresh, konfirmasi pembaruan, kompatibilitas API, pemantauan error, dan jalur rollback secara menyeluruh.