Temu Duga Frontend: Bagaimana Caching HTTP Pelayar Berfungsi?

Masalah dan Bila Ia Berlaku

Suatu aplikasi web mempunyai empat jenis respons GET:

• /index.html mempunyai URL yang stabil, berubah mengikut setiap deployment, dan merujuk kepada aset statik semasa.
• /assets/app.8f3c.js mempunyai cincangan kandungan (content hash) dalam nama failnya, jadi perubahan kandungan juga mengubah URL tersebut.
• /api/catalog ialah katalog produk awam. Pelayan memilih perwakilan daripada Accept-Language, dan produk ini membenarkan data basi (staleness) sekitar 60 saat.
• /api/cart diperibadikan untuk pengguna yang telah disahkan dan tidak boleh diguna semula oleh CDN atau pengguna lain.

Selepas satu keluaran (release), sesetengah pengguna mengekalkan HTML lama dan meminta fail JavaScript lama yang telah dipadamkan oleh proses deployment. Katalog kadangkala dipaparkan dalam bahasa yang salah. Pasukan juga menganggap no-cache sebagai "jangan simpan", jadi cadangan penyelesaian mereka tidak menggambarkan tingkah laku yang sepatutnya. Terangkan bagaimana interaksi antara cache pelayar peribadi, cache CDN yang dikongsi, kesegaran (freshness), pengesahan semula (revalidation), dan kunci cache (cache keys). Kemudian reka pengepala respons, urutan deployment, dan kaedah pengesahan untuk keempat-empat respons tersebut.

Nilai 60 saat hanyalah andaian temu duga, bukan ukuran produksi daripada mana-mana sumber. Skop asas merangkumi cache HTTP. Cache Service Worker, cache memori aplikasi, dan cache data rangka kerja akan dibincangkan dalam soalan susulan. Ini ialah soalan frontend, full-stack, atau prestasi web yang kemahiran terasnya adalah menaakul tentang tingkah laku platform pelayar dan HTTP, jadi kategorinya ialah frontend.

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah sama ada calon menetapkan dasar berdasarkan empat soalan: adakah respons boleh disimpan, siapa yang boleh menggunakannya semula, berapa lama ia kekal segar, dan apa yang berlaku selepas ia menjadi basi? Menghafal direktif Cache-Control sering kali mencampuradukkan penyimpanan dengan penggunaan semula secara terus. Jawapan yang kukuh mentakrifkan sempadan data sebelum menulis pengepala.

Isyarat kedua ialah perbezaan yang tepat antara no-cache dan no-store. no-cache membenarkan penyimpanan tetapi memerlukan pengesahan dengan pelayan asal (origin) sebelum setiap penggunaan semula. no-store memberitahu cache supaya tidak menyimpan respons tersebut langsung. Menggunakan no-store pada setiap respons dinamik akan menghilangkan faedah permintaan bersyarat dan beberapa keupayaan pelayar; ia sepatutnya digunakan hanya apabila keperluan benar-benar melarang penyimpanan cache HTTP.

Isyarat ketiga ialah model kesegaran dan pengesahan yang betul. Respons yang segar biasanya boleh diguna semula tanpa menghubungi pelayan huluan (upstream). Apabila ia basi atau pengesahan diperlukan, klien boleh menghantar If-None-Match atau If-Modified-Since. Jika perwakilan tidak berubah, pelayan mengembalikan 304 Not Modified; cache mengemas kini metadata dan menggunakan semula badan respons yang disimpan.

Akhir sekali, penemu duga mencari penaakulan berkaitan deployment dan kunci cache. Pengepala aset statik yang sempurna tidak dapat membaiki proses keluaran yang mana HTML lama merujuk kepada fail yang telah dipadamkan. Mengabaikan Vary: Accept-Language juga boleh menyebabkan cache yang dikongsi menggunakan perwakilan bahasa Cina untuk permintaan bahasa Inggeris ke URL yang sama. Jawapan yang kukuh merangkumi pengepala, jangka hayat aset, varian perwakilan, dan ujian yang boleh diulang semula.

