ਬਰਾਊਜ਼ਰ ਮੁਢਲੀ ਗੱਲਾਂ: ਨੈੱਟਵਰਕਿੰਗ, ਰੈਂਡਰਿੰਗ, ਕੈਸ਼ਿੰਗ ਬਿਨਾਂ ਮਿਥ

ਕਿਉਂ ਬਰਾਊਜ਼ਰ ਬਾਰੇ ਮਿਥ ਅਸਲ ਬੱਗ ਪੈਦਾ ਕਰਦੇ ਹਨ

ਕਈ ਫਰੰਟ-ਐਂਡ ਬੱਗ “ਰਹੱਸਮਈ ਬਰਾਊਜ਼ਰ ਬਿਹੇਵਿਯਰ” ਨਹੀਂ ਹੁੰਦੇ। ਇਹ ਅਧ-ਯਾਦ ਰਹਿ ਗਈਆਂ ਨਿਯਮਾਵਲੀਅਾਂ ਦਾ ਨਤੀਜਾ ਹੁੰਦੇ ਹਨ, ਜਿਵੇਂ "ਬਰਾਊਜ਼ਰ ਸਭ ਕੁਝ ਕੈਸ਼ ਕਰਦਾ ਹੈ" ਜਾਂ "React ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਤੇਜ਼ ਹੈ"। ਇਹ ਆਇਡੀਆਂ ਸਮਝਦਾਰ ਲੱਗਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਲੋਕ ਸਲੋਗਨ ਉੱਤੇ ਹੀ ਰੁਕ ਜਾਂਦੇ ਹਨ ਬਜਾਏ ਇਹ ਪੁੱਛਣ ਦੇ: ਕਿਸ ਨਾਲ ਤੁਲਨਾ ਕਰਨਾ ਹੈ, ਅਤੇ ਕਿਸ ਹਾਲਤ ਵਿੱਚ?

ਵੈੱਬ ਤਰਜੀحات 'ਤੇ ਬਣਿਆ ਹੈ। ਬਰਾਊਜ਼ਰ ਨੈੱਟਵਰਕ ਲੇਟੈਂਸੀ, CPU, ਰੈਮ, ਮੈਨ ਥ੍ਰੈਡ, GPU ਕੰਮ ਅਤੇ ਸਟੋਰੇਜ ਸੀਮਾਵਾਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਮਾਨਸਿਕ ਨਕਸ਼ਾ ਧੁੰਦਲਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਐਸੀ UI ਦੇ ਸਕਦੇ ਹੋ ਜੋ ਤੁਹਾਡੇ ਲੈਪਟਾਪ 'ਤੇ ਠੀਕ ਲੱਗੇ ਪਰ ਮੱਧ-ਸਤਹ ਦੇ ਫ਼ੋਨ ਤੇ ਖਰਾਬ ਹੋ ਜਾਵੇ ਜਾਂ ਅਟਕ ਜਾਵੇ ਜਦੋਂ Wi‑Fi ਢੀਲਾ ਹੋਵੇ।

ਕੁਝ ਆਮ ਮਨਮਾਨਿਆ ਅਨੁਮਾਨ ਜੋ ਅਸਲੀ ਬੱਗ ਬਣ ਜਾਂਦੇ ਹਨ:

• "ਪਹਿਲੇ ਲੋਡ ਦੇ ਬਾਅਦ ਤੇਜ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।" ਫਿਰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਕੁਝ ਵੀ ਕੈਸ਼ ਨਹੀਂ ਹੋਇਆ ਕਿਉਂਕਿ ਹੈਡਰ ਗੁੰਮ ਸਨ ਜਾਂ ਹਰ ਬਿਲਡ URLs ਬਦਲ ਰਹੇ ਸਨ।
• "ਬਰਾਊਜ਼ਰ ਸਭ ਕੁਝ ਪੈਰਲੈਲ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ।" ਫਿਰ ਇੱਕ ਵੱਡਾ ਸਕ੍ਰਿਪਟ ਮੈਨ ਥ੍ਰੈਡ ਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ ਇੰਪੁੱਟ ਅਟਕਦੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ।
• "ਛਬੀਆਂ ਸਸਤੀ ਹੁੰਦੀਆਂ ਹਨ।" ਫਿਰ ਅਨਕੰਪ੍ਰੈਸਡ ਹੀਰੋ ਛਬੀਆਂ ਰੈਂਡਰਿੰਗ ਨੂੰ ਦੇਰ ਕਰਦੀਆਂ ਹਨ, ਲੇਆਊਟ ਨੂੰ ਖਿਸਕਾਉਂਦੀਆਂ ਹਨ ਅਤੇ Core Web Vitals ਨੂੰ ਬਿਗਾੜਦੀਆਂ ਹਨ।
• "ਸਿਰਫ ਮੇਰਾ ਕੋਡ ਮਹੱਤਵਪੂਰਨ ਹੈ." ਫਿਰ ਤੀਜੀ-ਪੱਖੀ ਵਿਜਟਸ, ਫੋਂਟ ਅਤੇ ਲੰਬੇ ਟਾਸਕ ਟਾਈਮਲਾਈਨ 'ਤੇ ਪ੍ਰਭਾਵੀ ਹੋ ਜਾਂਦੇ ਹਨ।

AI-ਨਿਰਮਿਤ ਫਰੰਟਐਂਡ ਇਹ ਗਲਤੀਆਂ ਵਧਾ ਸਕਦੇ ਹਨ। ਇਕ ਮਾਡਲ ਇੱਕ ਸਹੀ-ਲੱਗਦੀ React ਪੇਜ ਬਣਾ ਸਕਦਾ ਹੈ, ਪਰ ਉਹ ਲੇਟੈਂਸੀ ਮਹਿਸูਸ ਨਹੀਂ ਕਰਦਾ, ਬੈਂਡਵਿਡਥ ਦਾ ਬਿਲ ਨਹੀਂ ਭਰਦਾ, ਅਤੇ ਇਹ ਨਹੀਂ ਦੇਖਦਾ ਕਿ ਹਰ ਰੈਂਡਰ ਵਾਧੂ ਕੰਮ ਕਿਉਂ ਕਰਦਾ ਹੈ। ਇਹ "ਸਿਖਲਾਈ ਵਾਸਤੇ" ਵੱਡੀਆਂ ਡਿਪੈਂਡੇਨਸੀਜ਼ ਜੋੜ ਸਕਦਾ ਹੈ, ਵੱਡਾ JSON HTML ਵਿੱਚ inline ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਇਕੋ ਡੇਟਾ ਦੋ ਵਾਰ ਫੈਚ ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਦੋ ਪੈਟਰਨ ਇੱਕ-ਸਰਹਦ ਦਿਖਦੇ ਹਨ।

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ vibe-coding ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਹੋਰ ਵੀ ਜ਼ਰੂਰੀ ਬਣ ਜਾਂਦਾ ਹੈ: ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਹੁਤ ਸਾਰਾ UI ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਜੋ ਚੰਗਾ ਹੈ, ਪਰ ਛੁਪੇ ਹੋਏ ਬਰਾਊਜ਼ਰ ਖਰਚ ਬਿਨਾਂ ਕਿਸੇ ਦੇ ਧਿਆਨ ਦੇ ਇਕੱਠੇ ਹੋ ਸਕਦੇ ਹਨ।

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

ਇੱਕ ਸਾਫ਼ ਮਾਨਸਿਕ ਨਕਸ਼ਾ: URL ਤੋਂ ਪਿਕਸਲ ਤੱਕ

ਬਰਾਊਜ਼ਰ ਨੂੰ ਉਸ ਫੈਕਟਰੀ ਵਾਂਗ ਸੋਚੋ ਜੋ ਇੱਕ URL ਨੂੰ ਪਿਕਸਲਾਂ ਵਿੱਚ ਬਦਲਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਲਾਈਨ 'ਤੇ ਸਟੇਸ਼ਨਾਂ ਨੂੰ ਜਾਣਦੇ ਹੋ, ਤਾਂ ਸਮਾਂ ਕਿੱਥੇ ਖਰਚ ਹੋ ਰਿਹਾ ਹੈ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।

ਜ਼ਿਆਦਾਤਰ ਪੰਨੇ ਇਹ ਪ੍ਰਵਾਹ ਮੰਨਦੇ ਹਨ:

• ਨੈਵੀਗੇਸ਼ਨ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ: ਤੁਸੀਂ URL ਦਰਜ ਜਾਂ ਲਿੰਕ 'ਤੇ ਕਲਿਕ ਕਰਦੇ ਹੋ, ਅਤੇ ਬਰਾਊਜ਼ਰ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਬੇਨਤੀ ਕਿੱਥੇ ਭੇਜਣੀ ਹੈ।
• ਬਾਇਟ ਆਉਂਦੇ ਹਨ: ਪਹਿਲਾਂ HTML, ਫਿਰ CSS, JS, ਇਮੇਜ ਅਤੇ ਫੋਂਟ।
• ਪਾਰਸਿੰਗ ਹੁੰਦੀ ਹੈ: HTML DOM ਬਣ ਜਾਂਦਾ ਹੈ, CSS ਉਹ ਨਿਯਮ ਬਣ ਜਾਂਦੇ ਹਨ ਜੋ ਬਰਾਊਜ਼ਰ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ।
• ਰੈਂਡਰਿੰਗ ਕੰਮ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਲੇਆਊਟ (ਸਾਈਜ਼ ਅਤੇ ਪੋਜ਼ੀਸ਼ਨ), ਪੇਂਟ (ਡਰਾਇੰਗ), ਫਿਰ ਕਾਂਪੋਜ਼ਿੰਗ (ਲੇਅਰਿੰਗ)।
• ਇੰਟਰਐਕਟੀਵਿਟੀ ਆਉਂਦੀ ਹੈ ਜਿਵੇਂ JavaScript ਚਲਦਾ ਹੈ ਅਤੇ ਇਵੈਂਟ ਹੈਂਡਲਰ ਲੱਗਦੇ ਹਨ।

ਸਰਵਰ HTML, API ਜਵਾਬ ਅਤੇ ਐਸੈੱਟਸ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਨਾਲ ਹੀ ਉਹ ਹੈਡਰ ਵੀ ਜੋ ਕੈਸ਼ਿੰਗ ਅਤੇ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਤ ਕਰਦੇ ਹਨ। ਬਰਾਊਜ਼ਰ ਦਾ ਕੰਮ ਬੇਨਤੀ ਤੋਂ ਪਹਿਲਾਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ (ਕੈਸ਼ ਲੁਕਅੱਪ, DNS, ਕਨੈਕਸ਼ਨ ਸੈਟਅਪ) ਅਤੇ ਜਵਾਬ ਤੋਂ ਬਾਅਦ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਜਾਰੀ ਰਹਿੰਦਾ ਹੈ (ਪਾਰਸਿੰਗ, ਰੈਂਡਰਿੰਗ, ਸਕ੍ਰਿਪਟ ਐਕਜ਼ਿਕਿਊਸ਼ਨ, ਅਗਲੀ ਵਾਰੀ ਲਈ ਸਟੋਰੇਜ)।

ਬਹੁਤ ਸਾਰਾ ਗੁੰਝਲਦਾਰਪਣ ਇਸ ਗੱਲ ਤੋਂ ਆ ਜਾਂਦਾ ਹੈ ਕਿ ਲੋਕ ਸੋਚਦੇ ਹਨ ਬਰਾਊਜ਼ਰ ਇੱਕ ਵਾਰੀ 'ਤੇ ਇਕੋ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਇਹ ਐਸਾ ਨਹੀਂ ਕਰਦਾ। ਕੁਝ ਕੰਮ main thread ਤੋਂ ਬਾਹਰ ਹੁੰਦੇ ਹਨ (ਨੈੱਟਵਰਕ ਫੈਚਿੰਗ, ਇਮੇਜ ਡੀਕੋਡਿੰਗ, ਕੁਝ ਕਾਂਪੋਜ਼ਟਿੰਗ), ਜਦੋਂ ਕਿ ਮੈਨ ਥ੍ਰੈਡ "ਇਸਨੂੰ ਰੋਕੋ ਨਹੀਂ" ਲੇਨ ਹੈ। ਇਹ ਯੂਜ਼ਰ ਇਨਪੁੱਟ ਸੰਭਾਲਦਾ ਹੈ, ਜ਼ਿਆਦਾਤਰ JavaScript ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਲੇਆਊਟ ਅਤੇ ਪੇਂਟ ਦਾ ਕੋਆਰਡੀਨੇਸ਼ਨ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਇਹ ਬਿਜੀ ਹੁੰਦਾ ਹੈ, ਕਲਿਕਸ ਅਣਦੇਖੇ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਅਤੇ ਸਕ੍ਰੋਲਿੰਗ ਚਿਪਚਿਪੀ ਹੋ ਜਾਂਦੀ ਹੈ।

ਜ਼ਿਆਦਾਤਰ ਦੇਰੀਆਂ ਇੱਕੋ ਕੁਝ ਥਾਵਾਂ 'ਚ ਲੁਕੀਆਂ ਹੁੰਦੀਆਂ ਹਨ: ਨੈੱਟਵਰਕ ਉਡੀਕਾਂ, ਕੈਸ਼ ਮਿਸ, CPU-ਭਾਰ ਕੰਮ (JavaScript, ਲੇਆਊਟ, ਬਹੁਤ ਵੱਡਾ DOM), ਜਾਂ GPU-ਭਾਰ ਕੰਮ (ਬਹੁਤ ਵੱਡੇ ਲੇਅਰ ਅਤੇ ਪ੍ਰਭਾਵ)। ਇਹ ਮਾਨਸਿਕ ਨਕਸ਼ਾ ਵੀ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ AI ਟੂਲ ਕੁਝ ਜਨਰੇਟ ਕਰਦਾ ਹੈ ਜੋ “ਠੀਕ ਲੱਗਦਾ” ਪਰ ਹੌਲੀ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ: ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਨੇ ਉਹਨਾਂ ਸਟੇਸ਼ਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ 'ਤੇ ਵਾਧੂ ਕੰਮ ਬਣਾਇਆ ਹੁੰਦਾ ਹੈ।

ਨੈੱਟਵਰਕਿੰਗ ਬੁਨਿਆਦੀ ਜੋ ਤੁਹਾਡੇ UI ਨੂੰ ਅਸਲ ਵਿੱਚ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ

ਕੋਈ ਪੰਨਾ ਅਸਲੀ ਸਮੱਗਰੀ ਡਾਊਨਲੋਡ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਹੌਲੀ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਬਰਾਊਜ਼ਰ ਨੂੰ ਪਹਿਲਾਂ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਣਾ ਪੈਂਦਾ ਹੈ।

ਜਦੋਂ ਤੁਸੀਂ URL ਟਾਈਪ ਕਰਦੇ ਹੋ, ਬਰਾਊਜ਼ਰ ਆਮ ਤੌਰ 'ਤੇ DNS (ਸਰਵਰ ਲੱਭਣਾ), TCP ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦਾ ਹੈ, ਫਿਰ TLS ਸਹਿਮਤੀ ਕਰਦਾ ਹੈ (ਇੰਕ੍ਰਿਪਟ ਅਤੇ ਵੇਰੀਫਾਈ)। ਹਰ ਕਦਮ ਉਡੀਕ ਵਧਾਉਂਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਮੋਬਾਈਲ ਨੈੱਟਵਰਕਾਂ 'ਤੇ। ਇਸੀ ਲਈ "ਬੰਡਲ ਸਿਰਫ 200 KB ਹੈ" ਹੁੰਦਾ ਹੋਇਆ ਵੀ ਹੌਲਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ।

ਫਿਰ ਬਰਾਊਜ਼ਰ HTTP ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ: ਸਟੇਟਸ ਕੋਡ, ਹੈਡਰ, ਅਤੇ ਬਾਡੀ। ਹੈਡਰ UI ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਨ ਕਿਉਂਕਿ ਉਹ ਕੈਸ਼ਿੰਗ, ਕੰਪ੍ਰੈਸ਼ਨ, ਅਤੇ ਕੰਟੈਂਟ ਟਾਈਪ ਨੂੰ ਨਿਯੰਤਰਤ ਕਰਦੇ ਹਨ। ਜੇ ਕੰਟੈਂਟ ਟਾਈਪ ਗਲਤ ਹੈ, ਤਾਂ ਬਰਾਊਜ਼ਰ ਫਾਇਲ ਨੂੰ ਉਮੀਦ ਮੁਤਾਬਕ ਪਾਰਸ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਜੇ ਕੰਪ੍ਰੈਸ਼ਨ ਚਾਲੂ ਨਹੀਂ, ਤਾੰ "ਟੈਕਸਟ" ਐਸੈੱਟ ਵੱਡੇ ਡਾਊਨਲੋਡ ਬਣ ਜਾਂਦੇ ਹਨ।

