আপনার AI-built app কেন স্লো লাগে (আর তা নিয়ে কী করবেন)

আপনার AI-built app কাজ করে। বোতামগুলো যেখানে যাওয়ার কথা সেখানেই যায়, স্ক্রিনগুলো ঠিকঠাক বসে, ডেটা সেভ হয়। কিন্তু কিছু একটা যেন বেঠিক লাগে। পেজ লোড হতে এক পলক বেশি সময় নেয়। পঞ্চাশটা আইটেমের একটা list এক সেকেন্ডের জন্য আটকে যায়। “save”-এ ক্লিক করলে আপনাকে অপেক্ষা করায়, তারপর আরও একটু অপেক্ষা করায়, তারপর ভাবায় আবার ক্লিক করবেন কি না। কিছুই ভাঙেনি — শুধু স্লো লাগে।

আপনি যদি একজন নন-টেকনিক্যাল ফাউন্ডার হন যিনি একটি AI app builder দিয়ে শিপ করছেন, তাহলে এটা সবচেয়ে সাধারণ “কী যে গণ্ডগোল বুঝতে পারছি না” মুহূর্তগুলোর একটা। সুখবর হলো, স্লো AI-built app-এর ৮০%-ই একই হাতেগোনা কয়েকটা কারণে স্লো। এর কোনোটার জন্যই আপনাকে ডেটাবেস কীভাবে কাজ করে তা শিখতে হবে না। সবগুলোরই এমন সমাধান আছে যা আপনি সাধারণ ভাষায় আপনার AI builder-কে চাইতে পারেন।

এই লেখাটাই সেই চিট শিট।

“স্লো” কেন সাধারণত চারটা জিনিস

ইউজাররা যখন বলে একটা app স্লো লাগছে, তখন তারা প্রায় কখনোই বোঝায় না “সার্ভারটা কম শক্তির।” তারা চারটা জিনিসের একটা বোঝায়:

1. প্রথম দেখা দেওয়া স্লো — তারা একটা লিংকে ক্লিক করে আর কিছু দেখা দেওয়ার আগে দুই সেকেন্ড একটা ফাঁকা স্ক্রিনের দিকে তাকিয়ে থাকে।
2. একটা লম্বা list মন্থর — স্ক্রল করা, filter করা, কিংবা “আমার সব প্রজেক্ট” লোড করা Instagram স্ক্রল করার চেয়ে বেশি সময় নেয়।
3. একটা অ্যাকশন কী হচ্ছে না জানিয়েই বেশি সময় নেয় — তারা “save” বা “send”-এ ক্লিক করে আর দৃশ্যত কিছুই সাড়া দেয় না।
4. ডেটাবেসকে অনেক বেশি প্রশ্ন করা হচ্ছে — যে পেজগুলো একাধিক জায়গা থেকে ডেটা দেখায়, সেগুলো প্রতিটা টুকরো আলাদাভাবে আনে আর অপেক্ষার সময়গুলো একটার ওপর একটা জমা করে।

ব্যস, এটুকুই। আমার দেখা প্রায় প্রতিটা স্লো AI-built app এই চারটা কারণের একটার জন্যই স্লো। প্রতিটা কীভাবে চিনবেন আর তা নিয়ে builder-কে কী করতে বলবেন, তা এখানে।

স্লো কারণ #১: প্রথম দেখা দেওয়া

দেখতে কেমন লাগে: আপনি আপনার app-এর একটা লিংকে ক্লিক করেন, URL বার লোডিং শেষ করে, কিন্তু কিছু দেখা দেওয়ার আগে পেজটা এক-দুই সেকেন্ড সাদা থাকে।

সাধারণত যা কারণ: app-টা আপনাকে কিছু দেখানোর আগে তার দরকার হতে পারে এমন প্রতিটা JavaScript টুকরো লোড করছে। AI app builder দরাজভাবে bundle করে — কিছু বাদ দেওয়ার চেয়ে অন্তর্ভুক্ত করা ভালো — আর আপনি যত ফিচার যোগ করেন, সেই bundle তত বড় হয়।

আপনার AI builder-কে যা বলবেন: “প্রথম পেজ লোড স্লো লাগছে। route ধরে ধরে JavaScript bundle-গুলো ভাগ করে দিতে পারবে, যাতে home পেজকে পুরো admin সেকশন download করতে না হয়?” কিংবা আরও সহজভাবে: “home পেজ ছাড়া বাকি route-গুলোর জন্য lazy loading যোগ করো।” বেশিরভাগ আধুনিক ফ্রেমওয়ার্ক এক-দুই লাইনের config-এ এটা সমর্থন করে। AI জানে কীভাবে — আপনার শুধু চাওয়া দরকার।

কথা যখন উঠলই: “landing পেজে এমন কোনো বড় image আছে যা আমরা optimize করতে পারি?” একটা ৪ MB-র hero ছবি যেকোনো কোডের সমস্যার চেয়ে বেশি অনুভূত গতি ডুবিয়ে দেবে।

স্লো কারণ #২: লম্বা list