Soalan Penjelasan Sebelum Menjawab

• Adakah keempat-empat respons melalui CDN? s-maxage mengawal cache yang dikongsi dan tidak menetapkan kesegaran pelayar peribadi. Tanpa CDN, dasar API awam boleh menjadi lebih ringkas.
• Adakah bahasa katalog diperoleh daripada URL atau pengepala permintaan? /api/catalog?locale=zh-CN sudah menggunakan URI yang berbeza sebagai sebahagian daripada kunci cache. URL tunggal yang perwakilannya bergantung pada Accept-Language memerlukan medan Vary yang bersesuaian.
• Bolehkah pelayar menyimpan respons troli dan mengesahkannya kemudian? Jika cache peribadi pengguna tunggal dibenarkan menyimpannya, gunakan private, no-cache. Jika dasar keselamatan atau produk melarang sebarang penyimpanan cache HTTP, gunakan no-store.
• Berapa lama aset ber-hash yang lama boleh kekal tersedia? Pemadaman serta-merta akan merosakkan tab lama, navigasi sejarah, deployment berperingkat, dan versi rollback. Pengekalan mesti merangkumi tempoh titik masuk lama masih boleh diakses ditambah dengan tetingkap rollback.
• Berapa tahap data basi yang boleh diterima oleh katalog? "Maksimum 60 saat" mesti membezakan kesegaran biasa daripada penggunaan data basi tambahan semasa pengesahan semula atau ralat. Jika kandungan yang lebih lama tidak boleh diterima langsung, stale-while-revalidate dan stale-if-error tidak boleh digunakan untuk memanjangkan penggunaan semula.
• Adakah Service Worker dipasang? Service Worker boleh memintas permintaan dan mengembalikan entri Cache Storage sebelum cache HTTP biasa terlibat. Ia mesti diperiksa sebagai lapisan yang berasingan.

Rangka Jawapan 30 Saat

"Bagi setiap respons, saya terlebih dahulu memutuskan sama ada ia boleh disimpan, siapa yang boleh menggunakannya semula, berapa lama ia segar, dan bagaimana ia disahkan selepas itu. Aset JavaScript dengan cincangan kandungan menerima max-age selama setahun berserta immutable, dengan jaminan bahawa bait pada URL yang sama tidak akan berubah. HTML menerima no-cache dan ETag, jadi pelayar boleh menyimpannya tetapi mengesahkannya pada penggunaan semula biasa. Katalog awam boleh memberikan CDN s-maxage=60, menambah ETag, dan menggunakan Vary: Accept-Language apabila URL yang sama menyediakan pelbagai bahasa. Troli sekurang-kurangnya ialah private; gunakan private, no-cache jika penyimpanan pelayar dibenarkan, dan no-store hanya apabila penyimpanan itu sendiri dilarang. Deploy aset baharu sebelum HTML dan kekalkan fail ber-hash yang lama. Kemudian uji respons 200 tanpa cache, hit segar, pengesahan semula 304, varian bahasa, dan main semula HTML lama."

Perbincangan Terperinci Langkah demi Langkah

Langkah 1: Modelkan penyimpanan, penggunaan semula, kesegaran, dan pengesahan secara berasingan

Caching HTTP bukanlah satu suis tunggal. Laluan permintaan memerlukan sekurang-kurangnya empat keputusan:

1. Penyimpanan: no-store melarang penyimpanan. Respons lain tertakluk kepada kaedah, status, pengesahan, dan peraturan caching yang eksplisit.
2. Skop penggunaan semula: Pelayar ialah cache peribadi yang biasanya berkhidmat untuk seorang pengguna. CDN dan proksi ialah cache yang dikongsi. private menghalang penggunaan semula oleh cache yang dikongsi, manakala public boleh membenarkannya secara eksplisit.
3. Kesegaran: max-age=N biasanya mentakrifkan berapa lama cache peribadi dan yang dikongsi boleh menggunakan semula respons secara terus. Dalam cache yang dikongsi, s-maxage=N mengatasi max-age. Usia respons semasa juga mencerminkan metadata seperti Date dan Age.
4. Tingkah laku selepas basi: Cache boleh menghantar permintaan bersyarat menggunakan pengesah (validator). Perwakilan yang tidak berubah menghasilkan 304 dan penggunaan semula badan yang disimpan; perwakilan yang berubah menghasilkan 200 dengan kandungan baharu.