ਰਿਡਾਇਰੇਕਟ ਵੀ ਸਮਾਂ ਬਰਬਾਦ ਕਰਨ ਦਾ ਆਸਾਨ ਤਰੀਕਾ ਹਨ। ਇੱਕ ਵਾਧੂ ਹੋਪ ਦਾ ਮਤਲਬ ਹੋਰ ਇੱਕ ਬੇਨਤੀ-ਜਵਾਬ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕਈ ਵਾਰੀ ਹੋਰ ਕਨੈਕਸ਼ਨ ਸੈਟਅਪ। ਜੇ ਤੁਹਾਡੀ ਹੋਮਪੇਜ ਇੱਕ URL ਤੇ ਰਿਡਾਇਰੈਕਟ ਕਰਦੀ ਹੈ, ਜੋ ਫਿਰ ਫਿਰ ਰਿਡਾਇਰੈਕਟ ਕਰਦੀ ਹੈ (http ਤੋਂ https, ਫਿਰ www, ਫਿਰ ਲੋਕੇਲ), ਤਾਂ ਤੁਸੀਂ ਮੁੱਖ CSS ਅਤੇ JS ਨੂੰ ਫੈਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਈ ਉਡੀਕਾਂ ਜੋੜ ਦਿੱਤੀਆਂ ਹਨ।

ਆਕਾਰ ਸਿਰਫ਼ ਇਮੇਜ ਨਹੀਂ ਹੁੰਦਾ। HTML, CSS, JS, JSON, ਅਤੇ SVG ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਕੰਪ੍ਰੈਸ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਨਾਲ ਹੀ ਧਿਆਨ ਰੱਖੋ कि ਤੁਹਾਡਾ JavaScript ਕੀ ਖਿੱਚ ਰਿਹਾ ਹੈ। ਇੱਕ "ਛੋਟਾ" JS ਫਾਇਲ ਵੀ ਤੁਰੰਤ ਹੋਰ ਬੇਨਤੀਆਂ (chunks, ਫੋਂਟ, ਤੀਜੀ-ਪੱਖੀ ਸਕ੍ਰਿਪਟ) ਨੂੰ ਟ੍ਰਿਗਰ ਕਰ ਸਕਦੀ ਹੈ।

ਕੁਝ ਤੇਜ਼ ਜਾਂਚ ਜੋ ਜ਼ਿਆਦਾਤਰ UI-ਸੰਬੰਧੀ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਫੜ ਲੈਂਦੇ ਹਨ:

• ਪਹਿਲੀ ਨੇਵੀਗੇਸ਼ਨ 'ਤੇ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਨਿਆਚਤ ਰਿਡਾਇਰੇਕਟ ਹਟਾਓ।
• ਟੈਕਸਟ ਐਸੈੱਟਸ (CSS, JS, JSON, SVG) ਲਈ ਕੰਪ੍ਰੈਸ਼ਨ ਚਾਲੂ ਕਰੋ।
• ਫਾਈਲਾਂ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਪਾਰਸ ਹੋਣ ਲਈ ਕੰਟੈਂਟ ਟਾਈਪ ਵੈਰੀਫਾਈ ਕਰੋ।
• ਬੇਨਤੀ ਬਰਸਟਰਾਂ ਤੇ ਨਜ਼ਰ ਰੱਖੋ: ਦੱਸਾਂ ਚੰਕ, ਫੋਂਟ, ਆਇਕਾਨ, ਅਤੇ ਟਰੈਕਰ।
• ਮੁੱਖ ਐਸੈੱਟਸ ਨੂੰ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਉਸੀ origin 'ਤੇ ਰੱਖੋ ਤਾਂ ਕਿ ਕਨੈਕਸ਼ਨ ਦੁਬਾਰਾ ਵਰਤੇ ਜਾ ਸਕਣ।

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

ਕੈਸ਼ਿੰਗ ਬਿਨਾਂ ਲੋਕਧਾਰਨਾ: ਕੀ ਕਦੋਂ ਦੁਬਾਰਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ

"ਕੈਸ਼" ਇੱਕ ਜਾਦੂਈ ਡੱਬਾ ਨਹੀਂ ਹੈ। ਬਰਾਊਜ਼ਰ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ ਤੋਂ ਡੇਟਾ ਦੁਬਾਰਾ ਵਰਤਦਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਦੀਆਂ ਨਿਯਮਾਵਲੀਅਾਂ ਵੱਖਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਕੁਝ ਸਰੋਤ ਸਮੇਂ ਲਈ ਮੈਮੋਰੀ 'ਚ ਰਹਿੰਦੇ ਹਨ (ਤੇਜ਼, ਪਰ ਰੀਫਰੇਸ਼ 'ਤੇ ਖਤਮ), ਹੋਰ ਡਿਸਕ 'ਤੇ ਸਟੋਰ ਹੁੰਦੇ ਹਨ (ਰਿਸਟਾਰਟ ਬਾਅਦ ਵੀ ਰਹਿੰਦੇ ਹਨ)। HTTP ਕੈਸ਼ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਇਕ ਜਵਾਬ ਦੁਬਾਰਾ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।

Cache-Control ਆਮ ਭਾਸ਼ਾ ਵਿੱਚ

ਜ਼ਿਆਦਾਤਰ ਕੈਸ਼ਿੰਗ ਵਿਵਹਾਰ ਜਵਾਬ ਹੈਡਰਾਂ ਨਾਲ ਚਲਦਾ ਹੈ:

• max-age=...: ਜਦ ਤੱਕ ਸਮਾਂ ਖਤਮ ਨਾ ਹੋਵੇ ਬਿਨਾਂ ਸਰਵਰ ਨਾਲ ਪੁੱਛੇ ਜਵਾਬ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤੋ।
• no-store: ਇਸਨੂੰ ਮੈਮੋਰੀ ਜਾਂ ਡਿਸਕ 'ਤੇ ਨਾਂ ਰੱਖੋ (ਨਾਜੁਕ ਡੇਟਾ ਲਈ ਵਧੀਆ)।
• public: ਸਾਂਝੇ ਕੈਸ਼ਾਂ ਦੁਆਰਾ ਵੀ ਕੈਸ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਸਿਰਫ ਬਰਾਊਜ਼ਰ ਨਹੀਂ।
• private: ਸਿਰਫ ਯੂਜ਼ਰ ਦੇ ਬਰਾਊਜ਼ਰ ਵਿੱਚ ਹੀ ਕੈਸ਼ ਕਰੋ।
• no-cache: ਨਾਮ ਗੁੰਝਲਦਾਰ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ ਇਸਦਾ ਮਤਲਬ ਹੁੰਦਾ ਹੈ "ਇਸਨੂੰ ਸਟੋਰ ਕਰੋ, ਪਰ ਦੁਬਾਰਾ ਵਰਤਣ ਤੋਂ ਪਹਿਲਾਂ ਰੀਵੈਲਿਡੇਟ ਕਰੋ"।

ਜਦੋਂ ਬਰਾਊਜ਼ਰ ਰੀਵੈਲਿਡੇਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਪੂਰੀ ਫਾਇਲ ਡਾਊਨਲੋਡ ਕਰਨ ਤੋਂ ਬਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਜੇ ਸਰਵਰ ਨੇ ETag ਜਾਂ Last-Modified ਦਿੱਤਾ ਹੈ, ਤਾਂ ਬਰਾਊਜ਼ਰ ਪੁੱਛ ਸਕਦਾ ਹੈ "ਕੀ ਇਹ ਬਦਲਿਆ ਹੈ?" ਅਤੇ ਸਰਵਰ "ਨਾਹ, ਬਦਲਿਆ ਨਹੀਂ" ਦੇ ਕੇ ਸੱਤਿਆ ਕਰ ਸਕਦਾ ਹੈ। ਉਹ ਰਾਊਂਡ ਟ੍ਰਿਪ ਫਿਰ ਵੀ ਸਮਾਂ ਲੈਂਦਾ ਹੈ, ਪਰ ਆਮ ਤੌਰ ਤੇ ਪੂਰੇ ਡਾਊਨਲੋਡ ਨਾਲੋਂ ਸਸਤਾ ਹੁੰਦਾ ਹੈ।

ਇੱਕ ਆਮ ਗਲਤੀ (ਖਾਸ ਕਰਕੇ AI-ਜਨਰੇਟ ਕੀਤੇ ਸੈਟਅੱਪਾਂ ਵਿੱਚ) ਇਹ ਹੈ ਕਿ ਹਰ ਬਿਲਡ 'ਤੇ ਜਾਂ ਹਰ ਪੇਜ ਲੋਡ 'ਤੇ ਰੈਂਡਮ ਕਵੇਰੀ ਸਟਰਿੰਗ ਵਰਗੀ app.js?cacheBust=1736 ਜੋੜ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਪਰ ਇਹ ਕੈਸ਼ਿੰਗ ਨੂੰ ਨਸਬ ਕਰ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਚੰਗਾ ਰੈਗਟ ਪੈਟਰਨ ਹੈ: ਸਥਿਰ URLs ਸਥਿਰ ਸਮੱਗਰੀ ਲਈ, ਅਤੇ ਵਰਜਨਡ ਐਸੈੱਟਸ ਲਈ ਫਾਈਲਾਂ ਵਿੱਚ ਕਾਂਟੈਂਟ ਹੈਸ਼।

