Core Web Vitals کے خراب اسکورز کو کیسے ٹھیک کروں؟

پہلے یہ معلوم کریں کہ کون سی میٹرک، کس ڈیوائس پر اور صفحات کے کس گروپ کے لیے ناکام ہو رہی ہے۔ Search Console کی Core Web Vitals رپورٹ حقیقی Chrome وزٹس کی بنیاد پر تینوں چیزیں دکھا دیتی ہے۔ اس کے بعد اس میٹرک کی اصل وجہ دور کریں: LCP کے لیے یہ دیکھیں کہ مرکزی تصویر یا متن کتنی جلدی پہنچتا ہے؛ INP کے لیے وہ طویل JavaScript ٹاسکس دیکھیں جو جواب میں تاخیر کرتے ہیں؛ اور CLS کے لیے وہ مواد دیکھیں جو بغیر جگہ مخصوص کیے ظاہر ہو جاتا ہے۔ فیلڈ ڈیٹا پچھلے 28 دن کا احاطہ کرتا ہے، اس لیے اصلاح کا نتیجہ ایک مہینے بعد جانچیں۔

مرحلہ 1: معلوم کریں کہ کیا ناکام ہو رہا ہے

1. Search Console میں Core Web Vitals رپورٹ کھولیں اور Mobile یا Desktop منتخب کریں؛ دونوں کی درجہ بندی الگ الگ ہوتی ہے۔
2. فہرست میں شامل کوئی مسئلہ کھولیں، مثلاً موبائل پر LCP کا مسئلہ، تاکہ متاثرہ URL گروپ اور مثالی URLs نظر آ جائیں۔ پورا گروپ ایک ہی اسٹیٹس شیئر کرتا ہے، جو اس کی بدترین میٹرک سے طے ہوتا ہے۔
3. کسی مثالی URL کو PageSpeed Insights میں چلائیں تاکہ اس صفحے کا فیلڈ ڈیٹا اور اس کے ساتھ ایک لیب ٹیسٹ نظر آئے جو ڈیبگنگ میں مدد دیتا ہے۔

Lighthouse جیسے لیب ٹولز INP ناپ نہیں سکتے کیونکہ ان میں کوئی صفحے کے ساتھ انٹرایکٹ نہیں کرتا، اس لیے وہ اس کی جگہ Total Blocking Time رپورٹ کرتے ہیں۔ INP کے لیے حقیقی صارفین کی پیمائش ہی قابلِ اعتماد رہنما ہے۔

سست LCP کو کیسے ٹھیک کریں

web.dev کی LCP آپٹیمائزیشن گائیڈ LCP کو چار حصوں میں تقسیم کرتی ہے: سرور کے جواب کا وقت، مرکزی ریسورس کے لوڈ ہونا شروع ہونے سے پہلے کی تاخیر، اس کے ڈاؤن لوڈ کا وقت، اور اس کے رینڈر ہونے سے پہلے کی تاخیر۔ سب سے بڑے حصے پر پہلے کام کریں:

• LCP تصویر کو ابتدائی HTML میں قابلِ دریافت بنائیں، اسے JavaScript یا CSS کے ذریعے شامل کرنے کے بجائے، اور اس پر fetchpriority="high" لگائیں۔
• LCP تصویر کو کبھی lazy-load نہ کریں۔
• اسے چھوٹا کر کے پیش کریں: درست سائز، جدید فارمیٹ، کمپریشن، اور وزیٹرز کے قریب CDN۔
• رینڈر کو روکنے والے ریسورسز ہٹائیں: چھوٹی اسٹائل شیٹس، <head> میں کوئی synchronous اسکرپٹ نہیں، اور مرکزی مواد کے لیے سرور سائیڈ رینڈرنگ۔
• سرور کا جواب تیز کریں: ری ڈائریکٹس کم کریں اور صفحات کو ایج پر کیش ہونے دیں۔

