എന്താണ് കാഷിംഗ്? ആപ്പ് ബിൽഡർമാർക്കായി ലളിതമായ ഗൈഡ്
വേഗത്തിൽ ലഭിക്കാത്തതോ ചെലവേറിയതോ ആയ ഒന്നിന്റെ തയ്യാറായ ഒരു കോപ്പി സൂക്ഷിക്കുന്നതാണ് കാഷിംഗ്, അതുവഴി അതിനായുള്ള അടുത്ത അഭ്യർത്ഥനയ്ക്ക് ആ കോപ്പിയിൽ നിന്ന് വേഗത്തിൽ മറുപടി നൽകാം. സൂക്ഷിച്ച കോപ്പിയെ cache എന്ന് വിളിക്കുന്നു. നിങ്ങളുടെ രണ്ടാമത്തെ സന്ദർശനത്തിൽ സൈറ്റ് വേഗത്തിൽ ലോഡ് ചെയ്യാൻ ബ്രൗസർ ചിത്രങ്ങൾ കാഷ് ചെയ്യുന്നു; ഓരോ സന്ദർശകനും വേണ്ടി വേഗം കുറഞ്ഞ ഡാറ്റാബേസ് ക്വറി വീണ്ടും ഓടിക്കാതിരിക്കാൻ സെർവർ അതിന്റെ ഫലം കാഷ് ചെയ്യുന്നു.
കാഷിംഗ് ആപ്പുകളെ വേഗമുള്ളതും പ്രവർത്തിപ്പിക്കാൻ വിലകുറഞ്ഞതുമാക്കുന്നു. അതിന്റെ ഒരു വലിയ വിട്ടുവീഴ്ച, കോപ്പി പഴകിപ്പോകാം എന്നതാണ്.
നിങ്ങൾ AI ഉപയോഗിച്ച് നിർമ്മിക്കുമ്പോൾ കാഷിംഗ് പ്രധാനമായത് എന്തുകൊണ്ട്
AI നിർമ്മിത ആപ്പുകളിൽ മൂന്ന് രീതികളിൽ കാഷിംഗ് നേരിടേണ്ടി വരും:
- “ആപ്പ് അപ്ഡേറ്റ് ചെയ്തു, പക്ഷേ പഴയ പതിപ്പ് ഇപ്പോഴും കാണുന്നു.” ഇത് ഏറ്റവും സാധാരണമായ കാഷിംഗ് സന്ദർഭമാണ്, സാധാരണയായി അത് ദോഷകരമല്ല — നിങ്ങളുടെ ബ്രൗസറോ CDN-ഓ സൂക്ഷിച്ച കോപ്പി കാണിക്കുകയാണ്.
- വേഗത. ഓരോ സന്ദർശകനും ഒരേ കണക്കുകൂട്ടൽ വീണ്ടും ചെയ്യുന്നതിനാൽ ഒരു പേജ് മന്ദഗതിയിലാണെങ്കിൽ, ഫലം കാഷ് ചെയ്യുന്നത് അതിനെ തൽക്ഷണമായി തോന്നിപ്പിക്കും.
- ചെലവ്. പല AI ബിൽഡറുകളും ഹോസ്റ്റുകളും കമ്പ്യൂട്ട്, ഡാറ്റാബേസ് സമയം, പുറത്തുള്ള API കോളുകൾ എന്നിവയ്ക്ക് ചാർജ് ഈടാക്കുന്നു. ആയിരം സന്ദർശകർ ഒരേ ചെലവേറിയ അഭ്യർത്ഥന ട്രിഗർ ചെയ്താൽ, കാഷിംഗ് വഴി അതിന് ഒരു തവണ മാത്രം പണം നൽകാം.
അടിസ്ഥാന കാര്യങ്ങൾ അറിയുന്നത്, സഹായകരമായ ഇടങ്ങളിൽ കാഷിംഗ് ആവശ്യപ്പെടാനും, എന്തെങ്കിലും തെറ്റായി കാണുന്നതിന്റെ കാരണം കാഷിംഗ് ആകുമ്പോൾ അത് തിരിച്ചറിയാനും സഹായിക്കുന്നു.
ദൈനംദിന ഉദാഹരണം
തിരക്കുള്ള ഒരു കഫേയുടെ അടുക്കള സങ്കൽപ്പിക്കുക.
ഓരോ രാവിലെയും ഓർഡർ വരുമ്പോൾ പുതുതായി പൊടിച്ച കാപ്പിക്കുരുവിൽ നിന്ന് ഓരോ കാപ്പിയും ഉണ്ടാക്കാൻ ഷെഫിന് കഴിയും. അത് വേഗം കുറഞ്ഞതാണ്. പകരം, ഹോട്ട് പ്ലേറ്റിൽ ഒരു പാത്രം ഫിൽറ്റർ കാപ്പി തയ്യാറായി സൂക്ഷിക്കുന്നു. മിക്ക ഉപഭോക്താക്കൾക്കും സെക്കൻഡുകൾക്കുള്ളിൽ ഒരു കപ്പ് കിട്ടും — അതാണ് cache hit. പാത്രം തീരുമ്പോൾ ആരെങ്കിലും പുതിയത് ഉണ്ടാക്കും — അതാണ് cache miss.
പക്ഷേ അധികനേരം ഇരിക്കുന്ന കാപ്പി പഴകും, അതിനാൽ കഫേയ്ക്ക് ഒരു നിയമമുണ്ട്: 30 മിനിറ്റിൽ കൂടുതൽ പഴക്കമുള്ള ഏത് പാത്രവും കളയണം. ആ നിയമമാണ് കാഷിന്റെ കാലഹരണ സമയം. ദിവസം മുഴുവൻ ഒരേ പാത്രം ആരും സൂക്ഷിക്കില്ല, ഓട്ട്‌സ് പാലും മൂന്ന് പഞ്ചസാരയും ചേർത്ത ആരുടെയെങ്കിലും പ്രത്യേക ഓർഡർ മുൻകൂട്ടി ഉണ്ടാക്കി വെക്കുകയുമില്ല — ചില കാര്യങ്ങൾ ഒട്ടും കാഷ് ചെയ്യരുത്.
കാഷുകൾ എവിടെയാണ് ഉള്ളത്
ഒരു പേജ് ലോഡിൽ തന്നെ ഒന്നിലധികം കാഷുകൾ കടന്നുപോകാം, ഉപയോക്താവിന് അടുത്തത് മുതൽ ഏറ്റവും അകലെയുള്ളത് വരെ:
| കാഷ് | എവിടെ | സാധാരണ സൂക്ഷിക്കുന്നത് | ഉദാഹരണം |
|---|---|---|---|
| ബ്രൗസർ കാഷ് | സന്ദർശകന്റെ ഉപകരണത്തിൽ | ചിത്രങ്ങൾ, സ്റ്റൈൽഷീറ്റുകൾ, സ്ക്രിപ്റ്റുകൾ, ഫോണ്ടുകൾ | രണ്ടാമത്തെ പേജിൽ നിങ്ങളുടെ ലോഗോ തൽക്ഷണം ലോഡ് ചെയ്യുന്നു |
| CDN കാഷ് | ഉപയോക്താക്കൾക്ക് അടുത്തുള്ള ലോകമെമ്പാടുമുള്ള സെർവറുകൾ | സ്റ്റാറ്റിക് ഫയലുകൾ, ചിലപ്പോൾ മുഴുവൻ പേജുകളും | ടോക്കിയോയിലെ സന്ദർശകന് ഒറിജിനിന് പകരം അടുത്തുള്ള സെർവറിൽ നിന്ന് ഫയലുകൾ ലഭിക്കുന്നു |
| ആപ്ലിക്കേഷൻ കാഷ് | നിങ്ങളുടെ സെർവറിലോ അതിനടുത്തോ, പലപ്പോഴും മെമ്മറിയിലോ Redis-ലോ | വേഗം കുറഞ്ഞ ക്വറികളുടെയോ പുറത്തുള്ള API കോളുകളുടെയോ ഫലങ്ങൾ | ഇന്നത്തെ വിനിമയ നിരക്കുകൾ, മണിക്കൂറിൽ ഒരു തവണ എടുക്കുന്നത് |
| ഡാറ്റാബേസ് കാഷ് | ഡാറ്റാബേസിനുള്ളിൽ | അടുത്തിടെ ഉപയോഗിച്ച ഡാറ്റയും ക്വറി പ്ലാനുകളും | ജനപ്രിയ വരികൾ വേഗമുള്ള മെമ്മറിയിൽ തന്നെ നിൽക്കുന്നു |
CDN (content delivery network) എന്നത് നിങ്ങളുടെ സൈറ്റിന്റെ ഫയലുകൾക്കായുള്ള ലോകവ്യാപകമായ കാഷുകളുടെ ശൃംഖലയാണ്.
ഒരു കാഷ് എന്ത് സൂക്ഷിക്കണമെന്ന് തീരുമാനിക്കുന്നത് എങ്ങനെ
ഓരോ കാഷും ഒരേ ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകണം:
- എന്ത് കാഷ് ചെയ്യാം? പൊതുവായ, പങ്കിട്ട ഡാറ്റ (ഒരു ഉൽപ്പന്ന ചിത്രം, ഒരു ബ്ലോഗ് പോസ്റ്റ്) — അതെ. സ്വകാര്യ ഡാറ്റ (ഒരു ഉപയോക്താവിന്റെ അക്കൗണ്ട് പേജ്, അവരുടെ സന്ദേശങ്ങൾ) — പങ്കിട്ട കാഷിൽ ഒരിക്കലും വേണ്ട.
- എത്ര നേരം? ഇതാണ് TTL (time to live). ഒരു ലോഗോ ഒരു വർഷം വരെ കാഷ് ചെയ്യപ്പെട്ടേക്കാം; ഒരു സ്റ്റോക്ക് നില 30 സെക്കൻഡ് മാത്രം.
- എങ്ങനെ അപ്ഡേറ്റ് ചെയ്യപ്പെടുന്നു? ഒന്നുകിൽ കോപ്പിയുടെ കാലാവധി തീരുകയും വീണ്ടും എടുക്കുകയും ചെയ്യുന്നു, അല്ലെങ്കിൽ ഡാറ്റ മാറുമ്പോൾ ആപ്പ് മനഃപൂർവ്വം അത് നീക്കം ചെയ്യുന്നു — ഇതിനെ invalidation എന്ന് വിളിക്കുന്നു.
വെബ്സൈറ്റുകൾക്ക്, ഓരോ ഫയലും ബ്രൗസറുകൾക്കും CDN-കൾക്കും എങ്ങനെ കാഷ് ചെയ്യണമെന്ന് സെർവർ Cache-Control ഹെഡർ വഴി പറയുന്നു. ഉദാഹരണത്തിന്, Cache-Control: max-age=3600 എന്നാൽ “ഈ കോപ്പി ഒരു മണിക്കൂർ വരെ വീണ്ടും ഉപയോഗിക്കാം” എന്നാണ്.
ആധുനിക ബിൽഡ് ടൂളുകൾ സ്റ്റാറ്റിക് ഫയലുകളുടെ ഏറ്റവും കഠിനമായ ഭാഗം cache busting വഴി കൈകാര്യം ചെയ്യുന്നു: ഓരോ തവണയും ഒരു ഫയൽ മാറുമ്പോൾ അതിന് app.3f9a2c.js പോലെ വിരലടയാളമുള്ള ഒരു പുതിയ പേര് കിട്ടുന്നു. പുതിയ പതിപ്പിന് വേറെ പേരായതിനാൽ, പഴയ പേര് ബ്രൗസറിന് ദീർഘകാലം കാഷ് ചെയ്യാം.
ഒരു ഉദാഹരണം: ഒരു ഉൽപ്പന്ന കാറ്റലോഗ്
നിങ്ങൾക്ക് ഒരു ചെറിയ ഓൺലൈൻ ഷോപ്പുണ്ട്. ഹോം പേജിൽ ഡാറ്റാബേസിൽ നിന്നുള്ള 50 ഉൽപ്പന്നങ്ങളും വിലകളും സ്റ്റോക്ക് നിലകളും കാണിക്കുന്നു, കൂടാതെ എല്ലാ ഓർഡറുകളിലുമായി വേഗം കുറഞ്ഞ കണക്കുകൂട്ടൽ വേണ്ട ഒരു “trending” പട്ടികയും.
- ചിത്രങ്ങളും സ്ക്രിപ്റ്റുകളും ബ്രൗസറും CDN-ഉം ദീർഘകാലത്തേക്ക് കാഷ് ചെയ്യുന്നു. ഓരോ പുതിയ ബിൽഡും മാറിയ ഫയലുകൾക്ക് പുതിയ പേര് നൽകുന്നതിനാൽ അപ്ഡേറ്റുകൾ ഇപ്പോഴും കാണാം.
- trending പട്ടിക ഓരോ 10 മിനിറ്റിലും ഒരു തവണ കണക്കാക്കി ആപ്ലിക്കേഷൻ കാഷിൽ സൂക്ഷിക്കുന്നു. ആ 10 മിനിറ്റിനുള്ളിലെ ഓരോ സന്ദർശകനും സൂക്ഷിച്ച ഫലം തൽക്ഷണം ലഭിക്കുന്നു.
- വിലകൾ കുറഞ്ഞ സമയത്തേക്ക് കാഷ് ചെയ്യുന്നു, ഒരു ഉൽപ്പന്നം എഡിറ്റ് ചെയ്യുമ്പോഴെല്ലാം കാഷ് ക്ലിയർ ചെയ്യുന്നതിനാൽ ഉപഭോക്താക്കൾ പഴയ വില അധികനേരം കാണില്ല.
- ചെക്ക്-ഔട്ടിലെ സ്റ്റോക്ക് ഒരിക്കലും കാഷ് ചെയ്യുന്നില്ല. ആരെങ്കിലും “Buy” ക്ലിക്ക് ചെയ്യുമ്പോൾ, ആപ്പ് യഥാർത്ഥ ഡാറ്റാബേസ് പരിശോധിക്കുന്നു, അതിനാൽ ഇപ്പോൾ തീർന്ന ഒരു ഇനം വിൽക്കാൻ കഴിയില്ല.
- കാർട്ട്, അക്കൗണ്ട് പേജുകൾ പങ്കിട്ട കാഷുകളിൽ ഒരിക്കലും സൂക്ഷിക്കുന്നില്ല, കാരണം അവ വ്യക്തിഗതമാണ്.
ഫലം: ഹോം പേജ് വേഗമുള്ളതാണ്, ഡാറ്റാബേസ് വളരെ കുറച്ച് ജോലി ചെയ്യുന്നു, പണത്തിനോ സ്വകാര്യതയ്‌ക്കോ പ്രധാനമായ ഒന്നും ഒരിക്കലും പഴകുന്നില്ല.
പ്രധാന പദങ്ങൾ
| പദം | അർത്ഥം |
|---|---|
| Cache hit / miss | ഡാറ്റ കാഷിൽ കണ്ടെത്തി / ഉറവിടത്തിൽ നിന്ന് എടുക്കേണ്ടി വന്നു. |
| TTL (time to live) | സൂക്ഷിച്ച കോപ്പി എത്ര നേരം പുതിയതായി കണക്കാക്കുന്നു. |
| പഴകിയ ഡാറ്റ (Stale data) | കാലഹരണപ്പെട്ട ഒരു കാഷ് ചെയ്ത കോപ്പി. |
| Invalidation | ഒറിജിനൽ മാറിയതിനാൽ കാഷ് ചെയ്ത കോപ്പി മനഃപൂർവ്വം നീക്കം ചെയ്യൽ. |
| Cache busting | ഫയൽ മാറുമ്പോൾ അതിന്റെ പേരോ URL-ഓ മാറ്റി കാഷുകൾ പുതിയ പതിപ്പ് എടുക്കാൻ ഇടയാക്കൽ. |
| Cache-Control | ഒരു പ്രതികരണം എങ്ങനെ കാഷ് ചെയ്യണമെന്ന് ബ്രൗസറുകളോടും CDN-കളോടും പറയുന്ന HTTP ഹെഡർ. |
| ഹാർഡ് റിഫ്രഷ് | കാഷ് അവഗണിക്കാൻ ബ്രൗസറിനോട് പറഞ്ഞുകൊണ്ട് പേജ് വീണ്ടും ലോഡ് ചെയ്യൽ. |
| Redis | പലപ്പോഴും ആപ്ലിക്കേഷൻ കാഷായി ഉപയോഗിക്കുന്ന ജനപ്രിയ മെമ്മറി ഡാറ്റാ സ്റ്റോർ. |
സാധാരണ തെറ്റിദ്ധാരണകൾ
- “കാഷിംഗ് എപ്പോഴും നല്ലതാണ്.” തെറ്റായ കാര്യം കാഷ് ചെയ്താൽ യഥാർത്ഥ ബഗുകൾ ഉണ്ടാകുന്നു: പഴയ വിലകൾ, പുതിയ പോസ്റ്റുകൾ കാണാതിരിക്കൽ, അല്ലെങ്കിൽ ഏറ്റവും മോശമായത് — ഒരു ഉപയോക്താവിന്റെ സ്വകാര്യ പേജ് മറ്റൊരാൾക്ക് കാണിക്കൽ. മനഃപൂർവ്വം കാഷ് ചെയ്യുക.
- “പഴയ പതിപ്പ് കാണുന്നെങ്കിൽ, എന്റെ അപ്ഡേറ്റ് പരാജയപ്പെട്ടു.” സാധാരണയായി അങ്ങനെയല്ല. എന്തെങ്കിലും തകർന്നതായി കരുതുന്നതിന് മുമ്പ് ഹാർഡ് റിഫ്രഷ് (Ctrl+Shift+R, അല്ലെങ്കിൽ Mac-ൽ Cmd+Shift+R) അല്ലെങ്കിൽ പ്രൈവറ്റ് വിൻഡോ പരീക്ഷിക്കുക.
- “കാഷിംഗ് മന്ദഗതിയുള്ള ആപ്പ് ശരിയാക്കുന്നു.” ആവർത്തിച്ചുള്ള അഭ്യർത്ഥനകൾക്ക് അത് മന്ദത മറയ്ക്കുന്നു. ആദ്യ അഭ്യർത്ഥന ഇപ്പോഴും മന്ദഗതിയിലാണ്, അടിസ്ഥാന പ്രശ്നം ഡാറ്റാബേസ് ഇൻഡെക്സിന്റെ അഭാവമാണെങ്കിൽ അതും ശരിയാക്കുക.
- “കഴിയുന്നിടത്തോളം കാലം എല്ലാം കാഷ് ചെയ്യണം.” നീണ്ട കാഷ് സമയം മാറുമ്പോൾ പുതിയ പേര് കിട്ടുന്ന ഫയലുകൾക്ക് യോജിക്കുന്നു. HTML പേജുകൾക്കും ഡാറ്റയ്ക്കും ചെറിയ സമയമാണ് സുരക്ഷിതം.
- “കാഷ് ക്ലിയർ ചെയ്താൽ എല്ലാവർക്കും ശരിയാകും.” അത് നിങ്ങളുടെ ബ്രൗസർ മാത്രമേ ക്ലിയർ ചെയ്യുന്നുള്ളൂ. സന്ദർശകരുടെയും CDN കാഷുകളുടെയും സ്വന്തം കോപ്പികൾ ഇപ്പോഴും ഉണ്ടാകും.
നിങ്ങളുടെ AI ബിൽഡറോട് ചോദിക്കേണ്ടത്
- “ഈ ആപ്പിലെ ഏത് ഭാഗങ്ങളാണ് മന്ദഗതിയിലുള്ളത്, ഏതൊക്കെ സുരക്ഷിതമായി കാഷ് ചെയ്യാം?”
- “[trending പട്ടിക / API ഫലം] [N] മിനിറ്റ് കാഷ് ചെയ്യൂ, അടിസ്ഥാന ഡാറ്റ മാറുമ്പോൾ അത് ക്ലിയർ ചെയ്യൂ.”
- “വ്യക്തിഗത അല്ലെങ്കിൽ അക്കൗണ്ട് ഡാറ്റയുള്ള ഒരു പേജും CDN-ഓ പങ്കിട്ട കാഷോ കാഷ് ചെയ്യാതിരിക്കാൻ ഉറപ്പാക്കൂ.”
- “ഫിംഗർപ്രിന്റ് ചെയ്ത സ്റ്റാറ്റിക് ഫയലുകൾക്ക് നീണ്ട കാഷ് സമയവും HTML-ന് ചെറിയ സമയവും സെറ്റ് ചെയ്യൂ.”
- “[പുറത്തുള്ള API]-യിൽ നിന്നുള്ള പ്രതികരണങ്ങൾ കാഷ് ചെയ്യൂ, അതിനാൽ ഓരോ പേജ് ലോഡിലും അത് വിളിക്കേണ്ടതില്ല — ഈ ഡാറ്റ എത്രത്തോളം പഴകിയേക്കാം എന്നും പറയൂ.”
- “പ്രസിദ്ധീകരിച്ച ശേഷം പഴയ പതിപ്പ് കാണുന്നു. അത് എന്റെ ബ്രൗസർ കാഷാണോ, അതോ എന്തെങ്കിലും ഡിപ്ലോയ് ആയിട്ടില്ലേ?”
Mythex-ലെ കാഷിംഗ്
Mythex ആപ്പിൽ ഒരു അപ്ഡേറ്റ് പ്രസിദ്ധീകരിച്ച ശേഷം, CDN കാഷുകൾ കുറച്ചുനേരം പിന്നിലായേക്കാമെന്നും, പൊതു URL-ന്റെ ഹാർഡ് റിഫ്രഷ് പുതിയ പതിപ്പ് കാണിക്കുമെന്നും ഡോക്സ് പറയുന്നു — How to publish കാണുക. Hosting limits പേജ് സ്റ്റാറ്റിക് അസറ്റുകൾ കാഷ് ചെയ്യാനും ശുപാർശ ചെയ്യുന്നു, കാരണം ഹോസ്റ്റിംഗ്, ഡാറ്റാബേസ് സമയം, ബാൻഡ്‌വിഡ്ത്ത് എന്നിവയ്ക്ക് നിങ്ങളുടെ ക്രെഡിറ്റ് ബാലൻസിൽ നിന്നാണ് പണം ഈടാക്കുന്നത്. അതിനപ്പുറം — ക്വറി ഫലങ്ങളോ API പ്രതികരണങ്ങളോ കാഷ് ചെയ്യുന്നത് — നിങ്ങളുടെ ആപ്പിൽ അത് നിർമ്മിച്ചുതരാൻ ഏജന്റിനോട് ആവശ്യപ്പെടേണ്ട കാര്യമാണ്.
അനുബന്ധ വായന: CDN എന്താണ്, നിങ്ങളുടെ വെബ്സൈറ്റ് വേഗത്തിലാക്കുന്നത് എങ്ങനെ, റേറ്റ് ലിമിറ്റിംഗ് എന്താണ്.
ചോദ്യങ്ങൾ
ലളിതമായി പറഞ്ഞാൽ എന്താണ് കാഷിംഗ്?
ലഭിക്കാൻ വൈകുകയോ ചെലവേറിയതാകുകയോ ചെയ്ത ഒന്നിന്റെ ഒരു കോപ്പി സൂക്ഷിക്കുന്നതാണ് കാഷിംഗ്. അടുത്ത തവണ അത് വേണ്ടിവരുമ്പോൾ സൂക്ഷിച്ച കോപ്പിയിൽ നിന്ന് വേഗത്തിൽ നൽകാം. ആപ്പുകൾ വേഗമുള്ളതും പ്രവർത്തിപ്പിക്കാൻ വിലകുറഞ്ഞതുമാക്കാൻ ബ്രൗസറുകളും CDN-കളും സെർവറുകളും ഡാറ്റാബേസുകളും കാഷുകൾ ഉപയോഗിക്കുന്നു.
വെബ്സൈറ്റ് അപ്ഡേറ്റ് ചെയ്തിട്ടും പഴയ പതിപ്പ് ഇപ്പോഴും കാണുന്നത് എന്തുകൊണ്ട്?
നിങ്ങളുടെ ബ്രൗസറോ CDN-ഓ പഴയ ഫയലുകളുടെ സൂക്ഷിച്ച കോപ്പി കാണിക്കുന്നുണ്ടാകാം. ഹാർഡ് റിഫ്രഷ് (Windows-ൽ Ctrl+Shift+R, Mac-ൽ Cmd+Shift+R) സാധാരണയായി ഇത് ശരിയാക്കും. സന്ദർശകർക്ക്, നന്നായി നിർമ്മിച്ച സൈറ്റുകൾ അപ്ഡേറ്റ് ചെയ്ത ഫയലുകൾക്ക് പുതിയ പേരുകൾ നൽകുന്നതിനാൽ കാഷുകൾ പുതിയ പതിപ്പ് സ്വയം എടുക്കുന്നു.
ബ്രൗസർ കാഷ് ക്ലിയർ ചെയ്താൽ എന്ത് സംഭവിക്കും?
ബ്രൗസർ കാഷ് ക്ലിയർ ചെയ്താൽ ബ്രൗസർ സൂക്ഷിച്ച ഫയലുകളുടെയും പേജുകളുടെയും കോപ്പികൾ ഇല്ലാതാകുന്നു, അടുത്ത തവണ എല്ലാം പുതുതായി ഡൗൺലോഡ് ചെയ്യും. തകർന്നതോ പഴയതോ ആയി കാണുന്ന പേജുകൾ ഇത് ശരിയാക്കിയേക്കാം, അതിനു ശേഷം ആദ്യ തവണ പേജുകൾ അല്പം വൈകി ലോഡ് ചെയ്യും.
കാഷിംഗ് പ്രശ്നങ്ങൾ ഉണ്ടാക്കുമോ?
ഉണ്ടാക്കാം. പ്രധാന അപകടം പഴകിയ ഡാറ്റ നൽകുന്നതാണ് — പഴയ വില, പഴകിയ സ്റ്റോക്ക് നില — അല്ലെങ്കിൽ അതിലും മോശമായി, ഒരു ഉപയോക്താവിന്റെ സ്വകാര്യ പേജ് കാഷ് ചെയ്ത് മറ്റൊരാൾക്ക് കാണിക്കുന്നത്. നല്ല കാഷിംഗ് നിയമങ്ങൾ എന്ത് കാഷ് ചെയ്യാം, എത്ര നേരം, എന്നും പങ്കിട്ട കാഷുകളിൽ വ്യക്തിഗത ഡാറ്റ ഒരിക്കലും കാഷ് ചെയ്യരുത് എന്നും തീരുമാനിക്കുന്നു.