ਕੈਸ਼ ਬੱਸਟਰ ਜੋ ਵਾਪਸੀ 'ਚ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੇ ਹਨ ਕੁਝ ਆਮ ਰੂਪਾਂ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ: ਰੈਂਡਮ ਕਵੇਰੀ ਪੈਰਾਮ, ਬਦਲ ਰਹੀ JS/CSS ਲਈ ਇੱਕੋ ਫਾਈਲ ਨਾਮ ਦੁਬਾਰਾ ਵਰਤਣਾ, ਹਰ ਡਿਪਲੋਇ 'ਤੇ URLs ਬਦਲਣਾ ਮੁਗਰੋਂ ਸਮੱਗਰੀ ਨ ਨ ਬਦਲੇ, ਜਾਂ ਵਿਕਾਸ ਦੌਰਾਨ ਕੈਸ਼ਿੰਗ ਬੰਦ ਕਰਨਾ ਅਤੇ ਭੁੱਲਣਾ ਕਿ ਇਸਨੂੰ واپس ਠੀਕ ਕਰਨਾ।

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

ਰੈਂਡਰਿੰਗ ਪਾਈਪਲਾਈਨ ਮੁਢਲੀ: ਪਾਰਸ, ਲੇਆਊਟ, ਪੇਂਟ, ਕੰਪੋਜ਼ਿਟ

"ਰਹੱਸਮਈ" UI ਬੱਗ ਨੂੰ ਘਟਾਉਣ ਲਈ, ਬਰਾਊਜ਼ਰ ਕਿਵੇਂ ਬਾਇਟਸ ਨੂੰ ਪਿਕਸਲਾਂ ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਇਹ ਸਿੱਖੋ।

ਜਦੋਂ HTML ਆਉਂਦਾ ਹੈ, ਬਰਾਊਜ਼ਰ ਇਸਨੂੰ ਉਪਰ-ਥੋਂ-ਥੱਲੇ ਪਾਰਸ ਕਰਦਾ ਹੈ ਅਤੇ DOM ਬਣਾਉਂਦਾ ਹੈ (ਤੱਤਾਂ ਦਾ ਇੱਕ ਦਰੱਖਤ)। ਜਦੋਂ ਇਹ ਪਾਰਸ ਕਰਦਾ ਹੈ, ਇਹ CSS, ਸਕ੍ਰਿਪਟ, ਇਮੇਜ ਅਤੇ ਫੋਂਟ ਨੂੰ ਖੋਜ ਸਕਦਾ ਹੈ ਜੋ ਦਿਖਾਈ ਜਾਣ ਵਾਲੀ ਸਮੱਗਰੀ ਨੂੰ ਬਦਲਦੇ ਹਨ।

CSS ਖਾਸ ਹੈ ਕਿਉਂਕਿ ਬਰਾਊਜ਼ਰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸਮੱਗਰੀ ਦਿਖਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਅੰਤਿਮ ਸਟਾਈਲਾਂ ਜਾਣਨ ਦੀ ਲੋੜ ਹੈ। ਇਸੀ ਲਈ CSS ਰੈਂਡਰਿੰਗ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ: ਬਰਾਊਜ਼ਰ CSSOM (ਸਟਾਈਲ ਨਿਯਮ) ਬਣਾਂਦਾ ਹੈ, ਫਿਰ DOM + CSSOM ਨੂੰ ਰੈਂਡਰ ਟਰੀ ਵਿੱਚ ਮਿਲਾਉਂਦਾ ਹੈ। ਜੇ ਮੁੱਖ CSS ਦੇਰ ਨਾਲ ਆਊਂਦਾ ਹੈ, ਪਹਿਲੀ ਪੇਂਟ ਦੇਰ ਨਾਲ ਆਉਂਦੀ ਹੈ।

ਜਦੋਂ ਸਟਾਈਲਾਂ ਪਤਾ ਲੱਗ ਜਾਂਦੀਆਂ ਹਨ, ਮੁੱਖ ਕਦਮ ਹਨ:

• Layout: ਆਕਾਰ ਅਤੇ ਸਥਾਨਾਂ ਦੀ ਗਣਨਾ।
• Paint: ਟੈਕਸਟ, ਬਾਰਡਰ, ਸ਼ੈਡੋ, ਇਮੇਜ ਆਦਿ ਲਈ ਪਿਕਸਲ ਬਣਾਓ।
• Composite: ਪੇਂਟ ਕੀਤੇ ਲੇਅਰਾਂ ਨੂੰ ਸਟੈਕ ਕਰੋ ਅਤੇ ਟ੍ਰਾਂਸਫਾਰਮ/ਓਪੇਸਿਟੀ ਲਗਾਓ।

ਇਮੇਜ ਅਤੇ ਫੋਂਟ ਅਕਸਰ ਉਸ ਗੱਲ ਦਾ ਨਿਰਧਾਰਕ ਹੁੰਦੇ ਹਨ ਜੋ ਯੂਜ਼ਰ "ਲੋਡ ਹੋਇਆ" ਸਮਝਦਾ ਹੈ। ਇੱਕ ਦੇਰ ਨਾਲ ਆਉਣ ਵਾਲੀ ਹੀਰੋ ਇਮੇਜ Largest Contentful Paint ਨੂੰ ਦੇਰ ਕਰਦੀ ਹੈ। Web ਫੋਂਟ ਅਦ੍ਰਿਸ਼ਟ ਟੈਕਸਟ ਜਾਂ ਸਟਾਈਲ ਸਵੈਪ ਕਰਵਾ ਸਕਦੇ ਹਨ ਜੋ ਫਲਿਕਰ ਵਰਗਾ ਲੱਗਦਾ ਹੈ। ਸਕ੍ਰਿਪਟ ਪਾਰਸਿੰਗ ਰੋਕਕੇ ਜਾਂ ਵਾਧੂ ਸਟਾਈਲ ਮੁੜਗਣਤਰੀ ਕਰਵਾਕੇ ਪਹਿਲੀ ਪੇਂਟ ਰੋਕ ਸਕਦੇ ਹਨ।

ਇਕ ਮਿਆਰੀ ਮਿਥ ਹੈ "ਐਨੀਮੇਸ਼ਨ ਮੁਫ਼ਤ ਹੈ"। ਇਹ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ animate ਕਰ ਰਹੇ ਹੋ। width, height, top, ਜਾਂ left ਨੁੰਬਰ ਬਦਲਣਾ ਅਕਸਰ ਲੇਆਊਟ ਨੂੰ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ, ਫਿਰ ਪੇਂਟ, ਫਿਰ ਕਾਂਪੋਜ਼ਿਟ। transform ਜਾਂ opacity animate ਕਰਨਾ ਅਕਸਰ ਕੰਪੋਜ਼ਿਟਿੰਗ ਵਿੱਚ ਹੀ ਰਹਿੰਦਾ ਹੈ, ਜੋ ਕਾਫ਼ੀ ਸਸਤਾ ਹੈ।

ਇੱਕ ਵਾਸਤਵਿਕ AI-ਜਨਰੇਟ ਕੀਤੀ ਗਲਤੀ ਇੱਕ ਲੋਡਿੰਗ ਸ਼ਿਮਰ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਕਈ ਕਾਰਡਾਂ 'ਤੇ background-position animate ਕਰਦੀ ਹੈ, ਨਾਲ ਹੀ ਇੱਕ ਟਾਈਮਰ ਤੋਂ ਆਉਣ ਵਾਲੇ ਅਵਿਰਤ DOM ਅਪਡੇਟ। ਨਤੀਜਾ ਨਿਰੰਤਰ ਰੀਪੇਂਟਿੰਗ ਹੁੰਦੀ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ ਸਹੀ ਕਰਨ ਲਈ ਸਧਾਰਣ ਹੁੰਦਾ ਹੈ: ਘੱਟ ਤੱਤ animate ਕਰੋ, ਗਤੀ ਲਈ transform/opacity ਵਰਤੋ, ਅਤੇ ਲੇਆਊਟ ਸਥਿਰ ਰੱਖੋ।

JavaScript ਅਤੇ ਫਰੇਮਵਰਕ ਖਰਚ ਜੋ ਤੁਸੀਂ ਮਹਿਸੂਸ ਕਰ ਸਕਦੇ ਹੋ

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

