ഹോസ്റ്റിംഗും പെർഫോമൻസും

ഞങ്ങൾ എങ്ങിനെയാണ് WordPress വേഗത്തിലാക്കുന്നത്: LiteSpeed Enterprise, LSCache, ഒപ്പം ഓരോ സൈറ്റിനുമുള്ള Redis

ഏറ്റവും വേഗതയേറിയ WordPress അഭ്യർത്ഥന എന്നത് ഒരിക്കലും റൺ ചെയ്യാത്ത ഒന്നാണ് — PHP അല്ലെങ്കിൽ MySQL പ്രവർത്തനക്ഷമമാക്കുന്നതിന് മുൻപ് തന്നെ ഞങ്ങളുടെ സ്റ്റാക്ക് കാഷെയിൽ നിന്ന് ഭൂരിഭാഗം സന്ദർശനങ്ങളെയും എങ്ങനെ പ്രതിരോധിക്കുന്നു എന്നും, അത് Core Web Vitals-ന് എന്താണ് അർത്ഥമാക്കുന്നത് എന്നും ഇവിടെ വിശദീകരിക്കുന്നു.

Neil Lock രചിച്ചത് · 2026 ജൂലൈ 15 · ഉള്ളിൽ ഹോസ്റ്റിംഗും പ്രകടനവും

ഒരിക്കലും റൺ ചെയ്യാത്ത അഭ്യർത്ഥനയാണ് ഏറ്റവും വേഗതയേറിയ അഭ്യർത്ഥന

ഒരു സാധാരണ WordPress അഭ്യർത്ഥനയ്ക്ക് കൂടുതൽ ചെലവ് വരുന്നു. വെബ് സെർവർ PHP-ലേക്ക് കൈമാറുന്നു, PHP WordPress ബൂട്ട് ചെയ്യുന്നു, പ്ലഗിന്നുകൾ പ്രവർത്തിപ്പിക്കുന്നു, ഡസൻ കണക്കിന് തവണ MySQL-ൽ അന്വേഷിക്കുന്നു, HTML കൂട്ടിച്ചേർക്കുന്നു, അതിനുശേഷമാണ് ബൈറ്റുകൾ തിരികെ അയക്കുന്നത്. തിരക്കേറിയ ഒരു സൈറ്റിൽ ഓരോ സന്ദർശകനും ഈ പ്രക്രിയ മുഴുവൻ നടക്കുന്നു, അവിടെയാണ് നിങ്ങളുടെ സമയം-മുതൽ-ആദ്യ-ബൈറ്റ് ഏതാണ്ട് പൂർണ്ണമായും പോകുന്നത്.

ഞങ്ങളുടെ ഉത്തരം, മിക്ക സന്ദർശനങ്ങൾക്കും അതിൽ യാതൊന്നും സംഭവിക്കുന്നില്ലെന്ന് ഉറപ്പാക്കുക എന്നതാണ്. ഞങ്ങൾ ഹോസ്റ്റ് ചെയ്യുന്ന സൈറ്റുകളിലുടനീളം — 100,000-ത്തിലധികം PBN സൈറ്റുകളും മെയിൻസ്ട്രീം മാനേജഡ് WordPress ഉം ഉൾപ്പെടെ — ഫ്രണ്ട്-എൻഡ് പേജ് വ്യൂകളിൽ വലിയൊരു ഭൂരിഭാഗവും PHP വിളിക്കുകയോ ഡാറ്റാബേസിൽ തൊടുകയോ ചെയ്യാതെ, കാഷെയിൽ നിന്ന് നേരിട്ട് പ്രീ-റെൻഡർ ചെയ്ത മുഴുവൻ പേജ് ആയി നൽകപ്പെടുന്നു. ഈ പോസ്റ്റിന്റെ ബാക്കി ഭാഗം, അത് സാധ്യമാക്കുന്ന ലെയറുകൾ എങ്ങനെ ഒരുമിച്ച് പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ചും, ഓരോ ലെയറും അതിന്റെ പങ്ക് എവിടെയാണ് നിറവേറ്റുന്നത് എന്നതിനെക്കുറിച്ചും ഉള്ളതാണ്.

