വെബ്സൈറ്റ് വേഗത്തിലാക്കുന്നത് എങ്ങനെ: പ്രായോഗിക ചെക്ക്‌ലിസ്റ്റ്

വെബ്സൈറ്റ് വേഗത്തിലാക്കാൻ, ആദ്യം PageSpeed Insights ഉപയോഗിച്ച് അളക്കുക, പിന്നെ അത് ചൂണ്ടിക്കാണിക്കുന്ന ഏറ്റവും വലിയ കാരണം പരിഹരിക്കുക — സാധാരണയായി വലുപ്പം കൂടിയ ചിത്രങ്ങൾ, അധികമായ JavaScript, ഭാരമേറിയ ഫോണ്ടുകൾ അല്ലെങ്കിൽ മൂന്നാം കക്ഷി സ്ക്രിപ്റ്റുകൾ. Google-ന്റെ Core Web Vitals "നല്ലത്" ലക്ഷ്യങ്ങൾ ലക്ഷ്യമിടുക: പ്രധാന ഉള്ളടക്കം 2.5 സെക്കൻഡിനുള്ളിൽ ദൃശ്യമാകണം, ടാപ്പുകളോടുള്ള പ്രതികരണം 200 മില്ലിസെക്കൻഡിനുള്ളിൽ, പേജ് ചലിക്കുന്നത് ഏതാണ്ട് ഇല്ലാതെ. മിക്ക സൈറ്റുകളും കുറച്ച് മാറ്റങ്ങൾ കൊണ്ട് അവിടെ എത്തുന്നു, പുനരെഴുത്ത് വേണ്ടിവരുന്നില്ല.

മാറ്റം വരുത്തുന്നതിന് മുമ്പ് അളക്കുക

ഊഹിക്കുന്നത് സമയം പാഴാക്കുന്നു. മിക്കവരെയും രണ്ട് സൗജന്യ ടൂളുകൾ കവർ ചെയ്യുന്നു:

• PageSpeed Insights (pagespeed.web.dev) — ഒരു ലൈവ് URL ഒട്ടിക്കുക. യഥാർത്ഥ Chrome ഉപയോക്താക്കളിൽ നിന്നുള്ള ഫീൽഡ് ഡാറ്റ (നിങ്ങളുടെ സൈറ്റിന് മതിയായ ട്രാഫിക് ഉണ്ടെങ്കിൽ), സിമുലേറ്റഡ് ലോഡിൽ നിന്നുള്ള ലാബ് ഡാറ്റ, നിർദ്ദിഷ്ട പ്രശ്നങ്ങളുടെ പട്ടിക എന്നിവ കാണിക്കുന്നു.
• Lighthouse Chrome DevTools-ൽ — അതേ ലാബ് പരിശോധന, നിങ്ങൾക്ക് തുറക്കാൻ കഴിയുന്ന ഏത് പേജിലും, preview ഉൾപ്പെടെ. മൊബൈൽ മോഡിൽ പരീക്ഷിക്കുക; വേഗത കുറഞ്ഞ നെറ്റ്‌വർക്കുകളിലുള്ള ഫോണുകളിലാണ് പ്രശ്നങ്ങൾ വ്യക്തമാകുന്നത്.

പ്രധാനപ്പെട്ട സംഖ്യകൾ Google-ന്റെ Core Web Vitals ആണ്. 2026 സെപ്റ്റംബർ വരെ, web.dev-ലെ Google-ന്റെ ഡോക്യുമെന്റേഷൻ ഈ "നല്ലത്" പരിധികൾ നൽകുന്നു, പേജ് ലോഡുകളുടെ 75-ാം ശതമാനത്തിൽ അളന്നത്:

2024-ൽ INP പഴയ First Input Delay മെട്രിക്കിന് പകരമായി. ഒരു ടൂൾ ഇപ്പോഴും FID റിപ്പോർട്ട് ചെയ്യുന്നുവെങ്കിൽ, അത് കാലഹരണപ്പെട്ടതാണ്.

നിങ്ങളുടെ തുടക്ക സംഖ്യകൾ എഴുതി വയ്ക്കുക. ഓരോ പരിഹാരത്തിനും ശേഷം വീണ്ടും പരിശോധിക്കുക, എന്താണ് സഹായിച്ചതെന്ന് അറിയാൻ.

