Perintah dan cakupan
Sebuah situs berita ingin mempercepat navigasi detail artikel dengan Speculation Rules API. Jelaskan bagaimana Anda memilih prefetch versus prerender, menentukan cakupan aturan, dan menangani efek samping saat login, kesegaran data, fallback browser, pembatalan, dan pemantauan.
Chrome mendokumentasikan bahwa prefetch terutama mengambil sumber daya lebih awal, sedangkan prerender memuat dan merender halaman dalam konteks yang tidak terlihat. Oleh karena itu, prerender dapat memberikan peningkatan navigasi yang lebih besar tetapi dapat mengeksekusi skrip dan memicu efek samping lebih awal. Pertanyaan ini menguji rekayasa performa, progressive enhancement, dan batasan keamanan.
Apa yang dievaluasi oleh pewawancara
Kandidat harus menghubungkan strategi dengan hit rate navigasi dan risiko efek samping; membatasi selektor, origin, cache, dan privasi; mempertahankan navigasi biasa ketika API tidak didukung atau spekulasi dibatalkan; serta membuktikan dampak dengan data pengguna nyata daripada skor lab saja.
Kerangka jawaban 30 detik
“Saya akan mulai dengan prefetch yang konservatif untuk tautan artikel yang memiliki probabilitas tinggi, hanya-baca (read-only), dan berasal dari origin yang sama. Saya akan menggunakan prerender hanya setelah memverifikasi tidak adanya efek samping penulisan (write side effects), hit rate yang memadai, dan anggaran sumber daya. Aturan akan mengecualikan rute login, pembayaran, personalisasi, dan mutasi. Server akan menegakkan idempoten dan caching privat; klien akan mendeteksi document.prerendering dan menunda analitik. Browser yang tidak didukung akan menggunakan tautan normal. Saya akan membandingkan tingkat aktivasi, LCP, INP, bandwidth, dan tingkat pembatalan.”
Jawaban mendalam langkah demi langkah
Langkah 1: Mengklasifikasikan risiko navigasi
Sertakan halaman artikel dan bantuan yang hanya-baca; kecualikan checkout, logout, suka (likes), pembayaran, dan halaman yang sangat dipersonalisasi. Prerender menjalankan kode siklus hidup halaman, sehingga operasi penulisan harus memerlukan aktivasi pengguna yang nyata.
Langkah 2: Memilih prefetch atau prerender
Gunakan prefetch ketika hit rate rendah atau efek samping tidak pasti. Gunakan prerender untuk halaman berprobabilitas tinggi dengan origin yang sama yang memiliki first paint stabil serta anggaran CPU dan memori yang cukup. Jangan pernah menerapkan prerender ke setiap tautan secara default.
Langkah 3: Membatasi aturan dan biaya sumber daya
Hasilkan aturan dokumen atau server yang hanya cocok dengan tautan artikel. Batasi kandidat konkuren dan ukuran sumber daya. Atur perilaku cache, Vary, dan invalidasi yang tepat agar respons privat tidak dibagikan secara keliru.
Langkah 4: Mengisolasi efek samping dan status login
Endpoint penulisan harus memerlukan interaksi nyata dan perlindungan CSRF; permintaan spekulatif tidak boleh memutasi status. Tunda analitik, iklan, dan notifikasi saat document.prerendering bernilai true, lalu kirim satu event yang telah dideduplikasi setelah aktivasi. Gunakan caching privat atau kecualikan respons yang dipersonalisasi.
Langkah 5: Merancang fallback dan pembatalan
Browser yang tidak didukung menggunakan tautan biasa. Spekulasi dapat dibatalkan oleh batas memori, jaringan, atau browser, sehingga halaman harus tetap dimuat secara normal. Jangan memblokir umpan balik klik saat menunggu halaman spekulatif.
Langkah 6: Menangani kesegaran data
Untuk artikel yang sering diedit, perpendek masa pakai cache dan validasi versi saat aktivasi; gunakan conditional request dengan ETag. Jika konten berubah setelah prerender, perbarui wilayah yang dapat berubah tanpa menampilkan kilasan konten basi atau memutar ulang aksi pengguna.
Langkah 7: Mengukur nilai bagi pengguna nyata
Jalankan perbandingan terkontrol dari tingkat aktivasi, waktu tunggu navigasi, LCP, INP, CLS, bandwidth, CPU, memori, dan pembatalan. Segmentasikan berdasarkan browser, jaringan, perangkat, dan status login. Jika kecepatan meningkat sementara biaya atau error meningkat, persempit aturan atau kembali ke prefetch.
Pertukaran (trade-off) dan batasan
Hit rate versus biaya sumber daya
Prerender dengan hit rate rendah membuang CPU, memori, dan bandwidth. Prefetch membutuhkan biaya lebih sedikit tetapi memberikan keuntungan yang lebih kecil. Tetapkan ambang batas dari aktivasi yang diamati dan anggaran yang ditentukan.
Kesegaran data versus navigasi instan
Caching yang lama meningkatkan hit rate tetapi meningkatkan keusangan data. Berikan versi pada URL statis; validasi konten dinamis saat aktivasi dan segarkan hanya bagian yang dapat berubah.
Kompatibilitas versus pemeliharaan
Spekulasi adalah lapisan progressive enhancement dan tautan biasa tetap bersifat kanonikal. Jaga agar transisi status bisnis tetap independen dari siklus hidup prerender.
Simulasi kegagalan dan evolusi
Halaman spekulatif memicu operasi penulisan
Catat permintaan spekulatif di staging dan verifikasi bahwa suka, analitik, dan notifikasi tidak memiliki mutasi. Hapus rute dari aturan dan pindahkan penulisan ke balik aktivasi nyata.
Hit rate rendah membuang sumber daya
Nonaktifkan prerender untuk perangkat dan jaringan yang terbatas, bandingkan bandwidth dan INP, dan beralihlah dari eksperimen prefetch kecil ke prerender hanya jika data mendukungnya.
Konten kedaluwarsa sebelum aktivasi
Simulasikan pembaruan publikasi antara prerender dan klik. Verifikasi validasi ETag dan penyegaran parsial sehingga halaman yang diaktifkan menampilkan judul dan isi terbaru.
Kesalahan umum dan tindak lanjut
Kesalahan 1: Melakukan prerender pada setiap tautan
Tanyakan tentang ambang batas hit rate, konkurensi, dan memori serta kondisi penonaktifan yang eksplisit.
Kesalahan 2: Memperlakukan prerender sebagai cache
Tanyakan skrip mana yang dieksekusi dan bagaimana analitik serta status login ditunda atau diisolasi.
Kesalahan 3: Hanya melihat Lighthouse
Tanyakan bagaimana aktivasi, pembatalan, dan bandwidth disegmentasikan dalam pengukuran pengguna nyata.
Kesalahan 4: Mengabaikan navigasi biasa
Tanyakan apakah klik tetap berfungsi saat browser tidak memiliki dukungan atau membatalkan spekulasi.
Kesalahan 5: Mengabaikan kesegaran data
Tanyakan bagaimana pembaruan publikasi antara prerender dan klik dapat menghindari konten basi.
Tindak lanjut lanjutan dan referensi jawaban
Mengapa tidak melakukan prerender pada setiap halaman?
Prerender menghabiskan sumber daya tambahan dan dapat mengeksekusi skrip. Pilih hanya halaman dengan hit tinggi, hanya-baca, dan origin yang sama dalam anggaran yang tersedia.
Bagaimana cara menghindari analitik duplikat?
Deteksi document.prerendering, tunda event hingga aktivasi, dan lakukan deduplikasi dengan pengidentifikasi navigasi.
Bagaimana Anda membuktikan bahwa pengoptimalan berhasil?
Gunakan penugasan pengguna nyata dan bandingkan LCP navigasi aktivasi, INP, waktu tunggu, bandwidth, dan pembatalan berdasarkan perangkat dan jaringan.