ഇവ തമ്മിൽ തിരഞ്ഞെടുക്കേണ്ട മത്സരിക്കുന്ന കാഷെകളല്ല എന്നതാണ് പ്രധാനപ്പെട്ട ആശയം. ഫുൾ-പേജ് കാഷെ, ഒബ്‌ജക്റ്റ് കാഷെ, സിഡിഎൻ എഡ്ജ് എന്നിവ ഓരോന്നും വ്യത്യസ്ത തരം റിക്വസ്റ്റുകളാണ് കൈകാര്യം ചെയ്യുന്നത്, ഇതിന്റെ യഥാർത്ഥ മൂല്യം ഇവ പരസ്പരം ചുമതലകൾ കൈമാറുന്ന രീതിയിലാണ് അടങ്ങിയിരിക്കുന്നത്.

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 ഓരോ അഭ്യർത്ഥനപ്രകാരവും കാർട്ട് ഫ്രാഗ്മെന്റ്, മിനി-കാർട്ട് മൊത്തം തുക, അക്കൗണ്ട് സ്റ്റേറ്റ് എന്നിവ റെൻഡർ ചെയ്യുന്നു. കാർട്ട്, ചെക്ക്ഔട്ട്, my-account, കൂടാതെ ഏതെങ്കിലും നോൺസ് അല്ലെങ്കിൽ സെഷൻ പേജുകൾ എന്നിവ സ്വയമേവ ഒഴിവാക്കപ്പെട്ടിരിക്കുന്നു. ഷോപ്പർമാർക്ക് എപ്പോഴും അവരുടെ സ്വന്തം ബാസ്കറ്റും പ്രവർത്തിക്കുന്ന ചെക്ക്ഔട്ടും കാണാൻ കഴിയും; എല്ലാവർക്കും സ്റ്റോർഫ്രണ്ട് കാഷെയിൽ നിന്ന് ലഭിക്കുകയും ചെയ്യും.

സ്മാർട്ട് ഓട്ടോ-പർജ് (auto-purge) വഴിയാണ് ഫ്രെഷ്‌നസ് കൈകാര്യം ചെയ്യുന്നത്. ഉള്ളടക്കം, ഉൽപ്പന്നങ്ങൾ, വിലകൾ അല്ലെങ്കിൽ ഓർഡറുകൾ എന്നിവ മാറുമ്പോൾ പർജ് ഹൂക്കുകൾ സ്വയം പ്രവർത്തിക്കും, അതിനാൽ പ്രസക്തമായ കാഷെ പേജുകൾ ഒരു ടൈമറിനേക്കാൾ വേഗത്തിൽ തൽക്ഷണം പുതുക്കപ്പെടുന്നു. കൂടാതെ ഡാഷ്‌ബോർഡിൽ നിന്നോ WordPress-നുള്ളിൽ നിന്നോ നിങ്ങൾക്ക് ആവശ്യാനുസരണം പർജ് ചെയ്യാനും കഴിയും. ടാഗ് അധിഷ്ഠിത പർജ് എന്നാൽ ഒരു പോസ്റ്റ് എഡിറ്റ് ചെയ്യുമ്പോൾ ആ പോസ്റ്റും അതിന്റെ ആർക്കൈവുകളും ക്ലിയർ ചെയ്യപ്പെടുന്നു - മുഴുവൻ കാഷെയും അല്ല - അതിനാൽ ഒരൊറ്റ എഡിറ്റിംഗ് കാരണം മുഴുവൻ സൈറ്റും കോൾഡ്-സ്റ്റാർട്ട് ആകുന്നില്ല.

ഓരോ സൈറ്റിനുമുള്ള Redis ഒബ്ജക്റ്റ് കാഷെ: മുഴുവൻ പേജാകാൻ കഴിയാത്തവയ്ക്ക്

എല്ലാ അഭ്യർത്ഥനകളും സ്റ്റാറ്റിക് ആയ പൂർണ്ണ പേജുകൾ ആകണമെന്നില്ല. ലോഗിൻ ചെയ്‌ത സെഷനുകൾ, WordPress അഡ്മിൻ, WooCommerce കാർട്ടുകൾ, തിരച്ചിൽ, ESI അവശേഷിപ്പിക്കുന്ന ഡൈനാമിക് ഫ്രാഗ്മെന്റുകൾ എന്നിവയ്‌ക്കെല്ലാം PHP പ്രവർത്തിക്കേണ്ടതുണ്ട്. അത്തരം സന്ദർഭങ്ങളിൽ, 'ആപ്ലിക്കേഷൻ ഒഴിവാക്കുക' എന്നതിൽ നിന്ന് 'ഡാറ്റാബേസ് ഒഴിവാക്കുക' എന്നതിലേക്ക് ലക്ഷ്യം മാറുന്നു.

