08 ਅਕਤੂ 2025·8 ਮਿੰਟ
ਕਾਮਯਾਬ ਪ੍ਰਦਰਸ਼ਨ ਬਜਟ: ਤੇਜ਼ ਵੈੱਬ ਐਪਸ ਲਈ ਵਰਤੋਂਯੋਗ ਸੀਮਾਵਾਂ
Performance ਬਜਟ ਤੇਜ਼ ਵੈੱਬ ਐਪਸ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ: ਲੋਡ ਸਮਾਂ, JS ਆਕਾਰ ਅਤੇ Core Web Vitals ਲਈ ਸਪੱਸ਼ਟ ਸੀਮਾਵਾਂ, ਤੇਜ਼ ਆਡਿਟ ਅਤੇ ਫਿਕਸ‑ਫਰਸਟ ਨਿਯਮ।
Performance ਬਜਟ ਤੇਜ਼ ਵੈੱਬ ਐਪਸ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ: ਲੋਡ ਸਮਾਂ, JS ਆਕਾਰ ਅਤੇ Core Web Vitals ਲਈ ਸਪੱਸ਼ਟ ਸੀਮਾਵਾਂ, ਤੇਜ਼ ਆਡਿਟ ਅਤੇ ਫਿਕਸ‑ਫਰਸਟ ਨਿਯਮ।
ਇੱਕ 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 ਨਾਲ ਮਿਲਦੇ ਹਨ:
ਟਾਈਮਿੰਗ ਬਜਟ ਤੁਹਾਡੇ ਨਾਰਥ ਸਟਾਰ ਹਨ ਕਿਉਂਕਿ ਇਹ ਵਰਤੋਂਕਾਰ ਦੀ ਨਿਰਾਸ਼ਾ ਨਾਲ ਮਿਲਦੇ ਹਨ। ਪਰ ਇਹ ਸਦਾ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਕਿਸਮਾਂ ਦੀ ਵੀ ਜ਼ਰੂਰਤ ਰੱਖਦੇ ਹੋ।
ਇਹ ਬਿਲਡ ਅਤੇ ਰਿਵਿਊਜ਼ ਵਿੱਚ ਲਾਗੂ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ konkret ਹਨ।
Weight ਬਜਟ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਕੈਪ ਕਰਦੇ ਹਨ: ਕੁੱਲ JavaScript, ਕੁੱਲ CSS, ਚਿੱਤਰ ਝਿੱਲ, ਅਤੇ ਫੌਂਟ ਵਜ਼ਨ। Request ਬਜਟ ਰਿਕਵੇਸਟ ਦੀ ਗਿਣਤੀ ਅਤੇ ਤੀਜੇ-ਪੱਖ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਕੈਪ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਨੈੱਟਵਰਕ ਓਵਰਹੈੱਡ ਅਤੇ ਟੈਗ/ਵਿੱਡਜੈੱਟ/ਟਰੈਕਰ ਤੋਂ ਆਉਣ ਵਾਲੀ "ਚੌਕ" ਘਟਦੀ ਹੈ। Runtime ਬਜਟ ਲੰਬੇ ਟਾਸਕ, ਮੁੱਖ-ਥਰੈੱਡ ਸਮਾਂ, ਅਤੇ hydration ਸਮਾਂ (ਖਾਸ ਕਰਕੇ React ਲਈ) ਉਤੇ ਸੀਮਾ ਰੱਖਦੇ ਹਨ, ਜਿਹੜੇ ਅਕਸਰ ਦੱਸਦੇ ਹਨ ਕਿ ਪੰਨਾ ਮਿਡ-ਰੇਂਜ ਫੋਨ 'ਤੇ ਕਿਉਂ "ਭਾਰੀ" ਲੱਗਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰੈਕਟੀਕਲ React ਉਦਾਹਰਨ: ਬੰਡਲ ਆਕਾਰ ਠੀਕ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਨਵਾਂ ਕਰੌਸਲ ਭਾਰੀ client-side rendering ਜੋੜਦਾ ਹੈ। ਪੰਨਾ ਲੋਡ ਹੋ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਵੀ ਫਿਲਟਰ ਟੈਪ ਕਰਨ ਤੇ sticky ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ hydration ਮੁੱਖ ਥਰੈੱਡ ਨੂੰ ਰੋਕ ਰਿਹਾ ਹੈ। ਇੱਕ runtime ਬਜਟ ਜਿਵੇਂ "ਸਟਾਰਟਅਪ ਦੌਰਾਨ X ms ਤੋਂ ਵੱਧ ਲੰਬੇ ਟਾਸਕ ਨਾ ਹੋਣ" ਜਾਂ "hydration Y ਸਕਿੰਟਾਂ ਵਿੱਚ ਮੁਕੰਮਲ ਹੋ ਜਾਵੇ" ਇਸਨੂੰ ਫੜ ਸਕਦਾ ਹੈ ਭਾਵੇਂ weight ਬਜਟ ਨਾ ਕਰ ਸਕੇ।
ਸਬ ਤੋਂ ਮਜ਼ਬੂਤ ਦ੍ਰਿਸ਼ਟਿਕੋਣ ਇਹਨਾਂ ਨੂੰ ਇੱਕ ਸਿਸਟਮ ਵਜੋਂ ਦੇਖਦਾ ਹੈ: ਤਜਰਬਾ ਬਜਟ ਸਫਲਤਾ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਆਕਾਰ/ਰਿਕਵੇਸਟ/ਰनਟਾਈਮ ਬਜਟ ਰਿਲੀਜ਼ਾਂ ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖਦੇ ਹਨ ਅਤੇ "ਕੀ ਬਦਲਿਆ?" ਦਾ ਜਵਾਬ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੀਆਂ ਸੀਮਾਵਾਂ ਰੱਖ ਦਿਓਗੇ ਤਾਂ ਲੋਕ ਧਿਆਨ ਦੇਣਾ ਛੱਡ ਦਿੰਦੇ ਹਨ। 3 ਤੋਂ 5 ਬਜਟ ਚੁਣੋ ਜੋ ਵਰਤੋਂਕਾਰ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਨ ਅਤੇ ਜੋ ਤੁਸੀਂ ਹਰ pull request ਜਾਂ ਰਿਲੀਜ਼ 'ਤੇ ਮਾਪ ਸਕੋ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਸ਼ੁਰੂਆਤੀ ਸੈੱਟ (ਨੰਬਰ ਬਾਅਦ ਵਿੱਚ ਟਿਊਨ ਕਰੋ):
ਦੋ ਥ੍ਰੈਸ਼ਹੋਲਡ ਰੱਖਣ ਨਾਲ ਚੀਜ਼ਾਂ ਸੰਭਲਦੀਆਂ ਹਨ। "Warn" ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਟ੍ਰੈਂਡ ਤੋਂ ਹਟ ਰਹੇ ਹੋ। "Fail" ਰਿਲੀਜ਼ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜਾਂ ਖਾਸ ਮਨਜ਼ੂਰੀ ਦੀ ਲੋੜ ਰੱਖਦਾ ਹੈ। ਇਸ ਨਾਲ ਸੀਮਾ ਹਕੀਕਤ ਬਣਦੀ ਹੈ ਬਿਨਾਂ ਹਰ ਵਾਰੀ ਦੰਗੇ ਮਚਾਉਣ ਦੇ।
ਬਜਟ ਨੂੰ ਇੱਕ ਸਾਂਝੇ ਸਥਾਨ 'ਤੇ ਲਿਖੋ ਤਾਂ ਕਿ ਰਿਲੀਜ਼ ਦੇ ਦੌਰਾਨ ਕੋਈ ਬਹਿਸ ਨਾ ਹੋਵੇ। ਛੋਟਾ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਰੱਖੋ: ਕਿਹੜੇ ਪੰਨੇ ਜਾਂ ਫਲੋ ਸ਼ਾਮਲ ਹਨ, ਮਾਪ ਕਿੱਥੇ ਚਲਦੇ ਹਨ (ਲੋਕਲ ਆਡਿਟ, CI, staged build), ਕਿਹੜਾ ਡਿਵਾਈਸ ਅਤੇ ਨੈੱਟਵਰਕ ਪ੍ਰੋਫ਼ਾਈਲ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਕਿਵੇਂ ਪਰਿਭਾਸ਼ਿਤ ਹਨ (field vs lab, gzip vs raw, route-level vs whole app)।
ਇੱਕ ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਬੇਸਲਾਈਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਜਾਂ ਦੋ ਮੁੱਖ ਪੰਨੇ ਚੁਣੋ ਅਤੇ ਹਰ ਵਾਰ ਉਹਨਾਂ ਨੂੰ ਇੱਕੋ ਡਿਵਾਈਸ ਪ੍ਰੋਫ਼ਾਈਲ ਅਤੇ ਨੈੱਟਵਰਕ 'ਤੇ ਟੈਸਟ ਕਰੋ। ਟੈਸਟ ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਵਾਰ ਚਲਾਓ ਅਤੇ ਮੀਡੀਅਨ ਨੋਟ ਕਰੋ ਤਾਂ ਕਿ ਇੱਕ ਅਜੀਬ ਰਨ ਤੁਹਾਡਾ ਨਿਰਦੇਸ਼ ਨਿਰਧਾਰਤ ਨਾ ਕਰੇ।
ਇੱਕ ਸਾਦਾ ਬੇਸਲਾਈਨ शीਟ ਵਰਤੋ ਜਿਸ ਵਿੱਚ ਇੱਕ ਯੂਜ਼ਰ ਮੈਟ੍ਰਿਕ ਅਤੇ ਇੱਕ ਬਿਲਡ ਮੈਟ੍ਰਿਕ ਦੋਹਾਂ ਸ਼ਾਮਲ ਹੋਣ। ਉਦਾਹਰਨ: ਪੰਨੇ ਲਈ LCP ਅਤੇ INP, ਨਾਲ ਹੀ ਬਿਲਡ ਲਈ ਕੁੱਲ JavaScript ਆਕਾਰ ਅਤੇ ਕੁੱਲ ਇਮੇਜ ਬਾਈਟਸ। ਇਹ ਬਜਟ ਨੂੰ ਹਕੀਕਤ ਬਣਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ ਕਿ ਐਪ ਨੇ ਕੀ ਸਪੁਰਦ ਕੀਤਾ, ਕੇਵਲ ਲੈਬ ਨਤੀਜਾ ਨਹੀਂ।
ਬਜਟ ਅੱਜ ਦੀ ਤుఛੀ ਉਮੀਦ ਨਾ ਰੱਖੋ; ਥੋੜਾ-ਥੋੜਾ ਬਿਹਤਰ ਰੱਖੋ। ਇੱਕ ਅਚਛਾ ਨਿਯਮ 5–10% ਸੁਧਾਰ ਹੈ ਤੁਹਾਡੇ ਮੌਜੂਦਾ ਮੀਡੀਅਨ ਤੋਂ। ਜੇ ਤੁਹਾਡਾ LCP ਬੇਸਲਾਈਨ 'ਤੇ 3.2s ਹੈ, ਤੁਰੰਤ 2.0s 'ਤੇ ਨਾ ਜਾਓ। 3.0s ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਫਿਰ ਕੱਸੋ ਜਦੋਂ ਤੁਸੀਂ ਸਾਬਤ ਕਰ ਲਵੋ ਕਿ ਇਹ ਰੱਖ ਸਕਦੇ ਹੋ।
ਹਰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ ਚੈੱਕ ਜੋੜੋ ਤਾਂ ਕਿ ਲੋਕ ਇਸਨੂੰ ਸਕਿਪ ਨਾ ਕਰਨ। ਇਕ ਸਧਾਰਣ ਰੂਪ ਇਹ ਹੈ: ਮਨਜ਼ੂਰ ਕੀਤਾ ਪੰਨਾ 'ਤੇ ਇੱਕ-ਪੰਨਾ ਆਡਿਟ ਚਲਾਓ, ਜੇ JavaScript ਜਾਂ images ਬਜਟ ਤੋਂ ਵੱਧ ਹਨ ਤਾਂ ਬਿਲਡ ਫੇਲ ਕਰੋ, ਨਤੀਜੇ ਹਰ ਕੰਮਿਟ ਲਈ ਸਟੋਰ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕੋ ਕਦੋਂ ਬਦਲਿਆ, ਅਤੇ ਹਮੇਸ਼ਾ ਉਹੀ URL ਪੈਟਰਨ ਟੈਸਟ ਕਰੋ (ਕੋਈ ਰੈਂਡਮ ਡਾਟਾ ਨਹੀਂ)।
ਹਫਤਾਵਾਰ ਬ੍ਰੀਚਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ ਜਦੋਂ ਕੋਈ ਸ਼ਿਕਾਇਤ ਆਏ। ਇੱਕ ਬ੍ਰੀਚ ਨੂੰ ਬੱਗ ਵਾਂਗਈ ਟਰਿਟ ਕਰੋ: ਜਿਸ ਕਮਟ ਨੇ ਇਹ ਲਿਆ ਉਸਨੂੰ ਪਛਾਣੋ, ਤੁਰੰਤ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ ਫੈਸਲਾ ਕਰੋ, ਅਤੇ ਕੀ ਬਾਅਦ ਵਿੱਚ ਸ਼ਡਿਊਲ ਕਰਨਾ ਹੈ ਨਿਰਧਾਰਤ ਕਰੋ। ਹੌਲੇ-ਹੌਲੇ ਕੱਸੋ, ਸਿਰਫ ਉਸ ਸਮੇਂ ਜਦੋਂ ਤੁਸੀਂ ਕੁਝ ਰਿਲੀਜ਼ਾਂ ਲਈ ਰੇਖਾ ਰੱਖ ਸਕਦੇ ਹੋ।
ਜਦੋਂ ਪ੍ਰੋਡਕਟ ਸਕੋਪ ਬਦਲਦਾ ਹੈ, ਬਜਟ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰੀ ਨਾਲ ਅਪਡੇਟ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਨਵਾਂ analytics ਟੂਲ ਜਾਂ ਕੋਈ ਭਾਰੀ ਫੀਚਰ ਜੋੜਦੇ ਹੋ, ਲਿਖੋ ਕਿ ਕੀ ਵਧਿਆ (ਆਕਾਰ, ਰਿਕਵੇਸਟ, ਰਨਟਾਈਮ), ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਕੀ ਕੀਤਾ ਕਰਕੇ ਇਸ ਦੀ ਮੁਆਵਜ਼ਾ ਕਰੋਗੇ, ਅਤੇ ਕਦੋਂ ਬਜਟ ਮੁੜ ਸਧਾਰ ਹੋਵੇ।
ਇੱਕ ਬਜਟ ਉਸ ਵੇਲੇ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਚੈਕ ਕਰ ਸਕੋ। 10‑ਮਿੰਟ ਆਡਿਟ ਦਾ ਮਕਸਦ ਪਰਫੈਕਟ ਨੰਬਰ ਸਾਬਤ ਕਰਨਾ ਨਹੀਂ—ਇਹ ਵੇਖਣਾ ਹੈ ਕਿ ਪਿਛਲੇ ਚੰਗੇ ਬਿਲਡ ਤੋਂ ਕੀ ਬਦਲਿਆ ਅਤੇ ਪਹਿਲਾਂ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ।
ਇੱਕ ਪੰਨਾ ਲਓ ਜੋ ਅਸਲ ਉਪਯੋਗ ਦਰਸ਼ਾਉਂਦਾ ਹੋਵੇ। ਫਿਰ ਹਮੇਸ਼ਾ ਇੱਕ ਵਰਗੇ ਤੇਜ਼ ਚੈੱਕ ਚਲਾਓ:
ਦੋ ਨਜ਼ਰੀਏ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਜਵਾਬ ਦਿੰਦੇ ਹਨ: ਨੈੱਟਵਰਕ ਵਾਟਰਫਾਲ ਅਤੇ ਮੁੱਖ-ਥਰੈਡ ਟਾਇਮਲਾਈਨ।
ਵਾਟਰਫਾਲ ਵਿਚ ਉਹ ਇਕ ਰਿਕਵੇਸਟ ਦੇਖੋ ਜੋ ਕਰੋਟਿਕਲ ਪਾਥ 'ਤੇ ਹੇਠਾਂ ਹੈ: ਇੱਕ ਵੱਡਾ ਸਕ੍ਰਿਪਟ, blocking ਫੌਂਟ, ਜਾਂ ਇੱਕ ਇਮੇਜ ਜੋ ਦੇਰ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਜੇ LCP ਰਿਸੋਰਸ ਜਲਦੀ ਨਹੀਂ ਮੰਗਿਆ ਜਾਂਦਾ, ਤਾਂ ਸਰਵਰ ਤੇਜ਼ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਪੰਨਾ LCP ਬਜਟ ਨਹੀਂ ਮਾਰ ਸਕਦਾ।
ਟਾਇਮਲਾਈਨ ਵਿੱਚ 50ms ਜਾਂ ਵੱਧ ਦੇ ਲੰਬੇ ਟਾਸਕ ਦੇਖੋ। ਸਟਾਰਟਅਪ ਦੇ ਨਜ਼ਦੀਕ ਲੰਬੇ ਟਾਸਕ ਦਾ ਗੁੱਛਾ ਆਮ ਤੌਰ 'ਤੇ ਦੱਸਦਾ ਹੈ ਕਿ ਪਹਿਲੀ ਲੋਡ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ JavaScript ਹੈ। ਇੱਕ ਵੱਡਾ ਟੁਕੜਾ ਆਮ ਤੌਰ 'ਤੇ ਰਾਉਟਿੰਗ ਮਸਲਾ ਜਾਂ ਸਾਂਝਾ ਬੰਡਲ ਹੈ ਜੋ ਸਮੇਂ ਵਿੱਚ ਵਧ ਗਿਆ।
ਤੇਜ਼ ਆਡਿਟ ਫੇਲ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਹਰ ਰਨ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ। ਕੁਝ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਦਰਜ ਕਰੋ ਤਾਂ ਕਿ ਬਦਲਾਅ ਸਪੱਸ਼ਟ ਹੋਣ: ਪੰਨੇ ਦਾ URL ਅਤੇ build/version, ਟੈਸਟ ਡਿਵਾਈਸ ਅਤੇ ਨੈੱਟਵਰਕ ਪ੍ਰੋਫ਼ਾਈਲ, LCP ਐਲੀਮੈਂਟ ਦੀ ਵਰਣਨਾ, ਮੁੱਖ ਨੰਬਰ (ਉਦਾਹਰਨ ਲਈ LCP, ਕੁੱਲ JS ਬਾਈਟਸ, ਰਿਕਵੇਸਟ ਗਿਣਤੀ), ਅਤੇ ਸਭ ਤੋਂ ਵੱਡਾ ਦੋਸ਼ੀ ਦਾ ਛੋਟਾ ਨੋਟ।
ਤੇਜ਼ ਫੀਡਬੈਕ ਅਤੇ PR ਚੈਕ ਲਈ ਡੈਸਕਟਾਪ ਟੈਸਟਿੰਗ ਠੀਕ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਬਜਟ ਦੇ ਨੇੜੇ ਹੋ, ਪੰਨਾ ਜੰਗਲੀ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ, ਜਾਂ ਤੁਹਾਡੇ ਵਰਤੋਂਕਾਰ ਮੋਬਾਈਲ ਤੇ ਜ਼ਿਆਦਾ ਹਨ ਤਾਂ ਅਸਲ ਡਿਵਾਈਸ ਵਰਤੋ। ਮੋਬਾਈਲ CPUs ਲੰਬੇ ਟਾਸਕ ਸੀਧੇ ਦਿਖਾਉਂਦੇ ਹਨ, ਅਤੇ ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ "ਮੇਰੇ ਲੈਪਟਾਪ ਤੇ ਠੀਕ" ਰਿਲੀਜ਼ fail ਹੋ ਜਾਂਦੇ ਹਨ।
ਜਦੋਂ ਇੱਕ ਬਜਟ fail ਕਰਦਾ ਹੈ, ਸਭ ਤੋਂ ਖਰਾਬ ਚਾਲ "ਸਭ ਕੁਝ optimize ਕਰੋ" ਹੈ। ਇਕ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਟ੍ਰਿਆਜ ਆਰਡਰ ਵਰਤੋਂ ਤਾਂ ਜੋ ਹਰ ਸੁਧਾਰ ਦਾ ਸਪੱਸ਼ਟ ਫਲ ਹੋਵੇ।
ਵਰਤੋਂਕਾਰ ਜਿਸਨੂੰ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਨੋਟਿਸ ਕਰਦੇ ਹਨ ਉਥੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਨਾਜ਼ੁਕ ਤਿੱਖੇ ਕੰਮ ਵੱਲ:
ਇੱਕ ਟੀਮ ਨਵਾਂ ਡੈਸ਼ਬੋਰਡ ਸ਼ਿਪ ਕਰਦੀ ਹੈ ਅਤੇ ਅਚਾਨਕ LCP ਬਜਟ ਮਿਸ ਹੋ ਜਾਂਦਾ ਹੈ। ਉਹ cache headers ਤਦ ਤੱਕ ਟਵੀਕ ਕਰਨ ਦੀ ਬਜਾਏ ਪਾਉਂਦੇ ਹਨ ਕਿ LCP ਐਲੀਮੈਂਟ ਇੱਕ full-width chart image ਹੈ। ਉਹ ਇਸਨੂੰ ਰੀਸਾਈਜ਼ ਅਤੇ ਹਲਕਾ ਫਾਰਮੇਟ ਸੇਵ ਕਰਦੇ ਹਨ ਤੇ ਸਿਰਫ਼ ਜ਼ਰੂਰੀ ਹਿੱਸਾ ਸ਼ੁਰੂਆਤੀ ਰੂਪ ਵਿੱਚ ਲੋਡ ਕਰਦੇ ਹਨ। ਫਿਰ ਉਹ ਦੇਖਦੇ ਹਨ ਕਿ ਇੱਕ ਵੱਡੀ charting library ਹਰ ਰੂਟ 'ਤੇ ਲੋਡ ਹੋ ਰਹੀ ਹੈ। ਉਹ ਇਸਨੂੰ ਸਿਰਫ analytics ਪੇਜ 'ਤੇ ਲੋਡ ਕਰਦੇ ਹਨ ਅਤੇ ਤੀਜੇ-ਪੱਖ support widget ਨੂੰ ਪਹਿਲੀ ਇੰਟਰੈਕਸ਼ਨ ਤੱਕ ਦੇਰ ਕਰ ਦਿੰਦੇ ਹਨ। ਇੱਕ ਦਿਨ ਵਿੱਚ, ਡੈਸ਼ਬੋਰਡ ਮੁੜ ਬਜਟ ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅਗਲੀ ਰਿਲੀਜ਼ ਦੇ "ਕੀ ਬਦਲਿਆ" ਦੇ ਸਪੱਸ਼ਟ ਜਵਾਬ ਹੁੰਦੇ ਹਨ।
ਸਭ ਤੋਂ ਵੱਡੀ ਨਾਕਾਮੀ ਇਹ ਹੈ ਕਿ ਬਜਟ ਨੂੰ ਇੱਕ ਇੱਕ ਵਾਰੀ ਦਾ ਦਸਤਾਵੇਜ਼ ਸਮਝ ਲਿਆ ਜਾਵੇ। ਬਜਟ صرف ਤਦ ਕੰਮ ਕਰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਚੈੱਕ ਕਰਨਾ ਆਸਾਨ ਹੋਵੇ, ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋਵੇ, ਅਤੇ ਤੁਹਾਡੇ ਸ਼ਿਪਿੰਗ ਰਸਤੇ ਨਾਲ ਜੁੜੇ ਹੋਵੇਂ।
ਜਿਆਦਾਤਰ ਟੀਮਾਂ ਕੁਝ ਫਸਲਾਂ ਵਿੱਚ ਫਸ ਜਾਂਦੀਆਂ ਹਨ:
ਅਕਸਰ ਪੈਟਰਨ ਇਹ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਛੋਟਾ ਫੀਚਰ ਜੋ ਇੱਕ ਨਵੀਂ ਲਾਇਬ੍ਰੇਰੀ ਲਿਆਉਂਦਾ ਹੈ। ਬੰਡਲ ਵਧਦਾ ਹੈ, LCP ਧੀਮਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਨੂੰ ਪਤਾ ਨਹੀਂ ਚਲਦਾ ਜਦ ਤੱਕ ਸਪੋਰਟ ਟਿਕਟ ਨਹੀਂ ਆਉਂਦੇ। ਬਜਟ ਇਸ ਬਦਲਾਅ ਨੂੰ ਰਿਵਿਊ ਸਮੇਂ ਵਿਖਾਉਂਦੇ ਹਨ।
ਸਧਾਰਨ ਰੱਖੋ ਅਤੇ ਚੈੱਕ ਲਗਾਤਾਰ ਕਰੋ। 2–4 ਬਜਟ ਚੁਣੋ ਜੋ ਵਰਤੋਂਕਾਰ ਅਨੁਭਵ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਧੀਰੇ-ਧੀਰੇ ਕੱਸੋ। ਆਪਣੀ ਟੈਸਟ ਸੈਟਅਪ ਲਾਕ ਕਰੋ ਅਤੇ ਲਿਖੋ। ਜੇ ਮਿਲ ਸਕੇ ਤਾਂ ਘੱਟ ਤੋਂ ਘੱਟ ਇੱਕ ਅਸਲ-ਉਪਯੋਗ ਸਿਗਨਲ ਟ੍ਰੈਕ ਕਰੋ, ਅਤੇ ਲੈਬ ਟੈਸਟ ਉਪਯੋਗ ਕਰਕੇ "ਕਿਉਂ" ਸਮਝਾਓ, ਤਕਨੀਕੀ ਚਰਚਾ ਜਿੱਤਣ ਲਈ ਨਹੀਂ। ਜਦੋਂ ਇੱਕ dependency ਮਹੱਤਵਪੂਰਨ ਵਜ਼ਨ ਜੋੜਦੀ ਹੈ, ਇੱਕ ਛੋਟੀ ਨੋਟ ਲਾਜ਼ਮੀ ਬਣਾਓ: ਇਹ ਕੀ ਖਰਚ ਕਰਦਾ ਹੈ, ਕੀ ਇਹ ਰਿਪਲੇਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਿਉਂ ਲਾਭਦਾਇਕ ਹੈ। ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਬਜਟ ਚੈੱਕ ਨੂੰ ਆਮ ਰਿਲੀਜ਼ ਰਾਹ 'ਤੇ ਰੱਖੋ।
ਜੇ ਬਜਟ ਰੁਕਾਵਟ محسوس ਹੁੰਦੀ ਹੈ, ਤਾਂ ਅਕਸਰ ਇਹ ਦੋ ਕਾਰਨਾਂ ਕਰਕੇ ਹੁੰਦੀ ਹੈ: ਉਹ ਅਤਿ‑ਆਧੁਨਿਕ ਹਨ ਜਾਂ ਉਹ ਅਸਲ ਫੈਸਲਿਆਂ ਨਾਲ ਨਹੀਂ ਜੁੜੇ। ਪਹਿਲਾਂ ਉਹ ਦੋ ਚੀਜ਼ਾਂ ਠੀਕ ਕਰੋ।
ਇੱਕ ਛੋਟੀ ਟੀਮ ਨੇ ਇੱਕ React analytics ਡੈਸ਼ਬੋਰਡ ਇੱਕ ਹਫ਼ਤੇ ਵਿੱਚ ਸ਼ਿਪ ਕੀਤਾ। ਸ਼ੁਰੂ ਵਿੱਚ ਤੇਜ਼ ਲੱਗਿਆ, ਪਰ ਹਰ ਸ਼ੁੱਕਰਵਾਰ ਦੀ ਰਿਲੀਜ਼ ਨਾਲ ਇਹ ਥੋੜ੍ਹਾ ਭਾਰੀ ਹੁੰਦਾ ਗਿਆ। ਇੱਕ ਮਹੀਨੇ ਬਾਅਦ, ਵਰਤੋਂਕਾਰ ਕਹਿਣ ਲੱਗੇ ਕਿ ਪਹਿਲੀ ਸਕ੍ਰੀਨ "ਟੰਗ" ਕਰਦੀ ਹੈ ਅਤੇ ਫਿਲਟਰ ਲੈਗ ਕਰਦੇ ਹਨ।
ਉਹਨਾਂ ਨੇ "ਕਿੰਨਾ ਤੇਜ਼ ਕਾਫ਼ੀ ਹੈ" ਤੇ बहਿਸ ਰੋਕ ਦਿੱਤੀ ਅਤੇ ਵਰਤੋਂਕਾਰ ਦੇ ਨੋਟਿਸ ਨਾਲ ਜੁੜੇ ਬਜਟ ਲਿਖ ਦਿੱਤੇ:
ਪਹਿਲੀ 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 ਉਸੇ ਟੈਸਟ ਡਿਵਾਈਸ 'ਤੇ।
ਬਜਟ ਤਾਂ ਹੀ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਲੋਕ ਹਰ ਵਾਰੀ ਇੱਕੋ ਤਰ੍ਹਾਂ ਪਾਲਨ ਕਰ ਸਕਣ। ਇਸਨੂੰ ਛੋਟਾ ਰੱਖੋ, ਲਿਖੋ, ਅਤੇ 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 ਵਰਤੋਂ ਜਦੋਂ ਕੋਈ ਬਦਲਾਅ ਤੁਹਾਨੂੰ ਕੈਪ ਤੋਂ ਉਪਰ ਧੱਕੇ। ਮਕਸਦ ਟੂਲ ਨਹੀਂ, ਆਦਤ ਹੈ: ਹਰ ਨਵੀਂ ਫੀਚਰ ਨੂੰ ਆਪਣੇ ਵਜ਼ਨ ਲਈ ਪੈਡ ਕਰਨਾ ਪਏਗਾ, ਨਹੀਂ ਤਾਂ ਉਹ ਸ਼ਿਪ ਨਹੀਂ ਹੋਵੇਗੀ।
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.