08 ਅਕਤੂ 2025·8 ਮਿੰਟ

ਕਾਮਯਾਬ ਪ੍ਰਦਰਸ਼ਨ ਬਜਟ: ਤੇਜ਼ ਵੈੱਬ ਐਪਸ ਲਈ ਵਰਤੋਂਯੋਗ ਸੀਮਾਵਾਂ

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.

Performance ਬਜਟ ਤੇਜ਼ ਵੈੱਬ ਐਪਸ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ: ਲੋਡ ਸਮਾਂ, JS ਆਕਾਰ ਅਤੇ Core Web Vitals ਲਈ ਸਪੱਸ਼ਟ ਸੀਮਾਵਾਂ, ਤੇਜ਼ ਆਡਿਟ ਅਤੇ ਫਿਕਸ‑ਫਰਸਟ ਨਿਯਮ।

Performance ਨੂੰ ਨਿਰਾਸ਼ਾਵਾਦ ਨਾਲ ਨਹੀਂ, ਬਜਟ ਨਾਲ ਚਲਾਓ

ਇੱਕ performance budget ਉਹ ਸੀਮਾਵਾਂ ਹਨ ਜੋ ਤੁਸੀਂ ਬਿਲਡ ਤੋਂ ਪਹਿਲਾਂ ਸਹਿਮਤ ਕਰਦੇ ਹੋ। ਇਹ ਸਮੇਂ ਦੀ ਸੀਮਾ (ਪੰਨੇ ਦਾ ਅਨੁਭਵ), ਆਕਾਰ ਦੀ ਸੀਮਾ (ਕਿੰਨੀ ਕੋਡ ਸਪੁਰਦ ਕਰਦੇ ਹੋ), ਜਾਂ ਸਿਧਾ ਕੈਪ ਹੋ ਸਕਦੀ ਹੈ (ਨਿਮਨ-ਗਿਣਤੀ ਰਿਕਵੇਸਟ, ਚਿੱਤਰ, ਤੀਜੇ-ਪੱਖ ਸਕ੍ਰਿਪਟ)। ਜੇ ਤੁਸੀਂ ਸੀਮਾ ਤੋਂ ਵੱਧ ਜਾਂਦੇ ਹੋ, ਇਸਨੂੰ "ਬਾਅਦ ਵਿੱਚ ਠੀਕ ਕਰਾਂਗੇ" ਦੀ ਜਗ੍ਹਾ ਇੱਕ ਟੁੱਟੀ ਮਨਜ਼ੂਰੀ ਵਾਂਗ ਸਮਝੋ।

ਗਤੀ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਲਈ ਖਰਾਬ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਸ਼ਿਪਿੰਗ ਜੋੜ੍ਹਦੀ ਹੈ। ਹਰ ਨਵਾਂ ਵਿਡਜੈੱਟ JavaScript, CSS, ਫੌਂਟ, ਇਮੇਜ, API ਕਾਲ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਲਈ ਹੋਰ ਕੰਮ ਜੋੜਦਾ ਹੈ। ਛੋਟੇ-ਛੋਟੇ ਬਦਲਾਅ ਇਕੱਠੇ ਹੋ ਕੇ ਐਪ ਨੂੰ ਭਾਰੀ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਮਿਡ-ਰੇਂਜ ਫੋਨਾਂ ਅਤੇ ਧੀਮੇ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਜਿੱਥੇ ਜ਼ਿਆਦਾਤਰ ਵਰਤੋਂਕਾਰ ਹਨ।

ਰਾਏ ਇੱਥੇ ਤੁਹਾਡੀ ਰੱਖਿਆ ਨਹੀਂ ਕਰਦੀ। ਇੱਕ ਕਹਿੰਦਾ ਹੈ "ਮੇਰੇ ਲੈਪਟਾਪ ਤੇ ਠੀਕ ਲੱਗਦਾ ਹੈ," ਦੂਜਾ ਕਹਿੰਦਾ ਹੈ "ਧੀਮਾ ਹੈ," ਅਤੇ ਟੀਮ ਵਿਚ बहਿਸ ਹੁੰਦੀ ਹੈ। ਇਕ ਬਜਟ ਇਹ ਬਹਿਸ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਇੱਕ ਮਾਪਣਯੋਗ ਉਤਪਾਦ ਸੀਮਾ ਬਣਾਉਂਦਾ ਹੈ।

ਇੱਥੇ Addy Osmani ਦੀ ਸੋਚ ਫਿੱਟ ਬੈਠਦੀ ਹੈ: ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਡਿਜ਼ਾਈਨ ਨਿਯਮ ਅਤੇ ਸੁਰੱਖਿਆ ਨਿਯਮਾਂ ਵਾਂਗ ਵਰਤੋਂ ਕਰੋ। ਤੁਸੀਂ "ਕੋਸ਼ਿਸ਼" ਕਰਕੇ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਰਹਿੰਦੇ। ਤੁਸੀਂ ਮਾਪਦੰਡ ਰੱਖਦੇ ਹੋ, ਲਗਾਤਾਰ ਚੈੱਕ ਕਰਦੇ ਹੋ, ਅਤੇ ਉਹ ਬਦਲਾਅ ਰੋਕਦੇ ਹੋ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਤੋੜਦੇ ਹਨ।

ਬਜਟ ਕਈ ਪ੍ਰਯੋਗਿਕ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਦੇ ਹਨ: ਉਹ ਟ੍ਰੇਡ‑ਆਫ़ਸ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਦੇ ਹਨ (ਨਵੀਂ ਵਿਸ਼ੇਸ਼ਤਾ ਜੁੜਣ ਦਾ ਕੀ ਕੀਲਾ-ਭਾਰ ਹੋਵੇਗਾ), ਰਿਗ੍ਰੈਸ਼ਨਜ਼ ਨੂੰ ਜਲਦੀ ਫੜਦੇ ਹਨ (ਜਿੱਥੇ ਠੀਕ ਕਰਨਾ ਸਸਤਾ ਹੁੰਦਾ ਹੈ), ਅਤੇ ਸਭ ਨੂੰ "ਕਿੰਨਾ ਤੇਜ਼ ਕਾਫੀ ਹੈ" ਦਾ ਇੱਕੋ ਪਰਿਭਾਸ਼ਾ ਦਿੰਦੇ ਹਨ। ਉਹ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਆਉਣ ਵਾਲੀ ਪੈਨਿਕ ਨੂੰ ਵੀ ਘਟਾਉਂਦੇ ਹਨ।

ਇਹ ਉਹ ਸਨਾਰੀਉ ਹੈ ਜਿਸ ਲਈ ਬਜਟ ਬਣਾਏ ਜਾਂਦੇ ਹਨ: ਤੁਸੀਂ ਇੱਕ ਰਿਚ ਚਾਰਟਿੰਗ ਲਾਇਬ੍ਰੇਰੀ ਇੱਕ ਡੈਸ਼ਬੋਰਡ ਵਿਊ ਲਈ ਜੋੜਦੇ ਹੋ। ਇਹ ਸਭ ਨੂੰ ਸ਼ਿਪ ਹੋ ਜਾਂਦੀ ਹੈ, ਮੁੱਖ ਬੰਡਲ ਵਧ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਪਹਿਲਾ ਮਹੱਤਵਪੂਰਨ ਸਕ੍ਰੀਨ ਦੇਖਣ ਵਿੱਚ ਦਿੱਲੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਬਜਟ ਨਾ ਹੋਵੇ ਤਾਂ ਇਹ ਫਿਰ ਵੀ ਸਰੁਚੀ ਨਾਲ ਵੀਤਰਤ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਫੀਚਰ "ਕਾਮ ਕਰਦਾ ਹੈ"। ਬਜਟ ਹੋਣ 'ਤੇ ਟੀਮ ਨੂੰ ਚੋਣ ਕਰਨੀ ਪੈਂਦੀ ਹੈ: ਚਾਰਟ lazy-load ਕਰੋ, ਲਾਇਬ੍ਰੇਰੀ ਬਦਲੋ ਜਾਂ ਵਿਊ ਸਧਾਰਨ ਕਰੋ।