ഓരോ സൈറ്റിനും അതിന്റേതായ പ്രത്യേക Redis ഒബ്ജക്റ്റ് കാഷെ ലഭിക്കുന്നു. ആവർത്തിച്ചുള്ള ഡാറ്റാബേസ് റീഡുകളുടെ ഫലങ്ങൾ — ഓപ്ഷനുകൾ, ട്രാൻസിയന്റുകൾ, പോസ്റ്റ്, ടേം ലുക്കപ്പുകൾ, WooCommerce ഉൽപ്പന്ന, സെഷൻ ഡാറ്റ എന്നിവ — WordPress മെമ്മറിയിൽ കാഷെ ചെയ്യുന്നു, അതിനാൽ ഓരോ ഹിറ്റിലും MySQL-ൽ അതേ ക്വറി പ്രവർത്തിക്കുന്നില്ല. ഫുൾ-പേജ് കാഷെക്ക് സഹായിക്കാൻ കഴിയാത്ത ഇടങ്ങളിലാണ് ഇതിന്റെ പ്രഭാവം ഏറ്റവും പ്രകടമാകുന്നത്: വേഗതയേറിയ ഡാഷ്‌ബോർഡുകൾ, വേഗതയേറിയ കാർട്ടുകൾ, ട്രാഫിക്കിൽ ഡാറ്റാബേസ് ലോഡ് വളരെ കുറയുന്നു.

ഒബ്ജക്റ്റ് കാഷെ ഓരോ സൈറ്റിനും പ്രത്യേകമായുള്ളതാണ്, ഇത് പങ്കിടപ്പെടുന്നില്ല. പെർഫോമൻസിനും ഐസൊലേഷനും ഇത് വളരെ പ്രധാനമാണ്. ഓരോ സൈറ്റിലെയും ഡാറ്റാബേസ് ത്രോട്ട്ലിങ്ങുമായി സംയോജിപ്പിച്ച്, ഒരു സൈറ്റിലെ ഭാരമേറിയതോ മോശമായി എഴുതപ്പെട്ടതോ ആയ ക്വറികൾക്ക് മറ്റ് സൈറ്റുകളുടെ ഡാറ്റാബേസ് ഉറവിടങ്ങളെ തടസ്സപ്പെടുത്താൻ കഴിയില്ല. ഞങ്ങളുടെ കാഷിംഗ് ഫീച്ചർ പേജിൽ ഈ മൾട്ടി-ലേയർ സജ്ജീകരണം എങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത് എന്നതിനെക്കുറിച്ചും, ഐസൊലേഷന് കീഴിലുള്ള വിവിധ ഉപയോക്താക്കൾ തമ്മിലുള്ള അതിരുകളെക്കുറിച്ചും നിങ്ങൾക്ക് കൂടുതൽ വായിക്കാവുന്നതാണ്.

എഡ്ജും അതിനു കീഴിലുള്ള ട്രാൻസ്‌പോർട്ടും

ഉത്ഭവസ്ഥാനത്ത് സൂക്ഷിക്കുന്ന കാഷ് നെറ്റ്‌വർക്ക് കടന്നുപോകേണ്ടതുണ്ട്. സെർവറിനു മുന്നിൽ CDN എഡ്ജ് സ്ഥിതി ചെയ്യുന്നു, അതിനാൽ സ്റ്റാറ്റിക് അസറ്റുകളും കാഷ് ചെയ്യാവുന്ന പേജുകളും സന്ദർശകന് അടുത്തുള്ള പോയിന്റ് ഓഫ് പ്രസൻസിൽ നിന്ന് നൽകപ്പെടുന്നു, കൂടാതെ ലോഡുള്ളപ്പോഴും ഉത്ഭവസ്ഥാനം പ്രവർത്തനരഹിതമായി തുടരുന്നു. ഞങ്ങളുടെ ഫുട്പ്രിന്റ്-ഫ്രീ ഹോസ്റ്റിംഗ് നിരയ്ക്കായി, ഒന്നിലധികം ദാതാക്കളിലായി വ്യാന്നുകിടക്കുന്ന ഒരു മൾട്ടി-CDN പൂളാണ് ഇതേ എഡ്ജ്, ഇത് പ്രകടന ലക്ഷ്യത്തിനൊപ്പം ഒരു ഫുട്പ്രിന്റ് ലക്ഷ്യവും നിറവേറ്റുന്നു; മെയിൻസ്ട്രീം 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 കാർട്ടോ ലോഗിൻ ചെയ്ത പേജുകളോ തകരാറിലാക്കുമോ?