Oleh itu, "cache hit" menggambarkan dua kos yang berbeza. Hit segar tidak memerlukan pengesahan huluan. Hit yang disahkan semula masih melibatkan masa ulang-alik rangkaian (round trip) dan kerja pengesahan, walaupun ia mengelakkan pemindahan keseluruhan badan respons. Jawapan temu duga harus menyatakan dengan jelas yang mana satu dimaksudkan.

Langkah 2: Berikan jangka hayat kesegaran yang panjang kepada aset statik bercincangan kandungan

Jika binaan (build) menjamin bahawa kandungan yang diubah menerima URL baharu, aset statik boleh mengembalikan:

Cache-Control: public, max-age=31536000, immutable

31536000 saat bersamaan dengan satu tahun. immutable menyatakan bahawa sumber tidak akan berubah semasa ia masih segar dan boleh mengelakkan pengesahan yang tidak perlu dalam beberapa senario muat semula. Bahagian yang penting bukanlah angka satu tahun tersebut. Ia adalah sepasang invariant:

• Bait pada URL ber-hash tertentu tidak akan berubah sama sekali.
• Versi baharu menggunakan URL baharu yang dirujuk oleh HTML baharu.

Menulis ganti fail pada URL jangka panjang yang sama menyebabkan klien mendapat kandungan lama. Memadam fail ber-hash yang lama juga merosakkan tab lama, sejarah pelayar, nod edge yang dikemas kini secara berperingkat, dan keluaran rollback yang masih boleh memintanya. Proses keluaran yang teguh memuat naik aset baharu terlebih dahulu, mengesahkan bahawa aset tersebut boleh dicapai, menerbitkan HTML selepas itu, dan mengekalkan aset ber-hash lama sehingga titik masuk lama dan versi rollback tidak lagi boleh diakses.

Langkah 3: Sahkan semula URL HTML yang stabil pada setiap penggunaan semula biasa

HTML titik masuk tidak boleh mengubah URL-nya secara semula jadi pada setiap perwakilan, jadi ia boleh mengembalikan:

Cache-Control: no-cache
ETag: "index-v184"

Pelayar boleh menyimpan dokumen tersebut, tetapi penggunaan semula biasa memerlukan pengesahan. Permintaan seterusnya mengandungi:

If-None-Match: "index-v184"

Pelayan mengembalikan 304 jika perwakilan tidak berubah, atau 200 dengan HTML baharu dan ETag baharu selepas sesuatu keluaran. ETag mengenal pasti versi sesuatu perwakilan. Ia tidak semestinya cincangan kandungan, tetapi ia mesti berubah apabila perwakilan berubah. Respons juga boleh membawa Last-Modified. Jika permintaan mengandungi kedua-dua If-None-Match dan If-Modified-Since, syarat ETag yang lebih tepat akan diutamakan di bawah semantik HTTP.

no-cache tidak bermaksud "jangan simpan". Gunakan no-store hanya jika produk memerlukan HTML tersebut tidak dimasukkan ke dalam mana-mana cache HTTP langsung, dengan menerima hakikat kehilangan faedah pengesahan semula 304. Cache ke belakang/ke hadapan (bfcache) pelayar juga boleh memulihkan syot kilat (snapshot) halaman tanpa melalui laluan pengesahan semula HTTP biasa, jadi isu "butang Back menunjukkan halaman lama" tidak boleh didiagnosis daripada Cache-Control semata-mata.

Langkah 4: Kawal tingkah laku pelayar dan CDN secara berasingan untuk API awam

