ویب سائٹ کی رفتار کیسے بڑھائیں: عملی چیک لسٹ

ویب سائٹ کو تیز بنانے کے لیے پہلے PageSpeed Insights سے اسے ناپیں، پھر وہ سب سے بڑی وجہ ٹھیک کریں جو وہ بتائے، جو عموماً بہت بڑی تصاویر، زیادہ JavaScript، بھاری فونٹس یا تھرڈ پارٹی اسکرپٹس ہوتی ہیں۔ Google کے Core Web Vitals کے "اچھے" اہداف کا ہدف رکھیں: اصل مواد 2.5 سیکنڈ میں نظر آئے، ٹیپ کا جواب 200 ملی سیکنڈ میں ملے، اور تقریباً کوئی layout نہ ہلے۔ زیادہ تر سائٹس چند تبدیلیوں سے یہاں پہنچ جاتی ہیں، دوبارہ لکھنے کی ضرورت نہیں ہوتی۔

کچھ بدلنے سے پہلے ناپیں

اندازے سے کام وقت ضائع کرتا ہے۔ دو مفت ٹولز تقریباً ہر کسی کے لیے کافی ہیں:

• PageSpeed Insights (pagespeed.web.dev) — ایک لائیو URL چسپاں کریں۔ یہ حقیقی Chrome صارفین سے field data دکھاتا ہے (اگر آپ کی سائٹ پر کافی ٹریفک ہو) اور ایک نقلی لوڈ سے lab data، ساتھ میں مخصوص مسائل کی فہرست۔
• Chrome DevTools میں Lighthouse — وہی lab ٹیسٹ، کسی بھی صفحے پر جو آپ کھول سکتے ہیں، preview سمیت۔ موبائل موڈ میں ٹیسٹ کریں؛ سست نیٹ ورک والے فونز پر ہی مسائل ظاہر ہوتے ہیں۔

جو اعداد اہم ہیں وہ Google کے Core Web Vitals ہیں۔ ستمبر 2026 تک، web.dev پر Google کی دستاویزات یہ "اچھے" حدود دیتی ہیں، جو صفحے کے لوڈز کے 75 ویں percentile پر ناپی جاتی ہیں:

INP نے 2024 میں پرانے First Input Delay میٹرک کی جگہ لی۔ اگر کوئی ٹول اب بھی FID دکھائے تو وہ پرانا ہے۔

اپنے ابتدائی اعداد لکھ لیں۔ ہر درستی کے بعد دوبارہ ٹیسٹ کریں تاکہ معلوم ہو کہ کیا فائدہ مند رہا۔

وقت کہاں جاتا ہے: آپشنز اور تجارتی شرائط

ہر عام وجہ کا ایک حل ہے، اور ہر حل کی ایک قیمت ہے۔ اوپر والوں سے شروع کریں، کیونکہ وہ سب سے سستے اور سب سے عام ہیں۔

تصاویر

تصاویر سب سے عام مسئلہ ہیں اور ٹھیک کرنا سب سے آسان۔ 800 پکسل چوڑائی پر دکھائی جانے والی 4,000 پکسل کی تصویر ہر وزیٹر کو اتنی بار زیادہ ڈاؤن لوڈ کرواتی ہے جتنا وہ دیکھتا ہے۔

• تصاویر کو اسی سائز میں دیں جس میں دکھائی جاتی ہیں، فونز اور ڈیسک ٹاپ کے لیے ریسپانسو srcset سائز کے ساتھ۔
• جدید فارمیٹس (WebP یا AVIF) اور مناسب کمپریشن استعمال کریں۔
• ہر تصویر پر width اور height سیٹ کریں تاکہ براؤزر جگہ محفوظ کر سکے۔ اکیلا یہی زیادہ تر layout shift ٹھیک کر دیتا ہے۔
• fold سے نیچے کی تصاویر کو loading="lazy" سے lazy-load کریں۔
• صفحے کے اوپر والی اہم تصویر کو کبھی lazy-load نہ کریں۔ Google کی LCP رہنمائی واضح ہے: LCP تصویر کو lazy-load کرنا ہمیشہ اسے تاخیر کا شکار کرتا ہے۔ اس کے بجائے اسے fetchpriority="high" دیں۔

JavaScript

AI سے بنی بہت سی سائٹس single-page apps (SPAs) ہوتی ہیں: براؤزر ایک JavaScript bundle ڈاؤن لوڈ کرتا ہے اور پھر صفحہ بناتا ہے۔ bundle جتنا بڑا، خالی اسکرین اتنی لمبی۔ کوشش کی ترتیب میں حل:

1. جو استعمال نہیں ہوتا ہٹا دیں۔ لائبریریوں کی فہرست مانگیں اور وہ کاٹ دیں جو ایک بار شامل ہوئیں اور بھلا دی گئیں، جیسے ایک تاریخ کے لیے پوری date لائبریری، یا پانچ آئیکنز کے لیے پورا آئیکن پیک۔
2. ہر route کے حساب سے تقسیم کریں۔ ایڈمن ڈیش بورڈ کا کوڈ صرف تب لوڈ کریں جب کوئی اسے کھولے، ہوم پیج پر نہیں۔
3. عوامی صفحات پہلے سے render کریں۔ مارکیٹنگ صفحہ جو اصل HTML کے طور پر جاتا ہے وہ کسی JavaScript چلنے سے پہلے ظاہر ہو جاتا ہے۔ اس سے سرچ انجنوں کو بھی مدد ملتی ہے؛ دیکھیں AI سے بنی ویب سائٹس کے لیے SEO۔

سست INP عموماً ایک طویل task کی وجہ سے ہوتا ہے جو صفحے کو روکتا ہے، جیسے ہر کی اسٹروک پر ایک بہت بڑی فہرست فلٹر کرنا، یا ایک سیل بدلنے پر پوری ٹیبل دوبارہ render کرنا۔ Chrome DevTools کا Performance پینل دکھاتا ہے کہ کون سا۔

فونٹس

ہر فونٹ خاندان اور وزن ایک اور فائل ہے۔ دو خاندان اور تین یا چار وزن عموماً کافی ہوتے ہیں۔ fold کے اوپر استعمال ہونے والا فونٹ preload کریں، font-display: swap استعمال کریں تاکہ متن فوراً دکھائی دے، اور اگر بیرونی فونٹ سروس آپ کے وزیٹرز کے لیے سست ہو تو فونٹس خود ہوسٹ کریں۔

تھرڈ پارٹی اسکرپٹس

چیٹ ویجیٹس، analytics، heatmaps، اشتہاری پکسلز، ایمبیڈڈ ویڈیوز اور سوشل فیڈز سب دوسرے سرورز سے کوڈ لوڈ کرتے ہیں۔ ہر ایک چھوٹا لگتا ہے؛ مل کر اکثر صفحے کا سب سے سست حصہ بن جاتے ہیں۔ وہ رکھیں جو آپ واقعی دیکھتے ہیں۔ باقی صفحہ قابل تعامل ہونے کے بعد لوڈ کریں، اور بھاری embeds (YouTube پلیئر، نقشہ) کو ایک ہلکے پیش نظارے سے بدلیں جو کلک پر اصل چیز لوڈ کرے۔

سرور کا ردعمل

Time to first byte (TTFB) — سرور کو جواب شروع کرنے میں کتنا وقت لگتا ہے — باقی ہر میٹرک کی بنیاد ہے۔ CDN (سرورز کا نیٹ ورک جو وزیٹرز کے قریب ہو؛ دیکھیں CDN کیا ہے) سے دیے جانے والے static صفحات تقریباً ہر جگہ تیز ہوتے ہیں۔ ہر درخواست پر سرور کے بنائے جانے والے صفحات اس سرور اور اس کے ڈیٹا بیس پر منحصر ہوتے ہیں۔ دہرائے جانے والے کام کو کیش کرنا اور سست کوئریز کے لیے ڈیٹا بیس انڈیکس شامل کرنا عام حل ہیں۔

کام کرنے والے پرامپٹس

مخصوص رہیں: صفحے، میٹرک اور پابندی کا نام لیں۔ اگر PageSpeed Insights کے نتائج ہیں تو وہ بھی چسپاں کریں۔

PageSpeed Insights موبائل پر ہوم پیج کا LCP 4.8 سیکنڈ بتاتا ہے، اور LCP عنصر ہیرو تصویر ہے۔ ہیرو تصویر کا سائز بدلیں اور WebP میں تبدیل کریں، ریسپانسو سائز دیں، width اور height سیٹ کریں، اسے fetchpriority="high" دیں اور یقینی بنائیں کہ وہ lazy-load نہ ہو۔ fold سے نیچے ہر تصویر کو lazy-load کریں۔ ڈیزائن نہ بدلیں۔

اس ایپ کی dependencies کا آڈٹ کریں۔ ہر پیکج، اسے کون استعمال کرتا ہے، اور bundle میں تقریباً کتنا اضافہ کرتا ہے، فہرست بنائیں۔ غیر استعمال شدہ پیکجز ہٹائیں اور /admin اور /settings routes کو الگ chunks میں تقسیم کریں جو صرف کھولے جانے پر لوڈ ہوں۔

/products پر سرچ باکس سست لگتا ہے۔ فلٹر کو debounce کریں، ہر کی اسٹروک پر پوری فہرست دوبارہ render کرنے سے بچیں، اور اگر فہرست میں 200 سے زیادہ آئٹمز ہیں تو صفحہ بندی یا virtualise کریں۔

مرحلہ وار