സമയം എവിടെ പോകുന്നു: ഓപ്ഷനുകളും ട്രേഡ്-ഓഫുകളും

ഓരോ സാധാരണ കാരണത്തിനും ഒരു പരിഹാരമുണ്ട്, ഓരോ പരിഹാരത്തിനും ഒരു വിലയുണ്ട്. മുകളിലുള്ളവയിൽ നിന്ന് തുടങ്ങുക — അവ ഏറ്റവും വിലകുറഞ്ഞതും ഏറ്റവും സാധാരണവുമാണ്.

ചിത്രങ്ങൾ

ചിത്രങ്ങളാണ് ഏറ്റവും സാധാരണമായ പ്രശ്നവും ശരിയാക്കാൻ ഏറ്റവും എളുപ്പമുള്ളതും. 800 പിക്സൽ വീതിയിൽ കാണിക്കുന്ന 4,000 പിക്സൽ ഫോട്ടോ, കാണുന്നതിന്റെ അഞ്ചിരട്ടി ഓരോ സന്ദർശകനും ഡൗൺലോഡ് ചെയ്യാൻ നിർബന്ധിക്കുന്നു.

• ചിത്രങ്ങൾ പ്രദർശിപ്പിക്കുന്ന വലുപ്പത്തിൽ നൽകുക, ഫോണുകൾക്കും ഡെസ്ക്ടോപ്പുകൾക്കും പ്രതികരണാത്മക srcset വലുപ്പങ്ങളോടെ.
• ആധുനിക ഫോർമാറ്റുകൾ (WebP അല്ലെങ്കിൽ AVIF) യുക്തിസഹമായ കംപ്രഷനോടെ ഉപയോഗിക്കുക.
• ബ്രൗസർ സ്ഥലം കരുതാൻ ഓരോ ചിത്രത്തിലും width, height സെറ്റ് ചെയ്യുക. ഇത് മാത്രം ലേഔട്ട് മാറ്റത്തിന്റെ മിക്ക പ്രശ്നങ്ങളും പരിഹരിക്കുന്നു.
• ഫോൾഡിന് താഴെയുള്ള ചിത്രങ്ങൾ loading="lazy" ഉപയോഗിച്ച് ലേസി-ലോഡ് ചെയ്യുക.
• പേജിന്റെ മുകളിലുള്ള പ്രധാന ചിത്രം ലേസി-ലോഡ് ചെയ്യരുത്. ഇതിൽ Google-ന്റെ LCP മാർഗ്ഗനിർദ്ദേശം വ്യക്തമാണ്: LCP ചിത്രം ലേസി-ലോഡ് ചെയ്യുന്നത് അതിനെ എപ്പോഴും വൈകിക്കുന്നു. പകരം fetchpriority="high" നൽകുക.

JavaScript

AI നിർമ്മിച്ച പല സൈറ്റുകളും സിംഗിൾ-പേജ് ആപ്പുകൾ (SPA) ആണ്: ബ്രൗസർ ഒരു JavaScript ബണ്ടിൽ ഡൗൺലോഡ് ചെയ്ത് പിന്നെ പേജ് വരയ്ക്കുന്നു. ബണ്ടിൽ വലുതാകുന്തോറും ശൂന്യമായ സ്‌ക്രീൻ കൂടുതൽ നേരം നിൽക്കുന്നു. പരിശ്രമത്തിന്റെ ക്രമത്തിൽ പരിഹാരങ്ങൾ:

1. ഉപയോഗിക്കാത്തത് നീക്കം ചെയ്യുക. ഡിപെൻഡൻസികളുടെ പട്ടിക ആവശ്യപ്പെടുക, ഒരിക്കൽ ചേർത്ത് മറന്നുപോയ ലൈബ്രറികൾ വെട്ടിക്കളയുക — ഒരു തീയതിക്ക് ഒരു തീയതി ലൈബ്രറി, അഞ്ച് ഐക്കണുകൾക്ക് ഒരു മുഴുവൻ ഐക്കൺ പാക്ക്.
2. റൂട്ട് അനുസരിച്ച് വിഭജിക്കുക. ആരെങ്കിലും തുറക്കുമ്പോൾ മാത്രം അഡ്മിൻ ഡാഷ്‌ബോർഡിന്റെ കോഡ് ലോഡ് ചെയ്യുക, ഹോം പേജിൽ അല്ല.
3. പൊതു പേജുകൾ പ്രീറെൻഡർ ചെയ്യുക. യഥാർത്ഥ HTML ആയി അയക്കുന്ന ഒരു മാർക്കറ്റിംഗ് പേജ് ഏതെങ്കിലും JavaScript പ്രവർത്തിക്കുന്നതിന് മുമ്പ് ദൃശ്യമാകുന്നു. ഇത് സെർച്ച് എഞ്ചിനുകളെയും സഹായിക്കുന്നു; AI-നിർമ്മിത വെബ്സൈറ്റുകൾക്കുള്ള SEO കാണുക.