Katakan katalog biasanya membenarkan kelewatan sehingga 60 saat. Pelayar perlu membuat pengesahan pada setiap permintaan, manakala CDN boleh terus menggunakan semula respons sehingga 60 saat:

Cache-Control: public, max-age=0, s-maxage=60
ETag: "catalog-v927"
Vary: Accept-Language

Setiap direktif mempunyai peranan yang tersendiri:

• max-age=0 membenarkan pelayar menyimpan respons tetapi menjadikannya basi serta-merta, supaya penggunaan seterusnya melalui laluan pengesahan.
• s-maxage=60 membenarkan cache yang dikongsi menggunakannya semula secara terus selama 60 saat.
• ETag membenarkan pelayar atau CDN membuat permintaan bersyarat selepas basi.
• Vary: Accept-Language memberitahu cache supaya menyertakan pengepala permintaan bahasa semasa memilih respons yang disimpan.

Jika produk menerima tambahan 30 saat data basi sebagai pertukaran untuk kependaman (latency) pengesahan yang lebih rendah, tambahkan stale-while-revalidate=30. Direktif standard ini mempengaruhi setiap cache yang menyokongnya, bukan hanya CDN. Jika hanya tingkah laku CDN yang perlu diubah, gunakan tetapan khusus CDN yang eksplisit daripada penyedia yang dipilih. Apabila jaminan perniagaan menyatakan bahawa kandungan tidak boleh lebih lama daripada 60 saat, jangan tambah tetingkap basi ini. Ia merupakan pertukaran eksplisit antara kesegaran dan kependaman yang lebih rendah, bukan pengoptimuman lalai.

Selalunya lebih mudah dijangka untuk meletakkan locale dalam URL, seperti /api/catalog?locale=zh-CN. Pengelogan, pemanasan cache (warming), pembatalan, dan kunci cache kemudian menjadi eksplisit, dan respons tidak lagi memerlukan Accept-Language untuk membezakan perwakilan pada satu URL. Elakkan daripada menambah Vary: User-Agent secara sembarangan; bilangan nilainya yang terlalu banyak boleh memusnahkan kecekapan penggunaan semula cache yang dikongsi.

Langkah 5: Lindungi troli yang diperibadikan

Respons troli tidak boleh sama sekali disediakan daripada cache yang dikongsi kepada pengguna lain. Jika pelayar dibenarkan menyimpan respons pengguna semasa tetapi mesti mengesahkannya sebelum diguna semula, kembalikan:

Cache-Control: private, no-cache
ETag: "cart-v19"

private mengehadkan penyimpanan kepada cache peribadi sahaja. no-cache memerlukan pengesahan sebelum penggunaan semula. Jangan cuba mengasingkan pengguna menggunakan Vary: Cookie: nilai kuki mempunyai kepelbagaian yang sangat tinggi (high cardinality) dan mencipta risiko kunci cache serta privasi. Respons yang diperibadikan mesti menghalang penggunaan semula yang dikongsi secara eksplisit.

Jika keperluan keselamatan menyatakan bahawa "respons tidak boleh ditulis ke mana-mana cache HTTP langsung", gunakan:

Cache-Control: no-store

Tidak perlu menambahkan private, no-cache, max-age=0. Direktif yang bertindih atau lebih terhad tidak menjadikan dasar itu lebih selamat; ia hanya menjadikan niatnya lebih sukar untuk diaudit. Selain itu, menambahkan no-store pada respons masa hadapan tidak memadamkan salinan segar yang telah disimpan sebelum ini. Tindak balas insiden mungkin memerlukan pembersihan (purge) CDN, URL berversi, penamatan tempoh entri lama, atau mekanisme pembersihan pelayar yang disasarkan.

Langkah 6: Pautkan dasar cache dengan protokol deployment

Kegagalan JavaScript yang dipadamkan tidak boleh dibaiki dengan pengepala sahaja. Protokol deployment sepatutnya:

1. Memuat naik setiap aset ber-hash yang baharu.
2. Mengesahkan dari lokasi edge produksi bahawa setiap aset boleh dicapai dan mempunyai jenis MIME, pemampatan, serta pengepala yang betul.
3. Menerbitkan HTML yang merujuk kepada URL baharu tersebut.
4. Mengekalkan aset ber-hash lama sepanjang tetingkap tab lama, keluaran berperingkat, dan tetingkap rollback.
5. Memulihkan HTML lama semasa rollback sementara aset lamanya masih wujud.
6. Memadam aset hanya selepas tiada lagi titik masuk yang boleh dicapai merujuk kepadanya.

Jika beberapa nod menjana HTML, ETag mereka juga mesti sepadan dengan perwakilan tersebut. ETag yang berbeza untuk kandungan yang sama menghasilkan respons 200 yang tidak perlu. Menggunakan semula ETag kuat yang sama untuk kandungan berbeza boleh menghasilkan respons 304 yang salah. Pemampatan, bahasa, dan perubahan perwakilan lain juga memerlukan kunci cache atau pengendalian Vary yang betul.

Langkah 7: Sahkan urutan permintaan dan bukannya satu muat semula sahaja

Bina matriks permintaan dalam DevTools pelayar atau menggunakan curl:

curl -I "$ORIGIN/index.html"
curl -I -H 'If-None-Match: "index-v184"' "$ORIGIN/index.html"
curl -I -H 'Accept-Language: zh-CN' "$ORIGIN/api/catalog"
curl -I -H 'Accept-Language: en-US' "$ORIGIN/api/catalog"

Tetapkan ORIGIN kepada origin laman sasaran sebelum menjalankan arahan. Sahkan semua perkara berikut:

• Permintaan awal mengembalikan 200, pengepala yang dimaksudkan, dan pengesah.
• Aset statik tidak menghubungi huluan semasa masih segar, dan URL yang berubah mengambil fail baharu.
• Permintaan bersyarat HTML yang tidak berubah mengembalikan 304, manakala deployment menghasilkan 200 dengan ETag baharu.
• Age meningkat pada hit CDN katalog, dan pengesahan berlaku selepas kesegaran yang dikongsi tamat.
• Dua permintaan bahasa menerima badan respons yang berbeza dan respons menyertakan Vary.
• Troli tidak mempunyai sebarang konfigurasi yang membenarkan penggunaan semula cache yang dikongsi.
• Memainkan semula HTML lama masih mengambil aset ber-hash yang dirujuk dengan status 200.
• Pilihan "Disable cache" dalam DevTools berguna untuk diagnosis rangkaian tetapi tidak menggantikan ujian laluan cache yang sebenar.

Uji muat semula biasa, muat semula paksa (force reload), tab baharu, navigasi ke belakang/ke hadapan, dan laluan dengan Service Worker secara berasingan. Muat semula paksa mengubah direktif cache permintaan, jadi hanya menguji laluan tersebut tidak menggambarkan tingkah laku pengguna biasa.

Contoh Jawapan Berkualiti Tinggi

"Saya tidak akan bermula dengan menyenaraikan pengepala. Bagi setiap respons, saya akan menjawab empat soalan: bolehkah ia disimpan, siapa yang boleh menggunakannya semula, berapa lama ia segar, dan bagaimana ia disahkan selepas itu?

Fail JavaScript mempunyai cincangan kandungan, jadi URL-nya berubah mengikut bait kandungannya. Saya akan mengembalikan public, max-age=31536000, immutable dan menjadikan 'tidak pernah menulis ganti kandungan pada URL yang sama' sebagai satu invariant keluaran. Dokumen HTML masuk mempunyai URL yang stabil, jadi saya akan menggunakan no-cache berserta ETag. Ia boleh disimpan, tetapi penggunaan semula biasa akan mengesahkannya; kandungan yang tidak berubah mendapat 304, manakala kandungan yang berubah mendapat HTML baharu dan ETag baharu. no-cache membenarkan penyimpanan. no-store ialah direktif yang melarangnya.