خراب INP کو کیسے ٹھیک کریں

INP آپٹیمائزیشن گائیڈ ہر انٹرایکشن کو input delay، processing time اور presentation delay میں تقسیم کرتی ہے:

• Input delay: صفحہ لوڈ ہوتے وقت چلنے والا JavaScript کم کریں، تاکہ جب کوئی ٹیپ کرے تو مین تھریڈ فارغ ہو۔
• Processing time: طویل ایونٹ ہینڈلرز کو چھوٹے ٹاسکس میں توڑیں اور مین تھریڈ کو وقفہ دیں؛ نظر آنے والی تبدیلی پہلے کریں اور باقی کام بعد پر ٹال دیں۔
• Presentation delay: DOM کو چھوٹا رکھیں، اسٹائلز تبدیل کرنے کے فوراً بعد انہیں پڑھ کر لے آؤٹ پر زور دینے سے بچیں، اور لمبے صفحات کے لیے content-visibility استعمال کریں۔

زیادہ CLS کو کیسے ٹھیک کریں

CLS آپٹیمائزیشن گائیڈ عام وجوہات اور ان کے حل بیان کرتی ہے:

• بغیر ڈائمینشنز کی تصاویر اور ویڈیوز: width اور height ایٹریبیوٹس شامل کریں، یا CSS کا aspect-ratio استعمال کریں۔
• اشتہارات، ایمبیڈز اور iframes: ان کے لوڈ ہونے سے پہلے لے آؤٹ میں ان کی جگہ مخصوص کر لیں۔
• موجودہ مواد کے اوپر شامل کیا جانے والا مواد: درست سائز کا پلیس ہولڈر استعمال کریں، یا نیا مواد اس حصے کے نیچے ڈالیں جسے وزیٹر پڑھ رہا ہے۔
• ویب فونٹس: اہم فونٹس کو پہلے سے لوڈ کریں تاکہ متن دیر سے دوبارہ نہ بہے۔
• اینیمیشنز: top یا left جیسی پراپرٹیز کے بجائے transform کو اینیمیٹ کریں۔

جو صفحات براؤزر کی back/forward cache استعمال کر سکتے ہیں، وہ وزیٹرز کے واپس آنے پر بھی لے آؤٹ شفٹس سے بچ جاتے ہیں۔

مرحلہ 3: اصلاح کی تصدیق کریں

اصلاح ڈیپلائے کریں، پھر Core Web Vitals رپورٹ میں وہ مسئلہ کھولیں اور validation شروع کریں۔ Google اس گروپ کو 28 دن تک مانیٹر کرتا ہے؛ validation نہ دوبارہ کرال کا سبب بنتی ہے اور نہ کسی چیز کو تیز کرتی ہے، یہ صرف دیکھتی ہے کہ مسئلہ ختم ہوا یا نہیں۔ چونکہ فیلڈ ڈیٹا 28 دن کی مدت پر چلتا ہے، اس لیے رپورٹ میں بہتری آہستہ آہستہ آنے کی توقع رکھیں۔ ہر میٹرک کا مطلب جاننے کے لیے LCP، INP اور CLS کا کیا مطلب ہے؟ دیکھیں۔

AutoPSEO کیسے مدد کرتا ہے

AutoPSEO کی Core Web Vitals رپورٹ آپ کی سائٹ یا کسی ایک URL کے لیے فون، ڈیسک ٹاپ یا ٹیبلٹ پر تقریباً چھ مہینے کا ہفتہ وار Chrome UX Report ڈیٹا چارٹ کی صورت میں دکھاتی ہے۔ یوں آپ اگلی 28 دن کی مدت مکمل ہونے کا انتظار کیے بغیر وہ ہفتہ دیکھ سکتے ہیں جس میں کسی اصلاح نے اثر دکھایا، یا وہ ہفتہ جس میں کسی ریلیز نے حالات خراب کیے۔