𝗠𝗲𝗿𝗶 𝗔𝗣𝗜 𝗻𝗲 𝟰 𝗺𝘀 𝗺𝗲𝗶𝗻 𝗷𝗮𝘄𝗮𝗯 𝗱𝗶𝘆𝗮, 𝗹𝗲𝗸𝗶𝗻 𝗡𝗮𝘃𝗶𝗴𝗮𝘁𝗶𝗼𝗻 𝗽𝗵𝗶𝗿 𝗯𝗵𝗶 𝘀𝗹𝗼𝘄 𝗺𝗮𝗵𝘀𝗼𝗼𝘀 𝗵𝗼 𝗿𝗮𝗵𝗶 𝘁𝗵𝗶

میں SvelteKit اور Rust API کے ساتھ بنی ہوئی ایک پروجیکٹ مینجمنٹ ایپ کو ڈی بگ (debug) کر رہا تھا۔

میری لوکل مشین پر سب کچھ فوری محسوس ہو رہا تھا۔ لیکن VPS پر، نیویگیشن بوجھل محسوس ہو رہی تھی۔ Tickets یا Timeline جیسے صفحات کھولنے میں بہت زیادہ وقت لگ رہا تھا۔ کسی ٹکٹ پر کلک کرنے سے پری ویو (preview) ظاہر ہونے سے پہلے ایک واضح تاخیر محسوس ہوتی تھی۔

میں نے سوچا کہ مسئلہ سرور کا ہے۔ مجھے شک تھا کہ ڈیٹا بیس کی کوئریز (queries) سست ہیں یا VPS کمزور ہے۔

پیمائش (measurements) نے مجھے غلط ثابت کر دیا۔

میں نے feature list endpoint چیک کیا۔ صرف 52 ٹکٹس کے لیے، API نے 4 ms میں جواب دیا۔ یہ سننے میں تیز لگتا ہے۔ لیکن ریسپانس کا سائز 354 KB تھا۔

SvelteKit route payload نے بھی یہی مسئلہ دکھایا۔ ایک سادہ سی لسٹ کے لیے ڈیٹا کا سائز بہت زیادہ تھا۔

مسئلہ رفتار کا نہیں تھا۔ مسئلہ وزن (weight) کا تھا۔

صرف تفصیلات (descriptions) ہی کل ریسپانس کا 80% حصہ تھیں۔ لسٹ اینڈ پوائنٹ ہر ایک آئٹم کے لیے مکمل Markdown تفصیلات واپس کر رہا تھا۔

یہ ایک عام جال ہے۔ لسٹ اینڈ پوائنٹ، ڈیٹیل اینڈ پوائنٹ بن چکا تھا۔ جب بھی کسی پیج کو لسٹ کی ضرورت ہوتی، اسے اس ڈیٹا کی قیمت چکانی پڑتی تھی جس کی اسے ضرورت ہی نہیں تھی۔

UI کا استعمال پے لوڈ (payload) کا تعین نہیں کرتا۔ بلکہ لوڈر کی واپسی کی شکل (loader return shape) اس کا تعین کرتی ہے۔

اگر آپ کا لوڈر ایک مکمل آبجیکٹ (object) واپس کرتا ہے، تو SvelteKit اس پورے آبجیکٹ کو روٹ ڈیٹا میں سیریلائز (serialize) کر دیتا ہے۔ اگرچہ آپ اس فیلڈ کو کبھی رینڈر (render) نہ کریں، پھر بھی یہ نیٹ ورک پر منتقل ہوتی ہے۔

میں نے سمری ڈیٹا (summary data) کو ڈیٹیل ڈیٹا (detail data) سے الگ کر کے اسے ٹھیک کیا۔

میں نے دو مختلف کنٹریکٹس (contracts) بنائے:

• خلاصوں کے لیے ایک لسٹ کنٹریکٹ (ID, title, status, dates)۔ • مکمل معلومات کے لیے ایک ڈیٹیل کنٹریکٹ (descriptions, commands)۔

میں نے API کو دو اینڈ پوائنٹس میں تقسیم کر دیا:

  • GET /features (خلاصے واپس کرتا ہے)
  • GET /features/:id (ایک مکمل تفصیل واپس کرتا ہے)

میں نے فرنٹ اینڈ کے کام کرنے کے طریقے کو بھی تبدیل کیا۔ اب، ایپ سمری ڈیٹا کا استعمال کرتے ہوئے لسٹ کو فوری طور پر رینڈر کرتی ہے۔ جب آپ کسی ٹکٹ پر کلک کرتے ہیں، تو ایپ ایک شیل (shell) دکھاتی ہے اور پس منظر (background) میں بھاری ڈیٹیل ڈیٹا حاصل کرتی ہے۔

نتائج بہت شاندار تھے:

• Feature list API: 89.6% کمی • Tickets route data: 91.4% کمی • OpenSpec docs API: 98.9% کمی

ڈیٹا بیس ہمیشہ تیز تھا۔ اصل رکاوٹ (bottleneck) API اور پیج کے درمیان ڈیٹا کنٹریکٹ تھی۔

لسٹ پر مبنی بھاری ایپس کے لیے اسباق:

  • صرف رسپانس ٹائم ہی نہیں، بلکہ رسپانس کے سائز کی بھی پیمائش کریں۔
  • لسٹ (list) اور ڈیٹیل (detail) پے لوڈز کو الگ الگ چیزیں سمجھیں۔
  • لسٹ ویو (list view) میں کبھی بھی بڑے ٹیکسٹ فیلڈز واپس نہ کریں۔
  • چیک کریں کہ آپ کا SSR لوڈر اصل میں کیا سیریلائز (serializing) کر رہا ہے۔
  • ڈیٹیل ڈیٹا کو لیزی لوڈ (lazy-load) کریں لیکن UI شیل (UI shell) کو فوری طور پر دکھائیں۔
  • بھاری پے لوڈ (heavy payload) کو چھپانے کے لیے لوڈنگ اسپنر (loading spinner) کا استعمال نہ کریں۔

ایک تیز کوئری (query) اس بات کی ضمانت نہیں دیتی کہ پیج بھی تیز ہوگا۔

ماخذ: https://dev.to/ahikmah/my-api-responded-in-4-ms-but-navigation-still-felt-slow-1hk8