Katalog awam membenarkan kelewatan sekitar 60 saat. Saya akan menggunakan max-age=0 untuk pelayar dan s-maxage=60 untuk CDN. Jika produk menerima tambahan 30 saat data basi sebagai pertukaran untuk menyembunyikan kependaman pengesahan semula, saya akan menambah stale-while-revalidate=30; jika tidak, saya akan meninggalkannya. Jika URL /api/catalog yang sama berbeza mengikut Accept-Language, ia memerlukan Vary: Accept-Language. Meletakkan locale dalam URL adalah lebih mudah untuk difahami.

Troli adalah khusus untuk pengguna secara peribadi. Jika penyimpanan dan pengesahan pelayar boleh diterima, saya akan mengembalikan private, no-cache. Jika dasar melarang penyimpanan, saya hanya akan mengembalikan no-store. Saya tidak akan membenarkan respons yang diperibadikan berada dalam cache yang dikongsi atau menggunakan kuki berkepelbagaian tinggi sebagai kunci cache yang dikongsi.

HTML lama yang meminta bundle yang telah dipadamkan turut mendedahkan pepijat protokol deployment. Saya akan memuat naik aset baharu terlebih dahulu, menerbitkan HTML kemudian, dan mengekalkan aset ber-hash lama sepanjang tempoh entri lama dan tetingkap rollback. Pengesahan saya akan menguji respons 200 awal, hit segar, 304 berasaskan ETag, 200 selepas deployment, dua perwakilan bahasa, sempadan cache yang dikongsi untuk troli, dan memainkan semula HTML lama—bukan sekadar satu ujian muat semula paksa."

Kesilapan Lazim

• Mentafsirkan no-cache sebagai tiada penyimpanan → ia membenarkan penyimpanan dan memerlukan pengesahan sebelum diguna semula → gunakan no-store untuk melarang penyimpanan, atau kekalkan no-cache berserta pengesah untuk memanfaatkan 304.
• Memberikan jangka hayat kesegaran satu tahun kepada semua sumber → HTML dengan URL yang stabil boleh terus merujuk kepada keluaran lama → khaskan kesegaran yang panjang untuk aset beralamat kandungan dan sahkan dokumen masuk.
• Memadam aset ber-hash lama serta-merta selepas keluaran → tab lama, sejarah, dan keluaran rollback masih boleh merujuk kepadanya → terbitkan aset sebelum titik masuk dan kekalkannya sepanjang tetingkap yang boleh dicapai.
• Menetapkan ETag tanpa dasar kesegaran → cache kekurangan jangka hayat penggunaan semula terus yang jelas dan mungkin melakukan pengesahan yang tidak perlu → takrifkan kesegaran dan pengesahan bersama-sama.
• Menganggap respons 304 sebagai percuma sepenuhnya → ia menjimatkan pemindahan badan respons tetapi masih memerlukan masa perjalanan pergi balik (round trip) dan kerja pengesahan → pilih jangka hayat segar apabila kependaman dan toleransi data mewajarkannya.
• Menyediakan pelbagai bahasa pada satu URL tanpa Vary → cache yang dikongsi boleh menggunakan semula perwakilan yang salah → letakkan bahasa dalam URL atau tambahkan Vary: Accept-Language pada kunci cache.
• Menggunakan Vary: Cookie untuk mengasingkan troli → kunci dengan kepelbagaian tinggi mengurangkan hit dan meningkatkan risiko privasi → halang penggunaan semula yang dikongsi dengan private atau no-store.
• Menganggap direktif no-store yang baru ditambah akan memadamkan entri lama → pengepala baharu tidak dapat sampai ke respons segar yang masih diguna semula secara terus → lakukan purge, jadikan ia berversi, atau tunggu sehingga entri lama tamat tempoh.
• Hanya menguji dengan muat semula paksa DevTools → muat semula paksa mengubah direktif cache permintaan → uji navigasi biasa, hit segar, pengesahan semula, pemulihan sejarah, dan laluan Service Worker.