ਫਰੇਮਵਰਕ ਆਪਣੇ ਖਰਚ ਜੋੜਦੇ ਹਨ। React ਵਿੱਚ, "ਰੈਂਡਿੰਗ" ਉਹ ਹੈ ਕਿ UI ਕਿਵੇਂ ਦਿਖਣਾ ਚਾਹੀਦਾ ਹੈ ਇਹ ਗਣਨਾ ਕਰਨਾ। ਪਹਿਲੀ ਲੋਡ 'ਤੇ, ਕਲਾਇਂਟ-ਸਾਈਡ ਐਪ ਅਕਸਰ hydration ਕਰਦੇ ਹਨ: ਇਵੈਂਟ ਹੈਂਡਲਰ ਜੋੜਨਾ ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਪੇਜ 'ਤੇ ਹਨ ਵਾਲੀ DOM ਨਾਲ ਮਿਲਾਉਣਾ। ਜੇ hydration ਭਾਰੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਪੇਜ ਮਿਲਦਾ ਹੈ ਜੋ ਦਿਖਣ ਵਿੱਚ ਤਿਆਰ ਲੱਗਦਾ ਹੈ ਪਰ ਕੁਝ ਸਮੇਂ ਲਈ ਟੈਪ ਨੂੰ ਅਣਦੇਖਾ ਕਰਦਾ ਹੈ।

ਦਰਦ ਆਮ ਤੌਰ 'ਤੇ ਲੰਮੇ ਟਾਸਕ ਵਿੱਚ ਦਿਸਦੀ ਹੈ: ਜਾਵਾਸਕ੍ਰਿਪਟ ਇੰਨਾ ਲੰਬਾ ਚਲਦਾ ਹੈ (ਅਕਸਰ 50ms ਜਾਂ ਉਸ ਤੋਂ ਵੱਧ) ਕਿ ਬਰਾਊਜ਼ਰ ਵਿਚਕਾਰ-ਵਿੱਚ ਸਕ੍ਰੀਨ ਅਪਡੇਟ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਤੁਸੀਂ ਇਸਨੂੰ ਦੇਰ ਨਾਲ ਇਨਪੁੱਟ, ਫ੍ਰੇਮ ਡਰਾਪ, ਅਤੇ ਕੱਚੇ ਐਨੀਮੇਸ਼ਨਾਂ ਵਜੋਂ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ।

ਆਮ ਦੋਸ਼ ਸਧਾਰਣ ਹਨ:

• ਸਟਾਰਟਅਪ 'ਤੇ ਬਹੁਤ ਸਾਰਾ ਕੋਡ ਚਲ ਰਿਹਾ ਹੈ
• ਵੱਡੇ JSON payloads ਜੋ ਪਾਰਸ ਅਤੇ ਟਰਾਂਸਫਾਰਮ ਕਰਨ ਵਿੱਚ ਸਮਾਂ ਲੈਂਦੇ ਹਨ
• ਕੰਪੋਨੈਂਟਾਂ ਜੋ ਇੱਕ ਵਾਰ ਵਿੱਚ ਬਹੁਤ ਸਾਰਾ ਕੰਮ ਰੈਂਡਰ ਕਰਦੀਆਂ ਹਨ
• ਮਾਉਂਟ 'ਤੇ ਬਹੁਤ ਸਾਰੇ эффੈਕਟਸ ਜੋ ਚਲਦੇ ਹਨ ਅਤੇ ਵਾਧੂ ਰੈਂਡਰ ਟ੍ਰਿਗਰ ਕਰਦੇ ਹਨ
• ਅਸਥਿਰ props, state ਜਾਂ context ਕਾਰਨ ਬਹੁਤ ਵਾਰ ਰੀ-ਰੈਂਡਰ

ਸੁਧਾਰ ਮੈਨ-ਥ੍ਰੈਡ ਕੰਮ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰਨ ਨਾਲ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੇ ਹਨ, ਸਿਰਫ ਬਾਈਟਸ 'ਤੇ ਨਹੀਂ:

• ਰੂਟ ਜਾਂ ਫੀਚਰ ਅਨੁਸਾਰ ਕੋਡ ਨੂੰ ਵੰਡੋ ਤਾਂ ਕਿ ਪਹਿਲੇ ਵਿਊ 'ਤੇ ਘੱਟ ਲੋਡ ਹੋਵੇ।
• ਗੈਰ-ਆਵਸ਼ਕ ਕੰਮ ਪਹਿਲੀ ਪੇਂਟ ਤੋਂ ਬਾਅਦ ਜਾਂ ਇੰਟਰਐਕਸ਼ਨ ਤੋਂ ਬਾਅਦ ਟਾਲ ਦਿਓ।
• ਹਾਈਡਰੇਸ਼ਨ ਹਲਕਾ ਰੱਖੋ ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਰੈਂਡਰਾਂ ਵਿੱਚ ਭਾਰੀ ਟਰਾਂਸਫਾਰਮ ਤੋਂ ਬਚੋ।
• ਧਿਆਨ ਨਾਲ memoize ਕਰੋ, ਪਰ ਮਾਪੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਬਿਨਾਂ ਲਾਭ ਦੇ ਜਟਿਲਤਾ ਨਾ ਜੋੜੋ।
• ਜਿਥੇ ਸੰਭਵ ਹੋ, ਮਹਿੰਗੇ ਪਾਰਸਿੰਗ/ਫਾਰਮੈਟਿੰਗ ਮੈਨ-ਥ੍ਰੈਡ ਤੋਂ ਬਾਹਰ ਕਰੋ।

ਜੇ ਤੁਸੀਂ ਚੈਟ-ਚਲਿਤ ਟੂਲ ਜਿਵੇਂ Koder.ai ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਮਦਦ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸਿੱਧਾ ਇਹ ਪਾਬੰਦੀਆਂ ਪੁڇੋ: ਪ੍ਰਾਰੰਭਿਕ JS ਛੋਟਾ ਰੱਖੋ, ਮਾਉਂਟ-ਟਾਈਮ эффੈਕਟਸ ਤੋਂ ਬਚੋ, ਅਤੇ ਪਹਿਲੀ ਸਕਰੀਨ ਸਧਾਰਨ ਰੱਖੋ।

ਕਦਮ-ਦਰ-कਦਮ: ਹੌਲੀ ਪੰਨੇ ਨੂੰ ਡੀਬੱਗ ਕਿਵੇਂ ਕਰੀਏ

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

ਇੱਕ ਵਰਤੋ ਗਯੋਗ ਵਰਕਫਲੋ

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

ਇੱਕ ਵਰਕਫਲੋ ਜੋ ਤੁਹਾਨੂੰ ਸਭ ਕੁਝ ਇਕੱਠੇ ਸੁਧਾਰਨ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ:

• ਲਿਖ ਦਿਓ ਕਿ ਕੀ ਸਲੋ ਹੈ (ਅਰੰਭਿਕ ਲੋਡ, ਇੰਟਰਐਕਸ਼ਨ, ਜਾਂ ਡੇਟਾ ਰੀਫਰੇਸ਼) ਅਤੇ ਲਗਭਗ ਸਮਾਂ।
• ਨੈੱਟਵਰਕ ਵਿਰੁੱਧ CPU ਨੂੰ ਵੱਖ ਕਰੋ: ਆਪਣੀ ਕਨੈਕਸ਼ਨ ਨੂੰ ਥਰੌਟਲ ਕਰੋ ਅਤੇ ਤੁਲਨਾ ਕਰੋ। ਜੇ ਇਹ ਬਹੁਤ ਖਰਾਬ ਹੋ ਜਾਂਦਾ ਹੈ, ਨੈੱਟਵਰਕ ਬੜਾ ਹਿੱਸਾ ਹੈ। ਜੇ ਇਹ ਥੋੜ੍ਹਾ ਬਦਲਦਾ ਹੈ, ਤਾਂ CPU ਕੰਮ 'ਤੇ ਧਿਆਨ ਦਿਓ।
• ਸਭ ਤੋਂ ਵੱਡੀ ਬੇਨਤੀ ਅਤੇ ਸਭ ਤੋਂ ਵੱਡੇ ਲੰਮੇ ਟਾਸਕ ਨੂੰ ਲੱਭੋ। ਇੱਕ ਭਾਰੀ JS ਬੰਡਲ, ਇੱਕ ਵੱਡੀ ਇਮੇਜ, ਜਾਂ ਇੱਕ ਲੰਮਾ "script" ਟਾਸਕ ਅਕਸਰ ਮੁੱਖ ਦੋਸ਼ੀ ਹੁੰਦਾ ਹੈ।
• ਇੱਕ-ਇੱਕ ਕਰਕੇ ਇੱਕ ਕਾਰਨ ਹਟਾਓ (ਇੱਕ ਬੰਡਲ ਸਪਲਿੱਟ ਕਰੋ, ਇੱਕ ਚਿੱਤਰ ਦਾ ਆਕਾਰ ਘਟਾਓ, ਇੱਕ ਤੀਜੀ-ਪੱਖੀ ਸਕ੍ਰਿਪਟ ਨੂੰ ਡਿਫਰ ਕਰੋ), ਫਿਰ ਮੁੜ-ਟੈਸਟ ਕਰੋ।
• ਵਾਸਤਵਿਕ ਡਿਵਾਈਸ ਅਤੇ ਕਨੈਕਸ਼ਨ 'ਤੇ ਮੁੜ-ਟੈਸਟ ਕਰੋ। ਇਕ ਤੇਜ਼ ਲੈਪਟਾਪ ਉਹ ਸਮੱਸਿਆਵਾਂ ਛੁਪਾਉਂਦਾ ਹੈ ਜੋ ਮੱਧ-ਸਤਹ ਫੋਨਾਂ 'ਤੇ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ।