ਇਹ ਹੋਰ ਵੀ ਜ਼ਿਆਦਾ ਅਹਮ ਹੈ ਜਦੋਂ ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਐਪ ਤਿਆਰ ਅਤੇ ਦੁਹਰਾਉਂਦੀ ਹੈ, ਸਮੇਤ chat-driven ਵਰਕਫਲੋਸ ਜਿਵੇਂ Koder.ai. ਗਤੀ ਵਧੀਆ ਹੈ, ਪਰ ਇਹ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ ਕਿ ਬਿਨਾਂ ਧਿਆਨ ਦਿੱਤੇ ਨਿਰਭਰਤਾਵਾਂ ਅਤੇ UI ਖੁਬਸੂਰਤੀਆਂ ਸ਼ਿਪ ਹੋ ਜਾਣ। ਬਜਟ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਨੂੰ ਧੀਮਾ ਉਤਪਾਦ ਬਣਨ ਤੋਂ ਰੋਕਦੇ ਹਨ।

ਇੱਕ ਸਾਦਾ ਟਾਰਗੇਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਪੰਨਾ, ਡਿਵਾਈਸ ਅਤੇ ਨੈੱਟਵਰਕ

Performance ਕੰਮ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਸਭ ਕੁਝ ਮਾਪਦੇ ਹੋ ਪਰ ਕਿਸੇ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਨਹੀਂ ਰੱਖਦੇ। ਇੱਕ ਐਸਾ ਪੰਨਾ ਚੁਣੋ ਜੋ ਅਸਲ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੋ, ਅਤੇ ਉਸਨੂੰ ਤੁਹਾਡੇ ਬਜਟ ਲਈ ਐਂਕਰ ਬਣਾਓ।

ਚੰਗੀ ਸ਼ੁਰੂਆਤ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਯਾਤਰਾ ਹੈ ਜਿੱਥੇ ਗਤੀ ਬਦਲਾਅ 'ਤੇ ਅਸਰ ਪੈਂਦਾ ਹੈ: ਜਿਵੇਂ "ਹੋਮ ਤੋਂ ਸਾਈਨਅਪ," "ਲੌਗਇਨ ਤੋਂ ਬਾਅਦ ਡੈਸ਼ਬੋਰਡ ਪਹਿਲੀ ਲੋਡ," ਜਾਂ "ਚੈਕਆਉਟ ਅਤੇ ਭੁਗਤਾਨ ਪੁਸ਼ਟੀ." ਕੁਝ ਪ੍ਰਤੀਨਿਧਿ ਅਤੇ ਆਮ ਚੋਣੋ, ਐਜ ਕੇਸ ਨਹੀਂ।

ਆਪਣੇ ਵਰਤੋਂਕਾਰਾਂ ਨਾਲ ਮਿਲਦਾ-ਜੁਲਦਾ ਟਾਰਗੇਟ ਚੁਣੋ

ਤੁਹਾਡਾ ਐਪ ਤੁਹਾਡੇ ਲੈਪਟਾਪ ਤੇ ਨਹੀਂ ਚਲਦਾ। ਇੱਕ ਬਜਟ ਜੋ ਤੇਜ਼ ਮਸ਼ੀਨ 'ਤੇ ਠੀਕ ਲੱਗਦਾ ਹੈ, ਉਹ ਮਿਡ-ਰੇਂਜ ਫੋਨ 'ਤੇ ਧੀਮਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ।

ਇੱਕ ਡਿਵਾਈਸ ਕਲਾਸ ਅਤੇ ਇੱਕ ਨੈੱਟਵਰਕ ਪ੍ਰੋਫ਼ਾਈਲ ਤੇ ਫੈਸਲਾ ਕਰੋ ਅਤੇ इसे ਸਾਫ਼-ਸੁਥਰਾ ਵਾਕ ਪ੍ਰਕਾਰ ਵਿੱਚ ਲਿਖੋ ਜੋ ਹਰ ਕੋਈ ਦੁਹਰਾ ਸਕੇ।

ਉਦਾਹਰਨ ਵਜੋਂ: ਆਖ਼ਰੀ 2-3 ਸਾਲਾਂ ਦਾ ਇੱਕ ਮਿਡ-ਰੇਂਜ Android ਫੋਨ, ਹਲਦਾਰ 4G ਉੱਤੇ ( ਦਫ਼ਤਰ Wi‑Fi ਨਹੀਂ), ਇੱਕ cold load ਮਾਪਣਾ ਅਤੇ ਫਿਰ ਇੱਕ ਕੁੰਜੀ ਨੈਵੀਗੇਸ਼ਨ, ਉਨ੍ਹਾਂ ਹੀ ਖੇਤਰਾਂ ਵਿੱਚ ਜਿੱਥੇ ਜ਼ਿਆਦਾਤਰ ਵਰਤੋਂਕਾਰ ਹਨ।

ਇਹ ਸਭ ਤੋਂ ਬੁਰਾ ਕੇਸ ਚੁਣਣ ਬਾਰੇ ਨਹੀਂ ਹੈ; ਇਹ ਉਹ ਆਮ ਕੇਸ ਚੁਣਨ ਬਾਰੇ ਹੈ ਜੋ ਤੁਸੀਂ ਵਾਸਤਵ ਵਿੱਚ ਠੀਕ ਕਰ ਸਕੋ।

ਇੱਕ ਬੇਸਲਾਈਨ ਟੈਸਟ ਸੈਟਅਪ ਲਾਕ ਕਰੋ

ਨੰਬਰਾਂ ਤਦ ਹੀ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ ਜਦੋਂ ਉਹ ਤੁਲਨਾਤਮਕ ਹੋਣ। ਜੇ ਇੱਕ ਰਨ "Chrome ਨਾਲ extensions ਤੇ MacBook" ਹੋਵੇ ਅਤੇ ਦੂਜਾ "ਥ੍ਰੌਟਲਡ ਮੋਬਾਇਲ," ਤਾਂ ਤੁਹਾਡਾ ਟ੍ਰੈਂਡ ਲਾਈਨ ਸ਼ੋਰ ਹੋਵੇਗੀ।

ਜਾਂਚਾਂ ਲਈ ਇੱਕ ਬੇਸਲਾਈਨ ਵਾਤਾਵਰਣ ਚੁਣੋ ਅਤੇ ਬਜਟ ਚੈਕਾਂ ਲਈ ਇਸ ਨੂੰ ਅਟੱਲ ਰੱਖੋ: ਇੱਕੋ ਬ੍ਰਾਊਜ਼ਰ ਵਰਜ਼ਨ, ਇੱਕੋ ਥ੍ਰੌਟਲਿੰਗ ਸੈਟਿੰਗ, ਇੱਕੋ ਟੈਸਟ ਰਾਹ, ਅਤੇ ਇੱਕੋ cache ਹਾਲਤ (cold ਜਾਂ warm)। ਜੇ ਤੁਸੀਂ ਅਸਲ ਡਿਵਾਈਸ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਇੱਕੋ ਮਾਡਲ ਵਰਤੋ।

ਹੁਣ "ਤੇਜ਼ ਕਾਫ਼ੀ" ਦਾ ਅਰਥ ਵਰਤੋਂਕਾਰ ਦੇ ਵਿਹਾਰ ਵਿੱਚ ਤੈਅ ਕਰੋ, ਨਾ ਕਿ ਪਰਫੈਕਟ ਡੈਮੋਜ਼ ਵਿੱਚ। ਉਦਾਹਰਨ: "ਵਰਤੋਂਕਾਰ ਜਲਦੀ ਸਮੱਗਰੀ ਪੜ੍ਹਨਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਨ" ਜਾਂ "ਲੌਗਇਨ ਤੋਂ ਬਾਅਦ ਡੈਸ਼ਬੋਰਡ ਜਵਾਬਦੇਹ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।" ਇਸਨੂੰ ਇੱਕ ਜਾਂ ਦੋ ਮੈਟ੍ਰਿਕਸ ਵਿੱਚ ਤਬਦੀਲ ਕਰੋ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਜਟ ਰੱਖੋ।

ਬਜਟ ਕਿਸਮਾਂ: ਸਮਾਂ, ਆਕਾਰ, ਰਿਕਵੇਸਟ ਅਤੇ ਰਨਟਾਈਮ