Soalan Susulan

Soalan Susulan 1: Bolehkah katalog menyajikan data basi apabila CDN atau pelayan asal mengalami kegagalan?

Bahagikan toleransi perniagaan kepada dua tetingkap: maksimum 60 saat semasa operasi normal, dan kebenaran berasingan semasa pelayan asal memberikan respons 5xx. Jika data lama boleh diterima semasa berlaku ralat, nilaikan stale-if-error dengan tempoh yang terhad. Jika harga atau inventori tidak boleh basi, paparkan ralat tersebut. stale-while-revalidate menyembunyikan kependaman pengesahan semula di latar belakang; stale-if-error membenarkan penggunaan semula data basi semasa kegagalan. Kedua-duanya menyelesaikan masalah yang berbeza.

Soalan Susulan 2: Bilakah pelayan patut menggunakan ETag kuat atau lemah?

ETag kuat bermaksud dua perwakilan adalah sama tepat bait demi bait dan sesuai digunakan apabila permintaan julat (range requests) yang tepat atau identiti bait diperlukan. ETag lemah bermula dengan W/ dan mewakili kesetaraan semantik walaupun terdapat perbezaan bait, yang sesuai untuk perubahan pemformatan kecil dalam output yang dijana oleh pelayan. Pengesahan cache boleh menggunakan salah satu daripadanya, tetapi kawalan konkurensi If-Match dan permintaan julat memerlukan semakan peraturan perbandingan kuat.

Soalan Susulan 3: Mengapa DevTools menyatakan "from memory cache" atau "from disk cache" tanpa menunjukkan 304?

Respons yang segar boleh diguna semula tanpa sebarang permintaan bersyarat, jadi tiada respons 304. Memori dan cakera menggambarkan pilihan penyimpanan yang dibuat oleh pelayar, bukan semantik HTTP yang berasingan. Periksa Cache-Control, Age, sama ada permintaan dihantar, dan usia respons semasa dan bukannya menyimpulkan keseluruhan dasar daripada satu label DevTools sahaja.

Soalan Susulan 4: Mengapa mengubah pengepala respons tidak membantu selepas menambah Service Worker?

Service Worker mungkin mengembalikan respons Cache Storage lama sebelum permintaan rangkaian berlaku, jadi cache HTTP biasa tidak pernah terlibat. Periksa pengendali fetch, versi Cache Storage, pembersihan semasa fasa activate, dan pemasaan claim klien. Gunakan versi pada nama cache atau manifes sumber, kemudian sahkan bagaimana halaman yang dikawal oleh Service Worker lama dinaik taraf.

Soalan Susulan 5: Bagaimanakah HTML diperibadikan yang merujuk kepada aset ber-hash patut di-cache?

HTML tersebut boleh menggunakan Cache-Control: private, no-cache untuk menghalang penggunaan semula yang dikongsi dan mengesahkannya sebelum penggunaan semula cache peribadi. Aset statik ber-hash yang serupa untuk setiap pengguna masih boleh menggunakan caching jangka panjang awam. Halaman yang disahkan dan sumber statiknya tidak memerlukan satu dasar berkongsi yang sama; tetapkan sempadan berdasarkan sama ada setiap perwakilan diperibadikan atau tidak.

Soalan Susulan 6: Bagaimanakah deployment boleh memadam aset statik lama dengan selamat?

Bina set rujukan daripada HTML semasa, HTML yang menyokong rollback, manifes laluan, dan rekod keluaran, kemudian tambahkan tetingkap kebolehcapaian halaman lama maksimum. Aset ber-hash layak untuk dipadamkan secara tertangguh hanya selepas tiada titik masuk yang diterbitkan merujuk kepadanya, tetingkap rollback telah tamat, dan log akses menunjukkan tiada lagi permintaan yang sah. Tugas pembersihan harus boleh dihentikan dan mengekalkan beberapa keluaran terkini supaya satu keputusan yang salah tidak merosakkan keupayaan rollback.