1. لائیو صفحہ ٹیسٹ کریں موبائل پر PageSpeed Insights میں۔ LCP، INP اور CLS نوٹ کریں، اور درج کردہ اوپر کے تین مسائل بھی۔
2. تصاویر پہلے ٹھیک کریں: سائز، فارمیٹس، ابعاد، fold سے نیچے lazy loading، ہیرو کے لیے ترجیح۔
3. وہ تھرڈ پارٹی اسکرپٹس کاٹیں جو آپ استعمال نہیں کرتے، اور باقی کو مؤخر کریں۔
4. فونٹس کو اتنا کم کریں جتنا ڈیزائن کے لیے ضروری ہے۔
5. JavaScript سکیڑیں: غیر استعمال شدہ پیکجز ہٹائیں، ہر route کے حساب سے تقسیم کریں۔
6. عوامی صفحات پہلے سے render کریں اگر وہ اب بھی کلائنٹ پر render ہو رہے ہیں اور LCP اب بھی سست ہے۔
7. سرور چیک کریں: کیشنگ، ڈیٹا بیس انڈیکسز، اور ایسے مواد کے لیے static ہوسٹنگ جو شاذ و نادر بدلتا ہے۔
8. دوبارہ شائع کریں اور دوبارہ ٹیسٹ کریں۔ PageSpeed Insights کا field data اگلے چند ہفتوں میں حقیقی وزٹس کے ساتھ اپ ڈیٹ ہوتا ہے، اس لیے ابتدائی نتائج کو lab data سے پرکھیں۔

عام غلطیاں

• صرف تیز لیپ ٹاپ پر ٹیسٹ کرنا۔ آپ کے وزیٹرز درمیانے درجے کے فونز اور غیر مستحکم موبائل ڈیٹا پر ہیں۔ موبائل موڈ میں ٹیسٹ کریں۔
• کامل 100 کا پیچھا کرنا۔ لیب اسکور ایک رہنما ہے۔ جب Core Web Vitals اچھی حد میں ہوں تو مواد اور قابل استعمال ہونا آخری چند پوائنٹس سے زیادہ اہم ہے۔
• ہر چیز کو lazy-load کرنا، ہیرو تصویر سمیت۔ اس سے LCP اور خراب ہوتا ہے۔
• اوپر سے کوئی speed plugin یا لائبریری شامل کرنا۔ وزن کم کرنا تقریباً ہمیشہ اسے سنبھالنے کے لیے مزید کوڈ شامل کرنے سے بہتر ہے۔
• لائیو سائٹ کے بجائے preview کو بہتر بنانا۔ ڈیولپمنٹ previews غیر بہتر build چلاتے ہیں۔ شائع شدہ URL کو ناپیں۔
• رفتار ایک بار درست کر کے چھوڑ دینا۔ ہر نیا ویجیٹ، تصویر اور فیچر وزن بڑھاتا ہے۔ بڑی تبدیلیوں کے بعد دوبارہ ٹیسٹ کریں۔

رفتار کی چیک لسٹ

• موبائل پر LCP ≤ 2.5 s، INP ≤ 200 ms، CLS ≤ 0.1
• تصاویر کا سائز بدلا، کمپریس، جدید فارمیٹ، width اور height کے ساتھ
• ہیرو تصویر lazy نہیں؛ fold سے نیچے کی تصاویر lazy-load
• کوئی غیر استعمال شدہ JavaScript لائبریری نہیں؛ بھاری routes الگ
• دو یا کم فونٹ خاندان، مرکزی فونٹ preload
• صرف وہی تھرڈ پارٹی اسکرپٹس جو واقعی استعمال ہوں، دیر سے لوڈ
• عوامی صفحات جہاں ممکن ہو پہلے سے render یا static
• شائع کرنے کے بعد لائیو URL پر دوبارہ ٹیسٹ

رفتار اور موبائل لے آؤٹ ساتھ چلتے ہیں؛ دیکھیں ویب سائٹ کو موبائل ریسپانسو کیسے بنائیں۔ مکمل لانچ سے پہلے کے جائزے کے لیے AI پروٹوٹائپ کو پروڈکشن تک کیسے لے جائیں باقی سب کچھ کور کرتی ہے۔

Mythex پر رفتار

Mythex پر آپ یہ تبدیلیاں چیٹ میں پوچھ کر کرتے ہیں، یا Pro پر کوڈ ایڈیٹر میں۔ Preview کے بجائے شائع شدہ URL چیک کریں، کیونکہ Preview ایک ڈیولپمنٹ سرور چلاتا ہے۔ Static فرنٹ اینڈز شائع کرنے پر static سائٹس کے طور پر ڈیپلائے ہوتے ہیں (static websites)، جو مواد والے صفحات کے لیے موزوں ہے۔ سرور رکھنے والی ایپس صفر تک اسکیل ہوتی ہیں: بیکار ہونے پر سو جاتی ہیں اور اگلی وزٹ پر جاگتی ہیں، اس لیے خاموشی کے بعد پہلی درخواست سست ہوتی ہے، اور منسلک ڈیٹا بیس 5 منٹ کی بیکاری کے بعد سو جاتا ہے (ہوسٹنگ کی حدود)۔ اگر کوئی عوامی صفحہ صرف پہلی وزٹ پر سست ہے، تو یہی ممکنہ وجہ ہے۔ مارکیٹنگ صفحات کو static رکھنا مدد کرتا ہے۔ تبدیلیوں کے بعد دوبارہ شائع کریں اور hard-refresh کریں۔

سوالات