ਇੱਕ ਕਾਂਕਰੀਟ ਉਦਾਹਰਨ: ਇੱਕ AI-ਜਨਰੇਟ ਕੀਤੇ React ਪੰਨੇ ਨੇ ਇਕੱਲਾ 2 MB ਜਾਵਾਸਕ੍ਰਿਪਟ ਫਾਇਲ ਅਤੇ ਇੱਕ ਵੱਡੀ ਹੀਰੋ ਇਮੇਜ ਸ਼ਿੱਪ ਕੀਤੀ। ਤੁਹਾਡੇ ਮਸ਼ੀਨ 'ਤੇ ਇਹ ਠੀਕ ਲੱਗਦਾ ਹੈ। ਫੋਨ ਤੇ ਇਹ JS ਪਾਰਸ ਕਰਨ ਵਿੱਚ ਸਕਿੰਟ ਲੈਂਦਾ ਹੈ ਪੂਰੇ ਤੌਰ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ। ਪਹਿਲੇ-ਦ੍ਰਿਸ਼ JS ਨੂੰ ਕੱਟੋ ਅਤੇ ਹੀਰੋ ਇਮੇਜ ਦਾ ਆਕਾਰ ਘਟਾਓ ਅਤੇ ਤੁਹਾਨੂੰ ਅਕਸਰ ਪਹਿਲੀ ਇੰਟਰੈਕਸ਼ਨ ਦਾ ਸਮਾਂ ਕਾਫੀ ਘਟਿਆ ਹੋਇਆ ਮਿਲੇਗਾ।

ਜਿੱਤ ਨੂੰ ਲਾਕ ਕਰੋ

ਜਦੋਂ ਤੁਹਾਨੂੰ ਮਾਪਯੋਗ ਸੁਧਾਰ ਮਿਲ ਜਾਏ, ਤਾਂ ਉਸਨੂੰ ਵਾਪਸ ਜਾਣਾ ਮੁਸ਼ਕਿਲ ਕਰ ਦਿਓ।

ਬਜਟ ਸੈੱਟ ਕਰੋ (ਅਧਿਕਤਮ ਬੰਡਲ ਆਕਾਰ, ਅਧਿਕਤਮ ਇਮੇਜ ਆਕਾਰ) ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਆਉਂਂਦੇ ਹੋ ਤਾਂ ਬਿਲਡ ਫੇਲ ਕਰਵਾਓ। ਰੇਪੋ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਪ੍ਰਦਰਸ਼ਨ ਨੋਟ ਰੱਖੋ: ਕੀ ਸਲੋ ਸੀ, ਕੀ ਠੀਕ ਕੀਤਾ, ਅਤੇ ਕੀ ਦੇਖਣਾ ਹੈ। ਵੱਡੇ UI ਬਦਲਾਵਾਂ ਜਾਂ ਨਵੀਆਂ ਡਿਪੈਂਡੰਸੀਜ਼ ਦੇ ਬਾਅਦ ਮੁੜ-ਚੈੱਕ ਕਰੋ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ AI ਤੇਜ਼ੀ ਨਾਲ ਕੰਪੋਨੈਂਟ ਜਨਰੇਟ ਕਰ ਰਿਹਾ ਹੋਵੇ।

AI-ਨਿਰਮਿਤ ਫਰੰਟਐਂਡ ਵਿੱਚ ਆਮ غلطੀਆਂ (ਅਤੇ ਕਿਉਂ ਹੁੰਦੀਆਂ ਹਨ)

AI ਤੇਜ਼ੀ ਨਾਲ ਕਾਰਯਸ਼ੀਲ UI ਲਿਖ ਸਕਦਾ ਹੈ, ਪਰ ਅਕਸਰ ਉਹ ਉਹ ਨਿਰਦੋਸ਼ ਪਰਤਾਂ ਛੱਡ ਦਿੰਦਾ ਹੈ ਜੋ ਪੰਨਿਆਂ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਬਰਾਊਜ਼ਰ ਮੁਢਲੀ ਜਾਣਕਾਰੀ ਤੁਹਾਨੂੰ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਜਲਦੀ ਪਛਾਣਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ, ਪਹਿਲਾਂ ਹੀ ਕਿ ਉਹ ਹੌਲੇ ਲੋਡ, ਛਿਕਦਾਰ ਸਕ੍ਰੋਲਿੰਗ, ਜਾਂ ਅਚਾਨਕ API ਬਿੱਲ ਵਜੋਂ ਸਾਹਮਣੇ ਆਉਣ।

ਓਵਰਫੈਚਿੰਗ ਆਮ ਹੈ। ਇੱਕ AI-ਜਨਰੇਟ ਕੀਤਾ ਪੰਨਾ ਇੱਕੋ ਸਕਰੀਨ ਲਈ ਬਹੁਤ ਸਾਰੀਆਂ ਐਂਡਪੌਇੰਟਾਂ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ, ਛੋਟੇ-ਸਟੇਟ ਬਦਲਾਅ 'ਤੇ ਰੀ-ਫੈਚ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਪੂਰਾ ਡੇਟਾ ਖਿੱਚ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਸਿਰਫ ਪਹਿਲੇ 20 ਆਈਟਮਾਂ ਦੀ ਲੋੜ ਹੋਵੇ। ਪ੍ਰੋੰਪਟਜ਼ ਵੱਧਤਰ UI ਨੂੰ ਵੇਰਵਾ ਕਰਦੇ ਹਨ ਨਾ ਕਿ ਡੇਟਾ ਦਾ ਆਕਾਰ, ਇਸ ਲਈ ਮਾਡਲ ਖਾਲੀ ਕੋਠੜੀ ਨੂੰ ਵਾਧੂ ਕਾਲ ਨਾਲ ਭਰ ਦਿੰਦਾ ਹੈ ਅਤੇ pagination ਜਾਂ batching ਨਹੀਂ ਜੋੜਦਾ।

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

ਕੈਸ਼ਿੰਗ ਦੀਆਂ ਗਲਤੀਆਂ ਅਕਸਰ ਭਲੇ ਮਨ ਤੋਂ ਕੀਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। AI ਕਈ ਵਾਰੀ ਐਸੇ ਹੈਡਰ ਜਾਂ ਫੈਚ ਵਿਕਲਪ ਜੋੜੇਗਾ ਜੋ ਅਸਲ 'ਚ "ਕਦੇ ਵੀ ਕੁਝ ਵੀ ਦੁਬਾਰਾ ਵਰਤੋ ਨਾ" ਵਰਗੇ ਨਤੀਜੇ ਦਿੰਦੇ ਹਨ, ਕਿਉਂਕਿ ਇਹ محفوظ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਨਤੀਜਾ: ਬੇਹੱਦ ਡਾਊਨਲੋਡ, ਦੁਹਰਾਈਆਂ ਯਾਤਰਾ ਹੌਲੀ, ਅਤੇ ਬੈਕਏਂਡ 'ਤੇ ਵਧੀਕ ਲੋਡ।

Hydration mismatches ਬਹੁਤ ਆਮ ਹਨ rushed React ਆਉਟਪੁੱਟਾਂ ਵਿੱਚ। ਸਰਵਰ ਤੇ ਰੈਂਡਰ ਕੀਤੀ ਮਾਰਕਅੱਪ (ਜਾਂ ਪ੍ਰੀ-ਰੈਂਡ) ਕਲਾਇੰਟ ਦੇ ਰੈਂਡਰ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ, ਤਾਂ React ਚੇਤਾਵਨੀ ਦੇਂਦਾ ਹੈ, ਮੁੜ-ਰੈਂਡ ਕਰਦਾ ਹੈ, ਜਾਂ ਇਵੈਂਟ ਅਨੋਖੀ ਤਰ੍ਹਾਂ ਲਗਾਉਂਦਾ ਹੈ। ਇਹ ਅਕਸਰ ਪਹਿਲੀ ਰੈਂਡਰ ਵਿੱਚ ਰੈਂਡਮ ਵੈਲਯੂਜ਼ (ਤਰੀਕਾਂ, ID) ਮਿਲਾਉਣ ਜਾਂ ਕਲੀਐਂਟ-ਓਨਲੀ ਸਟੇਟ 'ਤੇ ਨਿਰਭਰ ਸ਼ਰਤਾਂ ਦੇ ਮਿਸ਼ਰਣ ਤੋਂ ਹੁੰਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ਇਹ ਸੰਕੇਤ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਸਮਝੋ कि ਪੰਨਾ ਬਿਨਾਂ ਪ੍ਰਦਰਸ਼ਨ ਗਾਰਡਰੇਲ ਦੇ ਇਕੱਠਾ ਕੀਤਾ ਗਿਆ ਸੀ: ਇੱਕ ਸਕਰੀਨ ਲਈ ਕਈ ਬੇਨਤੀਆਂ, ਇਕ ਵੱਡਾ JS ਬੰਡਲ ਜੋ ਇਕ ਅਣਉਪਯੋਗ UI ਲਾਇਬ੍ਰੇਰੀ ਰੱਨ ਕਰਦਾ ਹੈ, efeito that refetch because they depend on unstable values, fonts or third-party scripts loading before critical CSS, or caching disabled globally instead of per-request.

