০৮ অক্টো, ২০২৫·7 মিনিট

কার্যকর পারফরম্যান্স বাজেট: দ্রুত ওয়েব অ্যাপের জন্য বাস্তব সীমা

Q: What is a performance budget, in plain terms?

A performance budget is a set of hard limits (time, size, requests, CPU work) that your team agrees to before building. If a change exceeds the limit, treat it like a broken requirement: fix it, reduce scope, or explicitly approve an exception with an owner and an expiry date.

Q: Why do we need budgets instead of just “caring about performance”?

Because performance gets worse gradually . Each feature adds JavaScript, CSS, images, fonts, API calls, and third‑party tags. Budgets stop the slow creep by forcing a tradeoff: if you add weight or work, you must pay it back (lazy-load, split a route, simplify UI, remove a dependency).

Q: What page or flow should we budget first?

Pick one real user journey and one consistent test setup. A good starter is something frequent and business-critical, like: - first load after login to the dashboard - home → signup - checkout confirmation Avoid edge cases at first; you want a flow you can measure every release.

Q: Which metrics make the best performance budgets?

Use a small set that covers both what users feel and what teams can control : - Timing: LCP , INP , CLS - Size: initial route JS gzip (and/or CSS) - Media: bytes for images in the first view Timing metrics show the pain; size and runtime limits help you quickly find what caused it.

Q: What are realistic starter numbers for budgets?

A practical starter set is: - LCP : warn at 2.5s, fail at 3.0s (mobile, cold load) - INP : warn at 200ms, fail at 300ms (common interactions) - CLS : warn at 0.10, fail at 0.15 - Initial JS (app code) : warn 170KB gzip, fail 220KB gzip - Images (first screen) : warn 800KB, fail 1.2MB Pick 3–5 budgets first. Tune later based on your baseline and release history.

Q: What’s the point of having “warn” and “fail” thresholds?

Use two thresholds: - Warn : signals you’re drifting; you can merge but should investigate. - Fail : blocks a release or requires explicit approval. This avoids constant fire drills while still making the limits real when you cross the line.

Q: What should we do the moment a budget fails?

Do this in order: 1) Confirm the LCP element didn’t change (a different hero can swing results). 2) Check what grew: JS bytes , image bytes , request count , third‑party tags. 3) Look for long tasks (50ms+) around startup; they often explain “it loads but feels sticky.” 4) Fix the biggest offender first (usually an above-the-fold image, a new dependency, or a route that stopped code-splitting). Treat the breach like a bug: identify the commit, fix or scope-reduce, and prevent repeats.

পারফরম্যান্স বাজেট ওয়েব অ্যাপকে দ্রুত রাখতে সহায় করে: লোড টাইম, JS সাইজ, Core Web Vitals‑এর স্পষ্ট সীমা সেট করে, দ্রুত অডিট এবং ফিক্স‑ফার্স্ট নিয়ম সরবরাহ করে।

কেন পারফরম্যান্সে ভাল ইচ্ছা নয়—বাজেট দরকার

পারফরম্যান্স বাজেট হল এমন কিছু সীমা যা আপনি নির্মাণ শুরু করার আগে ঠিক করেন। এটা সময় সীমানা হতে পারে (পেজটি কতো দ্রুত লাগে), আকারের সীমানা হতে পারে (কত কোড পাঠানো হচ্ছে), বা রিকোয়েস্ট/ইমেজ/থার্ড‑পার্টি স্ক্রিপ্টের একটি সরল ক্যাপ হতে পারে। যদি আপনি সেই সীমা ছাড়িয়ে যান, সেটাকে “পরবর্তীতে ঠিক করা যাবে” নয়—বরং ভাঙা রিকোয়্যারমেন্ট হিসেবে বিবেচনা করুন।

গতি সাধারণত খারাপ হয় কারণ ডেলিভারি সংযোজিত: প্রতিটি নতুন উইজেট JavaScript, CSS, ফন্ট, ইমেজ, API কল ইত্যাদি যোগ করে এবং ব্রাউজারের কাজ বাড়ে। ছোট পরিবর্তনগুলো মিলিয়ে একসময় অ্যাপ ভারী মনে হয়, বিশেষ করে মধ্যমানের ফোন এবং ধীর নেটওয়ার্কে যেখানে বেশিরভাগ ব্যবহারকারী থাকে।

মতামত এখানে রক্ষা করে না। একজন বলে “আমার ল্যাপটপে ঠিক আছে,” আরেকজন বলে “ধীর,” এবং দল বিতর্কে পড়ে। একটি বাজেট বিতর্ক শেষ করে—পারফরম্যান্সকে পরিমাপযোগ্য ও বাধ্যতামূলক প্রোডাক্ট কনস্ট্রেন্টে পরিণত করে।

Addy Osmani–র ভাবনার সাথে এটা মিলে: পারফরম্যান্সকে ডিজাইন কনস্ট্রেন্ট ও সিকিউরিটির নীতির মতো বিবেচনা করুন। আপনি “চেষ্টা” করে সিকিউর থাকতে পারেন না বা “আশা” করতে পারেন না লেআউট ঠিক থাকবে—মানক সেট করেন, ক্রমাগত যাচাই করেন, এবং এমন পরিবর্তন ব্লক করেন যা ভাঙে।

