Ima-map ang patakaran sa resource, hindi sa server
Gumawa ng imbentaryo ng mga kinakatawang URL bago baguhin ang mga header: home page, content page, application shell, CSS, JavaScript, mga imahe, font, API, login, account, checkout, at downloads. Para sa bawat isa, itala kung ang tugon ay pampubliko o personalized, kung nagbabago ba ang URL kapag nagbago ang bytes, at kung gaano kabilis dapat makarating ang isang pagwawasto sa mga bisita.
Gumawa ng policy matrix mula sa imbentaryong iyon. Ang isang public content-addressed asset ay nangangailangan ng ibang patakaran kaysa sa HTML na nasa isang stable na address. Ang mga tugon na walang Cache-Control ay maaari pa ring ma-cache nang heuristically, kaya mas madaling subukan ang mga tahasang patakaran.
Ang panahon na maaaring muling gamitin ang isang naka-imbak na tugon; ibinibigay ito ng max-age sa mga segundo.
Gamitin nang tumpak ang mga termino ng Cache-Control
Sinusabi ng Cache-Control sa mga browser at shared cache kung paano i-store at muling gamitin ang isang tugon. Ang max-age=N ay nagpapahintulot ng muling paggamit habang fresh. Ang s-maxage=N ay nagtatakda ng shared-cache freshness at nag-ooverride ng max-age doon; hindi ito binabasa ng mga browser. Ang public ay nagpapahintulot sa anumang cache; ang private ay nagpapahintulot ng browser caching ngunit pumipigil sa shared-cache storage.
Ang no-cache ay nagpapahintulot ng storage ngunit nangangailangan ng validation sa origin bago muling gamitin. Ang no-store naman ay nangangahulugang hindi dapat i-store ng mga cache ang tugon, ngunit hindi ito kumpletong kontrol sa privacy. Gamitin ang must-revalidate kapag hindi katanggap-tanggap ang pagsisilbi ng stale content pagkatapos mag-expire; sa ganoong paraan, ang unavailable na origin ay maaari nang magbalik ng 504 sa halip na stale fallback.
Tinatanggal nito ang storage sa halip na simpleng mangailangan ng tsek; ireserba ito para sa mga tugong talagang hindi dapat i-store.
I-version ang immutable na mga asset bago magtakda ng mahabang lifetime
Ang isang versioned asset URL ay naglalaman ng content fingerprint o release version, halimbawa app.4f2c.js. Kapag nagbago ang bytes ng asset, i-publish ang ibang URL at i-update ang reference sa HTML. Nakikita ng cache ang bagong resource, kaya kukunin ng bisita ang bagong asset nang hindi kailangang maabot ang invalidation sa bawat browser.
Para sa isang representasyon na hindi magbabago sa loob ng kanyang freshness lifetime, praktikal ang pattern na Cache-Control: max-age=31536000, immutable. Sinasabi ng immutable sa mga sumusuportang client na huwag mag-conditionally revalidate habang fresh. Huwag itong gamitin o magtakda ng isang taong max-age sa isang maramihang nagbabagong same-URL na file. Panatilihin ang mga naunang fingerprinted assets habang ang cached HTML ay maaaring tumutukoy pa rin sa mga ito.
Pinipili ng HTML ang mga asset URL, kaya kailangang panatilihin ng release sequencing ang referenced generation.
Gawing kasalukuyan ang HTML sa pamamagitan ng validation, hindi ng mahabang caching
Ang HTML karaniwang may stable, human-facing URL at nagbabago kasama ng content, asset references, feature flags, o security notice. Ang konserbatibong pampublikong pattern para sa HTML ay Cache-Control: no-cache kasama ng ETag at Last-Modified kapag kayang i-produce nang tama ng platform ang mga ito. I-iimbak ng browser ang body ngunit gagamit ng conditional request bago muling gamitin; ang hindi nagbago ay maaaring magbalik ng 304 Not Modified nang walang body.
Ang ETag ay nag-iidentipika ng version ng resource. Sa isang stale na tugon, maaaring ipadala ito ng browser sa If-None-Match; kung tumugma, sasagot ang server ng 304, kung hindi ay ipapadala nito ang bagong representasyon. Mas pinapayo ng RFC ang pagkakaroon ng parehong ETag at Last-Modified sa isang 200 response kapag posible. Hindi pinapangako ng no-cache na magkakaroon ng validation sa Back o Forward navigation dahil maaaring i-restore ng browser ang session-history snapshot.
Dapat magbago ang ETag kapag nagbago ang representasyon; subukin ito sa iba't ibang origin at deployment.
Paghiwalayin ang pampublikong paghahatid mula sa personalized at sensitibong tugon
Maaaring i-reuse ng shared cache, halimbawa isang CDN, ang isang tugon para sa maraming gumagamit. Huwag hayaang ma-reuse nito ang account-specific na HTML o API data across users. Para sa personalized na content na maaaring manatili sa browser, ang private, no-cache ay sensible na panimulang patakaran: pinipigilan nito ang shared storage at nangangailangan ng validation. Ang isang Set-Cookie header lamang ay hindi pumipigil sa caching.
Para sa mga tugong hindi dapat i-store, gumamit ng no-store at repasuhin ang application code, CDN rules, service workers, browser storage, logs, at error pages. Hindi sapat ang mga header lamang para sa privacy, compliance, o payment-security program. Magkaroon ng kwalipikadong security, privacy, at payment reviewers na susuriin ang mga sensitibong flow at ang mga naaangkop na requirement.
Isubok ang sign-in, sign-out, pag-switch ng account, at pagbabago ng permiso sa may init na browser at CDN caches.
I-roll out ang mga pagbabago sa cache bilang reversible na release
Kunin ang baseline headers at body behavior para sa uncached at repeat requests. Sa staging, i-deploy muna ang versioned assets, pagkatapos ang HTML na nagtutukoy sa mga ito, at subukan ang mas lumang cached HTML laban sa bagong origin. Suriin ang direct-origin at CDN paths kung pareho silang umiiral. Dapat ipakita ng DevTools Network headers ang nilalayong patakaran at gawi sa repeat requests.
Panatilihin ang release manifest ng asset URL, header rules, at configuration version. Kung ang release ay naghalo ng hindi magkakatugmang client files, ibalik ang compatible na HTML at application behavior, ngunit huwag i-overwrite ang nai-publish na fingerprinted file. I-repoint ang HTML sa known-good generation at panatilihin ang parehong generation habang maaaring i-request pa rin ang mga ito ng cached HTML. Hindi kayang pilitin ng shared-cache purge ang mga browser na i-discard ang fresh na tugon.
Gawing bahagi ng susunod na release checklist ang header-test failures, asset 404s, at version mismatches.