ഫീൽഡ് vs ലാബ് ഡാറ്റ: മിക്ക Core Web Vitals തർക്കങ്ങളും പരാജയപ്പെടുന്നത് എന്തുകൊണ്ട്
ആളുകൾ തെറ്റായ ഡാറ്റാസെറ്റുകൾ ഉപയോഗിക്കുന്നത് കൊണ്ടാണ് മിക്ക പെർഫോമൻസ് തർക്കങ്ങളും ഉണ്ടാകുന്നത്.
ഒരാൾ യഥാർത്ഥ ഉപയോക്താക്കളുടെ ഫലങ്ങൾ പരിശോധിക്കുന്നു. മറ്റൊരാൾ ഒരു ലാബ് സിമുലേഷൻ പരിശോധിക്കുന്നു. രണ്ടുപേരും ശരിയാണ്. രണ്ടുപേരും വ്യത്യസ്ത ചോദ്യങ്ങൾക്കാണ് ഉത്തരം നൽകുന്നത്.
നിങ്ങളുടെ ഡാറ്റാസെറ്റ് ഏതാണെന്ന് നിങ്ങൾക്ക് കൃത്യമായി പറയാൻ കഴിയുന്നില്ലെങ്കിൽ, നിങ്ങൾ പ്രശ്നം വിശകലനം ചെയ്യുകയല്ല, മറിച്ച് വെറുതെ തർക്കിക്കുകയാണ് ചെയ്യുന്നത്.
വ്യത്യാസം മനസ്സിലാക്കുക:
- ഫീൽഡ് ഡാറ്റ (Field data) യഥാർത്ഥ ഉപയോക്താക്കൾക്ക് വലിയ തോതിൽ പ്രശ്നങ്ങൾ നേരിടുന്നുണ്ടോ എന്ന് പറഞ്ഞുതരുന്നു. ഇതിൽ പതുക്കെയുള്ള ഫോണുകളും മോശം സെൽ സർവീസും ഉൾപ്പെടുന്നു.
- ലാബ് ഡാറ്റ (Lab data) അവർ എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു എന്ന് പറഞ്ഞുതരുന്നു. ഇത് നിയന്ത്രിതമായ ട്രേസുകളും (controlled traces) ആവർത്തിക്കാവുന്ന പരിശോധനകളും നൽകുന്നു.
LCP, INP, CLS തുടങ്ങിയ Core Web Vitals എന്നിവ ഔട്ട്കം മെട്രിക്സുകളാണ് (outcome metrics). എന്താണ് സംഭവിച്ചത് എന്ന് അവ പറഞ്ഞുതരുന്നു, എന്നാൽ എന്തുകൊണ്ട് സംഭവിച്ചു എന്ന് അല്ല.
ശരാശരികൾ (averages) ഉപയോഗിക്കുന്നത് നിർത്തുക. 75th percentile ഉപയോഗിക്കുക. ഒരു സൈറ്റ് നിങ്ങൾക്ക് വേഗതയുള്ളതായി തോന്നിയേക്കാം, എങ്കിലും അത് പരാജയപ്പെട്ടേക്കാം; കാരണം 75th percentile പതുക്കെയുള്ള നെറ്റ്വർക്കുകളെയും ദുർബലമായ ഉപകരണങ്ങളെയും കണക്കിലെടുക്കുന്നു.
പെർഫോമൻസ് പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ ഈ ക്രമം ഉപയോഗിക്കുക:
- ഫീൽഡ് ഡാറ്റ: പ്രശ്നം നിലവിലുണ്ടോ എന്ന് സ്ഥിരീകരിക്കുകയും അതിന്റെ വ്യാപ്തി കണ്ടെത്തുകയും ചെയ്യുക.
- ലാബ് ഡാറ്റ: നിങ്ങൾക്ക് പരിശോധിക്കാൻ കഴിയുന്ന ഒരു കാരണം വേർതിരിച്ചെടുക്കുക.
- ഫീൽഡ് ഡാറ്റ: നിങ്ങളുടെ യഥാർത്ഥ തെളിവുകൾ ഉപയോഗിച്ച് പരിഹാരം ശരിയാണോ എന്ന് പരിശോധിക്കുക.
നിങ്ങളുടെ വാദങ്ങൾ തെളിവുകളുമായി പൊരുത്തപ്പെടുത്തുക:
- ഉപയോക്താക്കൾക്ക് പ്രശ്നമുണ്ടെങ്കിൽ: Search Console ട്രെൻഡുകൾ പരിശോധിക്കുക.
- ഒരു ടെംപ്ലേറ്റ് ആണ് കാരണം എങ്കിൽ: സമാനമായ URL-കളിലെ പരാജയങ്ങൾ പരിശോധിക്കുക.
- സെർവർ കാരണം LCP പതുക്കെയാണെങ്കിൽ: വൈകിയ ഡോക്യുമെന്റ് റെസ്പോൺസുകൾ (late doc responses) കണ്ടെത്താൻ ലാബ് ട്രേസുകൾ ഉപയോഗിക്കുക.
- INP പരാജയപ്പെടുകയാണെങ്കിൽ: ലോങ്ങ് ടാസ്ക്കുകൾ (long tasks) കണ്ടെത്താൻ DevTools ഉപയോഗിക്കുക.
- ഒരു റിലീസ് കാരണം പെർഫോമൻസ് കുറഞ്ഞതാണെങ്കിൽ (regression): നിങ്ങളുടെ ഡിപ്ലോയ് ലോഗുകളുമായി (deploy logs) സമയക്രമം താരതമ്യം ചെയ്യുക.
ഒരു ഒറ്റ Lighthouse റൺ മാത്രം വിശ്വസിക്കരുത്. മൊബൈൽ പരാജയങ്ങൾ വിശദീകരിക്കാൻ ഡെസ്ക്ടോപ്പ് ടെസ്റ്റുകൾ ഉപയോഗിക്കരുത്. "ഇത് വേഗതയുള്ളതായി തോന്നുന്നു" എന്നത് ഒരു തെളിവായി ഉപയോഗിക്കരുത്.
ഈ ഘട്ടങ്ങൾ പിന്തുടരുക:
- നിങ്ങളുടെ ഡാറ്റാസെറ്റ് ഏതാണെന്ന് ഒരു വാചകത്തിൽ പറയുക.
- വ്യാപ്തി സ്ഥിരീകരിക്കുക. മറ്റൊന്ന് തെളിയിക്കുന്നത് വരെ ഇതൊരു ടെംപ്ലേറ്റ് പ്രശ്നമാണെന്ന് കരുതുക.
- തടസ്സം (constraint) ഏതാണെന്ന് തിരിച്ചറിയുക. അത് സെർവർ ആണോ, റെൻഡർ പാത്ത് (render path) ആണോ, അതോ ഒരു തേർഡ് പാർട്ടി ആണോ?
- നിങ്ങളുടെ സിദ്ധാന്തം തെറ്റാണെന്ന് തെളിയിക്കാൻ കഴിയുന്ന ഏറ്റവും ചെറിയ ടെസ്റ്റ് നടത്തുക.
തടസ്സം (bottleneck) കണ്ടെത്താൻ ലാബ് ഡാറ്റ ഉപയോഗിക്കുക. ആ തടസ്സം നീങ്ങി എന്ന് തെളിയിക്കാൻ ഫീൽഡ് ഡാറ്റ ഉപയോഗിക്കുക.