বাজেট কয়েকটি বাস্তব সমস্যা একসাথে সমাধান করে: তারা ট্রেড‑অফ স্পষ্ট করে (ফিচার বাড়ালে অন্য কোথাও দাম দিতে হবে), রিগ্রেশন দ্রুত ধরতে পারে (যখন ফিক্স সস্তা), এবং সবাইকে একই সংজ্ঞা দেয় “পর্যাপ্ত দ্রুততা” কিসে। এছাড়া লঞ্চের আগের দফায় দেখা ফ্রিকশনও কমায়।

বাজেটের জন্য তৈরি পরিস্থিতি এমন: আপনি একটি ড্যাশবোর্ডের জন্য একটি সমৃদ্ধ চার্টিং লাইব্রেরি যোগ করেন। সেটা সবার কাছে পৌঁছে যায়, প্রধান বাণ্ডেল বাড়ায় এবং প্রথম অর্থপূর্ণ স্ক্রিন দেরি করে। বাজেট না থাকলে এটা হারিয়ে যায় কারণ ফিচার “চালু” আছে। বাজেট থাকলে টিমকে নির্বাচন করতে হবে: চার্ট লেজি‑লোড করা, লাইব্রেরি পরিবর্তন করা, বা ভিউ সরল করা।

এটি আরও জরুরি যখন দল দ্রুত অ্যাপ তৈরি ও ইটারেট করতে পারে, এমনকি চ্যাট‑ড্রিভেন বিল্ড ওয়ার্কফ্লো যেমন Koder.ai‑সহ। গতি দারুণ, কিন্তু এটি সহজে অতিরিক্ত ডিপেন্ডেন্সি এবং UI সুপারফ্লুটালীটি নিঃশব্দে শিপ করে ফেলতে পারে। বাজেট দ্রুত ইটারেশনকে ধীর প্রোডাক্টে বদলাতে বাধা দেয়।

একটি সহজ লক্ষ্য দিয়ে শুরু করুন: পেজ, ডিভাইস এবং নেটওয়ার্ক

পারফরম্যান্স কাজ ব্যর্থ হয় যখন আপনি সবকিছু মাপেন কিন্তু কারো দায়িত্ব নেই। একটি গুরুত্বপূর্ণ পেজ ফ্লো বাছুন যা প্রকৃত ব্যবহারকারীদের জন্য গুরুত্বপূর্ণ, এবং সেটাকেই বাজেটগুলোর কেন্দ্র হিসেবে ধরুন।

ভালো শুরু হলো একটি প্রাইমারি জার্নি যেখানে গতি কনভার্শন বা দৈনন্দিন কাজ প্রভাবিত করে, যেমন “হোম থেকে সাইনআপ,” “লগইনের পর ড্যাশবোর্ডের প্রথম লোড,” বা “চেকআউট ও পেমেন্ট কনফার্মেশন।” প্রতিনিধিত্বশীল ও ঘন ঘন ব্যবহৃত কিছু বেছে নিন, এজ কেস নয়।

এমন লক্ষ্য বাছুন যা আপনার ব্যবহারকারীদের মেলে

আপনার অ্যাপ আপনার ল্যাপটপে চলে না। একটি বাজেট যা ফাস্ট মেশিনে ঠিক লাগে, সেটি একটি মধ্যমানের ফোনে ধীর মনে হতে পারে।

একটি ডিভাইস ক্লাস এবং একটি নেটওয়ার্ক প্রোফাইল দিয়ে শুরু করুন। সহজ রাখুন এবং এক বাক্যে লিখে রাখুন যাতে সবাই তা পুনরাবৃত্তি করতে পারে।

উদাহরণ: গত 2–3 বছরের মধ্যমানের একটি Android ফোন, চলন্ত অবস্থায় 4G‑এ (অফিস Wi‑Fi নয়), একটি কোল্ড লোড মাপছি এবং তারপর একটি মূল নেভিগেশন, সেই একই রিজিয়নে যেখানে বেশিরভাগ ব্যবহারকারী।

এটি সবচেয়ে খারাপ কেস বাছাই করার বলে না—বরং এমন একটি সাধারণ কেস যেটার জন্য আপনি সত্যিই অপ্টিমাইজ করতে পারবেন।

একটি বেসলাইন টেস্ট সেটআপ লক করুন

সংখ্যা কেবল তখনই মানে রাখে যখন তারা তুলনাযোগ্য। যদি এক রানের পারফরম্যান্স “Chrome এক্সটেনশন সহ MacBook” আর পরেরটি “থ্রটল করা মোবাইল” হয়, তখন ট্রেন্ড লাইন শব্দে পরিণত হয়।

একটি বেসলাইন এনভায়রনমেন্ট বেছে নিন এবং বাজেট পরীক্ষায় সেটাই ব্যবহার করুন: একই ব্রাউজার ভার্সন, একই থ্রটলিং সেটিং, একই টেস্ট পাথ, এবং একই ক্যাশ স্টেট (কোল্ড বা ওয়ার্ম)। রিয়েল ডিভাইস ব্যবহার করলে একই ডিভাইস মডেল ব্যবহার করুন।

