களத் தரவு vs ஆய்வகத் தரவு: பெரும்பாலான Core Web Vitals விவாதங்கள் ஏன் தோல்வியடைகின்றன?
பெரும்பாலான செயல்திறன் (performance) விவாதங்கள் தவறான தரவுத்தொகுப்புகளைப் (datasets) பயன்படுத்துவதால் ஏற்படுகின்றன.
ஒருவர் உண்மையான பயனர் முடிவுகளைப் பார்க்கிறார். மற்றொருவர் ஆய்வகச் சூழலை (lab simulation) பார்க்கிறார். இருவரும் சரிதான். இருவரும் வெவ்வேறு கேள்விகளுக்குப் பதிலளிக்கிறார்கள்.
உங்கள் தரவுத்தொகுப்பை உங்களால் சரியாகக் குறிப்பிட முடியாவிட்டால், நீங்கள் ஒரு பிரச்சனையைத் தீர்க்க முயலவில்லை; வெறும் விவாதம் மட்டுமே செய்கிறீர்கள்.
இந்த வேறுபாட்டைப் புரிந்துகொள்ளுங்கள்:
- களத் தரவு (Field data) என்பது உண்மையான பயனர்கள் பெரிய அளவில் (at scale) பாதிக்கப்படுகிறார்களா என்பதை உங்களுக்குத் தெரிவிக்கும். இதில் மெதுவான போன்கள் மற்றும் மோசமான செல்போன் சிக்னல் போன்றவையும் அடங்கும்.
- ஆய்வகத் தரவு (Lab data) அவர்கள் ஏன் பாதிக்கப்படுகிறார்கள் என்பதைத் தெரிவிக்கும். இது கட்டுப்படுத்தப்பட்ட தடயங்களையும் (controlled traces) மீண்டும் மீண்டும் செய்யக்கூடிய சோதனைகளையும் வழங்குகிறது.
LCP, INP மற்றும் CLS போன்ற Core Web Vitals என்பவை முடிவுகளைக் காட்டும் அளவீடுகள் (outcome metrics). அவை என்ன நடந்தது என்பதைத் தெரிவிக்கின்றனவே தவிர, ஏன் நடந்தது என்பதைத் தெரிவிக்கவில்லை.
சராசரியைப் (averages) பயன்படுத்துவதை நிறுத்துங்கள். 75th percentile-ஐப் பயன்படுத்துங்கள். ஒரு தளம் உங்களுக்கு வேகமாகத் தோன்றலாம், ஆனால் 75th percentile என்பது மெதுவான நெட்வொர்க்குகள் மற்றும் பலவீனமான சாதனங்களைக் கணக்கில் கொள்வதால், அந்தத் தளம் தோல்வியடையக்கூடும்.
செயல்திறன் சிக்கல்களைத் தீர்க்க இந்த வரிசையைப் பின்பற்றுங்கள்:
- களத் தரவு: பிரச்சனை இருப்பதை உறுதி செய்து அதன் அளவைக் கண்டறியவும்.
- ஆய்வகத் தரவு: உங்களால் சோதிக்கக்கூடிய ஒரு காரணத்தைத் தனிமைப்படுத்தவும்.
- களத் தரவு: உங்கள் ஆரம்பகால ஆதாரங்களைக் கொண்டு சரிசெய்தலை (fix) உறுதிப்படுத்தவும்.
உங்கள் வாதங்களை ஆதாரங்களுடன் ஒப்பிடுங்கள்:
- பயனர்கள் பாதிக்கப்படுகிறார்கள் என்றால்: Search Console போக்குகளைச் (trends) சரிபார்க்கவும்.
- ஒரு டெம்ப்ளேட் (template) காரணமாக இருந்தால்: ஒத்த URL-களில் உள்ள தோல்விகளைப் பார்க்கவும்.
- சர்வர் காரணமாக LCP மெதுவாக இருந்தால்: தாமதமான ஆவணப் பதில்களைக் (late doc responses) கண்டறிய ஆய்வகத் தடயங்களைப் பயன்படுத்தவும்.
- INP தோல்வியடைகிறது என்றால்: நீண்ட பணிகளைக் (long tasks) கண்டறிய DevTools-ஐப் பயன்படுத்தவும்.
- ஒரு புதிய வெளியீடு (release) பின்னடைவை (regression) ஏற்படுத்தியிருந்தால்: உங்கள் டெப்ளாய் பதிவுகளுடன் (deploy logs) நேரத்தைச் சரிபார்க்கவும்.
ஒரே ஒரு Lighthouse சோதனையை மட்டும் நம்பியிருக்க வேண்டாம். மொபைல் தோல்விகளை விளக்க டெஸ்க்டாப் சோதனைகளைப் பயன்படுத்த வேண்டாம். "இது வேகமாகத் தோன்றுகிறது" என்பதை ஆதாரமாகப் பயன்படுத்த வேண்டாம்.
இந்தப் படிகளைப் பின்பற்றுங்கள்:
- உங்கள் தரவுத்தொகுப்பை ஒரே வாக்கியத்தில் குறிப்பிடுங்கள்.
- அதன் அளவை உறுதிப்படுத்துங்கள். அது இல்லை என்று நிரூபிக்கும் வரை, அது ஒரு டெம்ப்ளேட் சிக்கல் என்று கருதுங்கள்.
- தடையைக் கண்டறியுங்கள். அது சர்வராவதா, ரெண்டர் பாதையா (render path) அல்லது மூன்றாம் தரப்புச் சேவையா?
- உங்கள் கோட்பாடு தவறானது என்பதை நிரூபிக்க முடிந்தவரை மிகச்சிறிய சோதனையைச் செய்யுங்கள்.
முட்டுக்கட்டையைக் (bottleneck) கண்டறிய ஆய்வகத் தரவைப் பயன்படுத்துங்கள். அந்த முட்டுக்கட்டை நீக்கப்பட்டுவிட்டது என்பதை நிரூபிக்க களத் தரவைப் பயன்படுத்துங்கள்.