LCP، INP اور CLS کا کیا مطلب ہے؟

یہ تین Core Web Vitals ہیں جنہیں Google کسی صفحے کے صارف تجربے کو بیان کرنے کے لیے استعمال کرتا ہے۔ Largest Contentful Paint (LCP) لوڈنگ کو ناپتا ہے، یعنی مرکزی مواد ظاہر ہونے میں کتنا وقت لگتا ہے۔ Interaction to Next Paint (INP) ردعمل کی رفتار کو ناپتا ہے، یعنی کلک کرنے، ٹیپ کرنے یا ٹائپ کرنے پر صفحہ کتنی جلدی جواب دیتا ہے۔ Cumulative Layout Shift (CLS) بصری استحکام کو ناپتا ہے، یعنی لے آؤٹ کتنا ادھر اُدھر کھسکتا ہے۔ اچھی قدروں کا مطلب ہے: LCP 2.5 سیکنڈ کے اندر، INP 200 ملی سیکنڈ کے اندر اور CLS 0.1 یا اس سے کم۔

تینوں میٹرکس ایک نظر میں

یہ حدیں Google کی Core Web Vitals رپورٹ کی ہیلپ میں دی گئی ہیں۔ کوئی صفحہ اس وقت پاس ہوتا ہے جب تینوں میٹرکس وزٹس کے 75ویں پرسنٹائل پر اچھے ہوں، اور یہ پیمائش موبائل اور ڈیسک ٹاپ کے لیے الگ الگ کی جاتی ہے۔

LCP: Largest Contentful Paint

LCP وہ وقت ہے جو صفحہ لوڈ ہونا شروع ہونے سے لے کر نظر آنے والے حصے کی سب سے بڑی تصویر، ویڈیو یا متن کے بلاک کے رینڈر ہونے تک لگتا ہے۔ اہل عناصر میں <img> عناصر، SVG کے اندر موجود تصاویر، ویڈیو کا پوسٹر یا پہلا فریم، CSS بیک گراؤنڈ تصاویر اور بلاک لیول متن شامل ہیں۔ وزیٹر کے صفحے کے ساتھ تعامل کرتے ہی براؤزر نئے امیدوار تلاش کرنا بند کر دیتا ہے۔ سست LCP عموماً سرور کے سست جواب، بڑی یا دیر سے دریافت ہونے والی ہیرو تصویر، یا رینڈرنگ کو روکنے والی CSS اور اسکرپٹس کی وجہ سے ہوتا ہے۔

INP: Interaction to Next Paint

INP وزٹ کے دوران ہونے والے کلکس، ٹیپس اور کی پریس کو دیکھتا ہے اور ناپتا ہے کہ ہر ایک کے بعد براؤزر کو اگلا فریم پینٹ کرنے میں کتنا وقت لگتا ہے۔ ہوور کرنا، اسکرول کرنا اور زوم کرنا شمار نہیں ہوتے۔ رپورٹ کی جانے والی قدر سب سے سست تعامل کی ہوتی ہے، البتہ زیادہ تعاملات والے صفحات پر غیر معمولی قدروں کو نظر انداز کر دیا جاتا ہے۔ INP نے مارچ 2024 میں First Input Delay (FID) کی جگہ Core Web Vital کا درجہ حاصل کیا؛ FID صرف پہلے تعامل کو دیکھتا تھا، جبکہ INP پورے وزٹ کا احاطہ کرتا ہے۔ خراب INP عموماً JavaScript کے طویل ٹاسکس کی وجہ سے ہوتا ہے جو مین تھریڈ کو مصروف رکھتے ہیں۔

CLS: Cumulative Layout Shift

CLS غیر متوقع لے آؤٹ شفٹس کو جمع کرتا ہے، مثلاً جب اوپر کوئی تصویر یا اشتہار لوڈ ہونے سے متن نیچے کھسک جائے، اور وزٹ کے دوران ایسے شفٹس کا سب سے بڑا مجموعہ رپورٹ کرتا ہے۔ ہر شفٹ کو اس بنیاد پر اسکور کیا جاتا ہے کہ اسکرین کا کتنا حصہ اور کتنے فاصلے تک کھسکا۔ کلک، ٹیپ یا کی پریس کے 500 ملی سیکنڈ کے اندر ہونے والے شفٹس شمار نہیں کیے جاتے، کیونکہ اس وقت وزیٹر صفحے کے بدلنے کی توقع رکھتا ہے۔

یہ اعداد و شمار کہاں سے آتے ہیں؟

Search Console کی Core Web Vitals رپورٹ Chrome UX Report کے فیلڈ ڈیٹا پر مبنی ہے، یعنی پچھلے 28 دنوں کے اصل Chrome وزٹس۔ ان کو ملتے جلتے صفحات کے گروپس میں تقسیم کیا جاتا ہے اور ہر گروپ کو اس کے بدترین میٹرک کے مطابق درجہ دیا جاتا ہے۔ Lighthouse جیسے لیب ٹولز صفحے کو کسی حقیقی وزیٹر کے بغیر لوڈ کرتے ہیں، اس لیے وہ INP نہیں ناپ سکتے اور اس کے متبادل کے طور پر Total Blocking Time استعمال کرتے ہیں، جیسا کہ web.dev کا Web Vitals کا جائزہ بتاتا ہے۔ لیب اسکورز کو مسائل کی تشخیص کا ذریعہ سمجھیں اور فیلڈ ڈیٹا کو حتمی فیصلہ۔

کیا Core Web Vitals رینکنگ پر اثر ڈالتے ہیں؟

Google Search میں کامیابی کے لیے اچھے Core Web Vitals حاصل کرنے کی پرزور سفارش کرتا ہے اور کہتا ہے کہ پیج ایکسپیریئنس ان چیزوں سے ہم آہنگ ہے جنہیں اس کے بنیادی رینکنگ سسٹمز انعام دینا چاہتے ہیں۔ یہ کوئی شارٹ کٹ نہیں ہے: تیز صفحے کو پھر بھی بہترین جواب ہونا چاہیے۔ میں خراب Core Web Vitals اسکورز کیسے ٹھیک کروں؟ میں بتایا گیا ہے کہ ہر میٹرک کے لیے کیا تبدیل کرنا چاہیے۔

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

AutoPSEO کی Core Web Vitals رپورٹ آپ کی پوری سائٹ یا کسی ایک URL کے لیے Chrome UX Report کی ہسٹری پڑھتی ہے، فون، ڈیسک ٹاپ یا ٹیبلٹ کے لحاظ سے، اور تقریباً چھ ماہ کے ہفتہ وار ڈیٹا پر 75ویں پرسنٹائل پر LCP، INP اور CLS (نیز first contentful paint اور time to first byte) کو چارٹ کرتی ہے، تاکہ آپ دیکھ سکیں کہ کوئی میٹرک کب بگڑنا شروع ہوا۔