ഹോസ്റ്റിംഗും പ്രകടനവും
ഞങ്ങൾ എങ്ങനെയാണ് WordPress വേഗത്തിലാക്കുന്നത്: LiteSpeed Enterprise, LSCache കൂടാതെ ഓരോ സൈറ്റിനും Redis
ഒരിക്കലും റൺ ചെയ്യാത്ത ഒന്നാണ് ഏറ്റവും വേഗതയേറിയ WordPress അഭ്യർത്ഥന — PHP അല്ലെങ്കിൽ MySQL പ്രവർത്തനക്ഷമമാകുന്നതിന് മുൻപ് തന്നെ ഞങ്ങളുടെ സ്റ്റാക്ക് കാഷിൽ നിന്ന് ഭൂരിഭാഗം സന്ദർശനങ്ങൾക്ക് എങ്ങനെ മറുപടി നൽകുന്നുവെന്നും Core Web Vitals-ൽ ഇത് എന്ത് മാറ്റമുണ്ടാക്കുന്നുവെന്നും ഇവിടെ കാണാം.
ഒരിക്കലും പ്രവർത്തിക്കാത്ത ഒന്നാണ് ഏറ്റവും വേഗതയേറിയ അഭ്യർത്ഥന
ഒരു സാധാരണ WordPress അഭ്യർത്ഥനയ്ക്ക് ഭാരമേറെയാണ്. വെബ് സെർവർ PHP-ലേക്ക് കൈമാറുന്നു, PHP WordPress-നെ ബൂട്ട് ചെയ്യുന്നു, പ്ലഗിനുകൾ പ്രവർത്തിപ്പിക്കുന്നു, MySQL-ലേക്ക് ഡസൻ കണക്കിന് തവണ ചോദ്യങ്ങൾ അയയ്ക്കുന്നു, HTML കൂട്ടിച്ചേർക്കുന്നു, അതിനുശേഷം മാത്രമേ ബൈറ്റുകൾ തിരികെ അയയ്ക്കൂ. തിരക്കേറിയ ഒരു സൈറ്റിൽ ഈ പ്രക്രിയ മുഴുവൻ ഓരോ സന്ദർശകനും സംഭവിക്കുന്നു, നിങ്ങളുടെ time-to-first-byte-ന്റെ ഭൂരിഭാഗവും ചെലവഴിക്കുന്നത് ഇവിടെയാണ്.
മിക്ക സന്ദർശനങ്ങളിലും ഇതിലൊന്നും ഒട്ടും സംഭവിക്കുന്നില്ല എന്ന് ഉറപ്പാക്കുക എന്നതാണ് ഞങ്ങളുടെ മറുപടി. ഞങ്ങൾ ഹോസ്റ്റ് ചെയ്യുന്ന സൈറ്റുകളിലുടനീളം — 100,000-ത്തിലധികം PBN സൈറ്റുകളും ഒപ്പം പ്രധാന നിയന്ത്രിത WordPress സൈറ്റുകളും — ഫ്രണ്ട്-എൻഡ് പേജ് കാഴ്‌ചകളുടെ ഭൂരിഭാഗവും PHP പ്രവർത്തനക്ഷമമാക്കുകയോ ഡാറ്റാബേസ് പരിശോധിക്കുകയോ ചെയ്യാതെ തന്നെ കാഷെയിൽ നിന്ന് നേരിട്ട് മുൻകൂട്ടി തയ്യാറാക്കിയ പൂർണ്ണ പേജായി നൽകപ്പെടുന്നു. ഇത് സാധ്യമാക്കുന്ന വിവിധ തലങ്ങൾ എങ്ങനെ പരസ്പരം പൊരുത്തപ്പെടുന്നുവെന്നും ഓരോന്നും അതിന്റേതായ പ്രാധാന്യം എങ്ങനെ നേടുന്നുവെന്നും ഉള്ളതാണ് ഈ ലേഖനത്തിന്റെ ബാക്കി ഭാഗം.
നിങ്ങൾ തിരഞ്ഞെടുക്കേണ്ട പരസ്പര മത്സരമുള്ള കാഷുകളല്ല ഇവ എന്നതാണ് പ്രധാനപ്പെട്ട കാര്യം. ഫുൾ-പേജ് കാഷെ, ഒബ്ജക്റ്റ് കാഷെ, CDN എഡ്ജ് എന്നിവ ഓരോന്നും വ്യത്യസ്ത തരത്തിലുള്ള അഭ്യർത്ഥനകളെയാണ് കൈകാര്യം ചെയ്യുന്നത്, അവ പരസ്പരം എങ്ങനെ കൈമാറ്റം ചെയ്യുന്നു എന്നതിലാണ് യഥാർത്ഥ മൂല്യം അടങ്ങിയിരിക്കുന്നത്.
LiteSpeed Enterprise + LSCache: പൂർണ്ണ-പേജ് തലം
എല്ലാ സൈറ്റുകളും സെർവർ-ലെവൽ LSCache ഉള്ള LiteSpeed Enterprise-ൽ പ്രവർത്തിക്കുന്നു. ഒരു ഫ്രണ്ട്-എൻഡ് പ്രതികരണം കാഷെ ചെയ്യാൻ കഴിയുമ്പോൾ, വെബ് സെർവർ അതിൽ LiteSpeed കാഷെ-നിയന്ത്രണവും ടാഗ് ഹെഡറുകളും നൽകുന്നു, അടുത്ത സന്ദർശനത്തിൽ LiteSpeed പൂർണ്ണമായ പേജ് നേരിട്ട് നൽകുന്നു — PHP പ്രോസസ്സ് സൃഷ്ടിക്കപ്പെടുന്നില്ല, MySQL അന്വേഷണം അയയ്ക്കപ്പെടുന്നില്ല. ഇത് ആപ്ലിക്കേഷന്റെ പൂർണ്ണ ബൂട്ടിനെ പ്രധാന പാതയിൽ നിന്ന് നീക്കം ചെയ്യുന്നതിനാൽ, WordPress TTFB-യിലെ ഏറ്റവും വലിയ ഘടകമാണിത്.
LSCache ഒരു PHP പ്ലഗിന് പകരം വെബ് സെർവറിനുള്ളിൽ പ്രവർത്തിക്കുന്നതിനാൽ, അഭ്യർത്ഥനയുടെ ലൈഫ് സൈക്കിളിന്റെ പ്രാരംഭ ഘട്ടത്തിൽ തന്നെ ഇത് പ്രവർത്തനം ആരംഭിക്കുകയും സെർവറിന് തൽക്ഷണം ഫ്ലഷ് ചെയ്യാൻ കഴിയുന്ന രൂപത്തിൽ പേജുകൾ സൂക്ഷിക്കുകയും ചെയ്യുന്നു. ഒരു കാഷെ ക്രോളർ ജനപ്രിയ പേജുകൾ സദാ സജ്ജമാക്കി നിർത്തുന്നു, അതിനാൽ കാഷെ നീക്കംചെയ്ത ശേഷമുള്ള ആദ്യ സന്ദർശകന് പേജ് വീണ്ടും ജനറേറ്റ് ചെയ്യുന്നതിനുള്ള കാലതാമസം നേരിടേണ്ടി വരുന്നില്ല. കാഷെ ഇപ്പോഴും PHP-ക്ക് പിന്നിൽ സ്ഥിതിചെയ്യുന്ന ഒരു സാധാരണ സ്റ്റാക്കിലേക്ക് ഘടിപ്പിച്ച പ്ലഗിൻ മാത്രമുള്ള കാഷെയേക്കാൾ വളരെ കുറഞ്ഞതും സ്ഥിരതയുള്ളതുമായ TTFB ആണ് ഇതിന്റെ ഫലം.
ഞങ്ങളുടെ സ്വന്തം റിപ്പോ-ഗ്രേഡ് കാഷെ പ്ലഗിൻ എല്ലാ സൈറ്റിലും മുൻകൂട്ടി ഇൻസ്റ്റാൾ ചെയ്തതും സ്വയമേവ അപ്ഡേറ്റ് ചെയ്യുന്നതുമാണ്, ഇത് തുടക്കം മുതൽ തന്നെ WordPress-നെ LSCache-ലേക്ക് കൃത്യമായി ബന്ധിപ്പിക്കുന്നു. LiteSpeed അല്ലാത്ത ഉറവിടങ്ങളിൽ, ഇത് പൂർണ്ണ-പേജ് ഹെഡറുകൾ നൽകുന്നില്ല ഒപ്പം തടസ്സമാകാതെ ഒഴിഞ്ഞുനിൽക്കുന്നു, അതേസമയം ഒബ്ജക്റ്റ് കാഷെയും ഒഴിവാക്കൽ നിയമങ്ങളും അവയുടെ പ്രവർത്തനം തുടരുന്നു — അതിനാൽ മൈഗ്രേറ്റ് ചെയ്ത ഒരു സൈറ്റ് ഒരിക്കലും അപൂർണ്ണമായ കോൺഫിഗറേഷനിലോ തകരാറിലായ അവസ്ഥയിലോ അവശേഷിക്കില്ല.
പഴയ ഉള്ളടക്കം നൽകാതെ വേഗത നിലനിർത്തുക: ESI, സ്മാർട്ട് സ്വയമേവയുള്ള പർജ് എന്നിവ
തീവ്രമായ ഫുൾ-പേജ് കാഷിംഗിന് രണ്ട് സാധാരണ പരാജയ മോഡുകളുണ്ട്: ലോഗിൻ ചെയ്ത ഉപയോക്താവിന് മറ്റൊരാളുടെ പേജ് നൽകുക, മാറേണ്ടിയിരുന്ന ഒരു പേജ് ആർക്കെങ്കിലും നൽകുക. കാഷിംഗ് കുറയ്ക്കുന്നതിന് പകരം കാഷിംഗ് ലെയറിലാണ് ഇവ രണ്ടും പരിഹരിക്കുന്നത്.
തത്സമയം നിലനിൽക്കേണ്ട ഭാഗങ്ങൾക്കായി ഒഴിവാക്കലുകൾ അനുവദിച്ചുകൊണ്ട് പേജ് കാഷെ ചെയ്യാൻ ESI (Edge Side Includes) ഞങ്ങളെ അനുവദിക്കുന്നു. ഒരു WooCommerce സ്റ്റോറിൽ, സാധ്യമായ ഏറ്റവും വേഗതയേറിയ TTFB-യ്ക്കായി കാറ്റലോഗ്, ഉൽപ്പന്നം, വിഭാഗം പേജുകൾ പൂർണ്ണ-പേജ് കാഷെയായി നൽകുന്നു, അതേസമയം ഓരോ അഭ്യർത്ഥനയ്ക്കും കാർട്ട് ഫ്രാഗ്മെന്റ്, മിനി-കാർട്ട് തുകകൾ, അക്കൗണ്ട് നില എന്നിവ ESI റെൻഡർ ചെയ്യുന്നു. കാർട്ട്, ചെക്ക്ഔട്ട്, മൈ-അക്കൗണ്ട്, കൂടാതെ ഏതെങ്കിലും nonce അല്ലെങ്കിൽ സെഷൻ പേജുകൾ ഡിഫോൾട്ടായി ഒഴിവാക്കപ്പെടുന്നു. ഉപഭോക്താക്കൾ എപ്പോഴും അവരുടെ സ്വന്തം ബാസ്ക്കറ്റും പ്രവർത്തിക്കുന്ന ചെക്ക്ഔട്ടും കാണുന്നു; എല്ലാവർക്കും ഇപ്പോഴും കാഷെയിൽ നിന്ന് തന്നെ സ്റ്റോർഫ്രണ്ട് ലഭിക്കുകയും ചെയ്യുന്നു.
സ്മാർട്ട് ഓട്ടോ-പർജ് വഴിയാണ് ഫ്രഷ്‌നെസ്സ് കൈകാര്യം ചെയ്യുന്നത്. ഉള്ളടക്കം, ഉൽപ്പന്നങ്ങൾ, വിലകൾ അല്ലെങ്കിൽ ഓർഡറുകൾ എന്നിവ മാറുമ്പോൾ പർജ് ഹുക്കുകൾ സ്വയമേവ പ്രവർത്തിക്കുന്നു, അതിനാൽ കാഷെ ചെയ്ത പ്രസക്തമായ പേജുകൾ ടൈമറിനെ ആശ്രയിക്കാതെ തൽക്ഷണം പുതുക്കപ്പെടുന്നു, കൂടാതെ ഡാഷ്‌ബോർഡിൽ നിന്നോ WordPress-ൽ നിന്നോ നിങ്ങൾക്ക് ആവശ്യാനുസരണം പർജ് ചെയ്യാനും കഴിയും. ടാഗ് അധിഷ്‌ഠിത പർജിംഗ് എന്നാൽ ഒരു പോസ്റ്റ് എഡിറ്റ് ചെയ്യുമ്പോൾ ആ പോസ്റ്റും അതിന്റെ ആർക്കൈവുകളും മാത്രമേ ക്ലിയർ ചെയ്യപ്പെടുകയുള്ളൂ — മുഴുവൻ കാഷെയുമല്ല — അതിനാൽ ഒരൊറ്റ എഡിറ്റ് മുഴുവൻ സൈറ്റിനെയും കോൾഡ്-സ്റ്റാർട്ട് ചെയ്യില്ല.
ഓരോ സൈറ്റിനുമുള്ള Redis ഒബ്ജക്റ്റ് കാഷെ: ഒരു പൂർണ്ണ പേജ് ആകാൻ കഴിയാത്തവയ്ക്ക്
എല്ലാ അഭ്യർത്ഥനകളും ഒരു സ്റ്റാറ്റിക് പൂർണ്ണ പേജ് ആകണമെന്നില്ല. ലോഗിൻ ചെയ്ത സെഷനുകൾ, WordPress അഡ്മിൻ, WooCommerce കാർട്ടുകൾ, തിരയൽ, ESI ലൈവായി വിടുന്ന ഡൈനാമിക് ഘടകങ്ങൾ എന്നിവയ്‌ക്കെല്ലാം PHP പ്രവർത്തിപ്പിക്കേണ്ടതുണ്ട്. അവയ്ക്കായി, ലക്ഷ്യം 'ആപ്ലിക്കേഷൻ ഒഴിവാക്കുക' എന്നതിൽ നിന്ന് 'ഡാറ്റാബേസ് ഒഴിവാക്കുക' എന്നതിലേക്ക് മാറുന്നു.
ഓരോ സൈറ്റിനും അതിന്റേതായ സമർപ്പിത Redis ഒബ്ജക്റ്റ് കാഷെ ലഭിക്കുന്നു. ആവർത്തിച്ചുള്ള ഡാറ്റാബേസ് റീഡുകളുടെ ഫലങ്ങൾ — ഓപ്ഷനുകൾ, ട്രാൻസിയന്റുകൾ, പോസ്റ്റ്-ടേം ലുക്കപ്പുകൾ, WooCommerce ഉൽപ്പന്ന, സെഷൻ വിവരങ്ങൾ എന്നിവ — WordPress മെമ്മറിയിൽ കാഷെ ചെയ്യുന്നു, അതിനാൽ ഓരോ തവണയും MySQL-ലേക്ക് ഒരേ അന്വേഷണം വീണ്ടും നടത്തുന്നില്ല. പൂർണ്ണ-പേജ് കാഷെക്ക് സഹായിക്കാനാകാത്ത ഇടങ്ങളിലാണ് ഇതിന്റെ ഫലം കൂടുതൽ ദൃശ്യമാകുന്നത്: വേഗത്തിലുള്ള ഡാഷ്‌ബോർഡുകൾ, വേഗതയേറിയ കാർട്ടുകൾ, ട്രാഫിക്കുള്ളപ്പോൾ വളരെ കുറഞ്ഞ ഡാറ്റാബേസ് ലോഡ്.
ഒബ്ജക്റ്റ് കാഷെ പങ്കിട്ട ഒന്നല്ല, ഓരോ സൈറ്റിനും മാത്രമുള്ളതാണ്, ഇത് പ്രകടനത്തിനും ഐസൊലേഷനും ഒരുപോലെ പ്രാധാന്യമർഹിക്കുന്നു. ഓരോ സൈറ്റിനുമുള്ള ഡാറ്റാബേസ് ത്രോട്ടിലിംഗുമായി സംയോജിപ്പിച്ചിരിക്കുന്നതിനാൽ, ഒരു സൈറ്റിലെ ഭാരമേറിയതോ തെറ്റായി എഴുതിയതോ ആയ ക്വറികൾക്ക് മറ്റ് സൈറ്റുകളുടെ ഡാറ്റാബേസ് റിസോഴ്‌സുകളെ ഇല്ലാതാക്കാൻ കഴിയില്ല. ഈ മൾട്ടി-ലെയർ സജ്ജീകരണം എങ്ങനെ ഒരുമിച്ച് പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ച് ഞങ്ങളുടെ കാഷിംഗ് ഫീച്ചർ പേജിലും, ഐസൊലേഷന് കീഴിലുള്ള വാടകക്കാർ തമ്മിലുള്ള അതിരുകളെക്കുറിച്ച് കൂടുതൽ വായിക്കാവുന്നതുമാണ്.
എഡ്ജും അതിനടിയിലുള്ള ട്രാൻസ്പോർട്ടും
ഒറിജിനിൽ തന്നെയുള്ള കാഷെയ്ക്കും നെറ്റ്‌വർക്ക് വഴി കടന്നുപോകേണ്ടതുണ്ട്. സെർവറിന് മുന്നിൽ CDN എഡ്ജ് ഉള്ളതിനാൽ, സ്റ്റാറ്റിക് അസറ്റുകളും കാഷെ ചെയ്യാൻ കഴിയുന്ന പേജുകളും സന്ദർശകന് അടുത്തുള്ള ഒരു പോയിന്റ് ഓഫ് പ്രസൻസിൽ നിന്നാണ് നൽകുന്നത്, അതിനാൽ കൂടുതൽ ട്രാഫിക് ഉള്ളപ്പോഴും ഒറിജിൻ സെർവർ ശാന്തമായി തുടരുന്നു. ഞങ്ങളുടെ footprint-free ഹോസ്റ്റിംഗ് വിഭാഗത്തിന്, ഈ എഡ്ജ് എന്നത് ഒന്നിലധികം ദാതാക്കളിലായി വിതരണം ചെയ്തിട്ടുള്ള ഒരു മൾട്ടി-CDN പൂൾ ആണ്, ഇത് പെർഫോമൻസിനൊപ്പം തന്നെ footprint ലക്ഷ്യത്തെയും സഹായിക്കുന്നു; സാധാരണ WordPress-ൽ, ഇത് ഒറിജിനുകളെ വിശ്രമാവസ്ഥയിൽ നിലനിർത്തുന്ന വേഗതയേറിയതും മികച്ചതുമായ ഒരു ലെയർ മാത്രമാണ്.
അടിസ്ഥാന സൗകര്യങ്ങളിൽ യാതൊരു വിട്ടുവീഴ്ചയും ചെയ്തിട്ടില്ല. സൈറ്റുകൾ HTTP/3 സഹിതമുള്ള NVMe സ്റ്റോറേജിലാണ് പ്രവർത്തിക്കുന്നത്, അതിനാൽ കാഷെ അയയ്ക്കുന്ന ബൈറ്റുകൾ, ഏതൊരു കാഷെ മിസ്സിനും പിന്നിലുള്ള വേഗതയേറിയ സ്റ്റോറേജോടുകൂടിയ ആധുനിക മൾട്ടിപ്ലെക്സ്ഡ് ട്രാൻസ്പോർട്ട് വഴി എത്തിച്ചേരുന്നു. ഈ ലെയറുകളിലൊന്നും അധികമായി പണം നൽകേണ്ട ആഡ്-ഓണുകളല്ല: LiteSpeed, LSCache, ഓരോ സൈറ്റിനുമുള്ള Redis, NVMe, HTTP/3 എന്നിവ എല്ലാ പ്ലാനുകളിലും അടിസ്ഥാന സൗകര്യങ്ങളാണ്, അല്ലാതെ ഉയർന്ന നിരക്കിലുള്ള പ്ലാനുകൾ വിൽക്കാനുള്ള തന്ത്രമല്ല.
Core Web Vitals-നെ യഥാർത്ഥത്തിൽ സ്വാധീനിക്കുന്നത് എന്താണ്
കൃത്യത പുലർത്തുന്നത് പ്രധാനമാണ്, കാരണം ഹോസ്റ്റിംഗുകൾ പലപ്പോഴും Core Web Vitals-ന്റെ പേരിൽ അമിതമായി വാഴ്ത്തപ്പെടാറുണ്ട്. ഈ സമവാക്യത്തിൽ സെർവറിന്റെ നിയന്ത്രണത്തിലുള്ള ഭാഗമാണ് TTFB, മുകളിലുള്ള കാഷിംഗ് സ്റ്റാക്കാണ് ഇതിനെ ഏറ്റവും കുറഞ്ഞ നിലയിലേക്ക് എത്തിക്കുന്നത് — എഡ്ജിൽ നിന്ന് HTTP/3 വഴി നൽകുന്ന കാഷ് ചെയ്ത ഒരു സമ്പൂർണ്ണ പേജിലൂടെ TTFB പരമാവധി കുറയ്ക്കാൻ സാധിക്കും. TTFB എന്നത് Largest Contentful Paint-ന്റെ പ്രാരംഭ ഘട്ടമായതിനാൽ, വേഗതയേറിയ ഒരു ഒറിജിൻ മറ്റ് എല്ലാ ഡൗൺസ്ട്രീം മെട്രിക്കുകൾക്കും മറ്റൊരു തരത്തിലും ലഭിക്കാത്ത മികച്ചൊരു തുടക്കം നൽകുന്നു.
എന്നാൽ LCP, CLS, INP എന്നിവ പ്രധാനമായും ബ്രൗസറിൽ, പേജ് തന്നെയാണ് നിർണ്ണയിക്കുന്നത്: ഒപ്റ്റിമൈസ് ചെയ്യാത്ത ഹീറോ ഇമേജ്, റെൻഡർ-ബ്ലോക്കിംഗ് CSS, JavaScript, ഫോണ്ടുകളും പരസ്യങ്ങളും ലോഡുചെയ്യുമ്പോൾ മാറുന്ന ലേഔട്ട്, പ്ലഗിനുകളിൽ നിന്നുള്ള കനത്ത മെയിൻ-ത്രെഡ് പ്രവർത്തനം എന്നിവയാണവ. സെർവർ കാഷിംഗിന്റെ എത്ര അളവിനും 2 MB ഹീറോ ഇമേജിനെയോ മെഗാബൈറ്റ് കണക്കിന് JavaScript നൽകുന്ന ഒരു തീമിനെയോ പരിഹരിക്കാനാവില്ല. വിശ്വസനീയമായ ഹോസ്റ്റിംഗ് സെർവറിന്റെ പങ്കിനെ ഫലപ്രദമായി സൌജന്യവും സുസ്ഥിരവുമാക്കുന്നു, തുടർന്ന് ഫ്രണ്ട് എൻഡ് ഭാരം കുറഞ്ഞതായി നിലനിർത്തേണ്ടത് സൈറ്റിന്റെ ഉത്തരവാദിത്തമാണ്.
ജോലിയുടെ ആ വിഭജനം ഒരു ഉപയോഗപ്രദമായ മാനസിക മാതൃകയാണ്. അഭ്യർത്ഥന ബ്രൗസറിൽ വേഗത്തിൽ എത്തുമെന്നും ഉയർന്ന ട്രാഫിക്കിലും വേഗത നിലനിർത്തുമെന്നും ഞങ്ങൾ ഉറപ്പുനൽകുന്നു; നിങ്ങൾ പേലോഡ് ചെറുതും സുസ്ഥിരവുമായി സൂക്ഷിക്കുക. കാഷെ വാം-അപ്പ്, എഡ്ജ് ഡെലിവറി, ഡൈനാമിക് പേജുകൾ സ്തംഭിക്കാതിരിക്കാൻ ഡാറ്റാബേസ് പ്രതികരണശേഷിയോടെ നിലനിർത്തൽ എന്നിവ രണ്ടും സംഗമിക്കുന്ന ഇടമാണ് ഞങ്ങളുടെ സ്റ്റാക്ക് കൃത്യമായി ട്യൂൺ ചെയ്തിരിക്കുന്ന ഇടം, കൂടാതെ ഒരു സാധാരണ ഹോസ്റ്റിലെ അതേ സൈറ്റിനേക്കാൾ ഈ പ്ലാറ്റ്‌ഫോമിലെ മാനേജ്ഡ് WordPress-നെ കൂടുതൽ വേഗതയുള്ളതാക്കുന്നതും ഇതാണ്.
പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ
എനിക്ക് ഇപ്പോഴും WP Rocket പോലെയുള്ള ഒരു കാഷിംഗ് പ്ലഗിൻ ആവശ്യമുണ്ടോ?
അല്ല. ഫുൾ-പേജ് കാഷിംഗ് വെബ് സെർവറിൽ LiteSpeed-ന്റെ LSCache ആണ് കൈകാര്യം ചെയ്യുന്നത്, കൂടാതെ മുൻകൂട്ടി ഇൻസ്റ്റാൾ ചെയ്തതും സ്വയമേവ അപ്ഡേറ്റ് ചെയ്യപ്പെടുന്നതുമായ ഞങ്ങളുടെ സ്വന്തം കാഷെ പ്ലഗിൻ WordPress-നെ ഇതിലേക്ക് ശരിയായി ബന്ധിപ്പിക്കുന്നു, ഇതിന് പിന്നിൽ ഓരോ സൈറ്റിനുമുള്ള ഒരു Redis ഒബ്ജക്റ്റ് കാഷെയും ഉണ്ട്. ഇതിനുപുറമേ രണ്ടാമതൊരു ഫുൾ-പേജ് കാഷിംഗ് പ്ലഗിൻ കൂടി ഉപയോഗിക്കുന്നത് സഹായിക്കുന്നതിന് പകരം സാധാരണയായി സെർവർ-ലെവൽ കാഷെയുമായി പൊരുത്തക്കേടുകൾ ഉണ്ടാക്കുന്നു, അതിനാൽ ഇത് ആവശ്യമില്ലാത്തതും ശുപാർശ ചെയ്യാത്തതുമാണ്.
കാഷിംഗ് എന്റെ WooCommerce കാർട്ടിനെയോ ലോഗിൻ ചെയ്ത പേജുകളെയോ തകരാറിലാക്കുമോ?
അല്ല. Cart, checkout, my-account, കൂടാതെ ഏതെങ്കിലും nonce അല്ലെങ്കിൽ session പേജുകൾ സ്വതവേ കാഷെയിൽ നിന്ന് ഒഴിവാക്കപ്പെട്ടിരിക്കുന്നു, കൂടാതെ കാഷെ ചെയ്യപ്പെട്ട മറ്റ് പേജുകളിൽ കാർട്ട് ഫ്രാഗ്‌മെന്റും ആകെത്തുകയും തത്സമയമായി നിലനിർത്താൻ ESI സഹായിക്കുന്നു. സ്റ്റോർഫ്രണ്ട് കാഷെയിൽ നിന്ന് ലോഡ് ചെയ്യപ്പെടുമ്പോഴും ഉപഭോക്താക്കൾക്ക് എല്ലായ്പ്പോഴും അവരുടെ സ്വന്തം ബാസ്ക്കറ്റും ശരിയായി പ്രവർത്തിക്കുന്ന ചെക്ക്ഔട്ടും കാണാനാകും.
ഞാൻ പ്രസിദ്ധീകരിക്കുമ്പോഴോ എഡിറ്റ് ചെയ്യുമ്പോഴോ കാഷെ എങ്ങനെ പുതിയതായി നിലനിൽക്കും?
പ്രസക്തമായ WordPress ഹുക്കുകളിൽ സ്മാർട്ട് ഓട്ടോ-പർജ് പ്രവർത്തിക്കുന്നു, അതിനാൽ ഉള്ളടക്കം പ്രസിദ്ധീകരിക്കുകയോ എഡിറ്റ് ചെയ്യുകയോ അല്ലെങ്കിൽ ഒരു ഉൽപ്പന്നമോ വിലയോ ഓർഡറോ മാറ്റുകയോ ചെയ്യുമ്പോൾ ബാധിക്കപ്പെട്ട പേജുകളും അവയുടെ ആർക്കൈവുകളും മാത്രമേ ഒഴിവാക്കപ്പെടുകയുള്ളൂ — കാഷെ പൂർണ്ണമായുമല്ല — ഒപ്പം ഒരു ക്രോളർ അവയെ വീണ്ടും സജ്ജമാക്കുകയും ചെയ്യുന്നു. ഡാഷ്‌ബോർഡിൽ നിന്നോ WordPress-ന് ഉള്ളിൽ നിന്നോ ആവശ്യാനുസരണം നിങ്ങൾക്ക് കാഷെ പർജ് ചെയ്യാനും കഴിയും.
ഹോസ്റ്റിംഗിന് മാത്രമായി എനിക്ക് മികച്ച Core Web Vitals നൽകാൻ കഴിയുമോ?
ഇത് നിങ്ങൾക്ക് സാധ്യമായ ഏറ്റവും മികച്ച TTFB നൽകുന്നു, ഇത് സെർവറിന്റെ പങ്കും Largest Contentful Paint-നുള്ള ഒരു മികച്ച തുടക്കവുമാണ്. എന്നാൽ LCP, CLS, INP എന്നിവ പ്രധാനമായും തീരുമാനിക്കുന്നത് പേജ് തന്നെയാണ് — ചിത്രങ്ങളുടെ വലുപ്പങ്ങൾ, റെൻഡറിംഗ് തടസ്സപ്പെടുത്തുന്ന അസറ്റുകൾ, ലേഔട്ട് സ്ഥിരത, പ്രധാന ത്രെഡിലെ JavaScript എന്നിവയാണവ. ഞങ്ങളുടെ സ്റ്റാക്ക് സെർവറിന്റെ സംഭാവന വേഗതയേറിയതും സ്ഥിരതയുള്ളതുമാക്കുന്നു; ഫ്രണ്ട്-എൻഡ് പേലോഡ് ഭാരം കുറഞ്ഞതായി നിലനിർത്തുന്നതാണ് ബാക്കിയുള്ള വ്യത്യാസം നികത്തുന്നത്.
ബന്ധപ്പെട്ടവ
14 ദിവസത്തേക്ക് സൗജന്യമായി പരീക്ഷിക്കൂ
നിങ്ങളുടെ ആദ്യ സൈറ്റുകൾ 14 ദിവസത്തേക്ക് സൗജന്യമായി ആരംഭിക്കൂ — കാർഡ് ആവശ്യമില്ല. നിലവിലുള്ള നെറ്റ്‌വർക്ക് മാറ്റുകയാണോ? മൈഗ്രേഷനുകൾ പരിധികളില്ലാതെ സൗജന്യമാണ്.
സൗജന്യമായി ആരംഭിക്കുക