മന്ദഗതിയിലുള്ള INP സാധാരണയായി അർത്ഥമാക്കുന്നത് ഒരൊറ്റ നീണ്ട ടാസ്ക് പേജിനെ തടയുന്നു എന്നാണ് — ഓരോ കീസ്ട്രോക്കിലും ഒരു വലിയ ലിസ്റ്റ് ഫിൽട്ടർ ചെയ്യുന്നത്, അല്ലെങ്കിൽ ഒരു സെൽ മാറുമ്പോൾ മുഴുവൻ ടേബിളും വീണ്ടും റെൻഡർ ചെയ്യുന്നത്. Chrome DevTools-ലെ Performance പാനൽ ഏതാണെന്ന് കാണിക്കുന്നു.

ഫോണ്ടുകൾ

ഓരോ ഫോണ്ട് കുടുംബവും വെയ്റ്റും മറ്റൊരു ഫയലാണ്. രണ്ട് കുടുംബങ്ങളും മൂന്നോ നാലോ വെയ്റ്റുകളും സാധാരണയായി മതി. ഫോൾഡിന് മുകളിൽ ഉപയോഗിക്കുന്ന ഫോണ്ട് പ്രീലോഡ് ചെയ്യുക, ടെക്സ്റ്റ് ഉടൻ കാണാൻ font-display: swap ഉപയോഗിക്കുക, ബാഹ്യ ഫോണ്ട് സേവനം നിങ്ങളുടെ സന്ദർശകർക്ക് സാവധാനമാണെങ്കിൽ ഫോണ്ടുകൾ സ്വയം ഹോസ്റ്റ് ചെയ്യുക.

മൂന്നാം കക്ഷി സ്ക്രിപ്റ്റുകൾ

ചാറ്റ് വിജറ്റുകൾ, അനലിറ്റിക്സ്, ഹീറ്റ്മാപ്പുകൾ, പരസ്യ പിക്സലുകൾ, എംബെഡ് ചെയ്ത വീഡിയോകൾ, സോഷ്യൽ ഫീഡുകൾ എന്നിവയെല്ലാം മറ്റ് സെർവറുകളിൽ നിന്ന് കോഡ് ലോഡ് ചെയ്യുന്നു. ഓരോന്നും ചെറുതായി തോന്നാം; ഒരുമിച്ച് അവയാണ് പലപ്പോഴും പേജിലെ ഏറ്റവും മന്ദഗതിയിലുള്ള ഭാഗം. നിങ്ങൾ യഥാർത്ഥത്തിൽ നോക്കുന്നവ നിലനിർത്തുക. ബാക്കിയുള്ളവ പേജ് ഇന്ററാക്ടീവ് ആയതിന് ശേഷം ലോഡ് ചെയ്യുക, ഭാരമേറിയ എംബെഡുകൾ (YouTube പ്ലെയർ, മാപ്പ്) ക്ലിക്കിൽ യഥാർത്ഥത്തെ ലോഡ് ചെയ്യുന്ന ഭാരം കുറഞ്ഞ പ്രിവ്യൂ കൊണ്ട് മാറ്റുക.

സെർവർ പ്രതികരണം

Time to first byte (TTFB) — സെർവർ ഉത്തരം തുടങ്ങാൻ എത്ര സമയമെടുക്കുന്നു — മറ്റെല്ലാ മെട്രിക്കുകൾക്കും അടിസ്ഥാനമാണ്. നിങ്ങളുടെ സന്ദർശകർക്ക് അടുത്തുള്ള സെർവറുകളുടെ ശൃംഖലയായ CDN വഴി നൽകുന്ന സ്റ്റാറ്റിക് പേജുകൾ ഏതാണ്ട് എല്ലായിടത്തും വേഗമുള്ളതാണ് (see what is a CDN). ഓരോ അഭ്യർത്ഥനയിലും സെർവറും അതിന്റെ ഡാറ്റാബേസും ആശ്രയിക്കുന്ന പേജുകൾ അങ്ങനെയാണ്. ആവർത്തിച്ചുള്ള ജോലി കാഷ് ചെയ്യുന്നതും മന്ദഗതിയിലുള്ള ക്വറികൾക്ക് ഡാറ്റാബേസ് ഇൻഡെക്സുകൾ ചേർക്കുന്നതും സാധാരണ പരിഹാരങ്ങളാണ്.