ਬਜਟ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ ਜੋ ਵਰਤੋਂਕਾਰ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਜੋ ਟੀਮ ਕੰਟਰੋਲ ਕਰ ਸਕਦੀ ਹੈ। ਚੰਗਾ ਸੈੱਟ ਤਜਰਬਾ‑ਮੈਟ੍ਰਿਕਸ ("ਕੀ ਮਹਿਸੂਸ ਕੀਤਾ") ਅਤੇ ਰਿਸੋਰਸ/CPU ਸੀਮਾਵਾਂ ("ਕਿਉਂ ਧੀਮਾ ਹੋਇਆ") ਦੋਹਾਂ ਨੂੰ ਮਿਲਾਉਂਦਾ ਹੈ।

ਟਾਈਮਿੰਗ ਬਜਟ (ਵਰਤੋਂਕਾਰ ਅਨੁਭਵ)

ਇਹ ਅਸਲ ਲੋਕਾਂ ਲਈ ਪੇਜ ਦੇ ਵਿਹਾਰ ਨੂੰ ਟਰੈਕ ਕਰਦੇ ਹਨ। ਸਭ ਤੋਂ ਲਾਭਦਾਇਕ ਹੇਠਾਂ ਦਿੱਤੇ Core Web Vitals ਨਾਲ ਮਿਲਦੇ ਹਨ:

LCP (Largest Contentful Paint): ਮੁੱਖ ਸਮੱਗਰੀ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਪੈਂਟ ਹੁੰਦੀ ਹੈ।
INP (Interaction to Next Paint): ਟੈਪ, ਕਲਿਕ ਜਾਂ ਟਾਈਪ ਕਰਨ ਤੇ ਪੰਨਾ ਕਿੰਨਾ ਜਵਾਬਦਾ ਹੈ।
CLS (Cumulative Layout Shift): ਲੇਆਉਟ ਕਿੰਨਾ ਹਿਲ-ਡੋਲਦਾ ਹੈ।

ਟਾਈਮਿੰਗ ਬਜਟ ਤੁਹਾਡੇ ਨਾਰਥ ਸਟਾਰ ਹਨ ਕਿਉਂਕਿ ਇਹ ਵਰਤੋਂਕਾਰ ਦੀ ਨਿਰਾਸ਼ਾ ਨਾਲ ਮਿਲਦੇ ਹਨ। ਪਰ ਇਹ ਸਦਾ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਕਿਸਮਾਂ ਦੀ ਵੀ ਜ਼ਰੂਰਤ ਰੱਖਦੇ ਹੋ।

ਆਕਾਰ, ਰਿਕਵੇਸਟ ਅਤੇ ਰਨਟਾਈਮ ਬਜਟ (ਕਿਹੜੀ ਚੀਜ ਧੀਮੀ ਬਣਾਉਂਦੀ ਹੈ)

ਇਹ ਬਿਲਡ ਅਤੇ ਰਿਵਿਊਜ਼ ਵਿੱਚ ਲਾਗੂ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ konkret ਹਨ।

Weight ਬਜਟ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਕੈਪ ਕਰਦੇ ਹਨ: ਕੁੱਲ JavaScript, ਕੁੱਲ CSS, ਚਿੱਤਰ ਝਿੱਲ, ਅਤੇ ਫੌਂਟ ਵਜ਼ਨ। Request ਬਜਟ ਰਿਕਵੇਸਟ ਦੀ ਗਿਣਤੀ ਅਤੇ ਤੀਜੇ-ਪੱਖ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਕੈਪ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਨੈੱਟਵਰਕ ਓਵਰਹੈੱਡ ਅਤੇ ਟੈਗ/ਵਿੱਡਜੈੱਟ/ਟਰੈਕਰ ਤੋਂ ਆਉਣ ਵਾਲੀ "ਚੌਕ" ਘਟਦੀ ਹੈ। Runtime ਬਜਟ ਲੰਬੇ ਟਾਸਕ, ਮੁੱਖ-ਥਰੈੱਡ ਸਮਾਂ, ਅਤੇ hydration ਸਮਾਂ (ਖਾਸ ਕਰਕੇ React ਲਈ) ਉਤੇ ਸੀਮਾ ਰੱਖਦੇ ਹਨ, ਜਿਹੜੇ ਅਕਸਰ ਦੱਸਦੇ ਹਨ ਕਿ ਪੰਨਾ ਮਿਡ-ਰੇਂਜ ਫੋਨ 'ਤੇ ਕਿਉਂ "ਭਾਰੀ" ਲੱਗਦਾ ਹੈ।

ਇੱਕ ਪ੍ਰੈਕਟੀਕਲ React ਉਦਾਹਰਨ: ਬੰਡਲ ਆਕਾਰ ਠੀਕ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਨਵਾਂ ਕਰੌਸਲ ਭਾਰੀ client-side rendering ਜੋੜਦਾ ਹੈ। ਪੰਨਾ ਲੋਡ ਹੋ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਵੀ ਫਿਲਟਰ ਟੈਪ ਕਰਨ ਤੇ sticky ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ hydration ਮੁੱਖ ਥਰੈੱਡ ਨੂੰ ਰੋਕ ਰਿਹਾ ਹੈ। ਇੱਕ runtime ਬਜਟ ਜਿਵੇਂ "ਸਟਾਰਟਅਪ ਦੌਰਾਨ X ms ਤੋਂ ਵੱਧ ਲੰਬੇ ਟਾਸਕ ਨਾ ਹੋਣ" ਜਾਂ "hydration Y ਸਕਿੰਟਾਂ ਵਿੱਚ ਮੁਕੰਮਲ ਹੋ ਜਾਵੇ" ਇਸਨੂੰ ਫੜ ਸਕਦਾ ਹੈ ਭਾਵੇਂ weight ਬਜਟ ਨਾ ਕਰ ਸਕੇ।

ਸਬ ਤੋਂ ਮਜ਼ਬੂਤ ਦ੍ਰਿਸ਼ਟਿਕੋਣ ਇਹਨਾਂ ਨੂੰ ਇੱਕ ਸਿਸਟਮ ਵਜੋਂ ਦੇਖਦਾ ਹੈ: ਤਜਰਬਾ ਬਜਟ ਸਫਲਤਾ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਆਕਾਰ/ਰਿਕਵੇਸਟ/ਰनਟਾਈਮ ਬਜਟ ਰਿਲੀਜ਼ਾਂ ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖਦੇ ਹਨ ਅਤੇ "ਕੀ ਬਦਲਿਆ?" ਦਾ ਜਵਾਬ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।

ਪ੍ਰਯੋਗਿਕ ਸ਼ੁਰੂਆਤੀ ਬਜਟ ਜੋ ਤੁਸੀਂ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ

ਜੇ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੀਆਂ ਸੀਮਾਵਾਂ ਰੱਖ ਦਿਓਗੇ ਤਾਂ ਲੋਕ ਧਿਆਨ ਦੇਣਾ ਛੱਡ ਦਿੰਦੇ ਹਨ। 3 ਤੋਂ 5 ਬਜਟ ਚੁਣੋ ਜੋ ਵਰਤੋਂਕਾਰ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਨ ਅਤੇ ਜੋ ਤੁਸੀਂ ਹਰ pull request ਜਾਂ ਰਿਲੀਜ਼ 'ਤੇ ਮਾਪ ਸਕੋ।

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਸ਼ੁਰੂਆਤੀ ਸੈੱਟ (ਨੰਬਰ ਬਾਅਦ ਵਿੱਚ ਟਿਊਨ ਕਰੋ):

LCP: warn at 2.5s, fail at 3.0s (mobile, cold load).
INP: warn at 200ms, fail at 300ms (ਆਮ ਇੰਟਰੈਕਸ਼ਨ ਜਿਵੇਂ ਮੇਨੂ ਖੋਲ੍ਹਣਾ ਜਾਂ ਫਾਰਮ ਸਬਮਿਟ).
CLS: warn at 0.10, fail at 0.15.
JavaScript bundle size (initial route): warn at 170KB gzip, fail at 220KB gzip (sirf app ਕੋਡ).
Images (initial view): warn at 800KB, fail at 1.2MB (ਪਹਿਲੀ ਸਕ੍ਰੀਨ ਉੱਤੇ ਲੋਡ ਹੋ ਰਹੇ ਇਮੇਜਾਂ ਦੀ ਕੁੱਲ ਟ੍ਰਾਂਸਫਰ ਕੀਤੀ ਬਾਈਟਸ).

