صرف فیلڈ ڈیٹا ہی اصل اسکور ہے
Lighthouse کسی ڈیٹا سینٹر میں سست کیے گئے کنکشن پر ایک فرضی درمیانے درجے کے فون پر چلتا ہے۔ آپ کے صارفین وہ نہیں ہیں۔ Google کی درجہ بندی CrUX یعنی Chrome User Experience Report پر ہوتی ہے — اصل سیشنز، 28 دن کی چلتی ونڈو، اور 75ویں پرسنٹائل پر اسکور — اس لیے لیب کے نمبر کے پیچھے بھاگنے سے وہ میٹرک جوں کا توں رہ سکتا ہے جو اصل میں اہم ہے۔ web-vitals لائبریری نصب کریں اور LCP، INP اور CLS اپنے اینالیٹکس میں صفحے کے ٹیمپلیٹ سمیت بھیجیں، تاکہ آپ کو نظر آئے کہ پرائسنگ صفحہ پاس ہے اور سرچ رزلٹس کا صفحہ نہیں۔ لیب ٹولز کو ڈیبگر سمجھیں، اسکور بورڈ نہیں: وہ بتاتے ہیں کہ ایک مخصوص لوڈ سست کیوں تھا، اور یہ کام وہ بہت اچھا کرتے ہیں۔ بس Lighthouse کا اسکور کبھی کسی اسٹیک ہولڈر کو اس ثبوت کے طور پر پیش نہ کریں کہ اصل صارفین کا تجربہ اچھا ہے۔
LCP تقریباً ہمیشہ ایک تصویر یا ایک فونٹ ہوتا ہے
Largest Contentful Paint کا بجٹ 75ویں پرسنٹائل پر 2.5 سیکنڈ ہے، اور ہمارے تجربے میں چار وجوہات ہی اکثر ناکامیوں کی وضاحت کر دیتی ہیں۔ پہلی، ہیرو تصویر lazy-load ہوتی ہے — براؤزر اسے لے آؤٹ چلنے سے پہلے لانا شروع ہی نہیں کرتا۔ اس پر fetchpriority="high" لگائیں اور loading="lazy" ہٹا دیں؛ Next.js میں یہی priority prop ہے۔ دوسری، تصویر 900KB کی PNG ہے جو درست پیمائش پر 60KB کی AVIF ہونی چاہیے تھی۔ تیسری، رینڈر روکنے والا ویب فونٹ متن کے پینٹ کو مؤخر کر دیتا ہے: اسے خود ہوسٹ کریں، فولڈ کے اوپر والا ایک وزن preload کریں، اور font-display: swap کے ساتھ ایسا میٹرک سے ملتا جلتا فال بیک رکھیں کہ یہ تبدیلی CLS بھی خراب نہ کرے۔ چوتھی، سرور کا سست جواب — اگر time to first byte 600ms سے بڑھ جائے تو کوئی فرنٹ اینڈ محنت آپ کو نہیں بچا سکتی۔ پہلے وہی ٹھیک کریں۔
INP ایک JavaScript مسئلہ ہے جسے آپ ناپ سکتے ہیں
Interaction to Next Paint نے مارچ 2024 میں First Input Delay کی جگہ لی، اور یہ کہیں سخت امتحان ہے: یہ پورے وزٹ کے دوران ہر انٹریکشن ناپتا ہے، صرف پہلا نہیں، اور بجٹ 200ms ہے۔ وجہ مین تھریڈ پر لمبے ٹاسکس ہوتے ہیں، اور React سائٹس پر عموماً سب سے بڑا ٹاسک ہائیڈریشن ہوتا ہے۔ کلائنٹ کو کم JavaScript بھیجیں — سرور کمپوننٹس، آئی لینڈز، یا سادہ progressive enhancement، سب کام کرتے ہیں، اور فریم ورک بائٹس کی تعداد سے کم اہم ہے۔ 50ms سے لمبے کام کو scheduler.yield یا ایونٹ لوپ کو موقع دے کر توڑیں۔ ان مخصوص قاتلوں پر نظر رکھیں: ایک بھاری onChange ہینڈلر جو ہر کی اسٹروک پر بڑی فہرست فلٹر کرتا ہے، ایک اینالیٹکس اسکرپٹ جو کلک ہینڈلر کے اندر ہی چل پڑتی ہے، اور تھرڈ پارٹی ٹیگ مینیجرز جو کسی بھی وینڈر کا کوڈ قطار میں لگا دیتے ہیں۔ debounce کریں، ورکر پر منتقل کریں، یا وینڈر ہٹا دیں۔
CLS سستا ہے، اور کچھ مشورے ضرورت سے زیادہ اہم سمجھے جاتے ہیں
Cumulative Layout Shift تینوں میں سب سے آسان ہے جسے 0.1 پر پاس کیا جا سکتا ہے: ہر تصویر اور ویڈیو پر width اور height لگائیں، اشتہار کے خانوں، بینرز اور ایمبیڈز کے لیے min-height سے جگہ محفوظ رکھیں، اور لوڈ کے بعد موجودہ مواد کے اوپر کبھی نیا مواد نہ ڈالیں — کوکی بینر یا پرومو بار کا صفحے کو نیچے دھکیلنا ایک کلاسک خود ساختہ ناکامی ہے۔ اب ضرورت سے زیادہ اہم سمجھی جانے والی فہرست۔ Critical CSS کو inline کرنا الجھا ہوا کام ہے، ری ڈیزائن پر ٹوٹ جاتا ہے، اور شاذ و نادر ہی محض کم CSS بھیجنے سے بہتر نکلتا ہے۔ درجن بھر وسائل preload کرنے سے سب آپس میں مقابلہ کرنے لگتے ہیں اور LCP عموماً سست ہو جاتا ہے۔ بنڈل سائز کو تقریباً 100KB gzipped سے نیچے لانے کی باریک محنت کا اثر ایک بلاک کرنے والی تھرڈ پارٹی اسکرپٹ ہٹانے کے مقابلے میں بہت کم ہے۔ اور ایسے صفحے پر Lighthouse کا مکمل 100 جو CrUX میں فیل ہو، نتیجہ نہیں — وہ ایک ایسا جھوٹا اطمینان ہے جس کی آپ نے قیمت ادا کی ہے۔