ਜਦੋਂ ਤੁਸੀਂ Koder.ai ਵਰਗੇ vibe-coding ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤGenerated output ਨੂੰ ਪਹਿਲੀ ਡਰਾਫ਼ਟ ਵਜੋਂ ਸਮਝੋ। pagination, explicit caching rules, ਅਤੇ ਇਹ ਕਿ ਪਹਿਲੀ ਪੇਂਟ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਲੋਡ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਮੰਗੋ।

ਇਕ ਹਕੀਕਤੀ ਉਦਾਹਰਨ: ਇੱਕ AI-ਜਨਰੇਟ React ਪੰਨਾ ਠੀਕ ਕਰਨਾ

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

ਲੱਛਣ ਜਾਣੇ-ਪਛਾਣ ਵਾਲੇ ਹਨ: ਟੈਕਸਟ ਦੇਰੀ ਨਾਲ ਦਿਖਦਾ ਹੈ, ਫੋਂਟ ਲੋਡ ਹੋਣ 'ਤੇ ਲੇਆਊਟ ਉਲਟ-ਪੁਲਟ ਹੋ ਜਾਂਦਾ ਹੈ, ਕੀਮਤ ਕਾਰਡ ਤਸਵੀਰਾਂ ਆਉਣ 'ਤੇ ਖਿੱਚਦੇ ਹਨ, API ਕਾਲ ਵਾਰ-ਵਾਰ ਚਲਦੀ ਹੈ, ਅਤੇ ਕੁਝ ਐਸੈੱਟ ਸੋਧ ਦੇ ਬਾਅਦ ਪੁਰਾਣੇ ਰਹਿ ਜਾਂਦੇ ਹਨ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਰਹੱਸਮਈ ਨਹੀਂ ਹੈ। ਇਹ ਮੁਢਲੀ ਬਰਾਊਜ਼ਰ ਵਿਹਾਰ ਦਾ UI 'ਤੇ ਪ੍ਰਭਾਵ ਹੈ।

ਦੋ ਨਜ਼ਾਰਿਆਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ।

ਪਹਿਲਾਂ, DevTools ਖੋਲ੍ਹੋ ਅਤੇ Network waterfall ਦੀ ਜਾਂਚ ਕਰੋ। ਇੱਕ ਵੱਡਾ JS ਬੰਡਲ ਜੋ ਸਭ ਕੁਝ ਰੋਕ ਰਿਹਾ ਹੈ, ਫੋਂਟ ਦੇ ਦੇਰ ਨਾਲ ਲੋਡ ਹੋਣਾ, ਇਮੇਜਾਂ ਵਿੱਚ ਸਾਈਜ਼ ਹਿੰਟ ਨਾ ਹੋਣਾ, ਅਤੇ ਇੱਕੋ ਹੀ ਐਂਡਪੌਇੰਟ ਲਈ ਦੁਹਰਾਈਆਂ ਕਾਲਾਂ (ਅਕਸਰ ਥੋੜ੍ਹੇ ਵੱਖ-ਵੱਖ ਕਵੇਰੀ ਸਟਰਿੰਗ ਨਾਲ) ਦੀ talash karo।

ਦੂਜਾ, ਮੁੜ-ਲੋਡ ਕਰਦਿਆਂ Performance ਟ੍ਰੇਸ ਰਿਕਾਰਡ ਕਰੋ। ਲੰਮੇ ਟਾਸਕ (ਮੈਨ ਥ੍ਰੈਡ ਰੋਕਣਾ) ਅਤੇ Layout Shift ਇਵੈਂਟਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ (ਜਦੋਂ ਸਮੱਗਰੀ ਆਉਣ ਤੋਂ ਬਾਅਦ ਪੇਜ ਮੁੜ-ਫਲੋ ਹੁੰਦਾ ਹੈ)।

ਇਸ ਸਿੱਧੀ ਸਥਿਤੀ ਵਿੱਚ, ਇੱਕ ਛੋਟੀ ਸੁਧਾਰ ਸੈੱਟ ਆਮ ਤੌਰ 'ਤੇ ਬਹੁਤ ਸਾਰਾ ਨਫ਼ਾ ਦਿੰਦਾ ਹੈ:

• ਕੈਸ਼ਿੰਗ ਹੈਡਰ: ਵਰਜਨਡ ਐਸੈੱਟਸ (ਜਿਵੇਂ app.abc123.js) ਨੂੰ ਲੰਬਾ ਕੈਸ਼ ਦਿਓ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ HTML ਸਦਾ ਨਹੀਂ ਕੈਸ਼ ਕੀਤੀ ਜਾ ਰਹੀ ਤਾਂ ਜੋ ਉਹ ਨਵੇਂ ਫਾਈਲਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਸਕੇ।
• ਫੋਂਟ ਰਣਨੀਤੀ: ਇੱਕ ਸਿਸਟਮ fallback ਵਰਤੋ, ਸਿਰਫ ਉਹਨਾਂ ਇੱਕ-ਦੋ ਫੋਂਟਾਂ ਨੂੰ preload ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੀ ਸਹੀ ਜ਼ਰੂਰਤ ਹੈ, ਅਤੇ ਬਹਿਸ ਵਾਲੇ ਵਜ਼ਨਾਂ ਨੂੰ ਲੋਡ ਕਰਨ ਤੋਂ ਬਚੋ।
• ਕੋਡ ਸਪਲਿੱਟਿੰਗ: "ਤਾਜ਼ਾ ਅੱਪਡੇਟ" ਵਿਜੇਟ ਅਤੇ ਭਾਰੀ ਐਨੀਮੇਸ਼ਨ ਲਾਇਬ੍ਰੇਰੀਜ਼ ਪਹਿਲੀ ਪੇਂਟ ਵਿੱਚ ਨਹੀਂ, ਜਦ ਲੋੜ ਹੋਵੇ ਤਦ ਲੋਡ ਕਰੋ।
• ਬੇਨਤੀ ਸਫਾਈ: API ਕਾਲਾਂ ਨੂੰ ਇੱਕ ਵਾਰ ਚਲਾਉ, (ਡੇਵ ਵਿੱਚ React Strict Mode effects ਦੁਆਰਾ ਦੋ-ਵਾਰ ਚਲਾਉਣ ਤੇ ਧਿਆਨ), ਫੈਚਾਂ ਨੂੰ ਡਿਡੁਪ ਕਰੋ, ਅਤੇ ਮਾਰਕੀਟਿੰਗ ਪੰਨੇ 'ਤੇ ਪੋਲਿੰਗ ਤੋਂ ਬਚੋ।
• ਚਿੱਤਰ ਸਥਿਰਤਾ: width ਅਤੇ height (ਜਾਂ aspect-ratio) ਸੈੱਟ ਕਰੋ ਤਾਂ ਕਿ ਬਰਾਊਜ਼ਰ ਥਾਂ ਰਿਜ਼ਰਵ ਕਰ ਸਕੇ ਅਤੇ ਲੇਆਊਟ ਜੰਪ ਤੋਂ ਬਚ ਸਕੇ।

ਫੈਸਲਾ ਕੀਤੇ ਸੂਧਾਰਾਂ ਦੀ ਜਾਂਚ ਕਰਦੇ ਸਮੇਂ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਟੂਲ ਦੀ ਲੋੜ ਨਹੀਂ। cache disabled ਨਾਲ ਤਿੰਨ ਰੀਲੋਡ ਕਰੋ, ਫਿਰ cache ਚਾਲੂ ਕਰਕੇ ਤਿੰਨ। waterfall ਨੂੰ ਤੁਲਨਾ ਕਰੋ। ਟੈਕਸਟ ਪਹਿਲਾਂ ਦਿਖਣਾ ਚਾਹੀਦਾ ਹੈ, API ਕਾਲ ਇੱਕ 'ਤੇ ਨਿਊਨਤਮ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਲੇਆਊਟ ਸਥਿਰ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। ਆਖ਼ਿਰ 'ਤੇ, ਡਿਪਲੋਇ ਦੇ ਬਾਅਦ ਹਾਰਡ ਰੀਫਰੇਸ਼ ਕਰੋ। ਜੇ ਅਜੇ ਵੀ ਪੁਰਾਣਾ CSS ਜਾਂ JS ਦਿਖਾਈ ਦੇ ਰਿਹਾ ਹੈ, ਤਾਂ ਕੈਸ਼ਿੰਗ ਨਿਯਮ ਤੁਹਾਡੇ ਬਿਲਡ ਪਾਬੰਦੀਆਂ ਨਾਲ ਸੰਗਤ ਨਹੀਂ ਹਨ।