এখন “পর্যাপ্ত দ্রুত” কী বোঝায় তা আচরণগতভাবে সংজ্ঞায়িত করুন, নিখুঁত ডেমো নয়। উদাহরণ: “ব্যবহারকারীরা দ্রুত কনটেন্ট পড়া শুরু করতে পারে” বা “লগইনের পর ড্যাশবোর্ড প্রতিক্রিয়াশীল অনুভব করে।” এটিকে এক‑ দুটো মেট্রিক্সে অনুবাদ করুন এবং তাদের চারপাশে বাজেট সেট করুন।

বাজেটের ধরন: সময়, আকার, রিকোয়েস্ট, এবং রানটাইম

বাজেট সেরা কাজ করে যখন তারা ব্যবহারকারীর অনুভূতি এবং টিম যা নিয়ন্ত্রণ করতে পারে—উভয়কেই কভার করে। ভালো সেট অভিজ্ঞতা মেট্রিক্স (“এটা কেমন দ্রুত অনুভূত হলো?”) এবং রিসোর্স ও CPU সীমা (“কেন এটা ধীর হলো?”) মিশায়।

টাইমিং বাজেট (ব্যবহারকারী অভিজ্ঞতা)

এগুলো ট্র্যাক করে পেজ বাস্তবে কেমন আচরণ করে। সবচেয়ে উপযোগীগুলো সরাসরি Core Web Vitals‑এর সাথে মানায়:

LCP (Largest Contentful Paint): প্রধান কনটেন্ট কত দ্রুত প্রদর্শিত হয়।
INP (Interaction to Next Paint): কেউ ট্যাপ/ক্লিক/টাইপ করলে পেজ কতটা প্রতিক্রিয়াশীল।
CLS (Cumulative Layout Shift): লেআউট কতটা ঝাঁপিয়ে যায়।

টাইমিং বাজেটগুলো আপনার নর্থস্টার কারণ এগুলো ব্যবহারকারীর হতাশার সাথে মিলছে। কিন্তু এগুলো সবসময় বলে না কী ঠিক করতে, তাই নীচের বাজেটগুলোও দরকার।

সাইজ, রিকোয়েস্ট এবং রানটাইম বাজেট (কী কারণে ধীর)

এসব বিল্ড ও রিভিউতে সহজে কার্যকর করা যায় কারণ এগুলো কংক্রিট।

ওয়েট বাজেটগুলো মোট JavaScript, মোট CSS, ইমেজ ও ফন্টের ওজন সীমাবদ্ধ করে। রিকোয়েস্ট বাজেটগুলো মোট রিকোয়েস্ট সংখ্যা ও তৃতীয়‑পক্ষ স্ক্রিপ্টের ক্যাপ করে, নেটওয়ার্ক ওভারহেড কমায় এবং ট্যাগ/উইজেট/ট্র্যাকার থেকে “সারপ্রাইজ” কাজ কমায়। রানটাইম বাজেটগুলো লং টাস্ক, মেইন‑থ্রেড টাইম, এবং হাইড্রেশন টাইম সীমাবদ্ধ করে (বিশেষ করে React‑এর জন্য), যা প্রায়শই বোঝায় কেন একটি পেজ মাঝারি ফোনে “ভারি” অনুভূত হয়।

একটি বাস্তব React উদাহরণ: বাণ্ডেল সাইজ ঠিক আছে মনে হতে পারে, কিন্তু একটি নতুন ক্যারসেল ভারী ক্লায়েন্ট‑সাইড রেন্ডারিং যোগ করে। পেজ লোড হয়, তবু ফিল্টার ট্যাপ করার সময় আটকে যায় কারণ হাইড্রেশন মেইন‑থ্রেড ব্লক করছে। একটি রানটাইম বাজেট যেমন “স্টার্টআপে X ms‑এর বেশি লং টাস্ক নেই” বা “মিড‑টিয়ার ডিভাইসে Y সেকেন্ডের মধ্যে হাইড্রেশন শেষ” এমন ঘটনাগুলো ধরতে পারে—যদিও ওজন বাজেট ধরতে না পারে।

শক্তিশালী পদ্ধতি এগুলোকে একটি সিস্টেম হিসেবে দেখা: অভিজ্ঞতা বাজেট সাফল্য সংজ্ঞায়িত করে, আর সাইজ/রিকোয়েস্ট/রানটাইম বাজেট রিলিজগুলোকে সতর্ক রাখে এবং “কী পরিবর্তিত হলো?” সহজ করে তোলে।

বাস্তব প্রয়োগযোগ্য শুরু বাজেট

আপনি যদি অনেক সীমা সেট করেন, মানুষ মনোযোগ দিতে ছেড়ে দেবে। 3–5টি বাজেট বেছে নিন যা ব্যবহারকারী অনুভূতিকে সবচেয়ে মিলায় এবং যা আপনি প্রতিটি PR বা রিলিজে মাপতে পারবেন।

একটি ব্যবহারিক শুরু সেট (সংখ্যাগুলো পরে টিউন করুন):

LCP:warn 2.5s, fail 3.0s (মোবাইল, কোল্ড লোড).
INP:warn 200ms, fail 300ms (কমন ইন্টার‌্যাকশন যেমন মেনু খোলা বা ফর্ম সাবমিট).
CLS:warn 0.10, fail 0.15.
JavaScript bundle size (initial route):warn 170KB gzip, fail 220KB gzip (শুধু অ্যাপ কোড)।
Images (initial view):warn 800KB, fail 1.2MB (প্রথম স্ক্রিনে লোড হওয়া ছবির মোট ট্রান্সফারড বাইট)।