പ്രവർത്തിക്കുന്ന പ്രോംപ്റ്റുകൾ

കൃത്യമായിരിക്കുക: പേജ്, മെട്രിക്, നിയന്ത്രണം എന്നിവ പേര് പറയുക. കയ്യിലുണ്ടെങ്കിൽ PageSpeed Insights കണ്ടെത്തലുകൾ ഒട്ടിക്കുക.

PageSpeed Insights മൊബൈലിൽ ഹോം പേജിന് 4.8 സെക്കൻഡ് LCP റിപ്പോർട്ട് ചെയ്യുന്നു, LCP ഘടകം ഹീറോ ചിത്രമാണ്. ഹീറോ ചിത്രം WebP-യിലേക്ക് മാറ്റി വലുപ്പം ക്രമീകരിക്കുക, പ്രതികരണാത്മക വലുപ്പങ്ങൾ നൽകുക, width, height സെറ്റ് ചെയ്യുക, fetchpriority="high" നൽകുകയും ലേസി-ലോഡ് ചെയ്യാതിരിക്കുകയും ചെയ്യുക. ഫോൾഡിന് താഴെയുള്ള എല്ലാ ചിത്രങ്ങളും ലേസി-ലോഡ് ചെയ്യുക. ഡിസൈൻ മാറ്റരുത്.

ഈ ആപ്പിന്റെ ഡിപെൻഡൻസികൾ ഓഡിറ്റ് ചെയ്യുക. ഓരോ പാക്കേജും, അത് ഉപയോഗിക്കുന്നത് എന്ത്, ബണ്ടിലിൽ ഏകദേശം എത്ര ചേർക്കുന്നു എന്നും പട്ടികപ്പെടുത്തുക. ഉപയോഗിക്കാത്തവ നീക്കം ചെയ്ത് /admin, /settings റൂട്ടുകൾ സന്ദർശിക്കുമ്പോൾ മാത്രം ലോഡ് ആകുന്ന പ്രത്യേക ചങ്കുകളായി വിഭജിക്കുക.

/products-ലെ തിരയൽ ബോക്സ് മന്ദഗതിയിലാണെന്ന് തോന്നുന്നു. ഫിൽട്ടർ ഡിബൗൺസ് ചെയ്യുക, ഓരോ കീസ്ട്രോക്കിലും ഫുൾ ലിസ്റ്റ് വീണ്ടും റെൻഡർ ചെയ്യുന്നത് ഒഴിവാക്കുക, ലിസ്റ്റിൽ 200-ലധികം ഇനങ്ങളുണ്ടെങ്കിൽ പേജിനേറ്റ് ചെയ്യുകയോ വെർച്വലൈസ് ചെയ്യുകയോ ചെയ്യുക.

ഘട്ടം ഘട്ടമായി

