০৮ অক্টো, ২০২৫·7 মিনিট
কার্যকর পারফরম্যান্স বাজেট: দ্রুত ওয়েব অ্যাপের জন্য বাস্তব সীমা
পারফরম্যান্স বাজেট ওয়েব অ্যাপকে দ্রুত রাখতে সহায় করে: লোড টাইম, JS সাইজ, Core Web Vitals‑এর স্পষ্ট সীমা সেট করে, দ্রুত অডিট এবং ফিক্স‑ফার্স্ট নিয়ম সরবরাহ করে।
পারফরম্যান্স বাজেট ওয়েব অ্যাপকে দ্রুত রাখতে সহায় করে: লোড টাইম, JS সাইজ, Core Web Vitals‑এর স্পষ্ট সীমা সেট করে, দ্রুত অডিট এবং ফিক্স‑ফার্স্ট নিয়ম সরবরাহ করে।
পারফরম্যান্স বাজেট হল এমন কিছু সীমা যা আপনি নির্মাণ শুরু করার আগে ঠিক করেন। এটা সময় সীমানা হতে পারে (পেজটি কতো দ্রুত লাগে), আকারের সীমানা হতে পারে (কত কোড পাঠানো হচ্ছে), বা রিকোয়েস্ট/ইমেজ/থার্ড‑পার্টি স্ক্রিপ্টের একটি সরল ক্যাপ হতে পারে। যদি আপনি সেই সীমা ছাড়িয়ে যান, সেটাকে “পরবর্তীতে ঠিক করা যাবে” নয়—বরং ভাঙা রিকোয়্যারমেন্ট হিসেবে বিবেচনা করুন।
গতি সাধারণত খারাপ হয় কারণ ডেলিভারি সংযোজিত: প্রতিটি নতুন উইজেট JavaScript, CSS, ফন্ট, ইমেজ, API কল ইত্যাদি যোগ করে এবং ব্রাউজারের কাজ বাড়ে। ছোট পরিবর্তনগুলো মিলিয়ে একসময় অ্যাপ ভারী মনে হয়, বিশেষ করে মধ্যমানের ফোন এবং ধীর নেটওয়ার্কে যেখানে বেশিরভাগ ব্যবহারকারী থাকে।
মতামত এখানে রক্ষা করে না। একজন বলে “আমার ল্যাপটপে ঠিক আছে,” আরেকজন বলে “ধীর,” এবং দল বিতর্কে পড়ে। একটি বাজেট বিতর্ক শেষ করে—পারফরম্যান্সকে পরিমাপযোগ্য ও বাধ্যতামূলক প্রোডাক্ট কনস্ট্রেন্টে পরিণত করে।
Addy Osmani–র ভাবনার সাথে এটা মিলে: পারফরম্যান্সকে ডিজাইন কনস্ট্রেন্ট ও সিকিউরিটির নীতির মতো বিবেচনা করুন। আপনি “চেষ্টা” করে সিকিউর থাকতে পারেন না বা “আশা” করতে পারেন না লেআউট ঠিক থাকবে—মানক সেট করেন, ক্রমাগত যাচাই করেন, এবং এমন পরিবর্তন ব্লক করেন যা ভাঙে।
বাজেট কয়েকটি বাস্তব সমস্যা একসাথে সমাধান করে: তারা ট্রেড‑অফ স্পষ্ট করে (ফিচার বাড়ালে অন্য কোথাও দাম দিতে হবে), রিগ্রেশন দ্রুত ধরতে পারে (যখন ফিক্স সস্তা), এবং সবাইকে একই সংজ্ঞা দেয় “পর্যাপ্ত দ্রুততা” কিসে। এছাড়া লঞ্চের আগের দফায় দেখা ফ্রিকশনও কমায়।
বাজেটের জন্য তৈরি পরিস্থিতি এমন: আপনি একটি ড্যাশবোর্ডের জন্য একটি সমৃদ্ধ চার্টিং লাইব্রেরি যোগ করেন। সেটা সবার কাছে পৌঁছে যায়, প্রধান বাণ্ডেল বাড়ায় এবং প্রথম অর্থপূর্ণ স্ক্রিন দেরি করে। বাজেট না থাকলে এটা হারিয়ে যায় কারণ ফিচার “চালু” আছে। বাজেট থাকলে টিমকে নির্বাচন করতে হবে: চার্ট লেজি‑লোড করা, লাইব্রেরি পরিবর্তন করা, বা ভিউ সরল করা।
এটি আরও জরুরি যখন দল দ্রুত অ্যাপ তৈরি ও ইটারেট করতে পারে, এমনকি চ্যাট‑ড্রিভেন বিল্ড ওয়ার্কফ্লো যেমন Koder.ai‑সহ। গতি দারুণ, কিন্তু এটি সহজে অতিরিক্ত ডিপেন্ডেন্সি এবং UI সুপারফ্লুটালীটি নিঃশব্দে শিপ করে ফেলতে পারে। বাজেট দ্রুত ইটারেশনকে ধীর প্রোডাক্টে বদলাতে বাধা দেয়।
পারফরম্যান্স কাজ ব্যর্থ হয় যখন আপনি সবকিছু মাপেন কিন্তু কারো দায়িত্ব নেই। একটি গুরুত্বপূর্ণ পেজ ফ্লো বাছুন যা প্রকৃত ব্যবহারকারীদের জন্য গুরুত্বপূর্ণ, এবং সেটাকেই বাজেটগুলোর কেন্দ্র হিসেবে ধরুন।
ভালো শুরু হলো একটি প্রাইমারি জার্নি যেখানে গতি কনভার্শন বা দৈনন্দিন কাজ প্রভাবিত করে, যেমন “হোম থেকে সাইনআপ,” “লগইনের পর ড্যাশবোর্ডের প্রথম লোড,” বা “চেকআউট ও পেমেন্ট কনফার্মেশন।” প্রতিনিধিত্বশীল ও ঘন ঘন ব্যবহৃত কিছু বেছে নিন, এজ কেস নয়।
আপনার অ্যাপ আপনার ল্যাপটপে চলে না। একটি বাজেট যা ফাস্ট মেশিনে ঠিক লাগে, সেটি একটি মধ্যমানের ফোনে ধীর মনে হতে পারে।
একটি ডিভাইস ক্লাস এবং একটি নেটওয়ার্ক প্রোফাইল দিয়ে শুরু করুন। সহজ রাখুন এবং এক বাক্যে লিখে রাখুন যাতে সবাই তা পুনরাবৃত্তি করতে পারে।
উদাহরণ: গত 2–3 বছরের মধ্যমানের একটি Android ফোন, চলন্ত অবস্থায় 4G‑এ (অফিস Wi‑Fi নয়), একটি কোল্ড লোড মাপছি এবং তারপর একটি মূল নেভিগেশন, সেই একই রিজিয়নে যেখানে বেশিরভাগ ব্যবহারকারী।
এটি সবচেয়ে খারাপ কেস বাছাই করার বলে না—বরং এমন একটি সাধারণ কেস যেটার জন্য আপনি সত্যিই অপ্টিমাইজ করতে পারবেন।
সংখ্যা কেবল তখনই মানে রাখে যখন তারা তুলনাযোগ্য। যদি এক রানের পারফরম্যান্স “Chrome এক্সটেনশন সহ MacBook” আর পরেরটি “থ্রটল করা মোবাইল” হয়, তখন ট্রেন্ড লাইন শব্দে পরিণত হয়।
একটি বেসলাইন এনভায়রনমেন্ট বেছে নিন এবং বাজেট পরীক্ষায় সেটাই ব্যবহার করুন: একই ব্রাউজার ভার্সন, একই থ্রটলিং সেটিং, একই টেস্ট পাথ, এবং একই ক্যাশ স্টেট (কোল্ড বা ওয়ার্ম)। রিয়েল ডিভাইস ব্যবহার করলে একই ডিভাইস মডেল ব্যবহার করুন।
এখন “পর্যাপ্ত দ্রুত” কী বোঝায় তা আচরণগতভাবে সংজ্ঞায়িত করুন, নিখুঁত ডেমো নয়। উদাহরণ: “ব্যবহারকারীরা দ্রুত কনটেন্ট পড়া শুরু করতে পারে” বা “লগইনের পর ড্যাশবোর্ড প্রতিক্রিয়াশীল অনুভব করে।” এটিকে এক‑ দুটো মেট্রিক্সে অনুবাদ করুন এবং তাদের চারপাশে বাজেট সেট করুন।
বাজেট সেরা কাজ করে যখন তারা ব্যবহারকারীর অনুভূতি এবং টিম যা নিয়ন্ত্রণ করতে পারে—উভয়কেই কভার করে। ভালো সেট অভিজ্ঞতা মেট্রিক্স (“এটা কেমন দ্রুত অনুভূত হলো?”) এবং রিসোর্স ও CPU সীমা (“কেন এটা ধীর হলো?”) মিশায়।
এগুলো ট্র্যাক করে পেজ বাস্তবে কেমন আচরণ করে। সবচেয়ে উপযোগীগুলো সরাসরি Core Web Vitals‑এর সাথে মানায়:
টাইমিং বাজেটগুলো আপনার নর্থস্টার কারণ এগুলো ব্যবহারকারীর হতাশার সাথে মিলছে। কিন্তু এগুলো সবসময় বলে না কী ঠিক করতে, তাই নীচের বাজেটগুলোও দরকার।
এসব বিল্ড ও রিভিউতে সহজে কার্যকর করা যায় কারণ এগুলো কংক্রিট।
ওয়েট বাজেটগুলো মোট JavaScript, মোট CSS, ইমেজ ও ফন্টের ওজন সীমাবদ্ধ করে। রিকোয়েস্ট বাজেটগুলো মোট রিকোয়েস্ট সংখ্যা ও তৃতীয়‑পক্ষ স্ক্রিপ্টের ক্যাপ করে, নেটওয়ার্ক ওভারহেড কমায় এবং ট্যাগ/উইজেট/ট্র্যাকার থেকে “সারপ্রাইজ” কাজ কমায়। রানটাইম বাজেটগুলো লং টাস্ক, মেইন‑থ্রেড টাইম, এবং হাইড্রেশন টাইম সীমাবদ্ধ করে (বিশেষ করে React‑এর জন্য), যা প্রায়শই বোঝায় কেন একটি পেজ মাঝারি ফোনে “ভারি” অনুভূত হয়।
একটি বাস্তব React উদাহরণ: বাণ্ডেল সাইজ ঠিক আছে মনে হতে পারে, কিন্তু একটি নতুন ক্যারসেল ভারী ক্লায়েন্ট‑সাইড রেন্ডারিং যোগ করে। পেজ লোড হয়, তবু ফিল্টার ট্যাপ করার সময় আটকে যায় কারণ হাইড্রেশন মেইন‑থ্রেড ব্লক করছে। একটি রানটাইম বাজেট যেমন “স্টার্টআপে X ms‑এর বেশি লং টাস্ক নেই” বা “মিড‑টিয়ার ডিভাইসে Y সেকেন্ডের মধ্যে হাইড্রেশন শেষ” এমন ঘটনাগুলো ধরতে পারে—যদিও ওজন বাজেট ধরতে না পারে।
শক্তিশালী পদ্ধতি এগুলোকে একটি সিস্টেম হিসেবে দেখা: অভিজ্ঞতা বাজেট সাফল্য সংজ্ঞায়িত করে, আর সাইজ/রিকোয়েস্ট/রানটাইম বাজেট রিলিজগুলোকে সতর্ক রাখে এবং “কী পরিবর্তিত হলো?” সহজ করে তোলে।
আপনি যদি অনেক সীমা সেট করেন, মানুষ মনোযোগ দিতে ছেড়ে দেবে। 3–5টি বাজেট বেছে নিন যা ব্যবহারকারী অনুভূতিকে সবচেয়ে মিলায় এবং যা আপনি প্রতিটি PR বা রিলিজে মাপতে পারবেন।
একটি ব্যবহারিক শুরু সেট (সংখ্যাগুলো পরে টিউন করুন):
দুটি থ্রেশহোল্ড ব্যাপারটাকে সহজ রাখে। “Warn” বলছে আপনি ড্রিফট করছেন। “Fail” রিলিজ ব্লক করে বা স্পষ্ট অনুমোদন দাবি করে। এটা সীমাটিকে বাস্তব করে তোলে, সবসময় আগাজাগ্রত করে না।
বাজেট একটি শেয়ার করা জায়গায় লিখে রাখুন যাতে ব্যস্ত রিলিজে কেউ তা নিয়ে তর্ক না করে। সংক্ষিপ্ত এবং নির্দিষ্ট রাখুন: কোন পেজ/ফ্লো কভার করা হয়, কোথায় মাপ নেওয়া হয় (লোকাল অডিট, CI, স্টেজড বিল্ড), কোন ডিভাইস ও নেটওয়ার্ক প্রোফাইল ব্যবহার করা হয়, এবং মেট্রিক্স ঠিক কীভাবে সংজ্ঞায়িত (ফিল্ড বনাম ল্যাব, gzip বনাম র’/রুট, রুট‑লেভেল বনাম পুরো অ্যাপ)।
একটি পুনরাবৃত্তিযোগ্য বেসলাইন দিয়ে শুরু করুন। এক বা দুইটি কী পেজ বেছে নিন এবং প্রতিবার একই ডিভাইস প্রোফাইল ও নেটওয়ার্কে টেস্ট চালান। টেস্টটি অন্তত তিনবার চালান এবং মিডিয়ান রেকর্ড করুন যাতে একটি অদ্ভুত রান আপনার দিকনির্দেশ নির্ধারণ না করে।
একটি সরল বেসলাইন শীট রাখুন যেটায় একটি ইউজার মেট্রিক এবং একটি বিল্ড মেট্রিক আছে। উদাহরণ: পেজের LCP ও INP, সঙ্গে মোট JavaScript সাইজ ও মোট ইমেজ বাইট। এটি বাজেটগুলো বাস্তব মনে করায় কারণ আপনি দেখতে পান অ্যাপ কী শিপ করেছে, কেবল ল্যাব অনুমান নয়।
বাজেটগুলো আজকের চেয়ে একটু ভালো সেট করুন, ফ্যান্টাসি সংখ্যা নয়। একটি সলিড নিয়ম হলো প্রতিটি মেট্রিকের আপনার বর্তমান মিডিয়ান থেকে 5–10% উন্নতি। যদি আপনার বেসলাইনে LCP 3.2s হয়, সরাসরি 2.0s‑এ নেমে যান না—প্রথমে 3.0s ঠিক করুন, তারপর ধরে রেখে ধীরেধীরে কষে নিন।
প্রতিটি রিলিজের আগে একটি দ্রুত চেক যোগ করুন যাতে ব্যবহারকারীদের আগে এটি চলে। এটা এত দ্রুত রাখুন যাতে মানুষ এড়িয়ে না যায়। একটি সরল ভার্সন: সম্মত পেজে একটি সিঙ্গেল‑পেজ অডিট চালান, যদি JS বা ইমেজ বাজেট ছাড়িয়ে যায় তাহলে বিল্ড ফেল করুন, কমিট প্রতি ফলাফল সংরক্ষণ করুন যাতে দেখা যায় কখন পরিবর্তন হয়েছে, এবং একই URL প্যাটার্ন টেস্ট করুন (র্যান্ডম ডেটা নয়)।
ব্রিচগুলো সপ্তাহে একবার রিভিউ করুন, কেবলই কেউ অভিযোগ করলে নয়। একটি ব্রিচকে একটি বাগের মতো বিবেচনা করুন: পরিবর্তনটি চিহ্নিত করুন, এখন কী ঠিক করা হবে এবং কী সময়সূচিতে রাখা হবে ঠিক করুন। ধীরে ধীরে কঠোর করুন—শুধু কয়েকটি রিলিজ ধরে রেখার পরই।
প্রডাক্ট স্কোপ বদলে গেলে বাজেটগুলো সচেতনভাবে আপডেট করুন। যদি আপনি একটি নতুন অ্যানালিটিক্স টুল বা একটি ভারী ফিচার যোগ করেন, লিখে নিন কী বৃদ্ধি পেয়েছে (সাইজ, রিকোয়েস্ট, রানটাইম), পরে দিচ্ছেন কীভাবে তা পরিশোধ করবেন, এবং কখন বাজেট ফিরে আসবে।
একটি বাজেট তখনই সাহায্য করবে যখন আপনি দ্রুত তা চেক করতে পারবেন। 10 মিনিটের অডিটের লক্ষ্য নিখুঁত সংখ্যা প্রমাণ করা নয়—পরিবর্তিত কি হয়েছে তা শনাক্ত করে প্রথমে কী ঠিক করতে হবে তা নির্ধারণ করা।
একটি বাস্তব ব্যবহার প্রদর্শন করে এমন পেজ দিয়ে শুরু করুন। তারপর প্রতিবার একই দ্রুত চেকগুলো চালান:
দুইটি ভিউ মিনিটের মধ্যে উত্তর দেয়: নেটওয়ার্ক ওয়াটারফল এবং মেইন‑থ্রেড টাইমলাইন।
ওয়াটারফলে দেখুন কোনো একটি রিকোয়েস্ট কি ক্রিটিকাল পথ দখল করছে: একটি বিশাল স্ক্রিপ্ট, ব্লকিং ফন্ট, বা এমন ইমেজ যা দেরিতে শুরু হয়েছে। যদি LCP রিসোর্স আগে অনুরোধ না হয়, সার্ভার যত দ্রুতই সেবা দিক না কেন পেজ LCP বাজেট মেটাতে পারবে না।
টাইমলাইনে 50ms বা তার বেশি লং টাস্ক খুঁজুন। স্টার্টআপের আশপাশে লং টাস্কের ক্লাস্টার মানে প্রথম লোডে খুব বেশি JavaScript। এক বড় চাংক সাধারণত রাউটিং ইস্যু বা শেয়ার্ড বাণ্ডেলের ক্রপ বৃদ্ধি বোঝায়।
দ্রুত অডিট ব্যর্থ হয় যখন প্রতিটি রান আলাদা। কিছু মৌলিক তথ্য ক্যাপচার করুন যাতে পরিবর্তন স্পষ্ট হয়: পেজ URL ও বিল্ড/ভার্সন, টেস্ট ডিভাইস ও নেটওয়ার্ক প্রোফাইল, LCP এলিমেন্টের বর্ণনা, আপনার ট্র্যাক করা মূল সংখ্যাগুলো (উদাহরণ: LCP, মোট JS বাইট, রিকোয়েস্ট কাউন্ট), এবং সবচেয়ে বড় অপরাধীর সংক্ষিপ্ত নোট।
ডেস্কটপ টেস্টিং দ্রুত ফিডব্যাকে ঠিক আছে এবং PR চেকের জন্য ভালো। যখন আপনি বাজেটের কাছে থাকেন, পেজ জাঙ্কি মনে হলে, বা ব্যবহারকারীরা বেশি মোবাইল হয়—তবে রিয়েল ডিভাইস ব্যবহার করুন। মোবাইল CPU‑তে লং টাস্ক স্পষ্ট হয়, আর বহুবার “আমার ল্যাপটপে ঠিক আছে” তত্ত্ব সেখানে ভেঙে পড়ে।
একবার বাজেট ফেল করলে সবকিছু অপ্টিমাইজ করা সবচেয়ে খারাপ কাজ। একটি পুনরাবৃত্ত triage অর্ডার ব্যবহার করুন যাতে প্রতিটি ফিক্সের ক্লিয়ার ফলাফল থাকে।
ব্যবহারকারী যা সবচেয়ে বেশি লক্ষ্য করে তাতে শুরু করুন, তারপর সূক্ষ্ম টিউনিং‑এ নামুন:
এক দল একটি নতুন ড্যাশবোর্ড শিপ করে এবং হঠাৎ LCP বাজেট মিস করে। তারা কেশ হেডার পালিশ করার আগে লক্ষ্য করে LCP এলিমেন্ট একটি ফুল‑উইডথ চার্ট ইমেজ। তারা সেটি রিসাইজ করে, হালকা ফরম্যাটে সার্ভ করে, এবং শুধু প্রয়োজনীয় অংশই প্রথমে লোড করে। পরবর্তীতে তারা লক্ষ্য করে বড় চার্টিং লাইব্রেরিটা প্রতিটি রাউটে লোড হচ্ছে। তারা সেটি কেবল অ্যানালিটিক্স পেজে লোড করে এবং একটি তৃতীয়‑পক্ষ সাপোর্ট উইজেট প্রথম ইন্টার্যাকশনের পর লোড করে। এক দিনের মধ্যে ড্যাশবোর্ড বাজেটে ফিরে আসে এবং পরবর্তী রিলিজে স্পষ্ট “কি পরিবর্তিত হলো” উত্তর থাকে।
বড়তর ব্যর্থতা হলো বাজেটকে এক‑বারের ডকুমেন্ট মনে করা। বাজেট তখনই কাজ করে যখন তারা সহজে চেক করা যায়, উপেক্ষা করা কঠিন, এবং আপনার শিপিং প্রক্রিয়ার সাথে জড়িত।
বেশিরভাগ দল কয়েকটি ফাঁদে পড়ে:
একটি সাধারণ প্যাটার্ন হলো একটি “ছোট” ফিচার নতুন লাইব্রেরি টানছে। বাণ্ডেল বড় হয়, LCP ধীর হয়, এবং কেউ লক্ষ্য করে না যতক্ষণ না সাপোর্ট টিকিট আসে। বাজেটগুলো রিভিউ সময়ে সেই পরিবর্তনটিকে দৃশ্যমান করে তোলে।
সহজ শুরু করুন এবং চেকগুলো ধারাবাহিক রাখুন। 2–4টি বাজেট বেছে নিন যা ব্যবহারকারী অভিজ্ঞতার সাথে মানায় এবং ধীরে ধীরে সেগুলো কড়া করুন। আপনার টেস্ট সেটআপ লক করে লিখে রাখুন। সম্ভব হলে অন্তত একটি রিয়েল‑ইউজার সিগন্যাল ট্র্যাক করুন, এবং ল্যাব টেস্টগুলোকে “কেন” বোঝাতে ব্যবহার করুন—বিতর্ক জেতার জন্য নয়। একটি ডিপেন্ডেন্সি অর্থবহভাবে ওজন বাড়ালে একটি সংক্ষিপ্ত নোট বাধ্যতামূলক করুন: এটা কত খরচ করছে, কি প্রতিস্থাপন করে, এবং কেন এটা প্রয়োজনীয়। সবচেয়ে জরুরি হলো বাজেট চেককে সাধারণ রিলিজ পথে লাগানো।
যদি বাজেটগুলো কনস্ট্যান্ট friction মনে হয়, এর মানে তারা সম্ভবত আজকের জন্য অতিরিক্ত বাস্তববিরোধী বা বাস্তব সিদ্ধান্তের সাথে সংযুক্ত নয়। প্রথমে এই দুটি সমস্যা ঠিক করুন।
একটি ছোট দল একটি React অ্যানালিটিক্স ড্যাশবোর্ড সপ্তাহে শিপ করে। প্রথমে এটি ফাস্ট মনে হলো, কিন্তু প্রতি শুক্রবার রিলিজ একটু একটু করে ভারী হয়ে উঠলো। এক মাস পরে ব্যবহারকারীরা বলছে প্রথম স্ক্রিন "হ্যাং" করে এবং ফিল্টারগুলো জ্যাগি।
তারা “পর্যাপ্ত দ্রুত” নিয়া তর্ক বন্ধ করে এবং ব্যবহারকারীর নজরে পড়া মেট্রিক্সে বাজেট লিখে রাখে:
প্রথম ফেল দুই জায়গায় দেখা দিল। ইনিশিয়াল JS বাণ্ডেল চার্ট, ডেট লাইব্রেরি, এবং একটি UI kit যোগ হওয়ায় ক্রিপ করেছে। একই সঙ্গে ড্যাশবোর্ড হেডার ইমেজ বড় ফাইলে বদলে গেলে LCP সীমা ছাড়ায়। INP খারাপ হলো কারণ প্রতিটি ফিল্টার পরিবর্তন মেইন‑থ্রেডে ভারী রি‑রেন্ডার এবং ব্যয়বহুল গণনা ট্রিগার করছিল।
তারা দ্রুতই এমনভাবে ঠিক করে যাতে দ্রুত ফল দেখা যায় এবং পুনরাবৃত্তি বন্ধ হয়:
LCP আগে লাইনে নিয়ে আসা: ইমেজ রিসাইজ ও কমপ্রেস, স্পষ্ট ইমেজ ডাইমেনশন সেট, ও ব্লকিং ফন্ট লোড এড়ানো।
ইনিশিয়াল JS কমানো: অপ্রয়োজনীয় লাইব্রেরি বাদ, নন‑ক্রিটিকাল রাউট স্প্লিটিং, এবং চার্ট লেজি‑লোড করা।
INP উন্নত করা: ব্যয়বহুল কম্পোনেন্ট মেমোইজ করা, টাইপিং ফিল্টার ডিবাউন্স করা, ও ভারী কাজ হট পাথ থেকে সরিয়ে নেওয়া।
প্রতিটি রিলিজে বাজেট চেক যোগ করা যাতে কোনো মেট্রিক ভাঙলে রিলিজ অপেক্ষা করে।
দুই রিলিজ পরে LCP 3.4s থেকে 2.3s এ নেমে আসে, এবং INP একই টেস্ট ডিভাইসে প্রায় 350ms থেকে 180ms‑এর নিচে আসে।
বাজেট তখনই কাজে আসে যখন সবাই একভাবে একে অনুসরণ করে। ছোট রাখুন, লিখে রাখুন, এবং শিপিং‑এর অংশ বানান।
কিছু মেট্রিক বেছে নিন যা আপনার অ্যাপের সাথে মেলে, “warn vs fail” থ্রেশহোল্ড সেট করুন, এবং ঠিক কীভাবে টেস্ট করবেন তা ডকুমেন্ট করুন (ডিভাইস, ব্রাউজার, নেটওয়ার্ক, পেজ/ফ্লো)। বর্তমান সেরা রিলিজ থেকে একটি বেসলাইন রিপোর্ট সংরক্ষণ করুন এবং স্পষ্টভাবে লেবেল করুন। কোন এক্সসেপশন বৈধ হবে এবং কোনটি নয় তা ঠিক করুন।
প্রতিটি রিলিজের আগে একই অডিট চালান এবং তা বেসলাইন‑এর সাথে তুলনা করুন। কিছু রিগ্রেস করলে সেটি বাগ ট্র্যাকে লগ করুন এবং এটাকে একটি ভাঙা চেকআউট স্টেপ হিসেবে আচরণ করুন, “পরে” কাজ হিসেবে নয়। যদি আপনি এক্সসেপশন নিয়ে শিপ করেন, একটি মালিক ও মেয়াদ (প্রায় 1–2 স্প্রিন্ট) রেকর্ড করুন। যদি এক্সসেপশন বারবার নবায়ন হয়, বাজেটের উপর প্রকৃত আলোচনা দরকার।
বাজেটগুলো পরিকল্পনা ও এস্টিমেটিং‑এ আগে নিয়ে আসুন: “এই স্ক্রিন একটি চার্ট লাইব্রেরি যোগ করছে, তাই আমাদের অন্য কোথাও কিছু সরাতে হবে বা এটি লেজি‑লোড করতে হবে।” যদি আপনি Koder.ai (Koder.ai) দিয়ে তৈরি করে থাকেন, আপনি এগুলো Planning Mode‑এ আগে লিখে রাখতে পারেন, তারপর ছোট স্লাইসে ইটারেট করুন এবং স্ন্যাপশট ও রোলব্যাক ব্যবহার করুন যখন কোনো পরিবর্তন কেবল একটি ক্যাপ পেরিয়ে যায়। উদ্দেশ্য টুল নয়—অভ্যাস: প্রতিটি নতুন ফিচার তার ওজনের জন্য দায়ী নয় তবে শিপ করবে না।
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.
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).
Pick one real user journey and one consistent test setup.
A good starter is something frequent and business-critical, like:
Avoid edge cases at first; you want a flow you can measure every release.
Start with one target that matches typical users, for example:
Write it down and keep it stable. If you change device, network, cache state, or the path you test, your trend becomes noise.
Use a small set that covers both what users feel and what teams can control:
A practical starter set is:
Use two thresholds:
This avoids constant fire drills while still making the limits real when you cross the line.
Do this in order:
Not always. Bundle size can be fine while the page still feels slow because the main thread is busy.
Common React causes:
Add a runtime budget (for example, limit long tasks during startup or set a hydration time cap) to catch this class of issues.
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:
This keeps fast iteration from turning into a slow product.
Timing metrics show the pain; size and runtime limits help you quickly find what caused it.
Pick 3–5 budgets first. Tune later based on your baseline and release history.
Treat the breach like a bug: identify the commit, fix or scope-reduce, and prevent repeats.