দেখতে কেমন লাগে: আপনার একটা list আছে — প্রজেক্ট, কন্টাক্ট, পোস্ট, যা-ই হোক — আর একবার সেটা চল্লিশ-পঞ্চাশটা আইটেম পেরিয়ে গেলে স্ক্রল করা আটকে যায় কিংবা filter করতে লক্ষণীয় একটা সময় লাগে।

সাধারণত যা কারণ: app-টা প্রতিটা আইটেম একসঙ্গে পেজে render করছে, এমনকি যেগুলো আপনি দেখতে পাচ্ছেন না সেগুলোও। দশটা আইটেমে এটা ঠিক আছে। পাঁচশতে ব্রাউজার দম আটকে যায়।

আপনার AI builder-কে যা বলবেন: “আইটেম বেশি হলে projects list স্লো হয়ে যায়। আমরা কি pagination যোগ করতে পারি, কিংবা list-টা virtualize করতে পারি যাতে শুধু দৃশ্যমান সারিগুলো render হয়?” Pagination (“পেজপ্রতি ২০টা দেখাও, next/previous বোতামসহ”) সবচেয়ে সহজ সমাধান। Virtualization (“ইউজার স্ক্রল করতে করতে শুধু স্ক্রিনে যা আছে তা render করো”) দেখতে আরও মসৃণ লাগে কিন্তু সামান্য বেশি খাটুনি। দুটোর যেকোনোটাই ঠিক আছে।

list-টায় যদি search বা filter-ও থাকে: “search filter-টা ব্রাউজারে না করে সার্ভারে করা যায়?” সার্ভার-সাইড filter মানে ব্রাউজার কখনো শুধু মিলে যাওয়া সারিগুলোই ধরে রাখে, পুরো ডেটাসেট নয়।

স্লো কারণ #৩: নীরব অপেক্ষা

দেখতে কেমন লাগে: আপনি “save” বা “send” বা “generate”-এ ক্লিক করেন। দৃশ্যত কিছুই হয় না। দুই সেকেন্ড পরে স্ক্রিন আপডেট হয় আর আপনি বুঝতে পারেন এটা পুরোটা সময়ই কাজ করছিল।

সাধারণত যা কারণ: app-টা আসল কাজ করছে — ডেটাবেসে সেভ করা, একটা API কল করা — কিন্তু AI builder কোনো লোডিং স্টেট যোগ করেনি। তাই আপনার দিক থেকে দেখলে ক্লিকটা কিছুই করল না।

এটা আসলে কোনো performance সমস্যা নয়। এটা একটা অনুভূত performance সমস্যা, আর ওগুলো প্রায়ই আসলগুলোর চেয়ে বেশি যন্ত্রণাদায়ক। কোনো ফিডব্যাক ছাড়া ২০০-মিলিসেকেন্ডের একটা অ্যাকশন একটা spinner-সহ ২-সেকেন্ডের অ্যাকশনের চেয়ে বেশি স্লো লাগে, কারণ ইউজারের মস্তিষ্ক অন্ধকারে থাকে।

আপনার AI builder-কে যা বলবেন: “যে প্রতিটা বোতাম একটা অ্যাকশন চালু করে, তাতে একটা লোডিং স্টেট যোগ করো। কাজ চলার সময় একটা spinner বা ‘Saving…’ লেখা দেখাও, আর বোতামটা disable করে দাও যাতে ইউজার double-click করতে না পারে।” এটাই যেকোনো app-এর সবচেয়ে বেশি-ROI দেওয়া performance সমাধান, আর এর খরচ প্রায় কিছুই নয়।

কথা যখন উঠলই: “যেসব অ্যাকশনের ফলাফল আমরা আগেই জানি, সেগুলোর জন্য আমরা কি UI-টা optimistically আপডেট করতে পারি — পরিবর্তনটা সঙ্গে সঙ্গে দেখাও আর সার্ভার প্রত্যাখ্যান করলে ফিরিয়ে নাও?” Optimistic আপডেটের কারণেই সোশ্যাল app-এর “like” বোতাম তাৎক্ষণিক লাগে, এমনকি আপনার ফোনের নেটওয়ার্ক যাচ্ছেতাই হলেও।

স্লো কারণ #৪: বাচাল ডেটাবেস

দেখতে কেমন লাগে: একটা পেজ যা আইটেমের একটা list দেখায়, প্রতিটার সঙ্গে বাড়তি তথ্য — যেমন প্রজেক্টের একটা list যেখানে প্রতিটায় কতগুলো task আছে — একটা সাদামাটা list-এর চেয়ে লোড হতে অনেক বেশি সময় নেয়।

সাধারণত যা কারণ: পেজটা একটা query-তে প্রজেক্টগুলো লোড করছে, তারপর প্রতিটা প্রজেক্টের task count আলাদা একটা query-তে লোড করছে। দশটা প্রজেক্ট? এগারোটা query। একশটা প্রজেক্ট? একশ এক। এটাকে বলে “N+1 query,” আর AI-built app-এ এটাই সবচেয়ে সাধারণ ডেটাবেস performance bug, কারণ AI এমন কোডের জন্য অপ্টিমাইজ করছে যা পরিষ্কারভাবে পড়া যায়, এমন কোডের জন্য নয় যা দক্ষভাবে চলে।