ਦੋ ਥ੍ਰੈਸ਼ਹੋਲਡ ਰੱਖਣ ਨਾਲ ਚੀਜ਼ਾਂ ਸੰਭਲਦੀਆਂ ਹਨ। "Warn" ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਟ੍ਰੈਂਡ ਤੋਂ ਹਟ ਰਹੇ ਹੋ। "Fail" ਰਿਲੀਜ਼ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜਾਂ ਖਾਸ ਮਨਜ਼ੂਰੀ ਦੀ ਲੋੜ ਰੱਖਦਾ ਹੈ। ਇਸ ਨਾਲ ਸੀਮਾ ਹਕੀਕਤ ਬਣਦੀ ਹੈ ਬਿਨਾਂ ਹਰ ਵਾਰੀ ਦੰਗੇ ਮਚਾਉਣ ਦੇ।

ਬਜਟ ਨੂੰ ਇੱਕ ਸਾਂਝੇ ਸਥਾਨ 'ਤੇ ਲਿਖੋ ਤਾਂ ਕਿ ਰਿਲੀਜ਼ ਦੇ ਦੌਰਾਨ ਕੋਈ ਬਹਿਸ ਨਾ ਹੋਵੇ। ਛੋਟਾ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਰੱਖੋ: ਕਿਹੜੇ ਪੰਨੇ ਜਾਂ ਫਲੋ ਸ਼ਾਮਲ ਹਨ, ਮਾਪ ਕਿੱਥੇ ਚਲਦੇ ਹਨ (ਲੋਕਲ ਆਡਿਟ, CI, staged build), ਕਿਹੜਾ ਡਿਵਾਈਸ ਅਤੇ ਨੈੱਟਵਰਕ ਪ੍ਰੋਫ਼ਾਈਲ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਕਿਵੇਂ ਪਰਿਭਾਸ਼ਿਤ ਹਨ (field vs lab, gzip vs raw, route-level vs whole app)।

ਕਦਮ-ਦਰ-ਕਦਮ: ਆਪਣੇ ਮੌਜੂਦਾ ਐਪ ਤੋਂ ਬਜਟ ਸੈਟ ਕਰੋ

Launch and iterate safely

Deploy and host your app, then iterate in small slices with budgets in mind.

Deploy Now

ਇੱਕ ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਬੇਸਲਾਈਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਜਾਂ ਦੋ ਮੁੱਖ ਪੰਨੇ ਚੁਣੋ ਅਤੇ ਹਰ ਵਾਰ ਉਹਨਾਂ ਨੂੰ ਇੱਕੋ ਡਿਵਾਈਸ ਪ੍ਰੋਫ਼ਾਈਲ ਅਤੇ ਨੈੱਟਵਰਕ 'ਤੇ ਟੈਸਟ ਕਰੋ। ਟੈਸਟ ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਵਾਰ ਚਲਾਓ ਅਤੇ ਮੀਡੀਅਨ ਨੋਟ ਕਰੋ ਤਾਂ ਕਿ ਇੱਕ ਅਜੀਬ ਰਨ ਤੁਹਾਡਾ ਨਿਰਦੇਸ਼ ਨਿਰਧਾਰਤ ਨਾ ਕਰੇ।

ਇੱਕ ਸਾਦਾ ਬੇਸਲਾਈਨ शीਟ ਵਰਤੋ ਜਿਸ ਵਿੱਚ ਇੱਕ ਯੂਜ਼ਰ ਮੈਟ੍ਰਿਕ ਅਤੇ ਇੱਕ ਬਿਲਡ ਮੈਟ੍ਰਿਕ ਦੋਹਾਂ ਸ਼ਾਮਲ ਹੋਣ। ਉਦਾਹਰਨ: ਪੰਨੇ ਲਈ LCP ਅਤੇ INP, ਨਾਲ ਹੀ ਬਿਲਡ ਲਈ ਕੁੱਲ JavaScript ਆਕਾਰ ਅਤੇ ਕੁੱਲ ਇਮੇਜ ਬਾਈਟਸ। ਇਹ ਬਜਟ ਨੂੰ ਹਕੀਕਤ ਬਣਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ ਕਿ ਐਪ ਨੇ ਕੀ ਸਪੁਰਦ ਕੀਤਾ, ਕੇਵਲ ਲੈਬ ਨਤੀਜਾ ਨਹੀਂ।

ਬਜਟ ਅੱਜ ਦੀ ਤుఛੀ ਉਮੀਦ ਨਾ ਰੱਖੋ; ਥੋੜਾ-ਥੋੜਾ ਬਿਹਤਰ ਰੱਖੋ। ਇੱਕ ਅਚਛਾ ਨਿਯਮ 5–10% ਸੁਧਾਰ ਹੈ ਤੁਹਾਡੇ ਮੌਜੂਦਾ ਮੀਡੀਅਨ ਤੋਂ। ਜੇ ਤੁਹਾਡਾ LCP ਬੇਸਲਾਈਨ 'ਤੇ 3.2s ਹੈ, ਤੁਰੰਤ 2.0s 'ਤੇ ਨਾ ਜਾਓ। 3.0s ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਫਿਰ ਕੱਸੋ ਜਦੋਂ ਤੁਸੀਂ ਸਾਬਤ ਕਰ ਲਵੋ ਕਿ ਇਹ ਰੱਖ ਸਕਦੇ ਹੋ।

ਹਰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ ਚੈੱਕ ਜੋੜੋ ਤਾਂ ਕਿ ਲੋਕ ਇਸਨੂੰ ਸਕਿਪ ਨਾ ਕਰਨ। ਇਕ ਸਧਾਰਣ ਰੂਪ ਇਹ ਹੈ: ਮਨਜ਼ੂਰ ਕੀਤਾ ਪੰਨਾ 'ਤੇ ਇੱਕ-ਪੰਨਾ ਆਡਿਟ ਚਲਾਓ, ਜੇ JavaScript ਜਾਂ images ਬਜਟ ਤੋਂ ਵੱਧ ਹਨ ਤਾਂ ਬਿਲਡ ਫੇਲ ਕਰੋ, ਨਤੀਜੇ ਹਰ ਕੰਮਿਟ ਲਈ ਸਟੋਰ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕੋ ਕਦੋਂ ਬਦਲਿਆ, ਅਤੇ ਹਮੇਸ਼ਾ ਉਹੀ URL ਪੈਟਰਨ ਟੈਸਟ ਕਰੋ (ਕੋਈ ਰੈਂਡਮ ਡਾਟਾ ਨਹੀਂ)।

ਹਫਤਾਵਾਰ ਬ੍ਰੀਚਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ ਜਦੋਂ ਕੋਈ ਸ਼ਿਕਾਇਤ ਆਏ। ਇੱਕ ਬ੍ਰੀਚ ਨੂੰ ਬੱਗ ਵਾਂਗਈ ਟਰਿਟ ਕਰੋ: ਜਿਸ ਕਮਟ ਨੇ ਇਹ ਲਿਆ ਉਸਨੂੰ ਪਛਾਣੋ, ਤੁਰੰਤ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ ਫੈਸਲਾ ਕਰੋ, ਅਤੇ ਕੀ ਬਾਅਦ ਵਿੱਚ ਸ਼ਡਿਊਲ ਕਰਨਾ ਹੈ ਨਿਰਧਾਰਤ ਕਰੋ। ਹੌਲੇ-ਹੌਲੇ ਕੱਸੋ, ਸਿਰਫ ਉਸ ਸਮੇਂ ਜਦੋਂ ਤੁਸੀਂ ਕੁਝ ਰਿਲੀਜ਼ਾਂ ਲਈ ਰੇਖਾ ਰੱਖ ਸਕਦੇ ਹੋ।

ਜਦੋਂ ਪ੍ਰੋਡਕਟ ਸਕੋਪ ਬਦਲਦਾ ਹੈ, ਬਜਟ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰੀ ਨਾਲ ਅਪਡੇਟ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਨਵਾਂ analytics ਟੂਲ ਜਾਂ ਕੋਈ ਭਾਰੀ ਫੀਚਰ ਜੋੜਦੇ ਹੋ, ਲਿਖੋ ਕਿ ਕੀ ਵਧਿਆ (ਆਕਾਰ, ਰਿਕਵੇਸਟ, ਰਨਟਾਈਮ), ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਕੀ ਕੀਤਾ ਕਰਕੇ ਇਸ ਦੀ ਮੁਆਵਜ਼ਾ ਕਰੋਗੇ, ਅਤੇ ਕਦੋਂ ਬਜਟ ਮੁੜ ਸਧਾਰ ਹੋਵੇ।