ഇല്ല. കാർട്ട്, ചെക്ക്ഔട്ട്, മൈ-അക്കൗണ്ട്, ഏതെങ്കിലും നോൺസ് അല്ലെങ്കിൽ സെഷൻ പേജുകൾ എന്നിവ സ്വതവേ കാഷെയിൽ നിന്ന് ഒഴിവാക്കിയിരിക്കുന്നു. കൂടാതെ, കാഷെ ചെയ്‌ത മറ്റ് പേജുകളിൽ കാർട്ട് ഫ്രാഗ്മെന്റും ആകെ തുകയും തത്സമയം നിലനിർത്താൻ ESI സഹായിക്കുന്നു. സ്റ്റോർഫ്രണ്ട് കാഷെയിൽ നിന്ന് ലോഡ് ചെയ്യുമ്പോഴും ഷോപ്പർമാർക്ക് എപ്പോഴും അവരുടേതായ ബാസ്കറ്റും പ്രവർത്തനക്ഷമമായ ചെക്ക്ഔട്ടും കാണാൻ സാധിക്കും.

ഞാൻ പുതിയ പോസ്റ്റുകൾ പ്രസിദ്ധീകരിക്കുമ്പോഴോ എഡിറ്റുചെയ്യുമ്പോഴോ കാഷെ എങ്ങനെയാണ് പുതിയതായി നിലനിർത്തുന്നത്?

ബന്ധപ്പെട്ട WordPress ഹൂക്കുകളിൽ സ്മാർട്ട് ഓട്ടോ-പർജ് പ്രവർത്തിക്കുന്നു, അതിനാൽ ഉള്ളടക്കം പ്രസിദ്ധീകരിക്കുമ്പോഴോ എഡിറ്റ് ചെയ്യുമ്പോഴോ ഉൽപ്പന്നം, വില, ഓർഡർ എന്നിവ മാറ്റുമ്പോഴോ ബാധിക്കപ്പെട്ട പേജുകളും അവയുടെ ആർക്കൈവുകളും മാത്രമാണ് നീക്കം ചെയ്യപ്പെടുന്നത് — കാഷെ മുഴുവനായല്ല — കൂടാതെ ഒരു ക്രൗളർ അവ വീണ്ടും ചൂടാക്കുകയും ചെയ്യുന്നു. ഡാഷ്‌ബോർഡിൽ നിന്നോ WordPress-ൽ നിന്നോ നിങ്ങൾക്ക് ആവശ്യാനുസരണം പർജ് ചെയ്യാനും കഴിയും.

ഹോസ്റ്റിംഗ് മാത്രം ഉപയോഗിച്ചാൽ എനിക്ക് മികച്ച Core Web Vitals ലഭിക്കുമോ?

ഇത് നിങ്ങൾക്ക് ഏറ്റവും മികച്ച TTFB നൽകുന്നു, ഇത് സെർവറിന്റെ പങ്കും Largest Contentful Paint-നുള്ള ഒരു മുൻകൈയുമാണ്. എന്നാൽ LCP, CLS, INP എന്നിവ വലിയൊരു പങ്കും തീരുമാനിക്കുന്നത് പേജ് തന്നെയാണ് — ചിത്രങ്ങളുടെ വലുപ്പം, റെൻഡർ ബ്ലോക്ക് ചെയ്യുന്ന അസറ്റുകൾ, ലേഔട്ട് സ്ഥിരത, മെയിൻ-ത്രെഡ് ജാവസ്ക്രിപ്റ്റ് എന്നിവ. ഞങ്ങളുടെ സ്റ്റാക്ക് സെർവറിന്റെ സംഭാവന വേഗതയേറിയതും സ്ഥിരതയുള്ളതുമാക്കുന്നു; ഫ്രണ്ട്-എൻഡ് പേലോഡ് ചെറുതായി നിലനിർത്തുന്നതാണ് ബാക്കി വ്യത്യാസം പരിഹരിക്കുന്നത്.

ബന്ധപ്പെട്ടത്

14 ദിവസത്തേക്ക് സൗജന്യമായി പരീക്ഷിച്ചു നോക്കൂ

നിങ്ങളുടെ ആദ്യ സൈറ്റുകൾ 14 ദിവസത്തേക്ക് സൗജന്യമായി സമാരംഭിക്കുക — കാർഡ് ആവശ്യമില്ല. നിലവിലുള്ള ഒരു നെറ്റ്‌വർക്ക് മാറ്റുകയാണോ? നിങ്ങളുടെ ആദ്യ മൈഗ്രേഷൻ ഞങ്ങളുടെ വകയാണ്.

സൗജന്യമായി തുടങ്ങൂ