𝗠𝘆 𝗔𝗣𝗜 𝗥𝗲𝘀𝗽𝗼𝗻𝗱𝗲𝗱 𝗶𝗻 𝟰 𝗺𝘀, 𝗯𝘂𝘁 𝗡𝗮𝘃𝗶𝗴𝗮𝘁𝗶𝗼𝗻 𝗦𝘁𝗶𝗹𝗹 𝗙𝗲𝗹𝘁 𝗦𝗹𝗼𝘄

আমি SvelteKit এবং একটি Rust API দিয়ে তৈরি একটি প্রজেক্ট ম্যানেজমেন্ট অ্যাপ ডিবাগ করছিলাম।

আমার লোকাল মেশিনে সবকিছু তাৎক্ষণিক মনে হচ্ছিল। কিন্তু VPS-এ নেভিগেশন বেশ ভারী মনে হচ্ছিল। Tickets বা Timeline-এর মতো পেজগুলো খুলতে অনেক সময় নিচ্ছিল। একটি টিকিটে ক্লিক করার পর প্রিভিউ আসার আগে একটি লক্ষণীয় বিলম্ব হচ্ছিল।

আমি ভেবেছিলাম সমস্যাটি সার্ভারে। আমি সন্দেহ করেছিলাম যে ডাটাবেস কুয়েরি ধীরগতির অথবা VPS দুর্বল।

পরিমাপগুলো আমাকে ভুল প্রমাণ করল।

আমি feature list endpoint-টি পরীক্ষা করলাম। মাত্র ৫২টি টিকিটের জন্য API ৪ মিলি-সেকেন্ডে রেসপন্স করছিল। শুনতে এটি দ্রুত মনে হয়। কিন্তু রেসপন্স সাইজ ছিল ৩৫৪ KB।

SvelteKit route payload-তেও একই সমস্যা দেখা গেল। একটি সাধারণ লিস্টের জন্য ডেটার সাইজ ছিল বিশাল।

সমস্যাটি গতি নিয়ে ছিল না। সমস্যাটি ছিল ওজনের (weight)।

শুধুমাত্র ডেসক্রিপশনগুলোই মোট রেসপন্সের ৮০% দখল করে ছিল। লিস্ট endpoint-টি প্রতিটি আইটেমের জন্য সম্পূর্ণ Markdown ডেসক্রিপশন রিটার্ন করছিল।

এটি একটি সাধারণ ফাঁদ। লিস্ট endpoint-টি একটি detail endpoint-এ পরিণত হয়েছিল। যখনই কোনো পেজের একটি লিস্ট প্রয়োজন হতো, তাকে এমন ডেটার জন্য মূল্য দিতে হচ্ছিল যা তার প্রয়োজন ছিল না।

UI-এর ব্যবহার পেলোড (payload) নির্ধারণ করে না। loader-এর return shape নির্ধারণ করে।

আপনার loader যদি একটি পূর্ণাঙ্গ অবজেক্ট (full object) রিটার্ন করে, তবে SvelteKit সেই পুরো অবজেক্টটিকে route data-তে সিরিয়ালাইজ করে। এমনকি আপনি যদি কোনো ফিল্ড রেন্ডার না-ও করেন, তবুও সেটি নেটওয়ার্কের মাধ্যমে প্রবাহিত হয়।

আমি সামারি ডেটা (summary data) এবং ডিটেইল ডেটা (detail data) আলাদা করার মাধ্যমে এটি সমাধান করেছি।

আমি দুটি ভিন্ন কন্ট্রাক্ট (contract) তৈরি করেছি:

• সামারি বা সারসংক্ষেপের জন্য একটি লিস্ট কন্ট্রাক্ট (ID, title, status, dates)। • পূর্ণাঙ্গ তথ্যের জন্য একটি ডিটেইল কন্ট্রাক্ট (descriptions, commands)।

আমি API-টিকে দুটি endpoint-এ বিভক্ত করেছি:

  • GET /features (সামারি রিটার্ন করে)
  • GET /features/:id (একটি পূর্ণাঙ্গ ডিটেইল রিটার্ন করে)

আমি ফ্রন্টএন্ডের কাজের পদ্ধতিও পরিবর্তন করেছি। এখন, অ্যাপটি সামারি ডেটা ব্যবহার করে তাৎক্ষণিকভাবে লিস্টটি রেন্ডার করে। যখন আপনি একটি টিকিটে ক্লিক করেন, অ্যাপটি একটি শেল (shell) দেখায় এবং ব্যাকগ্রাউন্ডে ভারী ডিটেইল ডেটা ফেচ (fetch) করে।

ফলাফল ছিল বিশাল:

• Feature list API: ৮৯.৬% হ্রাস • Tickets route data: ৯১.৪% হ্রাস • OpenSpec docs API: ৯৮.৯% হ্রাস

ডাটাবেস সবসময়ই দ্রুত ছিল। আসল বাধা (bottleneck) ছিল API এবং পেজের মধ্যকার ডেটা কন্ট্রাক্ট।

লিস্ট-নির্ভর অ্যাপের জন্য শিক্ষা:

  • শুধুমাত্র রেসপন্স টাইম নয়, রেসপন্স সাইজও পরিমাপ করুন।
  • লিস্ট এবং ডিটেইল পেলোডগুলোকে আলাদা বিষয় হিসেবে বিবেচনা করুন।
  • লিস্ট ভিউতে কখনোই বড় টেক্সট ফিল্ড রিটার্ন করবেন না।
  • আপনার SSR লোডার আসলে কী সিরিয়ালাইজ করছে তা পরীক্ষা করুন।
  • ডিটেইল ডেটা লেজি-লোড করুন কিন্তু UI শেল অবিলম্বে দেখান।
  • একটি ভারী পেলোড লুকিয়ে রাখার জন্য লোডিং স্পিনার ব্যবহার করবেন না।

একটি দ্রুত কুয়েরি মানেই একটি দ্রুত পেজ নিশ্চিত হওয়া নয়।

উৎস: https://dev.to/ahikmah/my-api-responded-in-4-ms-but-navigation-still-felt-slow-1hk8