ਤੇਜ਼ ਆਡਿਟ: देखें ਕਿ ਕੀ ਬਦਲਿਆ

ਇੱਕ ਬਜਟ ਉਸ ਵੇਲੇ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਚੈਕ ਕਰ ਸਕੋ। 10‑ਮਿੰਟ ਆਡਿਟ ਦਾ ਮਕਸਦ ਪਰਫੈਕਟ ਨੰਬਰ ਸਾਬਤ ਕਰਨਾ ਨਹੀਂ—ਇਹ ਵੇਖਣਾ ਹੈ ਕਿ ਪਿਛਲੇ ਚੰਗੇ ਬਿਲਡ ਤੋਂ ਕੀ ਬਦਲਿਆ ਅਤੇ ਪਹਿਲਾਂ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ।

10‑ਮਿੰਟ ਆਡਿਟ ਫਲੋ

ਇੱਕ ਪੰਨਾ ਲਓ ਜੋ ਅਸਲ ਉਪਯੋਗ ਦਰਸ਼ਾਉਂਦਾ ਹੋਵੇ। ਫਿਰ ਹਮੇਸ਼ਾ ਇੱਕ ਵਰਗੇ ਤੇਜ਼ ਚੈੱਕ ਚਲਾਓ:

LCP ਐਲੀਮੈਂਟ ਪਛਾਣੋ (ਹੀਰੋ ਇਮੇਜ, ਹੈਡਿੰਗ ਬਲੌਕ, ਉਤਪਾਦ ਗੈਲਰੀ). ਜੇ LCP ਐਲੀਮੈਂਟ ਬਦਲਿਆ ਹੋਇਆ ਹੈ, ਨਤੀਜੇ ਉੱਪਰ-ਥੱਲੇ ਹੋ ਸਕਦੇ ਹਨ।
JavaScript ਵਜ਼ਨ ਅਤੇ ਸਭ ਤੋਂ ਵੱਡੇ ਟੁਕੜਿਆਂ ਨੂੰ ਜਾਂਚੋ। ਨਵੀਂ dependency, ਦੁਹਰਾਈ ਗਈ ਲਾਇਬ੍ਰੇਰੀ, ਜਾਂ ਵੱਡਾ ਫੀਚਰ ਲੱਭੋ।
Above-the-fold images ਲਈ ਆਮ ਗਲਤੀਆਂ ਚੈਕ ਕਰੋ (ਅਨਕੰਪ੍ਰੈੱਸਡ ਫਾਇਲਾਂ, ਗਲਤ ਮਾਪ, missing responsive sources)।
ਤੀਜੇ-ਪੱਖ ਟੈਗ (analytics, chat, A/B tests) ਦੀ ਸਮੀਖਿਆ ਕਰੋ। ਇੱਕ ਨਵਾਂ ਟੈਗ ਹੀ ਵੱਡੇ ਡਾਊਨਲੋਡ ਅਤੇ ਲੰਬੇ ਟਾਸਕ ਜੋੜ ਸਕਦਾ ਹੈ।
ਨੈੱਟਵਰਕ ਅਤੇ CPU ਨੂੰ ਇਕੱਠੇ ਦੇਖੋ: ਕੀ ਇਹ bytes ਵਧਣ ਕਰਕੇ ਧੀਮਾ ਹੈ, ਜਾਂ ਕਿਉਂਕਿ ਪੰਨਾ ਬਹੁਤ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ?

ਸਭ ਤੋਂ ਵੱਡੀ ਸਮੱਸਿਆ ਤੁਰੰਤ ਕਿਵੇਂ ਲੱਭੋ

ਦੋ ਨਜ਼ਰੀਏ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਜਵਾਬ ਦਿੰਦੇ ਹਨ: ਨੈੱਟਵਰਕ ਵਾਟਰਫਾਲ ਅਤੇ ਮੁੱਖ-ਥਰੈਡ ਟਾਇਮਲਾਈਨ।

ਵਾਟਰਫਾਲ ਵਿਚ ਉਹ ਇਕ ਰਿਕਵੇਸਟ ਦੇਖੋ ਜੋ ਕਰੋਟਿਕਲ ਪਾਥ 'ਤੇ ਹੇਠਾਂ ਹੈ: ਇੱਕ ਵੱਡਾ ਸਕ੍ਰਿਪਟ, blocking ਫੌਂਟ, ਜਾਂ ਇੱਕ ਇਮੇਜ ਜੋ ਦੇਰ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਜੇ LCP ਰਿਸੋਰਸ ਜਲਦੀ ਨਹੀਂ ਮੰਗਿਆ ਜਾਂਦਾ, ਤਾਂ ਸਰਵਰ ਤੇਜ਼ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਪੰਨਾ LCP ਬਜਟ ਨਹੀਂ ਮਾਰ ਸਕਦਾ।

ਟਾਇਮਲਾਈਨ ਵਿੱਚ 50ms ਜਾਂ ਵੱਧ ਦੇ ਲੰਬੇ ਟਾਸਕ ਦੇਖੋ। ਸਟਾਰਟਅਪ ਦੇ ਨਜ਼ਦੀਕ ਲੰਬੇ ਟਾਸਕ ਦਾ ਗੁੱਛਾ ਆਮ ਤੌਰ 'ਤੇ ਦੱਸਦਾ ਹੈ ਕਿ ਪਹਿਲੀ ਲੋਡ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ JavaScript ਹੈ। ਇੱਕ ਵੱਡਾ ਟੁਕੜਾ ਆਮ ਤੌਰ 'ਤੇ ਰਾਉਟਿੰਗ ਮਸਲਾ ਜਾਂ ਸਾਂਝਾ ਬੰਡਲ ਹੈ ਜੋ ਸਮੇਂ ਵਿੱਚ ਵਧ ਗਿਆ।

ਅਗਲੇ ਟੈਸਟ ਨੂੰ ਤੁਲਨਾਤਮਕ ਬਣਾਉਣ ਲਈ ਨੋਟਸ

ਤੇਜ਼ ਆਡਿਟ ਫੇਲ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਹਰ ਰਨ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ। ਕੁਝ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਦਰਜ ਕਰੋ ਤਾਂ ਕਿ ਬਦਲਾਅ ਸਪੱਸ਼ਟ ਹੋਣ: ਪੰਨੇ ਦਾ URL ਅਤੇ build/version, ਟੈਸਟ ਡਿਵਾਈਸ ਅਤੇ ਨੈੱਟਵਰਕ ਪ੍ਰੋਫ਼ਾਈਲ, LCP ਐਲੀਮੈਂਟ ਦੀ ਵਰਣਨਾ, ਮੁੱਖ ਨੰਬਰ (ਉਦਾਹਰਨ ਲਈ LCP, ਕੁੱਲ JS ਬਾਈਟਸ, ਰਿਕਵੇਸਟ ਗਿਣਤੀ), ਅਤੇ ਸਭ ਤੋਂ ਵੱਡਾ ਦੋਸ਼ੀ ਦਾ ਛੋਟਾ ਨੋਟ।

ਤੇਜ਼ ਫੀਡਬੈਕ ਅਤੇ PR ਚੈਕ ਲਈ ਡੈਸਕਟਾਪ ਟੈਸਟਿੰਗ ਠੀਕ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਬਜਟ ਦੇ ਨੇੜੇ ਹੋ, ਪੰਨਾ ਜੰਗਲੀ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ, ਜਾਂ ਤੁਹਾਡੇ ਵਰਤੋਂਕਾਰ ਮੋਬਾਈਲ ਤੇ ਜ਼ਿਆਦਾ ਹਨ ਤਾਂ ਅਸਲ ਡਿਵਾਈਸ ਵਰਤੋ। ਮੋਬਾਈਲ CPUs ਲੰਬੇ ਟਾਸਕ ਸੀਧੇ ਦਿਖਾਉਂਦੇ ਹਨ, ਅਤੇ ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ "ਮੇਰੇ ਲੈਪਟਾਪ ਤੇ ਠੀਕ" ਰਿਲੀਜ਼ fail ਹੋ ਜਾਂਦੇ ਹਨ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਠੀਕ ਕਰਨਾ: ਸਧਾਰਨ ਨਿਯਮ ਜੋ ਸਮਾਂ ਬਚਾਉਂਦੇ ਹਨ

