Panga sera kwa rasilimali, sio kwa server
Fanya hesabu ya URL za uwakilishi kabla ya kubadilisha vichwa: ukurasa wa nyumbani, ukurasa wa maudhui, application shell, CSS, JavaScript, picha, font, API, kuingia (login), akaunti, checkout, na upakuaji. Kwa kila moja, andika kama jibu ni la umma au la kibinafsi, kama URL yake hubadilika wakati bytes zake zinabadilika, na ni haraka kiasi gani marekebisho yanapaswa kufika kwa watumiaji.
Tengeneza matriisi ya sera kutoka kwa hesabu hiyo. Asset ya umma iliyotambulishwa kwa maudhui (content-addressed) inahitaji sheria tofauti na HTML kwenye anwani thabiti. Majibu bila Cache-Control bado yanaweza kukamatwa kwa mithili ya heuristics, hivyo sheria za wazi ni rahisi kujaribu.
Muda ambao jibu lililohifadhiwa linaweza kutumika tena; max-age linaliweka kwa sekunde.
Tumia maneno ya Cache-Control kwa usahihi
Cache-Control inaeleza kwa vivinjari na shared caches jinsi ya kuhifadhi na kutumia jibu. max-age=N inaruhusu matumizi wakati bado ni fresh. s-maxage=N inaweka uhai wa shared-cache na inazitawala max-age pale, lakini vivinjari huviheshimu s-maxage. public inaruhusu cache yoyote; private inaruhusu caching ya kivinjari lakini inazuia uhifadhi kwenye shared-cache.
no-cache inaruhusu uhifadhi lakini inataka uthibitisho kutoka kwa origin kabla ya matumizi. no-store inamaanisha caches haziruhusiwi kuhifadhi jibu, lakini si udhibiti kamili wa faragha. Tumia must-revalidate wakati kutumika kwa yaliyosahaulika baada ya muda wa uhai ni yasiyokubalika; origin isiyopatikana inaweza kisha kutoa 504 badala ya fallback ya stale.
Inafuta uhifadhi badala ya kuhitaji tu kuangalia; itumike kwa majibu ambayo kwa kweli hayapaswi kuhifadhiwa.
Toa version kwa assets zisizobadilika kabla ya kuzipa maisha marefu
URL ya asset iliyotolewa kwa version inajumuisha fingerprint ya maudhui au toleo, kama app.4f2c.js. Wakati bytes za asset zinabadilika, chapisha URL tofauti na sasisha rejeleo la HTML. Cache itaona rasilimali mpya, hivyo wageni watapakua asset mpya bila kuhitaji invalidation kufikia kila kivinjari.
Kwa representation ambayo haitabadilika wakati wa freshness lifetime yake, Cache-Control: max-age=31536000, immutable ni mtindo wa vitendo. immutable inasema kwa wateja wanaounga mkono kutoleta uthibitisho kwa masharti wakati bado ni fresh. Usitumie au max-age ya mwaka mmoja kwa faili inayoweza kubadilika yenye URL ileile. Hifadhi assets za fingerprint zilizotangulia wakati HTML iliyokaa bado inaweza kuziweka rejeleo.
HTML huchagua URL za asset, hivyo ufuatiliaji wa release lazima uhifadhi kizazi kilichotajwa.
Fanya HTML kuwa ya sasa kupitia uthibitisho, sio caching ndefu
HTML kwa kawaida ina URL thabiti inayoonekana na binadamu na hubadilika kwa maudhui, rejeleo za asset, flag za kipengele, au taarifa za usalama. Mfano wa tahadhari wa HTML ya umma ni Cache-Control: no-cache pamoja na ETag na Last-Modified wakati jukwaa lako linaweza kuzitengeneza ipasavyo. Kivinjari huhifadhi body lakini hutumia ombi conditional kabla ya matumizi; jibu lisilobadilika linaweza kurudisha 304 Not Modified bila body.
ETag hutambulisha toleo la rasilimali. Kwenye jibu lililosahaulika, kivinjari kinaweza kuituma kwa If-None-Match; ikiwa inalingana, server inarejesha 304, vinginevyo inatuma representation mpya. Mwito wa RFC unapendelea kuonyesha ETag na Last-Modified kwenye jibu la 200 inapowezekana. no-cache haisihi dhamana ya uthibitisho kwenye navigation ya Back au Forward kwa sababu kivinjari kinaweza kurejesha snapshot ya history ya session.
ETag lazima ibadilike wakati representation inabadilika; iteste kwenye origin na deployments.
Tenganisha utoaji wa umma na majibu yaliyo kibinafsi na yaliyo nyeti
Shared cache, kama CDN, inaweza kutumia jibu moja kwa watumiaji wengi. Usiruhusu itumike tena HTML ya akaunti au data za API maalum kwa watumiaji tofauti. Kwa maudhui ya kibinafsi ambayo yanaweza kuishi kwenye kivinjari, private, no-cache ni mwanzo mzuri: inazuia uhifadhi kwenye shared-cache na inahitaji uthibitisho. Kichwa cha Set-Cookie pekee hakizuizi caching.
Kwa majibu ambayo hayapaswi kuhifadhiwa, tumia no-store na pitia tena msimbo wa programu, sheria za CDN, service workers, hifadhi ya kivinjari, logi, na kurasa za hitilafu. Vichwa pekee si programu ya faragha, uzingatiaji, au usalama wa malipo. Waajiri wakaguzi wenye sifa za usalama, faragha, na malipo kuchambua mtiririko nyeti na mahitaji yanayotumika.
Testi kuingia (sign-in), kutoka (sign-out), kubadilisha akaunti, na mabadiliko ya ruhusa kwa caches za kivinjari na CDN zilizokolea (warm).
Acha mabadiliko ya cache yaliwezekane kurudishwa kama release iliyo na njia ya rollback
Chukua vichwa na tabia za body za msingi kwa maombi yasiyokuwa cached na ya kurudia kabla ya kubadilisha. Katika staging, deploy assets zilizo versioned kwanza, kisha HTML inayowarejelea, na jaribu HTML iliyohifadhiwa ya zamani dhidi ya origin mpya. Angalia njia za direct-origin na CDN kama zote zipo. Vichwa vya DevTools Network vinapaswa kuonyesha sera iliyokusudiwa na tabia za matumizi mara mbili.
Hifadhi manifest ya release ya URL za asset, sheria za vichwa, na toleo la mpangilio. Ikiwa release ina files za mtego zisizowiana, rejesha HTML inayofanya kazi, lakini usifanye overwrite ya faili iliyo fingerprinted. Elekeza HTML kwenye kizazi kilicho salama na uhifadhi vizazi vyote huku HTML zilizohifadhiwa zinaweza kuziweka. Purge ya shared-cache haiwezi kuwalazimisha vivinjari kuvuruga jibu ambalo bado ni fresh.
Geuza kushindwa kwa mtihani wa vichwa, 404 za asset, na mizozo ya toleo kuwa mabadiliko kwenye checklist ya release inayofuata.