দুটি থ্রেশহোল্ড ব্যাপারটাকে সহজ রাখে। “Warn” বলছে আপনি ড্রিফট করছেন। “Fail” রিলিজ ব্লক করে বা স্পষ্ট অনুমোদন দাবি করে। এটা সীমাটিকে বাস্তব করে তোলে, সবসময় আগাজাগ্রত করে না।

বাজেট একটি শেয়ার করা জায়গায় লিখে রাখুন যাতে ব্যস্ত রিলিজে কেউ তা নিয়ে তর্ক না করে। সংক্ষিপ্ত এবং নির্দিষ্ট রাখুন: কোন পেজ/ফ্লো কভার করা হয়, কোথায় মাপ নেওয়া হয় (লোকাল অডিট, CI, স্টেজড বিল্ড), কোন ডিভাইস ও নেটওয়ার্ক প্রোফাইল ব্যবহার করা হয়, এবং মেট্রিক্স ঠিক কীভাবে সংজ্ঞায়িত (ফিল্ড বনাম ল্যাব, gzip বনাম র’/রুট, রুট‑লেভেল বনাম পুরো অ্যাপ)।

ধাপে ধাপে: আপনার বর্তমান অ্যাপ থেকে বাজেট সেট করা

Align your team on fast enough

Bring teammates in and agree on one test setup and budget everyone follows.

Invite Team

একটি পুনরাবৃত্তিযোগ্য বেসলাইন দিয়ে শুরু করুন। এক বা দুইটি কী পেজ বেছে নিন এবং প্রতিবার একই ডিভাইস প্রোফাইল ও নেটওয়ার্কে টেস্ট চালান। টেস্টটি অন্তত তিনবার চালান এবং মিডিয়ান রেকর্ড করুন যাতে একটি অদ্ভুত রান আপনার দিকনির্দেশ নির্ধারণ না করে।

একটি সরল বেসলাইন শীট রাখুন যেটায় একটি ইউজার মেট্রিক এবং একটি বিল্ড মেট্রিক আছে। উদাহরণ: পেজের LCP ও INP, সঙ্গে মোট JavaScript সাইজ ও মোট ইমেজ বাইট। এটি বাজেটগুলো বাস্তব মনে করায় কারণ আপনি দেখতে পান অ্যাপ কী শিপ করেছে, কেবল ল্যাব অনুমান নয়।

বাজেটগুলো আজকের চেয়ে একটু ভালো সেট করুন, ফ্যান্টাসি সংখ্যা নয়। একটি সলিড নিয়ম হলো প্রতিটি মেট্রিকের আপনার বর্তমান মিডিয়ান থেকে 5–10% উন্নতি। যদি আপনার বেসলাইনে LCP 3.2s হয়, সরাসরি 2.0s‑এ নেমে যান না—প্রথমে 3.0s ঠিক করুন, তারপর ধরে রেখে ধীরেধীরে কষে নিন।

প্রতিটি রিলিজের আগে একটি দ্রুত চেক যোগ করুন যাতে ব্যবহারকারীদের আগে এটি চলে। এটা এত দ্রুত রাখুন যাতে মানুষ এড়িয়ে না যায়। একটি সরল ভার্সন: সম্মত পেজে একটি সিঙ্গেল‑পেজ অডিট চালান, যদি JS বা ইমেজ বাজেট ছাড়িয়ে যায় তাহলে বিল্ড ফেল করুন, কমিট প্রতি ফলাফল সংরক্ষণ করুন যাতে দেখা যায় কখন পরিবর্তন হয়েছে, এবং একই URL প্যাটার্ন টেস্ট করুন (র‍্যান্ডম ডেটা নয়)।

ব্রিচগুলো সপ্তাহে একবার রিভিউ করুন, কেবলই কেউ অভিযোগ করলে নয়। একটি ব্রিচকে একটি বাগের মতো বিবেচনা করুন: পরিবর্তনটি চিহ্নিত করুন, এখন কী ঠিক করা হবে এবং কী সময়সূচিতে রাখা হবে ঠিক করুন। ধীরে ধীরে কঠোর করুন—শুধু কয়েকটি রিলিজ ধরে রেখার পরই।

প্রডাক্ট স্কোপ বদলে গেলে বাজেটগুলো সচেতনভাবে আপডেট করুন। যদি আপনি একটি নতুন অ্যানালিটিক্স টুল বা একটি ভারী ফিচার যোগ করেন, লিখে নিন কী বৃদ্ধি পেয়েছে (সাইজ, রিকোয়েস্ট, রানটাইম), পরে দিচ্ছেন কীভাবে তা পরিশোধ করবেন, এবং কখন বাজেট ফিরে আসবে।

কুইক অডিট: কী পরিবর্তিত হলো তা দ্রুত দেখার উপায়

একটি বাজেট তখনই সাহায্য করবে যখন আপনি দ্রুত তা চেক করতে পারবেন। 10 মিনিটের অডিটের লক্ষ্য নিখুঁত সংখ্যা প্রমাণ করা নয়—পরিবর্তিত কি হয়েছে তা শনাক্ত করে প্রথমে কী ঠিক করতে হবে তা নির্ধারণ করা।