1. ലൈവ് പേജ് പരിശോധിക്കുക മൊബൈലിൽ PageSpeed Insights-ൽ. LCP, INP, CLS, അവ ലിസ്റ്റ് ചെയ്ത ആദ്യ മൂന്ന് പ്രശ്നങ്ങൾ എന്നിവ കുറിച്ചെടുക്കുക.
2. ആദ്യം ചിത്രങ്ങൾ ശരിയാക്കുക: വലുപ്പങ്ങൾ, ഫോർമാറ്റുകൾ, അളവുകൾ, ഫോൾഡിന് താഴെ ലേസി ലോഡിംഗ്, ഹീറോയ്ക്ക് മുൻഗണന.
3. ഉപയോഗിക്കാത്ത മൂന്നാം കക്ഷി സ്ക്രിപ്റ്റുകൾ വെട്ടിക്കളയുക, ബാക്കിയുള്ളവ വൈകിക്കുക.
4. ഫോണ്ടുകൾ ഡിസൈനിന് ആവശ്യമുള്ളതിലേക്ക് ചുരുക്കുക.
5. JavaScript ചുരുക്കുക: ഉപയോഗിക്കാത്ത പാക്കേജുകൾ നീക്കം ചെയ്യുക, റൂട്ട് അനുസരിച്ച് വിഭജിക്കുക.
6. പൊതു പേജുകൾ പ്രീറെൻഡർ ചെയ്യുക, അവ ഇപ്പോഴും ക്ലയന്റ്-സൈഡിൽ റെൻഡർ ചെയ്യുകയും LCP ഇപ്പോഴും മന്ദഗതിയിലുമാണെങ്കിൽ.
7. സെർവർ പരിശോധിക്കുക: കാഷിംഗ്, ഡാറ്റാബേസ് ഇൻഡെക്സുകൾ, അപൂർവ്വമായി മാറുന്ന ഉള്ളടക്കത്തിന് സ്റ്റാറ്റിക് ഹോസ്റ്റിംഗ്.
8. വീണ്ടും പ്രസിദ്ധീകരിച്ച് വീണ്ടും പരിശോധിക്കുക. യഥാർത്ഥ സന്ദർശനങ്ങൾ വരുന്നതനുസരിച്ച് PageSpeed Insights-ലെ ഫീൽഡ് ഡാറ്റ വരുന്ന ആഴ്ചകളിൽ അപ്‌ഡേറ്റ് ചെയ്യുന്നു, അതിനാൽ ആദ്യകാല ഫലങ്ങൾ ലാബ് ഡാറ്റ വച്ച് വിലയിരുത്തുക.

സാധാരണ തെറ്റുകൾ

• വേഗമേറിയ ലാപ്‌ടോപ്പിൽ മാത്രം പരിശോധിക്കുന്നത്. നിങ്ങളുടെ സന്ദർശകർ ഇടത്തരം ഫോണുകളിലും അസ്ഥിരമായ മൊബൈൽ ഡേറ്റയിലുമാണ്. മൊബൈൽ മോഡിൽ പരീക്ഷിക്കുക.
• തികഞ്ഞ 100-നെ പിന്തുടരുന്നത്. ലാബ് സ്കോർ ഒരു മാർഗ്ഗനിർദ്ദേശമാണ്. Core Web Vitals നല്ല പരിധിയിൽ എത്തിക്കഴിഞ്ഞാൽ, ഉള്ളടക്കവും ഉപയോഗക്ഷമതയും അവസാന കുറച്ച് പോയിന്റുകളെക്കാൾ പ്രധാനമാണ്.
• എല്ലാം ലേസി-ലോഡ് ചെയ്യുന്നത്, ഹീറോ ചിത്രം ഉൾപ്പെടെ. അത് LCP-യെ മോശമാക്കുന്നു.
• മുകളിൽ ഒരു സ്പീഡ് പ്ലഗിനോ ലൈബ്രറിയോ ചേർക്കുന്നത്. ഭാരം നീക്കം ചെയ്യുന്നത് എപ്പോഴും അതിനെ നിയന്ത്രിക്കാൻ കൂടുതൽ കോഡ് ചേർക്കുന്നതിനെക്കാൾ മികച്ചതാണ്.
• ലൈവ് സൈറ്റിന് പകരം പ്രിവ്യൂ ഒപ്റ്റിമൈസ് ചെയ്യുന്നത്. ഡെവലപ്പ്മെന്റ് പ്രിവ്യൂകൾ ഒപ്റ്റിമൈസ് ചെയ്യാത്ത ബിൽഡുകൾ പ്രവർത്തിപ്പിക്കുന്നു. പ്രസിദ്ധീകരിച്ച URL അളക്കുക.
• വേഗത ഒരിക്കൽ മാത്രം ശരിയാക്കുന്നത്. ഓരോ പുതിയ വിജറ്റും ചിത്രവും ഫീച്ചറും ഭാരം കൂട്ടുന്നു. വലിയ മാറ്റങ്ങൾക്ക് ശേഷം വീണ്ടും പരിശോധിക്കുക.

വേഗത ചെക്ക്‌ലിസ്റ്റ്