Align your team on fast enough

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

Invite Team

ਜਦੋਂ ਇੱਕ ਬਜਟ fail ਕਰਦਾ ਹੈ, ਸਭ ਤੋਂ ਖਰਾਬ ਚਾਲ "ਸਭ ਕੁਝ optimize ਕਰੋ" ਹੈ। ਇਕ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਟ੍ਰਿਆਜ ਆਰਡਰ ਵਰਤੋਂ ਤਾਂ ਜੋ ਹਰ ਸੁਧਾਰ ਦਾ ਸਪੱਸ਼ਟ ਫਲ ਹੋਵੇ।

ਪ੍ਰੈਕਟੀਕਲ ਟ੍ਰਿਆਜ ਆਰਡਰ

ਵਰਤੋਂਕਾਰ ਜਿਸਨੂੰ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਨੋਟਿਸ ਕਰਦੇ ਹਨ ਉਥੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਨਾਜ਼ੁਕ ਤਿੱਖੇ ਕੰਮ ਵੱਲ:

ਮੁੱਖ above-the-fold ਐਲੀਮੈਂਟ ਨੂੰ ਤੇਜ਼ ਬਣਾਓ। ਸਭ ਤੋਂ ਵੱਡੀ ਸਮੱਗਰੀ ਜੋ ਪਹਿਲਾਂ ਪੈਂਟ ਹੁੰਦੀ ਹੈ ਉਸਨੂੰ ਠੀਕ ਕਰੋ। ਚਿੱਤਰਾਂ ਨੂੰ ਰੀਸਾਈਜ਼ ਅਤੇ ਕੰਪ੍ਰੈੱਸ ਕਰੋ, ਠੀਕ ਫਾਰਮੇਟ ਵਰਤੋ, ਅਤੇ ਐਸੇ ਫੌਂਟਾਂ ਤੋਂ ਬਚੋ ਜੋ ਪਹਿਲੀ ਨਜ਼ਰ ਨੂੰ ਰੋਕਦੇ ਹਨ।
CSS ਪਾਲਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ JavaScript ਘੱਟ ਕਰੋ। ਜੇ ਪੰਨਾ ਜ਼ਿਆਦਾ JS ਭੇਜਦਾ ਹੈ, ਤਾਂ parsing, ਮੁੱਖ-ਥਰੈਡ ਕੰਮ, ਅਤੇ ਰੈਂਡਰਿੰਗ ਸਬ ਨੂੰ ਪ੍ਰਭਾਵਤ ਹੁੰਦੇ ਹਨ। ਅਣਉਪਯੋਗ ਕੋਡ ਹਟਾਓ, ਭਾਰੀ ਰੂਟਸ ਨੂੰ ਸਪਲਿਟ ਕਰੋ, ਅਤੇ ਸਧਾਰਨ UI ਲਈ server-rendered ਜਾਂ static ਸਮੱਗਰੀ ਨੂੰ ਤਰਜੀਹ ਦਿਓ।
ਤੀਜੇ-ਪੱਖ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਤਾਮ ਕਰੋ। chat widgets, analytics, tag managers, ਅਤੇ A/B tools ਵੱਡੇ ਡਾਊਨਲੋਡ ਅਤੇ ਲੰਬੇ ਟਾਸਕ ਜੋੜ ਸਕਦੇ ਹਨ। ਜੇ ਇਹ ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ ਲੋੜੀਂਦਾ ਨਹੀਂ, ਤਾਂ ਦੇਰ ਨਾਲ ਲੋਡ ਕਰੋ। ਜੇ ਇਹ ਘੱਟ ਮੁੱਲ ਦਾ ਹੈ, ਤਾਂ ਹਟਾ ਦਿਓ।
ਡਿਜ਼ਾਈਨ ਨਾਲ ਲੇਆਉਟ ਸ਼ਿਫਟ ਰੋਕੋ। ਇਮੇਜ, ਵਿਗਿਆਪਨ ਅਤੇ ਐਂਬੇਡ ਲਈ ਜਗ੍ਹਾ ਰਿਜ਼ਰਵ ਕਰੋ। width/height ਸੈੱਟ ਕਰੋ, ਸਥਿਰ placeholders ਵਰਤੋ, ਅਤੇ ਲੋਡ ਤੋਂ ਬਾਅਦ ਮੌਜੂਦਾ ਸਮੱਗਰੀ ਤੋਂ ਉ©ਪਰ UI inject ਕਰਨ ਤੋਂ ਬਚੋ।
ਜੇ ਇੰਟਰੈਕਸ਼ਨ ਲੈਗੀ ਹੈ ਤਾਂ ਲੰਬੇ ਟਾਸਕ ਮਾਰੋ। ਜਦੋਂ INP ਖਰਾਬ ਹੁੰਦਾ ਹੈ, ਭਾਰੀ client-side ਕੰਮ ਵੇਖੋ: ਵੱਡੇ renders, ਮਹਿੰਗੇ state updates, ਅਤੇ ਵੱਡੀ JSON ਪ੍ਰੋਸੈਸਿੰਗ। ਕੰਮ ਨੂੰ ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਤੋੜੋ, rerenders ਘਟਾਓ, ਅਤੇ ਗੈਰ-UI ਕੰਮ critical path ਤੋਂ ਬਾਹਰ ਭੇਜੋ।

ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਨ

ਇੱਕ ਟੀਮ ਨਵਾਂ ਡੈਸ਼ਬੋਰਡ ਸ਼ਿਪ ਕਰਦੀ ਹੈ ਅਤੇ ਅਚਾਨਕ LCP ਬਜਟ ਮਿਸ ਹੋ ਜਾਂਦਾ ਹੈ। ਉਹ cache headers ਤਦ ਤੱਕ ਟਵੀਕ ਕਰਨ ਦੀ ਬਜਾਏ ਪਾਉਂਦੇ ਹਨ ਕਿ LCP ਐਲੀਮੈਂਟ ਇੱਕ full-width chart image ਹੈ। ਉਹ ਇਸਨੂੰ ਰੀਸਾਈਜ਼ ਅਤੇ ਹਲਕਾ ਫਾਰਮੇਟ ਸੇਵ ਕਰਦੇ ਹਨ ਤੇ ਸਿਰਫ਼ ਜ਼ਰੂਰੀ ਹਿੱਸਾ ਸ਼ੁਰੂਆਤੀ ਰੂਪ ਵਿੱਚ ਲੋਡ ਕਰਦੇ ਹਨ। ਫਿਰ ਉਹ ਦੇਖਦੇ ਹਨ ਕਿ ਇੱਕ ਵੱਡੀ charting library ਹਰ ਰੂਟ 'ਤੇ ਲੋਡ ਹੋ ਰਹੀ ਹੈ। ਉਹ ਇਸਨੂੰ ਸਿਰਫ analytics ਪੇਜ 'ਤੇ ਲੋਡ ਕਰਦੇ ਹਨ ਅਤੇ ਤੀਜੇ-ਪੱਖ support widget ਨੂੰ ਪਹਿਲੀ ਇੰਟਰੈਕਸ਼ਨ ਤੱਕ ਦੇਰ ਕਰ ਦਿੰਦੇ ਹਨ। ਇੱਕ ਦਿਨ ਵਿੱਚ, ਡੈਸ਼ਬੋਰਡ ਮੁੜ ਬਜਟ ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅਗਲੀ ਰਿਲੀਜ਼ ਦੇ "ਕੀ ਬਦਲਿਆ" ਦੇ ਸਪੱਸ਼ਟ ਜਵਾਬ ਹੁੰਦੇ ਹਨ।

ਟੀਮਾਂ ਵੱਲੋਂ ਬਜਟਾਂ ਨਾਲ ਹੋਣ ਵਾਲੀਆਂ ਆਮ ਗਲਤੀਆਂ