10-মিনিট অডিট ফ্লো

একটি বাস্তব ব্যবহার প্রদর্শন করে এমন পেজ দিয়ে শুরু করুন। তারপর প্রতিবার একই দ্রুত চেকগুলো চালান:

LCP এলিমেন্ট চিহ্নিত করুন (হিরো ইমেজ, হেডিং ব্লক, প্রোডাক্ট গ্যালারি)। LCP এলিমেন্ট বদলে গেলে ফলাফল বড়ভাবে পরিবর্তিত হবে।
JavaScript ওজন এবং বড় চাংকগুলো চেক করুন। নতুন ডিপেন্ডেন্সি, ডুপ্লিকেট লাইব্রেরি, বা বড় ফিচার আছে কি দেখুন।
উপরের‑ভিউ ইমেজগুলো স্ক্যান করুন সাধারণ ভুলের জন্য (কমপ্রেস করা নেই, ভুল ডাইমেনশন, রেসপন্সিভ সোর্স নেই)।
তৃতীয়‑পক্ষ ট্যাগ রিভিউ করুন (অ্যানালিটিক্স, চ্যাট, A/B টেস্ট)। একটি নতুন ট্যাগ বড় ডাউনলোড ও লং টাস্ক যোগ করতে পারে।
নেটওয়ার্ক ও CPU একসাথে দেখুন: ধীরতা কি বাইট বাড়ায়নি, নাকি পেজ বেশি কাজ করছে?

দ্রুতই সবচেয়ে বড় সমস্যা খুঁজে পাওয়ার উপায়

দুইটি ভিউ মিনিটের মধ্যে উত্তর দেয়: নেটওয়ার্ক ওয়াটারফল এবং মেইন‑থ্রেড টাইমলাইন।

ওয়াটারফলে দেখুন কোনো একটি রিকোয়েস্ট কি ক্রিটিকাল পথ দখল করছে: একটি বিশাল স্ক্রিপ্ট, ব্লকিং ফন্ট, বা এমন ইমেজ যা দেরিতে শুরু হয়েছে। যদি LCP রিসোর্স আগে অনুরোধ না হয়, সার্ভার যত দ্রুতই সেবা দিক না কেন পেজ LCP বাজেট মেটাতে পারবে না।

টাইমলাইনে 50ms বা তার বেশি লং টাস্ক খুঁজুন। স্টার্টআপের আশপাশে লং টাস্কের ক্লাস্টার মানে প্রথম লোডে খুব বেশি JavaScript। এক বড় চাংক সাধারণত রাউটিং ইস্যু বা শেয়ার্ড বাণ্ডেলের ক্রপ বৃদ্ধি বোঝায়।

পরবর্তী টেস্টকে তুলনাযোগ্য রাখার নোট

দ্রুত অডিট ব্যর্থ হয় যখন প্রতিটি রান আলাদা। কিছু মৌলিক তথ্য ক্যাপচার করুন যাতে পরিবর্তন স্পষ্ট হয়: পেজ URL ও বিল্ড/ভার্সন, টেস্ট ডিভাইস ও নেটওয়ার্ক প্রোফাইল, LCP এলিমেন্টের বর্ণনা, আপনার ট্র্যাক করা মূল সংখ্যাগুলো (উদাহরণ: LCP, মোট JS বাইট, রিকোয়েস্ট কাউন্ট), এবং সবচেয়ে বড় অপরাধীর সংক্ষিপ্ত নোট।

ডেস্কটপ টেস্টিং দ্রুত ফিডব্যাকে ঠিক আছে এবং PR চেকের জন্য ভালো। যখন আপনি বাজেটের কাছে থাকেন, পেজ জাঙ্কি মনে হলে, বা ব্যবহারকারীরা বেশি মোবাইল হয়—তবে রিয়েল ডিভাইস ব্যবহার করুন। মোবাইল CPU‑তে লং টাস্ক স্পষ্ট হয়, আর বহুবার “আমার ল্যাপটপে ঠিক আছে” তত্ত্ব সেখানে ভেঙে পড়ে।

কী আগে ঠিক করবেন: সময় বাঁচানো কিছু সহজ নিয়ম

Stop bundle growth on React apps

Build a dashboard, set initial route caps, and catch dependency creep early.

Start Project

একবার বাজেট ফেল করলে সবকিছু অপ্টিমাইজ করা সবচেয়ে খারাপ কাজ। একটি পুনরাবৃত্ত triage অর্ডার ব্যবহার করুন যাতে প্রতিটি ফিক্সের ক্লিয়ার ফলাফল থাকে।

ব্যবহারিক ট্রায়াজ অর্ডার

ব্যবহারকারী যা সবচেয়ে বেশি লক্ষ্য করে তাতে শুরু করুন, তারপর সূক্ষ্ম টিউনিং‑এ নামুন:

উপরের‑ভিউ প্রধান উপাদানকে দ্রুত করুন। সবচেয়ে বড় কন্টেন্ট কোনটা তা খুঁজে প্রথমে সেই অ্যাসেট বা রেন্ডারিং পথ ঠিক করুন। ইমেজ রিসাইজ ও কমপ্রেস করুন, সঠিক ফরম্যাট ব্যবহার করুন, এবং লেট‑লোডিং ফন্ট এড়ান যা প্রথম ভিউ ব্লক করে।
CSS পালিশ করার চেয়ে JS কমান। যদি পেজে অতিরিক্ত JS শিপ হয়, সবকিছুই পিছনে পড়ে: ধীর পার্স, দীর্ঘ মেইন‑থ্রেড কাজ, দেরিতে রেন্ডারিং। অপ্রয়োজনীয় কোড সরান, ভারী রাউট স্প্লিট করুন, এবং সাধারণ UI‑এর জন্য সার্ভার‑রেন্ডার বা স্ট্যাটিক কন্টেন্ট পছন্দ করুন।
শুরুতেই থার্ড‑পার্টি স্ক্রিপ্ট নিয়ন্ত্রণ করুন। চ্যাট উইজেট, অ্যানালিটিক্স, ট্যাগ ম্যানেজার, A/B টুল বড় ডাউনলোড ও লং টাস্ক যোগ করতে পারে। যেটা প্রথম ভিউতে দরকার নেই, তা বিলম্বিত করুন। দরকারী না হলে, সরিয়ে দিন।
ডিজাইনে লেআউট শিফট বন্ধ করুন। ইমেজ, অ্যাড, এমবেডের জন্য স্পেস رزার্ভ করুন। width/height সেট করুন, স্থিতিশীল প্লেসবহোল্ডার ব্যবহার করুন, এবং লোডের পরে বিদ্যমান কন্টেন্টের উপর UI ইনজেক্ট করা এড়ান।
ইন্টার‌্যাকশন জটিল হলে লং টাস্ক মেরে ফেলুন। যখন INP খারাপ, ভারী ক্লায়েন্ট‑সাইড কাজ দেখুন: বড় রেন্ডার, ব্যয়বহুল স্টেট আপডেট, বড় JSON প্রসেসিং। কাজ ছোট করে ভাগ করুন, রি‑রেন্ডার কমান, এবং নন‑UI কাজ ক্রিটিকাল পাথ থেকে সরিয়ে দিন।

একটি দ্রুত উদাহরণ

এক দল একটি নতুন ড্যাশবোর্ড শিপ করে এবং হঠাৎ LCP বাজেট মিস করে। তারা কেশ হেডার পালিশ করার আগে লক্ষ্য করে LCP এলিমেন্ট একটি ফুল‑উইডথ চার্ট ইমেজ। তারা সেটি রিসাইজ করে, হালকা ফরম্যাটে সার্ভ করে, এবং শুধু প্রয়োজনীয় অংশই প্রথমে লোড করে। পরবর্তীতে তারা লক্ষ্য করে বড় চার্টিং লাইব্রেরিটা প্রতিটি রাউটে লোড হচ্ছে। তারা সেটি কেবল অ্যানালিটিক্স পেজে লোড করে এবং একটি তৃতীয়‑পক্ষ সাপোর্ট উইজেট প্রথম ইন্টার‌্যাকশনের পর লোড করে। এক দিনের মধ্যে ড্যাশবোর্ড বাজেটে ফিরে আসে এবং পরবর্তী রিলিজে স্পষ্ট “কি পরিবর্তিত হলো” উত্তর থাকে।

পারফরম্যান্স বাজেট নিয়ে দলগুলো যে সাধারণ ভুলগুলো করে

বড়তর ব্যর্থতা হলো বাজেটকে এক‑বারের ডকুমেন্ট মনে করা। বাজেট তখনই কাজ করে যখন তারা সহজে চেক করা যায়, উপেক্ষা করা কঠিন, এবং আপনার শিপিং প্রক্রিয়ার সাথে জড়িত।

বাজেট ব্যর্থ করতে যেসব ভুল করা হয়

বেশিরভাগ দল কয়েকটি ফাঁদে পড়ে:

প্রথমদিনে খুব বেশি বাজেট সেট করা, বা এত কড়া করা যে প্রতিটি বিল্ড ফেল করে।
প্রতিবার আলাদা সেটিংস দিয়ে মাপা (ডিভাইস, থ্রটলিং, ক্যাশ স্টেট, টেস্ট পেজ)।
ল্যাব স্কোরের পিছনে ছুটে বাস্তব ব্যবহারকারীর যন্ত্রণা মিস করা।
একটি বড় ডিপেন্ডেন্সি চুপিচুপি ঢুকতে দেওয়া।
পারফরম্যান্সকে একটি শেষ করা প্রজেক্ট হিসেবে দেখা, না যে একটি রিলিজ নিয়ম।

একটি সাধারণ প্যাটার্ন হলো একটি “ছোট” ফিচার নতুন লাইব্রেরি টানছে। বাণ্ডেল বড় হয়, LCP ধীর হয়, এবং কেউ লক্ষ্য করে না যতক্ষণ না সাপোর্ট টিকিট আসে। বাজেটগুলো রিভিউ সময়ে সেই পরিবর্তনটিকে দৃশ্যমান করে তোলে।

কিভাবে এড়াবেন