আপনার AI builder-কে যা বলবেন: “এই পেজটা প্রতি আইটেমে একটা করে query করছে। আমরা কি সম্পর্কিত সব ডেটা একটা query-তে আনতে পারি — একটা join বা একটা aggregate?” এর কোনো শব্দের মানে আপনার জানার দরকার নেই। AI জানে। স্লো পেজটা তাকে দেখিয়ে “আমার মনে হয় এটায় একটা N+1 সমস্যা আছে” বলাই সাধারণত যথেষ্ট।

কোনো টুল ছাড়াই আপনি N+1 সমস্যা শনাক্ত করতে পারেন: পেজটা খুলুন, কতক্ষণ লাগে তা গুনুন, তারপর নিচের list-টায় দশ গুণ বেশি আইটেম যোগ করুন। পেজটা এখন দশ গুণ স্লো হলে, আপনার একটা N+1 আছে। সামান্যই স্লো হলে, নেই।

অকাল optimization নিয়ে দু-কথা

নতুন বিল্ডাররা যে ফাঁদে পড়ে: কেউ app ব্যবহার করার আগেই প্রতিটা পেজ দ্রুত করার চেষ্টা করা। করবেন না।

Performance-এর কাজের একটা আসল খরচ আছে। যে list-এ কখনো কুড়িটার বেশি সারি হবেই না, তাতে pagination যোগ করা অপচয়। যে পেজ দিনে দুবার লোড হয় তাতে optimize করা অপচয়। তিনজন ইউজারওয়ালা একটা ইন্টারনাল টুলের জন্য bundle ভাগ করা অপচয়। একটা স্লো পেজ ঠিক করার সঠিক সময় হলো তখন, যখন আপনি পেজটা, অ্যাকশনটা, আর সেটায় বিরক্ত হওয়া একজন মানুষের নাম বলতে পারবেন।

তাই আগে এটা স্বাভাবিকভাবে বানান। শিপ করুন। এটা কীভাবে ব্যবহৃত হয় দেখুন। যখন কোনো আসল মানুষের কাছে — আপনি নিজেও — কিছু একটা স্লো লাগে, তখন লক্ষণটাকে ওপরের চারটা শ্রেণির একটার সঙ্গে মিলিয়ে সেই নির্দিষ্ট সমাধানটা চান। আপনি একটা দ্রুততর app পাবেন, এমন infrastructure-এ এক সপ্তাহ খরচ না করেই যা আপনার ইউজাররা কখনো খেয়ালই করবে না।

গতি নিয়ে আপনার AI builder-এর সঙ্গে কথা বলবেন কীভাবে

যে প্যাটার্নটা কাজ করে: সমাধান নয়, লক্ষণ বর্ণনা করুন। AI ঠিক সমাধানটা বাছতে আপনার ধারণার চেয়ে অনেক ভালো, যতক্ষণ সে জানে আসলে কী গণ্ডগোল।

কপি করার মতো ভালো prompt:

• “আমি settings পেজটা খুললে কিছু দেখা দেওয়ার আগে এক সেকেন্ডের একটা দেরি হয়। প্রথম render-টা কী আটকে রাখছে তা কি আমরা বের করতে পারি?”
• “dashboard home পেজের চেয়ে কম ডেটা দেখালেও লোড হতে বেশি সময় নেয়। এটা কীভাবে তার ডেটা আনছে তা কি আমরা দেখতে পারি?”
• “profile পেজে ‘save changes’-এ ক্লিক করলে দুই সেকেন্ড কিছুই হয় না। একটা লোডিং স্টেট যোগ করো আর নিশ্চিত করো বোতামটা double-click করা যাবে না।”
• “এই list-টা ৫০০টা নকল আইটেম দিয়ে টেস্ট করো আর বলো কোথায় স্লো হচ্ছে।”

শেষটা যথেষ্ট মূল্যায়িত নয়। AI-কে টেস্ট ডেটা তৈরি করতে আর পেজটা নিজে চালিয়ে দেখতে বলা আপনার করার মতো সবচেয়ে কাজের জিনিসগুলোর একটা। সে প্রায়ই আপনার ইউজারদের আগেই স্লো জায়গাগুলো খুঁজে বের করবে — আর একই জবাবে সমাধানটাও দেবে।

AI-built app-এ গতি কোনো জাদুর ব্যাপার নয়। ব্যাপারটা হলো আপনার সমস্যাটা চারটা বালতির কোনটায় পড়ে তা জানা, আর পরিষ্কার শব্দে সঠিক সমাধানটা চাওয়া। সেটা করুন, আর “স্লো লাগে” হয়ে যাবে “ঠিকঠাক লাগে” — হাতেগোনা কয়েকটা ছোট, লক্ষ্যভেদী পরিবর্তনে, কোনো নতুন করে লেখা ছাড়াই।