ਸਭ ਤੋਂ ਵੱਡੀ ਨਾਕਾਮੀ ਇਹ ਹੈ ਕਿ ਬਜਟ ਨੂੰ ਇੱਕ ਇੱਕ ਵਾਰੀ ਦਾ ਦਸਤਾਵੇਜ਼ ਸਮਝ ਲਿਆ ਜਾਵੇ। ਬਜਟ صرف ਤਦ ਕੰਮ ਕਰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਚੈੱਕ ਕਰਨਾ ਆਸਾਨ ਹੋਵੇ, ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋਵੇ, ਅਤੇ ਤੁਹਾਡੇ ਸ਼ਿਪਿੰਗ ਰਸਤੇ ਨਾਲ ਜੁੜੇ ਹੋਵੇਂ।

ਉਹ ਗਲਤੀਆਂ ਜੋ ਬਜਟਾਂ ਨੂੰ ਫੇਲ ਕਰ ਦਿੰਦੀਆਂ ਹਨ

ਜਿਆਦਾਤਰ ਟੀਮਾਂ ਕੁਝ ਫਸਲਾਂ ਵਿੱਚ ਫਸ ਜਾਂਦੀਆਂ ਹਨ:

ਪਹਿਲੇ ਦਿਨ ਬਹੁਤ ਸਾਰੇ ਬਜਟ ਸੈੱਟ ਕਰ ਦੇਣਾ, ਜਾਂ ਇੰਨੇ ਕਠੋਰ ਰੱਖਣਾ ਕਿ ਹਰ ਬਿਲਡ fail ਹੋ ਜਾਵੇ।
ਹਰ ਵਾਰੀ ਵੱਖ-ਵੱਖ ਸੈਟਿੰਗ ਨਾਲ ਮਾਪਣਾ (ਡਿਵਾਈਸ, ਥ੍ਰੌਟਲਿੰਗ, cache ਹਾਲਤ, ਟੈਸਟ ਪੰਨਾ)।
ਵਿਲੱਖਣ lab ਸਕੋਰਾਂ ਨੂੰ ਪਿੱਛੇ ਪਾ ਕੇ ਅਸਲ ਵਰਤੋਂਕਾਰ ਦਰਦ ਨੂੰ ਨਾ ਦੇਖਣਾ।
ਇੱਕ ਵੱਡੀ dependency ਨੂੰ ਆਹਿਸਤਾ-ਆਹਿਸਤਾ ਰਾਹ ਲੰਘ ਜਾਣਾ।
ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਸਮਝ ਕੇ ਮੁਕੰਮਲ ਕਰ ਦੇਣਾ, ਨਾ ਕਿ ਰਿਲੀਜ਼ ਨਿਯਮ ਵਜੋਂ ਰੱਖਣਾ।

ਅਕਸਰ ਪੈਟਰਨ ਇਹ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਛੋਟਾ ਫੀਚਰ ਜੋ ਇੱਕ ਨਵੀਂ ਲਾਇਬ੍ਰੇਰੀ ਲਿਆਉਂਦਾ ਹੈ। ਬੰਡਲ ਵਧਦਾ ਹੈ, LCP ਧੀਮਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਨੂੰ ਪਤਾ ਨਹੀਂ ਚਲਦਾ ਜਦ ਤੱਕ ਸਪੋਰਟ ਟਿਕਟ ਨਹੀਂ ਆਉਂਦੇ। ਬਜਟ ਇਸ ਬਦਲਾਅ ਨੂੰ ਰਿਵਿਊ ਸਮੇਂ ਵਿਖਾਉਂਦੇ ਹਨ।

ਉਨ੍ਹਾਂ ਤੋਂ ਬਚਣ ਦਾ ਤਰੀਕਾ

ਸਧਾਰਨ ਰੱਖੋ ਅਤੇ ਚੈੱਕ ਲਗਾਤਾਰ ਕਰੋ। 2–4 ਬਜਟ ਚੁਣੋ ਜੋ ਵਰਤੋਂਕਾਰ ਅਨੁਭਵ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਧੀਰੇ-ਧੀਰੇ ਕੱਸੋ। ਆਪਣੀ ਟੈਸਟ ਸੈਟਅਪ ਲਾਕ ਕਰੋ ਅਤੇ ਲਿਖੋ। ਜੇ ਮਿਲ ਸਕੇ ਤਾਂ ਘੱਟ ਤੋਂ ਘੱਟ ਇੱਕ ਅਸਲ-ਉਪਯੋਗ ਸਿਗਨਲ ਟ੍ਰੈਕ ਕਰੋ, ਅਤੇ ਲੈਬ ਟੈਸਟ ਉਪਯੋਗ ਕਰਕੇ "ਕਿਉਂ" ਸਮਝਾਓ, ਤਕਨੀਕੀ ਚਰਚਾ ਜਿੱਤਣ ਲਈ ਨਹੀਂ। ਜਦੋਂ ਇੱਕ dependency ਮਹੱਤਵਪੂਰਨ ਵਜ਼ਨ ਜੋੜਦੀ ਹੈ, ਇੱਕ ਛੋਟੀ ਨੋਟ ਲਾਜ਼ਮੀ ਬਣਾਓ: ਇਹ ਕੀ ਖਰਚ ਕਰਦਾ ਹੈ, ਕੀ ਇਹ ਰਿਪਲੇਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਿਉਂ ਲਾਭਦਾਇਕ ਹੈ। ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਬਜਟ ਚੈੱਕ ਨੂੰ ਆਮ ਰਿਲੀਜ਼ ਰਾਹ 'ਤੇ ਰੱਖੋ।

ਜੇ ਬਜਟ ਰੁਕਾਵਟ محسوس ਹੁੰਦੀ ਹੈ, ਤਾਂ ਅਕਸਰ ਇਹ ਦੋ ਕਾਰਨਾਂ ਕਰਕੇ ਹੁੰਦੀ ਹੈ: ਉਹ ਅਤਿ‑ਆਧੁਨਿਕ ਹਨ ਜਾਂ ਉਹ ਅਸਲ ਫੈਸਲਿਆਂ ਨਾਲ ਨਹੀਂ ਜੁੜੇ। ਪਹਿਲਾਂ ਉਹ ਦੋ ਚੀਜ਼ਾਂ ਠੀਕ ਕਰੋ।

ਉਦਾਹਰਨ: ਇੱਕ ਧੀਮੇ ਹੋ ਰਹੇ ਵੈੱਬ ਐਪ ਨੂੰ ਬਜਟਿਤ ਰਿਲੀਜ਼ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਬਦਲਣਾ

Test changes without regret

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

Use Snapshots

ਇੱਕ ਛੋਟੀ ਟੀਮ ਨੇ ਇੱਕ React analytics ਡੈਸ਼ਬੋਰਡ ਇੱਕ ਹਫ਼ਤੇ ਵਿੱਚ ਸ਼ਿਪ ਕੀਤਾ। ਸ਼ੁਰੂ ਵਿੱਚ ਤੇਜ਼ ਲੱਗਿਆ, ਪਰ ਹਰ ਸ਼ੁੱਕਰਵਾਰ ਦੀ ਰਿਲੀਜ਼ ਨਾਲ ਇਹ ਥੋੜ੍ਹਾ ਭਾਰੀ ਹੁੰਦਾ ਗਿਆ। ਇੱਕ ਮਹੀਨੇ ਬਾਅਦ, ਵਰਤੋਂਕਾਰ ਕਹਿਣ ਲੱਗੇ ਕਿ ਪਹਿਲੀ ਸਕ੍ਰੀਨ "ਟੰਗ" ਕਰਦੀ ਹੈ ਅਤੇ ਫਿਲਟਰ ਲੈਗ ਕਰਦੇ ਹਨ।

ਉਹਨਾਂ ਨੇ "ਕਿੰਨਾ ਤੇਜ਼ ਕਾਫ਼ੀ ਹੈ" ਤੇ बहਿਸ ਰੋਕ ਦਿੱਤੀ ਅਤੇ ਵਰਤੋਂਕਾਰ ਦੇ ਨੋਟਿਸ ਨਾਲ ਜੁੜੇ ਬਜਟ ਲਿਖ ਦਿੱਤੇ:

LCP: 2.5s on a mid-range phone on 4G
INP: under 200ms for common actions (open menu, apply filter)
JavaScript: 250KB gzip for the initial route, with a clear cap per new feature
Images: no uncompressed hero images, and a max pixel size per component