সহজ শুরু করুন এবং চেকগুলো ধারাবাহিক রাখুন। 2–4টি বাজেট বেছে নিন যা ব্যবহারকারী অভিজ্ঞতার সাথে মানায় এবং ধীরে ধীরে সেগুলো কড়া করুন। আপনার টেস্ট সেটআপ লক করে লিখে রাখুন। সম্ভব হলে অন্তত একটি রিয়েল‑ইউজার সিগন্যাল ট্র্যাক করুন, এবং ল্যাব টেস্টগুলোকে “কেন” বোঝাতে ব্যবহার করুন—বিতর্ক জেতার জন্য নয়। একটি ডিপেন্ডেন্সি অর্থবহভাবে ওজন বাড়ালে একটি সংক্ষিপ্ত নোট বাধ্যতামূলক করুন: এটা কত খরচ করছে, কি প্রতিস্থাপন করে, এবং কেন এটা প্রয়োজনীয়। সবচেয়ে জরুরি হলো বাজেট চেককে সাধারণ রিলিজ পথে লাগানো।

যদি বাজেটগুলো কনস্ট্যান্ট friction মনে হয়, এর মানে তারা সম্ভবত আজকের জন্য অতিরিক্ত বাস্তববিরোধী বা বাস্তব সিদ্ধান্তের সাথে সংযুক্ত নয়। প্রথমে এই দুটি সমস্যা ঠিক করুন।

উদাহরণ: একটি ধীর হয়ে যাওয়া ওয়েব অ্যাপকে বাজেটভিত্তিক রিলিজ প্রক্রিয়ায় পরিণত করা

Test changes without regret

Experiment freely, then roll back instantly when a change breaks your budget.

Use Snapshots

একটি ছোট দল একটি React অ্যানালিটিক্স ড্যাশবোর্ড সপ্তাহে শিপ করে। প্রথমে এটি ফাস্ট মনে হলো, কিন্তু প্রতি শুক্রবার রিলিজ একটু একটু করে ভারী হয়ে উঠলো। এক মাস পরে ব্যবহারকারীরা বলছে প্রথম স্ক্রিন "হ্যাং" করে এবং ফিল্টারগুলো জ্যাগি।

তারা “পর্যাপ্ত দ্রুত” নিয়া তর্ক বন্ধ করে এবং ব্যবহারকারীর নজরে পড়া মেট্রিক্সে বাজেট লিখে রাখে:

LCP: mid‑range ফোনে 4G‑এ 2.5s
INP: সাধারণ অ্যাকশনের জন্য 200ms-এর নিচে
JavaScript: ইনিশিয়াল রুটের জন্য 250KB gzip, প্রতি নতুন ফিচারের জন্য স্পষ্ট ক্যাপ
Images: আনকমপ্রেস্ড হিরো ইমেজ নেই, এবং প্রতিটি কম্পোনেন্টের মেয়াদী পিক্সেল সাইজ সীমা

প্রথম ফেল দুই জায়গায় দেখা দিল। ইনিশিয়াল JS বাণ্ডেল চার্ট, ডেট লাইব্রেরি, এবং একটি UI kit যোগ হওয়ায় ক্রিপ করেছে। একই সঙ্গে ড্যাশবোর্ড হেডার ইমেজ বড় ফাইলে বদলে গেলে LCP সীমা ছাড়ায়। INP খারাপ হলো কারণ প্রতিটি ফিল্টার পরিবর্তন মেইন‑থ্রেডে ভারী রি‑রেন্ডার এবং ব্যয়বহুল গণনা ট্রিগার করছিল।

তারা দ্রুতই এমনভাবে ঠিক করে যাতে দ্রুত ফল দেখা যায় এবং পুনরাবৃত্তি বন্ধ হয়:

LCP আগে লাইনে নিয়ে আসা: ইমেজ রিসাইজ ও কমপ্রেস, স্পষ্ট ইমেজ ডাইমেনশন সেট, ও ব্লকিং ফন্ট লোড এড়ানো।
ইনিশিয়াল JS কমানো: অপ্রয়োজনীয় লাইব্রেরি বাদ, নন‑ক্রিটিকাল রাউট স্প্লিটিং, এবং চার্ট লেজি‑লোড করা।
INP উন্নত করা: ব্যয়বহুল কম্পোনেন্ট মেমোইজ করা, টাইপিং ফিল্টার ডিবাউন্স করা, ও ভারী কাজ হট পাথ থেকে সরিয়ে নেওয়া।
প্রতিটি রিলিজে বাজেট চেক যোগ করা যাতে কোনো মেট্রিক ভাঙলে রিলিজ অপেক্ষা করে।

দুই রিলিজ পরে LCP 3.4s থেকে 2.3s এ নেমে আসে, এবং INP একই টেস্ট ডিভাইসে প্রায় 350ms থেকে 180ms‑এর নিচে আসে।

চেকলিস্ট এবং পরবর্তী ধাপ (হালকা Koder.ai ওয়ার্কফ্লো সহ)

বাজেট তখনই কাজে আসে যখন সবাই একভাবে একে অনুসরণ করে। ছোট রাখুন, লিখে রাখুন, এবং শিপিং‑এর অংশ বানান।

কিছু মেট্রিক বেছে নিন যা আপনার অ্যাপের সাথে মেলে, “warn vs fail” থ্রেশহোল্ড সেট করুন, এবং ঠিক কীভাবে টেস্ট করবেন তা ডকুমেন্ট করুন (ডিভাইস, ব্রাউজার, নেটওয়ার্ক, পেজ/ফ্লো)। বর্তমান সেরা রিলিজ থেকে একটি বেসলাইন রিপোর্ট সংরক্ষণ করুন এবং স্পষ্টভাবে লেবেল করুন। কোন এক্সসেপশন বৈধ হবে এবং কোনটি নয় তা ঠিক করুন।