• മൊബൈലിൽ LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1
• ചിത്രങ്ങൾ വലുപ്പം ക്രമീകരിച്ചു, കംപ്രസ് ചെയ്തു, ആധുനിക ഫോർമാറ്റ്, width, height ഉള്ളത്
• ഹീറോ ചിത്രം ലേസി-ലോഡ് ചെയ്തിട്ടില്ല; ഫോൾഡിന് താഴെയുള്ളവ ലേസി-ലോഡ് ചെയ്തിട്ടുണ്ട്
• ഉപയോഗിക്കാത്ത JavaScript ലൈബ്രറികളില്ല; ഭാരമേറിയ റൂട്ടുകൾ വേർതിരിച്ചിരിക്കുന്നു
• രണ്ട് ഫോണ്ട് കുടുംബങ്ങളോ അതിൽ കുറവോ, പ്രധാന ഫോണ്ട് പ്രീലോഡ് ചെയ്തത്
• നിങ്ങൾ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന മൂന്നാം കക്ഷി സ്ക്രിപ്റ്റുകൾ മാത്രം, വൈകി ലോഡ് ചെയ്തത്
• പൊതു പേജുകൾ പ്രീറെൻഡർ ചെയ്തതോ സാധ്യമാകുന്നിടത്ത് സ്റ്റാറ്റിക്കോ ആണ്
• പ്രസിദ്ധീകരിച്ച ശേഷം ലൈവ് URL-ൽ വീണ്ടും പരിശോധിച്ചു

വേഗതയും മൊബൈൽ ലേഔട്ടും ഒരുമിച്ച് പോകുന്നു; വെബ്സൈറ്റ് മൊബൈൽ പ്രതികരണാത്മകമാക്കുന്ന വിധം കാണുക. ലോഞ്ചിന് മുമ്പുള്ള പൂർണ്ണ പരിശോധനയ്ക്ക്, AI പ്രോട്ടോടൈപ്പ് പ്രൊഡക്ഷനിലേക്ക് എടുക്കുന്ന വിധം ബാക്കിയുള്ളത് ഉൾക്കൊള്ളുന്നു.

Mythex-ൽ വേഗത

Mythex-ൽ ഈ മാറ്റങ്ങൾ നിങ്ങൾ ചാറ്റിൽ ആവശ്യപ്പെട്ടോ, Pro-യിൽ കോഡ് എഡിറ്ററിൽ ചെയ്തോ വരുത്തുന്നു. Preview ഒരു ഡെവലപ്പ്മെന്റ് സെർവർ പ്രവർത്തിപ്പിക്കുന്നതിനാൽ, Preview അല്ല, പ്രസിദ്ധീകരിച്ച URL പരിശോധിക്കുക. നിങ്ങൾ പ്രസിദ്ധീകരിക്കുമ്പോൾ സ്റ്റാറ്റിക് ഫ്രണ്ട് എൻഡുകൾ സ്റ്റാറ്റിക് സൈറ്റുകളായി ഡിപ്ലോയ് ചെയ്യപ്പെടുന്നു (static websites), ഇത് ഉള്ളടക്ക പേജുകൾക്ക് യോജിക്കുന്നു. സെർവറുള്ള ആപ്പുകൾ സീറോയിലേക്ക് സ്കെയിൽ ചെയ്യുന്നു: നിഷ്ക്രിയമാകുമ്പോൾ ഉറങ്ങുകയും അടുത്ത സന്ദർശനത്തിൽ ഉണരുകയും ചെയ്യുന്നു, അതിനാൽ നിശ്ചലമായ ഇടവേളയ്ക്ക് ശേഷമുള്ള ആദ്യ അഭ്യർത്ഥന മന്ദഗതിയിലാണ്, ഘടിപ്പിച്ച ഡാറ്റാബേസ് 5 മിനിറ്റ് നിഷ്ക്രിയത്വത്തിന് ശേഷം ഉറങ്ങുന്നു (hosting limits). ഒരു പൊതു പേജ് ആദ്യ സന്ദർശനത്തിൽ മാത്രം മന്ദഗതിയിലാണെങ്കിൽ, അതാണ് സാധ്യതയുള്ള കാരണം. മാർക്കറ്റിംഗ് പേജുകൾ സ്റ്റാറ്റിക് ആയി സൂക്ഷിക്കുന്നത് സഹായിക്കുന്നു. മാറ്റങ്ങൾക്ക് ശേഷം വീണ്ടും പ്രസിദ്ധീകരിച്ച് ഹാർഡ്-റിഫ്രഷ് ചെയ്യുക.

ചോദ്യങ്ങൾ