ਪਹਿਲੀ failure ਦੋ ਥਾਂਵਾਂ ਤੇ ਨਜ਼ਰ ਆਈ। initial JavaScript bundle ਵਧ ਗਿਆ ਜਦ charts, date libraries, ਅਤੇ UI kit ਜੋੜੇ ਗਏ। ਨਾਲ ਹੀ, header image ਨੂੰ ਵੱਡਾ ਫਾਇਲ ਲੱਗਾ ਦਿੱਤਾ ਗਿਆ "ਸਿਰਫ਼ ਅਜੇ ਲਈ," ਜਿਸ ਨੇ LCP ਨੂੰ ਬਜਟ ਤੋਂ ਉਪਰ ਧੱਕ ਦਿੱਤਾ। INP ਖਰਾਬ ਹੋਇਆ ਕਿਉਂਕਿ ਹਰ ਫਿਲਟਰ ਚੇਨਜ ਨੇ ਭਾਰੀ rerenders ਅਤੇ ਮਹਿੰਗੇ ਹਿਸਾਬ-ਕਿਤਾਬ ਕਰਵਾਏ ਜਿਹੜੇ ਮੁੱਖ ਥਰੈਡ ਤੇ ਚੱਲ ਰਹੇ ਸਨ।

ਉਹਨਾਂ ਨੇ ਇਸਨੂੰ ਇੱਕ ਆਰਡਰ ਵਿੱਚ ਠੀਕ ਕੀਤਾ ਜੋ ਤੇਜ਼ ਨਤੀਜੇ ਦਿੰਦਾ ਅਤੇ ਮੁੜ ਰਿਗ੍ਰੈਸ਼ਨ ਰੋਕਦਾ:

LCP ਨੂੰ ਲਾਈਨ ਦੇ ਹੇਠਾਂ ਲਿਆਓ: ਇਮੇਜਾਂ ਨੂੰ ਰੀਸਾਈਜ਼ ਅਤੇ ਕੰਪ੍ਰੈੱਸ ਕਰੋ, explicit image dimensions ਸੈੱਟ ਕਰੋ, ਅਤੇ blocking font loads ਤੋਂ ਬਚੋ.
initial JS ਕੱਟੋ: ਅਣਉਪਯੋਗ ਲਾਇਬ੍ਰੇਰੀਆਂ ਹਟਾ ਕੇ, non-critical routes ਸਪਲਿਟ ਕਰ ਕੇ, ਅਤੇ charts ਨੂੰ lazy-load ਕਰਕੇ.
INP ਸੁਧਾਰੋ: ਮਹਿੰਗੇ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ memoize ਕਰੋ, typing filters ਨੂੰ debounce ਕਰੋ, ਅਤੇ ਭਾਰੀ ਕੰਮ ਨੂੰ hot path ਤੋਂ ਬਾਹਰ ਭੇਜੋ.
ਹਰ ਰਿਲੀਜ਼ 'ਤੇ ਬਜਟ ਚੈੱਕ ਜੋੜੋ ਤਾਂ ਜੋ ਜੇ ਕੋਈ ਮੈਟ੍ਰਿਕ ਟੁੱਟੇ, ਰਿਲੀਜ਼ ਰੁਕ ਜਾਏ।

ਦੋ ਰਿਲੀਜ਼ਾਂ ਤੋਂ ਬਾਅਦ, LCP 3.4s ਤੋਂ 2.3s ਤੇ ਆ ਗਿਆ, ਅਤੇ INP ਲਗਭਗ 350ms ਤੋਂ 180ms ਤੋਂ ਘੱਟ ਹੋ gaya ਉਸੇ ਟੈਸਟ ਡਿਵਾਈਸ 'ਤੇ।

ਚੈਕਲਿਸਟ ਅਤੇ ਅਗਲੇ ਕਦਮ (ਲਾਈਟ Koder.ai ਵਰਕਫਲੋ ਸਮੇਤ)

ਬਜਟ ਤਾਂ ਹੀ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਲੋਕ ਹਰ ਵਾਰੀ ਇੱਕੋ ਤਰ੍ਹਾਂ ਪਾਲਨ ਕਰ ਸਕਣ। ਇਸਨੂੰ ਛੋਟਾ ਰੱਖੋ, ਲਿਖੋ, ਅਤੇ shipping ਦਾ ਹਿੱਸਾ ਬਣਾਓ।

ਕੁਝ ਮੈਟ੍ਰਿਕ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਐਪ ਨਾਲ ਫਿੱਟ ਖਾਂਦੇ ਹਨ, "warn vs fail" ਥ੍ਰੈਸ਼ਹੋਲਡ ਸੈੱਟ ਕਰੋ, ਅਤੇ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਟੈਸਟ ਕਰਨ ਦੀ ਪ੍ਰਿਭਾਸ਼ਾ ਦਸਤਾਵੇਜ਼ ਕਰੋ (ਡਿਵਾਈਸ, ਬਰਾਊਜ਼ਰ, ਨੈੱਟਵਰਕ, ਪੰਨਾ/ਫਲੋ)। ਮੌਜੂਦਾ ਸਭ ਤੋਂ ਚੰਗੀ ਰਿਲੀਜ਼ ਤੋਂ ਇੱਕ ਬੇਸਲਾਈਨ ਰਿਪੋਰਟ ਸੇਵ ਕਰੋ ਅਤੇ ਉਸਨੂੰ ਸਪਸ਼ਟ ਲੇਬਲ ਦਿਓ। ਇੱਕ ਮਾਨਯ exception ਕੀ ਗਿਣਤੀ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ, ਇਹ ਫੈਸਲਾ ਕਰੋ।

ਹਰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਉਹੀ ਆਡਿਟ ਚਲਾਓ ਅਤੇ ਬੇਸਲਾਈਨ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਜੇ ਕੁਝ ਰਿਗ੍ਰੈਸ ਕੀਤਾ, ਤਾਂ ਇਸਨੂੰ bug tracker ਵਿੱਚ ਲੋਗ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਟੁੱਟੀ ਚੈੱਕਆਉਟ ਕਦਮ ਵਾਂਗ ਇਲਾਜ ਕਰੋ, ਨਾ ਕਿ "ਬਾਅਦ" ਦਾ ਟਾਸਕ। ਜੇ exception ਨਾਲ ship ਕਰਦੇ ਹੋ, ਤਾਂ ਇੱਕ owner ਅਤੇ expiry date ਦਰਜ ਕਰੋ (ਅਕਸਰ 1–2 ਸਪ੍ਰਿੰਟ)। ਜੇ exception بار بار renew ਹੁੰਦੀ ਰਹੇ, ਤਾਂ ਬਜਟ 'ਤੇ ਗੰਭੀਰ ਗੱਲਬਾਤ ਲਾਜ਼ਮੀ ਹੈ।

ਬਜਟਾਂ ਨੂੰ ਯੋਜਨਾ ਅਤੇ ਅੰਦਾਜ਼ਿਆਂ ਵਿੱਚ ਪਹਿਲਾਂ ਰੱਖੋ: "ਇਹ ਸਕ्रीन ਇੱਕ chart library ਜੋੜਦਾ ਹੈ, ਇਸ ਲਈ ਅਸੀਂ ਕੁਝ ਹੋਰ ਹਟਾਉਂਗੇ ਜਾਂ lazy-load ਕਰਾਂਗੇ।" ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਨਾਲ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਸੀਮਾਵਾਂ Planning Mode ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਲਿਖ ਸਕਦੇ ਹੋ, ਫਿਰ ਛੋਟੇ ਹਿੱਸਿਆਂ 'ਚ iterate ਕਰੋ ਅਤੇ snapshots/rollback ਵਰਤੋਂ ਜਦੋਂ ਕੋਈ ਬਦਲਾਅ ਤੁਹਾਨੂੰ ਕੈਪ ਤੋਂ ਉਪਰ ਧੱਕੇ। ਮਕਸਦ ਟੂਲ ਨਹੀਂ, ਆਦਤ ਹੈ: ਹਰ ਨਵੀਂ ਫੀਚਰ ਨੂੰ ਆਪਣੇ ਵਜ਼ਨ ਲਈ ਪੈਡ ਕਰਨਾ ਪਏਗਾ, ਨਹੀਂ ਤਾਂ ਉਹ ਸ਼ਿਪ ਨਹੀਂ ਹੋਵੇਗੀ।

ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ

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.