প্রতিটি রিলিজের আগে একই অডিট চালান এবং তা বেসলাইন‑এর সাথে তুলনা করুন। কিছু রিগ্রেস করলে সেটি বাগ ট্র্যাকে লগ করুন এবং এটাকে একটি ভাঙা চেকআউট স্টেপ হিসেবে আচরণ করুন, “পরে” কাজ হিসেবে নয়। যদি আপনি এক্সসেপশন নিয়ে শিপ করেন, একটি মালিক ও মেয়াদ (প্রায় 1–2 স্প্রিন্ট) রেকর্ড করুন। যদি এক্সসেপশন বারবার নবায়ন হয়, বাজেটের উপর প্রকৃত আলোচনা দরকার।

বাজেটগুলো পরিকল্পনা ও এস্টিমেটিং‑এ আগে নিয়ে আসুন: “এই স্ক্রিন একটি চার্ট লাইব্রেরি যোগ করছে, তাই আমাদের অন্য কোথাও কিছু সরাতে হবে বা এটি লেজি‑লোড করতে হবে।” যদি আপনি Koder.ai (Koder.ai) দিয়ে তৈরি করে থাকেন, আপনি এগুলো Planning Mode‑এ আগে লিখে রাখতে পারেন, তারপর ছোট স্লাইসে ইটারেট করুন এবং স্ন্যাপশট ও রোলব্যাক ব্যবহার করুন যখন কোনো পরিবর্তন কেবল একটি ক্যাপ পেরিয়ে যায়। উদ্দেশ্য টুল নয়—অভ্যাস: প্রতিটি নতুন ফিচার তার ওজনের জন্য দায়ী নয় তবে শিপ করবে না।

সাধারণ প্রশ্ন

What is a performance budget, in plain terms?

A performance budget is a set of hard limits (time, size, requests, CPU work) that your team agrees to before building.

If a change exceeds the limit, treat it like a broken requirement: fix it, reduce scope, or explicitly approve an exception with an owner and an expiry date.

Why do we need budgets instead of just “caring about performance”?

Because performance gets worse gradually. Each feature adds JavaScript, CSS, images, fonts, API calls, and third‑party tags.

Budgets stop the slow creep by forcing a tradeoff: if you add weight or work, you must pay it back (lazy-load, split a route, simplify UI, remove a dependency).

What page or flow should we budget first?

Pick one real user journey and one consistent test setup.

A good starter is something frequent and business-critical, like:

first load after login to the dashboard
home → signup
checkout confirmation

Avoid edge cases at first; you want a flow you can measure every release.

How do we choose a device and network target without overcomplicating it?

Start with one target that matches typical users, for example:

a mid-range phone
4G (not office Wi‑Fi)
cold load plus one key navigation

Write it down and keep it stable. If you change device, network, cache state, or the path you test, your trend becomes noise.

Which metrics make the best performance budgets?

Use a small set that covers both what users feel and what teams can control:

Timing: LCP, INP, CLS
Size: initial route JS gzip (and/or CSS)
Media: bytes for images in the first view

Timing metrics show the pain; size and runtime limits help you quickly find what caused it.

What are realistic starter numbers for budgets?

A practical starter set is:

LCP: warn at 2.5s, fail at 3.0s (mobile, cold load)
INP: warn at 200ms, fail at 300ms (common interactions)
CLS: warn at 0.10, fail at 0.15
Initial JS (app code): warn 170KB gzip, fail 220KB gzip
Images (first screen): warn 800KB, fail 1.2MB

Pick 3–5 budgets first. Tune later based on your baseline and release history.

What’s the point of having “warn” and “fail” thresholds?

Use two thresholds:

Warn: signals you’re drifting; you can merge but should investigate.
Fail: blocks a release or requires explicit approval.

This avoids constant fire drills while still making the limits real when you cross the line.

What should we do the moment a budget fails?

Do this in order:

Confirm the LCP element didn’t change (a different hero can swing results).
Check what grew: JS bytes, image bytes, request count, third‑party tags.
Look for long tasks (50ms+) around startup; they often explain “it loads but feels sticky.”
Fix the biggest offender first (usually an above-the-fold image, a new dependency, or a route that stopped code-splitting).

Treat the breach like a bug: identify the commit, fix or scope-reduce, and prevent repeats.

Why can a React app feel slow even when the bundle size budget passes?

Not always. Bundle size can be fine while the page still feels slow because the main thread is busy.

Common React causes:

heavy hydration work
expensive re-renders on first interaction
large components doing too much client-side rendering

Add a runtime budget (for example, limit long tasks during startup or set a hydration time cap) to catch this class of issues.

How do performance budgets fit teams building quickly with tools like Koder.ai?

Fast generation and iteration can quietly add dependencies, UI flourishes, and third-party scripts that ship to everyone.

The fix is to make budgets part of the workflow:

write budgets into planning (what page, what limits, what test setup)
run quick checks on every release (or PR)
use snapshots/rollback if a change pushes you over a cap

This keeps fast iteration from turning into a slow product.