ਜੇ ਤੁਸੀਂ ਪੰਨਾ Koder.ai ਵਰਗੇ vibe-coding ਟੂਲ ਨਾਲ ਬਣਾਇਆ ਹੈ, ਤਾਂ ਇੱਕ ਹੀ ਲੂਪ ਰੱਖੋ: ਇਕ waterfall ਇੰਸਪੈਕਟ ਕਰੋ, ਇਕ ਗੱਲ ਬਦਲੋ, ਫਿਰ ਮੁੜ-ਜਾਂਚ ਕਰੋ। ਛੋਟੇ ਇਤਰੈਸ਼ਨਾਂ ਨਾਲ "AI-ਤਿਆਰ ਫਰੰਟਐਂਡ" ਨੂੰ "AI-ਤਿਆਰ ਹੈਰਾਨੀ" ਬਣਨ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਤੇਜ਼ੀ ਲਈ ਚੁਕ-ਚੈਕਲਿਸਟ ਅਤੇ ਅਗਲੇ ਕਦਮ

ਜਦੋਂ ਇੱਕ ਪੰਨਾ ਹੌਲਾ ਜਾਂ glitchy ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਲੋਕਧਾਰਨਾ ਦੀ ਲੋੜ ਨਹੀਂ। ਕੁਝ ਜਾਂਚਾਂ ਜ਼ਿਆਦਾਤਰ ਅਸਲ-ਦੁਨੀਆ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਸਮਝਾ ਦਿੰਦੀਆਂ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ AI-ਜਨਰੇਟ ਕੀਤੀਆਂ UI ਵੀ ਸ਼ਾਮِل ਹਨ।

ਸ਼ੁਰੂ ਕਰੋ ਇੱਥੋਂ:

• ਵਾਧੂ ਰਿਡਾਇਰੇਕਟ ਹਟਾਓ (ਖਾਸ ਕਰਕੇ http ਤੋਂ https, ਜਾਂ www to non-www)। ਹਰ ਹੋਪ ਲੇਟੈਂਸੀ ਵਧਾਉਂਦਾ ਹੈ ਅਤੇ ਪਹਿਲੀ ਪੇਂਟ ਨੂੰ ਦੇਰ ਕਰ ਸਕਦਾ ਹੈ।
• ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਕੈਸ਼ਿੰਗ ਹੈਡਰ ਤੁਹਾਡੀ ਐਸੈੱਟ ਰਣਨੀਤੀ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ। ਜੇ ਇੱਕ ਵੱਡਾ ਬੰਡਲ ਕਦੇ ਵੀ ਕੈਸ਼ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਹਰ ਵਿਜ਼ਿਟ ਪੂਰੀ ਡਾਊਨਲੋਡ ਬਣ ਜਾਂਦੀ ਹੈ।
• ਰੈਂਡਰ-ਬਲਾਕਿੰਗ CSS ਲਭੋ। ਸਿਰਲੇਖ ਵਿੱਚ ਵੱਡੀਆਂ stylesheets ਰੈਂਡਰ ਨੂੰ ਦੇਰ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਜਨਰੇਟ ਕੀਤਾ ਆਉਟਪੁੱਟ ਅਕਸਰ ਜ਼ਿਆਦਾ CSS ਸ਼ਾਮِل ਕਰਦਾ ਹੈ।
• ਸਭ ਤੋਂ ਵੱਡੀ ਜਾਵਾਸਕ੍ਰਿਪਟ ਫਾਇਲ ਪਛਾਣੋ ਅਤੇ ਫੈਸਲਾ ਕਰੋ ਕਿ ਇਹ ਪਹਿਲੀ ਸਕਰੀਨ 'ਤੇ ਕਿਉਂ ਲੋਡ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
• ਇੱਕੋ ਸਰੋਤ ਲਈ ਦੁਹਰਾਈਆਂ ਬੇਨਤੀਆਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ (ਅਕਸਰ ਅਸਥਿਰ URLs ਜਾਂ ਅਣਮੈਚ ਕੈਸ਼ ਨਿਯਮਾਂ ਕਰਕੇ)।

ਜੇ ਪੰਨਾ ਸਿਰਫ ਹੌਲਾ ਨਹੀਂ ਪਰ ਚਿਪਚਿਪ ਹੈ, ਤਾਂ ਚਲਣ ਅਤੇ ਮੈਨ-ਥ੍ਰੈਡ ਕੰਮ 'ਤੇ ਧਿਆਨ ਦਿਓ। ਲੇਆਊਟ ਸ਼ਿਫਟ ਆਮ ਤੌਰ 'ਤੇ ਇਮੇਜਾਂ ਦੇ ਬਿਨਾਂ ਮਾਪ, ਦੇਰ ਨਾਲ ਲੋਡ ਹੋਣ ਵਾਲੇ ਫੋਂਟ, ਜਾਂ ਡੇਟਾ ਆਉਣ ਤੋਂ ਬਾਅਦ ਆਕਾਰ ਬਦਲ ਦੇਣ ਵਾਲੇ ਕੰਪੋਨੈਂਟਾਂ ਤੋਂ ਆਉਂਦੇ ਹਨ। ਲੰਮੇ ਟਾਸਕ ਆਮ ਤੌਰ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਜਾਵਾਸਕ੍ਰਿਪਟ ਇਕੱਠਾ ਚਲਾਉਣ (ਭਾਰੀ ਹਾਈਡਰੇਸ਼ਨ, ਭਾਰੀ ਲਾਇਬ੍ਰੇਰੀਜ਼, ਜਾਂ ਬਹੁਤ ਸਾਰੇ ਨੋਡ ਰੇਂਡਰ ਕਰਨ) ਕਰਕੇ ਹੁੰਦੇ ਹਨ।

ਜਦੋਂ AI ਨੂੰ ਪ੍ਰੋੰਪਟਿੰਗ ਕਰੋ, ਉਹ ਸ਼ਬਦ ਵਰਤੋਂ ਜੋ ਅਸਲ ਬਾਧਾਵਾਂ ਦੀ ਉਲਜਣ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ:

• "ਰੈਂਡਰ-ਬਲਾਕਿੰਗ CSS ਤੋਂ ਬਚੋ; ਸਿਰਫ above-the-fold ਲਈ ਆਵਸ਼ਕਤ ਸਟਾਈਲ inline ਕਰੋ।"
• "ਮੁੱਖ ਬੰਡਲ ਨੂੰ ਵੰਡੋ; ਗੈਰ-ਅਹੰਕਾਰਕ ਕੋਡ ਨੂੰ ਪਹਿਲੇ ਇੰਟਰਐਕਸ਼ਨ ਦੇ ਬਾਅਦ ਲੋਡ ਕਰੋ।"
• "ਸਥਿਰ ਐਸੈੱਟਾਂ ਲਈ Cache-Control ਸੈੱਟ ਕਰੋ; ਫਾਈਲਾਂ ਨੂੰ fingerprint ਕਰੋ।"
• "ਲੇਆਊਟ ਸ਼ਿਫਟ ਰੋਕੋ: ਇਮੇਜ, ਇਸ਼ਤਿਹਾਰ, ਅਤੇ ਐਸਿੰਕ ਕੰਪੋਨੈਂਟ ਲਈ ਥਾਂ ਰਿਜ਼ਰਵ ਕਰੋ।"
• "ਦੁਹਰਾਈਆਂ ਫੈਚ ਤੋਂ ਬਚੋ: ਫੈਚਾਂ ਨੂੰ ਡਿਡੁਪ ਕਰੋ ਅਤੇ URLs ਸਥਿਰ ਰੱਖੋ।"

ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ Planning Mode ਇੱਕ ਚੰਗੀ ਜਗ੍ਹਾ ਹੈ ਇਹ ਪਾਬੰਦੀਆਂ ਪਹਿਲਾਂ ਲਿਖਣ ਲਈ। ਫਿਰ ਛੋਟੇ ਬਦਲਾਵਾਂ ਵਿੱਚ ਦੁਹਰਾਓ ਅਤੇ ਡਿਪਲੋਇ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੱਖਿਅਤ ਟੈਸਟਿੰਗ ਲਈ snapshots ਅਤੇ rollback ਵਰਤੋਂ।