14 ਅਗ 2025·8 ਮਿੰਟ
ਵੈੱਬ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਕੰਪਾਇਲਰ ਪਹੁੰਚ: ਰਿਚ ਹੈਰਿਸ ਦੀ ਰਾਏ
ਕੰਪਾਇਲਰ-ਪਹਿਲਾਂ ਪਹੁੰਚ ਦੁਆਰਾ ਵੈੱਬ ਪ੍ਰਦਰਸ਼ਨ ਦਾ ਵਰਤੋਂਯੋਗ ਨਜ਼ਰੀਆ: runtime-ਭਾਰੀ ਫ੍ਰੇਮਵਰਕਾਂ ਨਾਲ ਤુલਨਾ, build-ਟਾਈਮ ਆਉਟਪੁੱਟ ਦੇ ਫਾਇਦੇ, ਅਤੇ ਇੱਕ ਸਧਾਰਨ ਫੈਸਲਾ ਫਰੇਮਵਰਕ।
ਕੰਪਾਇਲਰ-ਪਹਿਲਾਂ ਪਹੁੰਚ ਦੁਆਰਾ ਵੈੱਬ ਪ੍ਰਦਰਸ਼ਨ ਦਾ ਵਰਤੋਂਯੋਗ ਨਜ਼ਰੀਆ: runtime-ਭਾਰੀ ਫ੍ਰੇਮਵਰਕਾਂ ਨਾਲ ਤુલਨਾ, build-ਟਾਈਮ ਆਉਟਪੁੱਟ ਦੇ ਫਾਇਦੇ, ਅਤੇ ਇੱਕ ਸਧਾਰਨ ਫੈਸਲਾ ਫਰੇਮਵਰਕ।
ਯੂਜ਼ਰ ਕਮ technical ਸ਼ਬਦ ਵਰਤਦੇ ਹਨ। ਉਹ ਕਹਿੰਦੇ ਹਨ ਕਿ ਐਪ ਭਾਰੀ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਪੇਜ ਨੂੰ ਕੁਝ ਵਕਤ ਲੱਗਦਾ ਹੈ kujh ਵੀ ਦਿਖਾਉਣ ਲਈ, ਬਟਨ ਦੇ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਦੇਰੀ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਆਮ ਕਾਰਵਾਈਆਂ ਜਿਵੇਂ ਮੇਨੂ ਖੋਲ੍ਹਣਾ, search ਬਾਕਸ ਵਿੱਚ ਲਿਖਣਾ, ਜਾਂ ਟੈਬ ਬਦਲਣਾ, ਜ਼ਬਰਦਸਤੀ ਜਾਂ ਜਿਰਟ ਹੋ ਜਾਂਦੇ ਹਨ।
ਲੱਛਣ ਜਾਣੇ-ਪਛਾਣੇ ਹਨ: ਪਹਿਲੀ ਲੋਡ ਸਲੋ (ਸਫੈਦ ਜਾਂ ਅਧ-ਤਿਆਰ UI), ਜਿਆਦਾ ਲੈਗ ਵਾਲੀਆਂ ਇੰਟਰੈਕਸ਼ਨਸ (ਕਲਿੱਕ ਜਿਹੜੇ ਦੇਰੀ ਨਾਲ ਲੈਂਡ ਹੁੰਦੇ ਹਨ, ਜਿੱਟਰਿੰਗ ਸਕ੍ਰੋਲਿੰਗ), ਅਤੇ ਉਹ ਲੰਬੇ spinner ਜਦੋਂ ਕੋਈ ਐਕਸ਼ਨ ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਵੇਂ ਫਾਰਮ ਸੇਵ ਕਰਨਾ ਜਾਂ ਲਿਸਟ ਫਿਲਟਰ ਕਰਨਾ।
ਇਸ ਦਾ ਬਹੁਤ ਹਿੱਸਾ runtime ਲਾਗਤ ਹੁੰਦੀ ਹੈ। ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਇਹ ਉਹ ਕੰਮ ਹੈ ਜੋ ਪੇਜ ਲੋਡ ਹੋਣ ਤੋਂ ਬਾਅਦ ਬ੍ਰਾਉਜ਼ਰ ਨੂੰ ਐਪ ਨੂੰ ਵਰਤਣਯੋਗ ਬਣਾਉਣ ਲਈ ਕਰਨਾ ਪੈਂਦਾ ਹੈ: ਹੋਰ JavaScript ਡਾਊਨਲੋਡ ਕਰਨਾ, ਉਸਨੂੰ ਪਾਰਸ ਕਰਨਾ, ਚਲਾਉਣਾ, UI ਬਣਾਉਣਾ, ਹੈਂਡਲਰ ਜੋੜਨਾ, ਅਤੇ ਹਰ ਅਪਡੇਟ 'ਤੇ ਵੱਧ ਕੰਮ ਕਰਨਾ। ਤੇਜ਼ ਡਿਵਾਈਸਾਂ 'ਤੇ ਵੀ, ਬ੍ਰਾਉਜ਼ਰ ਰਾਹੀਂ ਜਾਵਾਸਕ੍ਰਿਪਟ ਦੀ ਇੱਕ ਸੀਮਾ ਹੁੰਦੀ ਹੈ ਜਿਸ ਤੋਂ ਵੱਧ ਭੇਜਿਆ ਗਿਆ ਤਾਂ ਅਨੁਭਵ ਮੰਦ ਹੋਣ ਲੱਗਦਾ ਹੈ।
ਪਰਫੋਰਮੈਂਸ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦੇ ਨਤੀਜੇ ਬਾਅਦ ਵਿੱਚ ਵੀ ਦਿੱਸਦੇ ਹਨ। ਪਹਿਲਾਂ ਐਪ ਛੋਟਾ ਹੁੰਦਾ ਹੈ: ਕੁਝ ਸਕਰੀਨ, ਹਲਕਾ ਡਾਟਾ, ਸਾਧਾਰਣ UI। ਫਿਰ ਪ੍ਰੋਡਕਟ ਵਧਦਾ ਹੈ। ਮਾਰਕੀਟਿੰਗ ਟਰੇਕਰ ਜੋੜਦੀ ਹੈ, ਡਿਜ਼ਾਈਨ ਰਿਚਰ ਕੰਪੋਨੈਂਟ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ, ਟੀਮਾਂ ਸਟੇਟ, ਫੀਚਰ, ਡਿਪੈਂਡਨਸੀਜ਼, ਅਤੇ personalization ਜੋੜਦੀਆਂ ਹਨ। ਹਰ ਬਦਲਾਅ ਅਕਸਰ ਨੁਕਸਾਨ-ਰਹਿਤ ਲੱਗਦਾ ਹੈ, ਪਰ ਕੁੱਲ ਕੰਮ ਵਧਦਾ ਜਾਂਦਾ ਹੈ।
ਇਸੇ ਲਈ ਟੀਮਾਂ ਕੰਪਾਇਲਰ-ਪਹਿਲਾਂ ਦੀ ਸੋਚ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਨ। ਮਕਸਦ ਅਕਸਰ ਪਰਫੈਕਟ ਸਕੋਰ ਨਹੀਂ ਹੁੰਦਾ। ਮਕਸਦ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ship ਕਰਦੇ ਰਹੋ ਬਿਨਾਂ ਐਪ ਹਰ ਮਹੀਨੇ ਧੀਰਾ ਹੋਣ ਦੇ।
ਵੱਧਤਰ ਫਰੰਟਐਂਡ ਫ੍ਰੇਮਵਰਕ ਤੁਹਾਨੂੰ ਦੋ ਚੀਜ਼ਾਂ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ: ਇੱਕ ਐਪ ਬਣਾਉਣਾ, ਅਤੇ UI ਨੂੰ ਡਾਟਾ ਨਾਲ sync ਰੱਖਣਾ। ਮੁੱਖ ਫਰਕ ਇਹ ਹੈ ਕਿ ਦੂਜਾ ਹਿੱਸਾ ਕਦੋਂ ਹੁੰਦਾ ਹੈ।
runtime-ਭਾਰੀ ਫ੍ਰੇਮਵਰਕ ਨਾਲ, ਵੱਧ ਕੰਮ ਬ੍ਰਾਉਜ਼ਰ ਵਿੱਚ ਪੇਜ ਲੋਡ ਹੋਣ ਦੇ ਬਾਅਦ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ general-purpose runtime ਭੇਜਦੇ ਹੋ ਜੋ ਕਈ ਕੇਸ ਸੰਭਾਲ ਸਕਦਾ ਹੈ: ਚੇਂਜ ਟਰੈਕ ਕਰਨਾ, ਕਿਹੜਾ ਅਪਡੇਟ ਕਰਨਾ ਹੈ ਫੈਸਲਾ ਕਰਨਾ, ਅਤੇ ਉਹਨਾਂ ਅਪਡੇਟਸ ਨੂੰ ਲਾਗੂ ਕਰਨਾ। ਇਹ ਵਿਕਾਸ ਲਈ ਚੰਗਾ ਹੈ, ਪਰ ਅਕਸਰ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ UI ਤਿਆਰ ਹੋਣ ਤੱਕ ਹੋਰ ਜਾਵਾਸਕ੍ਰਿਪਟ ਡਾਊਨਲੋਡ, ਪਾਰਸ ਅਤੇ ਐਗਜ਼ਿਕਿਊਟ ਹੋਣਾ ਪੈਂਦਾ ਹੈ।
compile-time ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਨਾਲ, ਵੱਧ ਕੰਮ build ਦੌਰਾਨ ਹੋ ਜਾਂਦਾ ਹੈ। build ਟੂਲ ਤੁਹਾਡੇ ਕੰਪੋਨੈਂਟਾਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ ਅਤੇ ਵਧੇਰੇ ਸਿੱਧਾ, ਐਪ-ਖਾਸ ਕੋਡ ਜਨਰੇਟ ਕਰਦਾ ਹੈ।
ਇੱਕ ਮਦਦਗਾਰ ਮਾਨਸਿਕ ਮਾਡਲ:
ਅਕਸਰ ਅਸਲੀ ਉਤਪਾਦ ਦੋਨਾਂ ਵਿਚਕਾਰ ਕਿਸੇ ਜਗ੍ਹਾ 'ਤੇ ਹੁੰਦੇ ਹਨ। ਕੰਪਾਇਲਰ-ਪਹਿਲਾਂ ਵਾਲੇ ਐਪ ਵੀ ਕੁਝ runtime ਕੋਡ ਭੇਜਦੇ ਹਨ (routing, ਡਾਟਾ ਫੇਚਿੰਗ, animations, error handling)। runtime-ਭਾਰੀ ਫ੍ਰੇਮਵਰਕ ਵੀ build-ਟਾਈਮ ਤਕਨੀਆਂ 'ਤੇ ਨਿਰਭਰ ਰਹਿੰਦੇ ਹਨ (minification, code splitting, server rendering) ਤਾਂ ਕਿ ਕਲਾਇੰਟ ਕੰਮ ਘੱਟ ਹੋਵੇ। ਪ੍ਰਯੋਗਿਕ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ ਕਿਹੜਾ ਕੈਂਪ "ਸਹੀ" ਹੈ, ਬਲਕਿ ਇਹ ਕਿ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਲਈ ਕਿਹੜਾ ਮਿਲਾਪ ਵਧੀਆ ਹੈ।
Rich Harris ਕੰਪਾਇਲਰ-ਪਹਿਲਾਂ ਫਰੰਟਐਂਡ ਸੋਚ ਦੇ ਸਭ ਤੋਂ ਸਪਸ਼ਟ ਬੋਲਣ ਵਾਲਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਉਸਦਾ ਦਲੀਲ ਸਿੱਧਾ ਹੈ: ਅੱਗੇ ਤੋਂ ਵਧੇਰੇ ਕੰਮ ਕਰੋ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਘੱਟ ਕੋਡ ਡਾਊਨਲੋਡ ਕਰਨ ਅਤੇ ਬ੍ਰਾਉਜ਼ਰ ਘੱਟ ਕੰਮ ਕਰਨ।
ਮਕਸਦ ਵਰਤੋਂਯੋਗ ਹੈ। ਬਹੁਤ ਸਾਰੇ runtime-ਭਾਰੀ ਫ੍ਰੇਮਵਰਕ ਇੱਕ general-purpose ਇੰਜਣ ਭੇਜਦੇ ਹਨ: ਕੰਪੋਨੈਂਟ ਲੌਜਿਕ, reactivity, diffing, scheduling, ਅਤੇ ਮਦਦਗਾਰ ਜੋ ਹਰ ਸੰਭਵ ਐਪ ਲਈ ਕੰਮ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। ਉਹ ਲਚੀਲਤਾ bytes ਅਤੇ CPU ਦੀ ਕੀਮਤ 'ਤੇ ਆਉਂਦੀ ਹੈ। ਭਾਵੇ ਤੁਹਾਡਾ UI ਛੋਟਾ ਹੋਵੇ, ਫਿਰ ਵੀ ਤੁਸੀਂ ਇੱਕ ਵੱਡੇ runtime ਲਈ ਭੁਗਤਾਨ ਕਰ ਸਕਦੇ ਹੋ।
ਕੰਪਾਇਲਰ ਪਹੁੰਚ ਮਾਡਲ ਨੂੰ ਉਲਟ ਕਰਦੀ ਹੈ। build ਸਮੇਂ, ਕੰਪਾਇਲਰ ਤੁਹਾਡੇ ਅਸਲ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਵੇਖਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਲਈ ਖਾਸ DOM ਅਪਡੇਟ ਕੋਡ ਜਨਰੇਟ ਕਰਦਾ ਹੈ। ਜੇ ਇੱਕ label ਕਦੇ ਨਹੀਂ ਬਦਲਦਾ, ਉਹ ਸਧਾਰਨ HTML ਬਣ ਜਾਂਦੀ ਹੈ। ਜੇ ਸਿਰਫ ਇੱਕ value ਬਦਲਦੀ ਹੈ, ਤਾਂ ਉਸ value ਲਈ ਹੀ ਅਪਡੇਟ ਪਾਥ ਜਾਰੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜਨਰਿਕ UI ਮਸ਼ੀਨ ਭੇਜਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਆਪਣੀ ਉਤਪਾਦ-ਖਾਸ ਆਉਟਪੁੱਟ ਭੇਜਦੇ ਹੋ।
ਇਸਦਾ ਨਤੀਜਾ ਅਕਸਰ ਸਧਾਰਨ ਹੁੰਦਾ ਹੈ: ਯੂਜ਼ਰਾਂ ਨੂੰ ਘੱਟ ਫ੍ਰੇਮਵਰਕ ਕੋਡ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਹਰ ਇੰਟਰੈਕਸ਼ਨ 'ਤੇ ਘੱਟ ਕੰਮ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਘੱਟ-ਅੰਤ ਵਾਲੀਆਂ ਡਿਵਾਈਸਾਂ 'ਤੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ, ਜਿੱਥੇ ਵਾਧੂ runtime ਖਪਤ ਤੇਜ਼ੀ ਨਾਲ ਦਿਖਾਈ ਦੇਂਦੀ ਹੈ।
ਟਰੇਡ-ਆਫ਼ ਫਿਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ:
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: ਜੇ ਤੁਹਾਡਾ UI build ਸਮੇਂ ਜਿਆਦਾਤਰ ਜਾਣਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਕੰਪਾਇਲਰ ਤੰਗ ਆਉਟਪੁੱਟ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ UI ਬਹੁਤ ਹੀ ਡਾਇਨਾਮਿਕ ਜਾਂ ਪਲੱਗਇਨ-ਚਲਿਤ ਹੈ, ਤਾਂ ਇੱਕ ਭਾਰੀ runtime ਆਸਾਨੀ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦੀ ਹੈ।
ਕੰਪਾਇਲ-ਟਾਈਮ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਇਹ ਬਦਲਦੀ ਹੈ ਕਿ ਕੰਮ ਕਿੱਥੇ ਹੁੰਦਾ ਹੈ। ਵੱਧ ਫੈਸਲੇ build ਦੌਰਾਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਬ੍ਰਾਉਜ਼ਰ ਲਈ ਘੱਟ ਕੰਮ ਬਚਦਾ ਹੈ।
ਇੱਕ ਦਿੱਸਣ-ਯੋਗ ਨਤੀਜਾ ਘੱਟ JavaScript ਭੇਜਣਾ ਹੈ। ਛੋਟੇ ਬੰਡਲ ਨੈਟਵਰਕ ਸਮਾਂ, ਪਾਰਸਿੰਗ ਸਮਾਂ, ਅਤੇ ਪੇਜ ਦੇ ਟੈਪ ਜਾਂ ਕਲਿੱਕ ਨੂੰ ਜਵਾਬ ਦੇਣ ਤੱਕ ਦੀ ਦੇਰੀ ਘਟਾਉਂਦੇ ਹਨ। ਮਿਡ-ਰੇਂਜ ਫੋਨਾਂ 'ਤੇ ਇਹ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ।
ਕੰਪਾਇਲਰ ਹੋਰ ਸਿੱਧੇ DOM ਅਪਡੇਟ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹਨ। ਜਦੋਂ build ਕਦਮ ਕਿਸੇ ਕੰਪੋਨੈਂਟ ਦੀ ਬਣਤਰ ਨੂੰ ਵੇਖ ਸਕਦਾ ਹੈ, ਤਾਂ ਉਹ ਅਜਿਹਾ ਕੋਡ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਸਿਰਫ ਉਹਨਾਂ DOM ਨੋਡਾਂ ਨੂੰ ਛੇੜਦਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਬਦਲਦੇ ਹਨ, ਬਿਨਾਂ ਹਰ ਇੰਟਰੈਕਸ਼ਨ 'ਤੇ ਵੱਧ ਪਰਤਾਂ ਵਾਲੀ ਅਭਿਕਲਪਨਾ ਦੇ। ਇਹ ਅਕਸਰ lists, tables ਅਤੇ forms ਵਿੱਚ ਅਕਤਿਵ ਅਪਡੇਟਸ ਨੂੰ ਜ਼ਿਆਦਾ ਤੀਖਾ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ।
build-ਟਾਈਮ ਵਿਸ਼ਲੇਸ਼ਣ tree-shaking ਅਤੇ dead-code removal ਨੂੰ ਮਜ਼ਬੂਤ ਕਰ ਸਕਦੀ ਹੈ। ਲਾਭ ਸਿਰਫ ਛੋਟੇ ਫਾਈਲਾਂ ਨਹੀਂ—ਇਹ ਉਹ ਕੋਡ ਪਾਥ ਘਟਾਉਂਦਾ ਹੈ ਜੋ ਬ੍ਰਾਉਜ਼ਰ ਨੂੰ ਲੋਡ ਅਤੇ ਐਗਜ਼ਿਕਿਊਟ ਕਰਨੇ ਪੈਂਦੇ ਹਨ।
Hydration ਇੱਕ ਹੋਰ ਖੇਤਰ ਹੈ ਜਿੱਥੇ build-ਟਾਈਮ ਚੋਣਾਂ ਮਦਦ ਕਰ ਸਕਦੀਆਂ ਹਨ। Hydration ਉਹ ਕਦਮ ਹੈ ਜਿੱਥੇ ਸਰਵਰ-ਰੇਂਡਰ ਕੀਤੀ ਪੇਜ ਇੰਟਰਐਕਟਿਵ ਬਣਦੀ ਹੈ। ਜੇ build ਇਹ ਚਿੰਨ੍ਹਾਂ ਸਕੇ ਕਿ ਕਿੰਝ ਹਿੱਸੇ ਨੂੰ ਹੀ ਇੰਟਰਐਕਟਿਵ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪਹਿਲੀ ਲੋਡ ਦਾ ਕੰਮ ਘਟਾ ਸਕਦੇ ਹੋ।
ਇੱਕ ਸਾਈਡ ਇਫੈਕਟ ਵਜੋਂ, ਕੰਪਾਇਲੇਸ਼ਨ ਅਕਸਰ CSS scoping ਨੂੰ ਵੀ ਸੁਧਾਰਦੀ ਹੈ। build ਕਲਾਸ ਨਾਂ ਨਹੀਂ ਲਿਖ ਕੇ, unused styles ਹਟਾ ਕੇ, ਅਤੇ cross-component style leakage ਘਟਾ ਕੇ ਸੁਧਾਰ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ UI ਵਧਣ 'ਤੇ ਆਚਾਨਕ ਲਾਗਤਾਂ ਘਟਾਉਂਦਾ ਹੈ।
ਇੱਕ ਡੈਸ਼ਬੋਰਡ ਦਾ ਸੋਚੋ ਜਿਸ ਵਿੱਚ ਫਿਲਟਰ ਅਤੇ ਵੱਡੀ ਡੇਟਾ ਟੇਬਲ ਹੈ। ਕੰਪਾਇਲਰ-ਪਹਿਲਾਂ ਪਹੁੰਚ ਆਰੰਭਿਕ ਲੋਡ ਨੂੰ ਹਲਕਾ ਰੱਖ ਸਕਦੀ ਹੈ, ਫਿਲਟਰ ਕਲਿੱਕ ਤੋਂ ਬਾਅਦ ਸਿਰਫ ਉਹੀ ਸੈੱਲ ਬਦਲਦੇ ਜੋ ਬਦਲੇ, ਅਤੇ ਪੇਜ ਦੇ ਉਹ ਹਿੱਸੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਦੇ ਇੰਟਰਐਕਟਿਵ ਨਹੀਂ ਹੋਣਾ ਉਹਨਾਂ ਦੀ ਹਾਈਡ੍ਰੇਸ਼ਨ ਬਚਾ ਸਕਦੀ ਹੈ।
ਇੱਕ ਵੱਡਾ runtime ਆਪਣੇ ਆਪ ਵਿਚ ਖਰਾਬ ਨਹੀਂ। ਇਹ ਅਕਸਰ ਲਚੀਲਤਾ ਦਿੰਦਾ ਹੈ: runtime ਵਿੱਚ ਫੈਸਲੇ, ਬਹੁਤ ਸਾਰੇ ਤੀਸਰੇ-ਪੱਖ ਕੰਪੋਨੈਂਟ, ਅਤੇ ਸਾਲਾਂ ਤੋਂ ਸਥਿਰ ਵਰਕਫਲੋ।
runtime-ਭਾਰੀ ਫ੍ਰੇਮਵਰਕ ਉਹਨਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਚਮਕਦੇ ਹਨ ਜਦੋਂ UI ਨਿਯਮ ਬਾਰ-ਬਾਰ ਬਦਲਦੇ ਹਨ। ਜੇ ਤੁਹਾਨੂੰ ਜਟਿਲ routing, nested layouts, ਰਿਚ forms, ਅਤੇ ਡੂੰਘਾ state ਮਾਡਲ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਪੱਕਾ runtime ਇੱਕ ਸੇਫਟੀ ਨੈਟ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ।
Runtime ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਫ੍ਰੇਮਵਰਕ ਚਲਦੇ ਸਮੇਂ ਬਹੁਤ ਕੁਝ ਸੰਭਾਲੇ, ਨ ਕਿ ਸਿਰਫ build ਦੌਰਾਨ। ਇਸ ਨਾਲ ਟੀਮਾਂ ਰੋਜ਼ਾਨਾ ਤੇਜ਼ ਮਹਿਸੂਸ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਭਾਵੇ ਇਹ ਥੋੜ੍ਹਾ ਜ਼ਿਆਦਾ ਓਵਰਹੈੱਡ ਜੋੜਦਾ ਹੋਵੇ।
ਆਮ ਫਾਇਦੇ ਵਿੱਚ ਵੱਡਾ ecosystem, ਸਟੇਟ ਅਤੇ ਡਾਟਾ ਫੈਚਿੰਗ ਲਈ ਜਾਣ-ਪਛਾਣ ਪੈਟਰਨ, ਮਜ਼ਬੂਤ dev tools, ਪਲੱਗਿਨ-ਸਟਾਈਲ ਵਿਸਥਾਰ ਲਈ ਆਸਾਨੀ, ਅਤੇ hiring ਲਈ ਜਾਣ-ਪਛਾਣ ਸ਼ਾਮਲ ਹਨ।
ਟੀਮ ਪਛਾਣ ਇਕ ਅਸਲ ਲਾਗਤ ਅਤੇ ਲਾਭ ਦੋਹਾਂ ਹੈ। ਇੱਕ ਥੋੜ੍ਹਾ ਢੀਲਾ ਫ੍ਰੇਮਵਰਕ ਜਿਸ ਨਾਲ ਤੁਹਾਡੀ ਟੀਮ ਭਰੋਸੇ ਨਾਲ ship ਕਰ ਸਕਦੀ ਹੈ, ਉਹ ਇੱਕ ਤੇਜ਼ ਤਰੀਕੇ ਨਾਲ ਆਉਣ ਵਾਲੀ ਤੇਜ਼ ਪਹੁੰਚ ਨੂੰ ਹਰਾ ਸਕਦੀ ਹੈ ਜਿਸ ਲਈ retraining ਜਾਂ ਕਸਟਮ tooling ਦੀ ਲੋੜ ਹੋਵੇ।
ਬਹੁਤ ਸਾਰੀਆਂ “ਧੀਰੀ ਐਪ” ਸ਼ਿਕਾਇਤਾਂ ਫ੍ਰੇਮਵਰਕ runtime ਨਾਲ ਨਹੀਂ ਜੁੜਦੀਆਂ। ਜੇ ਤੁਹਾਡਾ ਪੇਜ ਸੁਸਤ APIs, ਭਾਰੀ ਇਮੇਜਾਂ, ਬਹੁਤ ਫੋਂਟਸ, ਜਾਂ ਤੀਸਰੇ-ਪੱਖ ਸਕ੍ਰਿਪਟਾਂ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਫ੍ਰੇਮਵਰਕ ਬਦਲਨ ਨਾਲ ਮੂਲ ਸਮੱਸਿਆ ਹਟੇਗੀ ਨਹੀਂ।
ਇੱਕ ਅੰਦਰੂਨੀ admin ਡੈਸ਼ਬੋਰਡ ਜੋ ਲੌਗਿਨ ਦੇ ਪਿੱਛੇ ਹੈ ਅਕਸਰ ਇੱਕ ਵੱਡੇ runtime ਨਾਲ ਠੀਕ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਯੂਜ਼ਰ ਤਕਨਾਲੋਜੀਕਲ ਤੌਰ 'ਤੇ ਮਜ਼ਬੂਤ ਡਿਵਾਈਸਾਂ ਤੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਕੰਮ backend ਕਵੇਰੀਆਂ ਅਤੇ ਟੇਬਲਾਂ ਨਾਲ ਪ੍ਰਭਾਵਤ ਹੁੰਦਾ ਹੈ।
“ਕਾਫੀ ਤੇਜ਼” ਸ਼ੁਰੂ ਵਿੱਚ ਸਹੀ ਲਕੜੀ ਹੋ ਸਕਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਅਜੇ ਵੀ ਪ੍ਰੋਡਕਟ ਮੁੱਲ ਸਾਬਤ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਟਰੇਸ਼ਨ ਦੀ ਗਤੀ ਉੱਚੀ ਰੱਖੋ, ਬੁਨਿਆਦੀ ਬਜਟ ਸੈੱਟ ਕਰੋ, ਅਤੇ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਕੰਪਾਇਲਰ-ਪਹਿਲਾਂ ਘੁੰਮਾਓ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਸਬੂਤ ਹੋਵੇ ਕਿ ਇਹ ਜਰੂਰੀ ਹੈ।
ਇਟਰੇਸ਼ਨ ਗਤੀ ਉਹ ਸਮਾਂ-ਤੱਕ-ਪ੍ਰਤੀਕਿਰਿਆ ਹੈ: ਕਿੰਨਾ ਤੇਜ਼ ਕੋਈ ਬੰਦਾ ਇੱਕ ਸਕ੍ਰੀਨ ਬਦਲ ਸਕਦਾ, ਚਲਾ ਸਕਦਾ, ਵੇਖ ਸਕਦਾ ਕਿ ਕੀ ਟੁੱਟਿਆ, ਅਤੇ ਠੀਕ ਕਰ ਸਕਦਾ। ਜੋ ਟੀਮ ਇਹ ਲੂਪ ਛੋਟਾ ਰੱਖਦੀਆਂ ਹਨ ਉਹ ਅਕਸਰ ਜ਼ਿਆਦਾ ਤੇਜ਼ ship ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਤੇਜ਼ ਸਿੱਖਦੀਆਂ ਹਨ। ਇਸੀ ਲਈ runtime-ਭਾਰੀ ਫ੍ਰੇਮਵਰਕ ਸ਼ੁਰੂ ਵਿੱਚ ਉਤਪਾਦਕ ਬਣਦੇ ਮਹਿਸੂਸ ਹੋ ਸਕਦੇ ਹਨ: ਜਾਣ-ਪਛਾਣ ਵਾਲੇ ਪੈਟਰਨ, ਤੁਰੰਤ ਨਤੀਜੇ, ਅਤੇ ਬਹੁਤ ਸਾਰਾ ਨਿਰਮਿਤ ਵਰਤਾਰਾ।
ਪਰ ਪ੍ਰਦਰਸ਼ਨ ਕੰਮ ਜਦੋਂ ਜ਼ਰੂਰਤ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂ ਬਹੁਤ ਵਿਆਪਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਉਹ ਇਸ ਲੂਪ ਨੂੰ ਮੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਜੇ ਹਰ pull request ਇੱਕ ਮਾਈਕ੍ਰੋ-ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਦੀ ਚਰਚਾ ਬਣ ਜਾਂਦੀ ਹੈ, ਟੀਮ ਜੋਖਮ ਲੈਣਾ ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਕਠੋਰ ਪਾਈਪਲਾਈਨ ਬਣਾਉਂਦੇ ਹੋ ਪਹਿਲਾਂ ਹੀ ਪਤਾ ਨਾ ਹੋਣ ਤੇ ਕਿ ਪ੍ਰੋਡਕਟ ਕੀ ਹੈ, ਲੋਕ tooling ਨਾਲ ਲੜਾਈ ਕਰਨ ਲੱਗਦੇ ਹਨ ਬਜਾਏ ਯੂਜ਼ਰਾਂ ਨਾਲ ਗੱਲ ਕਰਨ ਦੇ।
ਚਾਲਾਕੀ ਇਹ ਹੈ ਕਿ “ਅਚਛਾ ਕਿਹੜਾ ਹੈ” 'ਤੇ ਸਹਿਮਤ ਹੋਵੋ ਅਤੇ ਉਸ ਬੈਕਸ ਦੇ ਅੰਦਰ ਇਟਰੇਟ ਕਰੋ। ਪਰਫੋਰਮੈਂਸ ਬਜਟ ਤੁਹਾਨੂੰ ਉਹ ਬੈਕਸ ਦਿੰਦਾ ਹੈ। ਇਹ ਪਰਫੈਕਟ ਸਕੋਰ ਲਈ ਨਹੀਂ, ਬਲਕਿ ਐਸੇ ਹੱਦਾਂ ਲਈ ਜੋ ਅਨੁਭਵ ਦੀ ਰੱਖਿਆ ਕਰਨਗੀਆਂ ਅਤੇ ਵਿਕਾਸ ਨੂੰ ਚਲਾਉਂਦੀਆਂ ਰਹਿਣ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਬਜਟ ਸ਼ਾਮਲ ਹੋ ਸਕਦਾ ਹੈ:
ਜੇ ਤੁਸੀਂ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਅਣਦੇਖਾ ਕਰੋਗੇ ਤਾਂ ਅਕਸਰ ਬਾਅਦ ਵਿੱਚ ਭੁਗਤਾਨ ਕਰਨਾ ਪਵੇਗਾ। ਇੱਕ ਵਾਰੀ ਪ੍ਰੋਡਕਟ ਵਧ ਗਿਆ, ਧੀਰਜਤਾਪ ਸ਼ੁਆਮਭੋ ਸਿਰਫ ਛੋਟੇ ਟਵੀਕਸ ਨਾਲ ਨਹੀਂ ਸੁਧਰਦੀ; ਅਕਸਰ ਆਖਰੀ ਸੋਧ ਦਾ ਮਤਲਬ ਫੀਚਰ ਰੋਕਣਾ, ਟੀਮ ਨੂੰ retrain ਕਰਨਾ, ਅਤੇ ਪਹਿਲਾਂ ਚੱਲ ਰਹੀਆਂ ਵਰਕਫਲੋਜ਼ ਤੋੜਨਾ ਹੁੰਦਾ ਹੈ।
ਕੰਪਾਇਲਰ-ਪਹਿਲਾਂ tooling ਇਸ ਤਜਰਬੇ ਨੂੰ ਬਦਲ ਸਕਦੀ ਹੈ। ਤੁਸੀਂ ਸ਼ਾਇਦ ਥੋੜ੍ਹਾ ਲੰਬਾ build ਸਵੀਕਾਰ ਕਰੋ, ਪਰ ਹਰ ਡਿਵਾਈਸ ਤੇ, ਹਰ ਵਿਜ਼ਿਟ ਤੇ ਹੋਣ ਵਾਲੇ ਕੰਮ ਨੂੰ ਘਟਾ ਦਿਓ।
ਬਜਟ ਨੂੰ ਉਹ ਵੇਲੇ ਫਿਰੋ ਜਦੋਂ ਪ੍ਰੋਡਕਟ ਸਾਬਤ ਹੋ ਜਾਵੇ। ਸ਼ੁਰੂ ਵਿੱਚ ਮੂਲ ਗਾਰਡਰੇਲ ਰੱਖੋ। ਜਿਵੇਂ ਟ੍ਰੈਫਿਕ ਅਤੇ ਰੈਵਨਿュー ਵਧਦਾ ਹੈ, ਬਜਟ ਤੰਗ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਜਗ੍ਹਾਂ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰੋ ਜਿੱਥੇ ਅਸਲੀ ਮੈਟ੍ਰਿਕਸ 'ਤੇ ਅਸਰ ਪੈਂਦਾ ਹੈ, ਨਾ ਕਿ ਸ਼ੋਖੀ 'ਤੇ।
ਪਰਫੋਰਮੈਂਸ ਦੀਆਂ ਚਰਚਾਵਾਂ ਗੜਬੜ ਹੋ ਜਾਦੀਆਂ ਹਨ ਜਦੋਂ ਕੋਈ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦਾ ਕਿ “ਤੇਜ਼” ਦਾ ਮਤਲਬ ਕੀ ਹੈ। ਕੁਝ metrics ਚੁਣੋ, ਉਹਨਾਂ ਨੂੰ ਲਿਖੋ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੇ ਸਕੋਰਬੋਰਡ ਵਾਂਗ ਸਮਝੋ।
ਇੱਕ ਸਰਲ ਸ਼ੁਰੂਆਤ:
ਨੁਮਰੇ ਪ੍ਰਤੀਨਿਧੀ ਡਿਵਾਈਸਾਂ 'ਤੇ ਮਾਪੋ, ਕੇਵਲ ਡੈਵਲਪਰ ਲੈਪਟੌਪ 'ਤੇ ਨਹੀਂ। ਤੇਜ਼ CPU, ਗਰਮ cache, ਅਤੇ ਸਥਾਨਕ ਸਰਵਰ ਉਹ ਦੇਰੀਆਂ ਲੁਕਾ ਕੇ ਰੱਖ ਸਕਦੇ ਹਨ ਜੋ ਮਿਡ-ਰੇਂਜ ਫੋਨ ਤੇ ਆਉਂਦੀਆਂ ਹਨ।
ਇਸ ਨੂੰ ਜ਼ਮੀਨੀ ਰੱਖੋ: 2-3 ਡਿਵਾਈਸ ਚੁਣੋ ਜੋ ਅਸਲੀ ਯੂਜ਼ਰਾਂ ਨੂੰ ਮਿਲਦੇ ਹਨ ਅਤੇ ਹਰ ਵਾਰ ਉਹੀ ਫਲੋ ਚਲਾਓ (ਹੋਮ ਸਕ੍ਰੀਨ, ਲੌਗਿਨ, ਇਕ ਆਮ ਟਾਸਕ)। ਇਹ ਨਿਰੰਤਰ ਕਰੋ।
ਫ੍ਰੇਮਵਰਕ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਬੇਸਲਾਈਨ ਕੈਪਚਰ ਕਰੋ। ਅੱਜ ਦੀ build ਲਓ, ਇਕੋ ਫਲੋ ਲਈ ਨੰਬਰ ਰیکارਡ ਕਰੋ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਨੇੜੇ ਰੱਖੋ। ਇਹ ਤੁਹਾਡਾ “ਪਹਿਲਾਂ” ਫੋਟੋ ਹੋਵੇਗਾ।
ਇੱਕ ਇਕੱਲਾ ਲੈਬ ਸਕੋਰ ਨਾਲ ਪਰਫੋਰਮੈਂਸ ਨੂੰ ਨਿਆਇਆ ਨਾ ਕਰੋ। ਲੈਬ ਟੂਲ ਮਦਦ ਕਰਦੇ ਹਨ, ਪਰ ਉਹ ਗਲਤ ਚੀਜ ਨੂੰ ਇਨਾਮ ਦੇ ਸਕਦੇ ਹਨ (ਉੱਤਮ ਪਹਿਲੀ ਲੋਡ) ਜਦਕਿ ਯੂਜ਼ਰ ਜੋ ਸ਼ਿਕਾਇਤ ਕਰਦੇ ਹਨ ਉਹ ਮੁੱਖ ਚੀਜ਼ਾਂ (ਜਿਗੀ ਮੈਨੂ, ਸਲੋ ਟਾਈਪਿੰਗ, ਪਹਿਲੀ ਸਕ੍ਰੀਨ ਬਾਅਦ ਦੀਆਂ ਦੇਰੀਆਂ) ਨੂੰ ਛੱਡ ਸਕਦੇ ਹਨ।
ਜਦੋਂ ਨੰਬਰ ਖਰਾਬ ਹੋਣ, ਅਨੁਮਾਨ ਨਾ ਲਗਾਓ। ਵੇਖੋ ਕੀ ਸ਼ਿਪ ਹੋਇਆ, ਕੀ rendering ਰੋਕ ਰਿਹਾ ਸੀ, ਅਤੇ ਸਮਾਂ ਕਿੱਥੇ ਗਿਆ: ਨੈੱਟਵਰਕ, ਜਾਵਾਸਕ੍ਰਿਪਟ, ਜਾਂ API।
ਫ੍ਰੇਮਵਰਕ ਅਤੇ ਰੇਂਡਰਿੰਗ ਦੇ ਫੈਸਲੇ ਨੂੰ ਪ੍ਰੋਡਕਟ ਫੈਸਲਿਆਂ ਵਾਂਗ ਸੋਚੋ। ਮਕਸਦ ਸਭ ਤੋਂ ਵਧੀਆ ਟੈਕ ਨਹੀਂ, ਬਲਕਿ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਟੀਮ ਦੀ ਰਫ਼ਤਾਰ ਵਿਚਕਾਰ ਸਹੀ ਸੰਤੁਲਨ ਹੈ।
ਇੱਕ thin slice ਵਿੱਚ ਗੰਦੇ ਹਿੱਸੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ: ਅਸਲੀ ਡੇਟਾ, auth, ਅਤੇ ਤੁਹਾਡੀ ਸਭ ਤੋਂ ਹੌਲੀ ਸਕ੍ਰੀਨ।
ਜੇ ਤੁਸੀਂ ਉਸ thin slice ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ Koder.ai ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ—ਇਹ ਚੈਟ ਰਾਹੀਂ ਵੈੱਬ, ਬੈਕਐਂਡ, ਅਤੇ ਮੋਬਾਈਲ ਫਲੋ ਬਣਾਉਂਦਾ ਅਤੇ ਸੋਰਸ ਏਕਸਪੋਰਟ ਕਰਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ ਅਸਲ ਰੂਟ ਜਲਦੀ ਟੈਸਟ ਕਰਨ ਅਤੇ ਪ੍ਰਯੋਗਾਂ ਨੂੰ snapshots ਅਤੇ rollback ਨਾਲ ਵਾਪਸ ਲੈਣਯੋਗ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ।
ਫੈਸਲਾ ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਕਰੋ, ਜਿਸ ਵਿੱਚ ਇਹ ਵੀ ਲਿਖੋ ਕਿ ਕਿਹੜੀ ਸਥਿਤੀ ਵਿੱਚ ਤੁਸੀਂ ਇਸਨੂੰ ਦੁਬਾਰਾ ਵੇਖੋਗੇ (ਟ੍ਰੈਫਿਕ ਵਾਧਾ, ਮੋਬਾਈਲ ਸ਼ੇਅਰ, SEO ਲਕਸ਼)। ਇਹ ਚੋਣ ਟੀਮ ਬਦਲਣ 'ਤੇ ਵੀ ਟਿਕਾਊ ਬਣਾਉਂਦੀ ਹੈ।
ਪਤਰਫਰਮੈਂਸ ਫੈਸਲੇ ਅਕਸਰ ਗਲਤ ਤਾਂ ਹੋਂਦੇ ਹਨ ਜਦੋਂ ਟੀਮ ਉਹ ਚੀਜ਼ optimize ਕਰਦੀ ਹੈ ਜੋ ਉਹ ਅੱਜ ਵੇਖ ਸਕਦੀ ਹੈ, ਨ ਕਿ ਜੋ ਯੂਜ਼ਰ ਤਿੰਨ ਮਹੀਨੇ ਵਿੱਚ ਮਹਿਸੂਸ ਕਰਨਗੇ।
ਇਕ ਗਲਤੀ ਹੈ ਪਹਿਲੇ ਹਫ਼ਤੇ ਵਿੱਚ ਵੱਧ-ਅਪਟੀਮਾਈਜ਼ ਕਰਨ ਦੀ। ਟੀਮ ਇੱਕ ਪੇਜ ਦੇ ਮਿਲੀਸੈਕੰਡ ਘਟਾਉਣ ਲਈ ਦਿਨ ਖਰਚ ਕਰਦੀ ਹੈ ਜੋ ਹਰ ਰੋਜ਼ ਬਦਲਦਾ ਹੈ, ਜਦਕਿ ਅਸਲੀ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਯੂਜ਼ਰਾਂ ਕੋਲ ਅਜੇ ਸਹੀ ਫੀਚਰ ਨਹੀਂ ਹਨ। ਸ਼ੁਰੂ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਣਾ ਪਹਿਲਾ ਤੇਜ਼ ਕਰੋ। routes ਅਤੇ ਕੰਪੋਨੈਂਟ ਸਥਿਰ ਹੋਣ 'ਤੇ ਡੀਪ ਪਰਫੋਰਮੈਂਸ ਕੰਮ ਲਗਾਓ।
ਇਕ ਹੋਰ ਗਲਤੀ ਬੰਡਲ ਵਾਧੇ ਨੂੰ ਅਣਦੇਖਾ ਕਰਨਾ ਹੁੰਦਾ ਹੈ। 200 KB ਤੇ ਸਭ ਕੁਝ ਠੀਕ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਫਿਰ ਕੁਝ “ਛੋਟੇ” ਜੋੜਾਂ ਨਾਲ ਤੁਸੀਂ ਮੈਗਾਬਾਈਟ ਭੇਜਣ ਲੱਗਦੇ ਹੋ। ਇੱਕ ਆਸਾਨ ਅਦਤ ਮਦਦਗਾਰ ਹੈ: ਸਮੇਂ ਦੇ ਨਾਲ ਬੰਡਲ ਸਾਈਜ਼ ਟ੍ਰੈਕ ਕਰੋ ਅਤੇ ਅਚਾਨਕ ਉਛਾਲਾਂ ਨੂੰ ਬੱਗ ਮੰਨੋ।
ਟੀਮਾਂ ਕਈ ਵਾਰੀ ਸਾਰੇ ਨੂੰ client-only rendering ਤੇ ਡਿਫੌਲਟ ਕਰਦੀਆਂ ਹਨ, ਜਦੋਂ ਕਿ ਕੁਝ ਰੂਟ ਜ਼ਿਆਦਾਤਰ ਸਥਿਰ ਹੁੰਦੇ ਹਨ (pricing pages, docs, onboarding)। ਉਹ ਪੰਨੇ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫੀ ਘੱਟ ਡਿਵਾਈਸ ਕੰਮ ਨਾਲ ਦਿੱਤੇ ਜਾ ਸਕਦੇ ਹਨ।
ਇੱਕ ਚੁੱਪ ਕਾਤਲ ਵੱਡੀ UI ਲਾਇਬ੍ਰੇਰੀ ਜੋ ਸੁਵਿਧਾ ਲਈ ਜੋੜੀ ਜਾਂਦੀ ਹੈ ਬਿਨਾਂ ਉਸ ਦੀ production build ਲਾਗਤ ਮਾਪੇ। ਸੁਵਿਧਾ ਵੈਧ ਹੈ, ਪਰ ਸਪੱਸ਼ਟ ਰਹੋ ਕਿ ਤੁਸੀਂ ਵਧੇਰੇ ਜਾਵਾਸਕ੍ਰਿਪਟ, CSS, ਅਤੇ mid-range ਫੋਨਾਂ 'ਤੇ ਸੁਸਤ ਇੰਟਰੈਕਸ਼ਨਾਂ ਲਈ ਕੀ ਭੁਗਤਾਨ ਕਰ ਰਹੇ ਹੋ।
ਅਖੀਰੀ ਗਲਤੀ ਹੈ ਬਿਨਾਂ ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ ਦੇ approaches ਨੂੰ ਮਿਲਾਉਣਾ। ਜੇ ਐਪ ਦਾ ਅਧ-ਹਿੱਸਾ ਕੰਪਾਇਲਰ-ਜਨਰੇਟਡ ਅੱਪਡੇਟਸ ਫਰੁੱਮਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਅਤੇ ਦੂਜਾ ਹਿੱਸਾ runtime ਜਾਦੂ 'ਤੇ, ਤਾਂ ਸਮਝਣਯੋਗ ਨਿਯਮ ਨਹੀਂ ਰਹਿੰਦੇ ਅਤੇ ਨਿਰਾਸ਼ਾਵੇਂ ਖਾਮੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।
ਕੁਝ ਰੱਖਵਾਲੀ ਨਿਯਮ ਜੋ ਅਸਲੀ ਟੀਮਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ:
ਸੋਚੋ ਇੱਕ 3-ਅਦਮੀ ਟੀਮ ਇੱਕ scheduling ਅਤੇ billing SaaS ਬਣਾ ਰਹੀ ਹੈ। ਇਸਦੇ ਦੋ ਚਿਹਰੇ ਹਨ: ਇੱਕ ਪਬਲਿਕ ਮਾਰਕੀਟਿੰਗ ਸਾਈਟ (ਲੈਂਡਿੰਗ ਪੇਜ, ਪ੍ਰਾਈਸਿੰਗ, docs) ਅਤੇ ਇਕ ਅਥੈਂਟੀਕੇਟਡ ਡੈਸ਼ਬੋਰਡ (ਕੈਲੰਡਰ, ਇਨਵੌਇਸ, ਰਿਪੋਰਟ, ਸੈਟਿੰਗ)।
runtime-ਪਹਿਲਾਂ ਰਾਹ ਵਿੱਚ, ਉਹ ਇਕ runtime-ਭਾਰੀ ਸੈਟਅੱਪ ਚੁਣਦੇ ਹਨ ਕਿਉਂਕਿ UI ਬਦਲਾਅ ਤੇਜ਼ ਹੁੰਦੇ ਹਨ। ਡੈਸ਼ਬੋਰਡ ਵੱਡਾ client-side ਐਪ ਬਣ ਜਾਂਦਾ ਹੈ reusable components, state library, ਅਤੇ ਰਿਚ ਇੰਟਰੈਕਸ਼ਨਾਂ ਨਾਲ। ਇਟਰੇਸ਼ਨ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ। ਸਮੇਂ ਦੇ ਨਾਲ, ਪਹਿਲੀ ਲੋਡ mid-range ਫੋਨਾਂ 'ਤੇ ਭਾਰੀ ਮਹਿਸੂਸ ਹੋਣ ਲੱਗਦੀ ਹੈ।
ਕੰਪਾਇਲਰ-ਪਹਿਲਾਂ ਪਾਸੇ, ਉਹ ਐਸਾ ਫ੍ਰੇਮਵਰਕ ਚੁਣਦੇ ਹਨ ਜੋ ਵਧੇਰੇ ਕੰਮ build ਸਮੇਂ ਧਕੇਲਦਾ ਹੈ ਤਾਂ ਕਿ client JavaScript ਘੱਟ ਰਹੇ। ਆਮ ਫਲੋ ਜਿਵੇਂ ਡੈਸ਼ਬੋਰਡ ਖੋਲ੍ਹਣਾ, ਟੈਬ ਬਦਲਣਾ, ਅਤੇ search ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ। ਟਰੇਡਾਫ ਇਹ ਹੈ ਕਿ ਟੀਮ patterns ਅਤੇ tooling 'ਤੇ ਜਿਆਦਾ ਸੋਚ-ਵਿਚਾਰ ਕਰਨ ਦੀ ਲੋੜ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਕੁਝ ਆਸਾਨ runtime ਚਾਲਾਂ ਜਿਸਨਾਂ ਨੂੰ drop-in ਕਰਨਾ ਔਖਾ ਹੋ ਸਕਦਾ ਹੈ।
ਆਮ ਤੌਰ 'ਤੇ ਬਦਲਾਅ ਦੀਆਂ ਵਜ੍ਹਾ ਸਵਾਦ-ਮੂਡ ਨਹੀ ਹੁੰਦੀਆਂ; ਉਹ ਰੀਅਲਿਟੀ ਦੇ ਦਬਾਅ ਹੁੰਦੀਆਂ ਹਨ: ਸਲੋ ਪੇਜ signups ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੇ ਹਨ, ਨੀਚੇ ਦੇ ਡਿਵਾਈਸਾਂ ਤੋਂ ਯੂਜ਼ਰ ਵੱਧ ਆਉਂਦੇ ਹਨ, ਐਂਟਰਪ੍ਰਾਈਜ਼ ਖਰੀਦਦਾਰ predictable budgets ਮੰਗਦੇ ਹਨ, ਡੈਸ਼ਬੋਰਡ ਹਮੇਸ਼ਾਂ ਖੁੱਲ੍ਹਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ memory ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦੀ ਹੈ, ਜਾਂ support tickets ਨੈੱਟਵਰਕ ਤੇ ਸਲੋਨੈੱਸ ਦਾ ਜ਼ਿਕਰ ਕਰਦੇ ਹਨ।
ਹਾਈਬ੍ਰਿਡ ਵਿਕਲਪ ਅਕਸਰ ਜਿੱਤਦਾ ਹੈ। ਮਾਰਕੀਟਿੰਗ ਪੇਜਾਂ ਨੂੰ ਪਤਲਾ ਰੱਖੋ (server-rendered ਜਾਂ ਵੱਧ ਤਰ static, ਘੱਟ client ਕੋਡ) ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਵੱਧ runtime ਬਰਦਾਸ਼ਤ ਕਰੋ ਜਿੱਥੇ ਇੰਟਰਐਕਟਿਵਿਟੀ ਆਪਣੀ ਕੀਮਤ ਵਸੂਲਦੀ ਹੈ।
ਫੈਸਲੇ ਕਦਮ ਵਰਤ ਕੇ: ਉਹਨਾਂ ਨੇ ਹਿਊਕ-ਜਰਨੀਜ਼ (signup, ਪਹਿਲਾ ਇਨਵੌਇਸ, ਹਫ਼ਤਾਵਾਰ ਰਿਪੋਰਟਿੰਗ) ਦੀ ਨਾਂ-ਪਛਾਣ ਕੀਤੀ, ਉਹਨਾਂ ਨੂੰ mid-range ਫੋਨ 'ਤੇ ਮਾਪਿਆ, ਬਜਟ ਸੈੱਟ ਕੀਤਾ, ਅਤੇ hybrid ਚੁਣਿਆ। ਪਬਲਿਕ ਪੇਜਾਂ ਅਤੇ shared components ਲਈ ਕੰਪਾਇਲਰ-ਪਹਿਲਾਂ defaults ਅਤੇ ਜਿੱਥੇ ਇਟਰੇਸ਼ਨ ਤੇਜ਼ ਹੋਵੇ ਉਥੇ runtime-ਭਾਰੀ ਹੀ ਵਰਤਿਆ ਗਿਆ।
ਇਹ ਧਾਰਣਾ ਹਕੀਕਤ ਵਿੱਚ ਲਿਆਉਣ ਲਈ ਇੱਕ ਛੋਟਾ ਸਪਤਾਹਿਕ ਲੂਪ ਸਭ ਤੋਂ ਆਸਾਨ ਹੈ।
15 ਮਿੰਟ ਦਾ ਸਕੈਨ ਸ਼ੁਰੂ ਕਰੋ: ਕੀ ਬੰਡਲ سਾਈਜ਼ ਵੱਧ ਰਿਹਾ ਹੈ, ਕਿਹੜੇ ਰੂਟ ਸੁਸਤ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ, ਉਹਨਾਂ ਰੂਟਾਂ ਤੇ ਸਭ ਤੋਂ ਵੱਡੇ UI ਟੁਕੜੇ ਕੀ ਹਨ (tables, charts, editors, maps), ਅਤੇ ਕਿਹੜੇ ਡਿਪੈਂਡਨਸੀਜ਼ ਸਭ ਤੋਂ ਜਿਆਦਾ ਯੋਗਦਾਨ ਪਾ ਰਹੇ ਹਨ। ਫਿਰ ਇੱਕ ਬੋਤਲਨੈਕ ਚੁਣੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਬਿਨਾਂ ਹੋਰ ਸਟੈਕ ਰੀ-ਰਾਈਟ ਕੀਤੇ ਸੁਧਾਰ ਸਕਦੇ ਹੋ।
ਇਸ ਹਫਤੇ ਲਈ, ਛੋਟੀ ਰੱਖੋ:
ਚੋਣਾਂ ਨੂੰ ਵਾਪਸ-ਲੈਣਯੋਗ ਰੱਖਣ ਲਈ routes ਅਤੇ ਫੀਚਰਾਂ ਦਰਮਿਆਨ ਸਾਫ਼ ਸੀਮਾਵਾਂ ਖਿੱਚੋ। ਐਸੇ ਮਾਡਿਊਲਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਬਦਲ ਸਕੋ (charts, rich text editors, analytics SDKs) ਬਿਨਾਂ ਪੂਰੇ ਐਪ ਵਿੱਚ ਹੱਥ ਪਾਏ।
ਜ਼ਿਆਦਾਤਰ ਸਮੇਂ ਇਹ ਸਿਰਫ ਨੈੱਟਵਰਕ ਦੀ ਹੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੁੰਦੀ—ਇਸਦਾ ਮੁੱਖ ਕਾਰਨ runtime cost ਹੁੰਦਾ ਹੈ: ਬ੍ਰਾਉਜ਼ਰ ਜਾਵਾਸਕ੍ਰਿਪਟ ਡਾਊਨਲੋਡ ਕਰਨਾ, ਪਾਰਸ ਕਰਨਾ ਅਤੇ ਚਲਾਉਣਾ, UI ਬਣਾਉਣਾ ਅਤੇ ਹਰ ਅਪਡੇਟ 'ਤੇ ਵਾਧੂ ਕੰਮ ਕਰਨਾ।
ਇਸ ਲਈ ਇੱਕ ਐਪ ਵੱਡੀ ਜਾਵਾਸਕ੍ਰਿਪਟ ਲੋਡ ਹੋਣ ‘ਤੇ ਇੱਕ ਚੰਗੇ ਲੈਪਟੌਪ ‘ਤੇ ਵੀ “ਭਾਰੀ” ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ।
ਉਹੀ ਮਕਸਦ ਹੈ (ਕਲਾਇਂਟ 'ਤੇ ਘੱਟ ਕੰਮ ਕਰਵਾਉਣਾ), ਪਰ ਮਕੈਨਿਜ਼ਮ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ।
ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਫ੍ਰੇਮਵਰਕ build ਸਮੇਂ ਤੁਹਾਡੇ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਐਪ ਲਈ ਮੁਤਾਬਕ ਕੋਡ ਆਉਟਪੁੱਟ ਕਰਦਾ ਹੈ, ਨ ਕਿ ਇੱਕ ਵੱਡਾ, ਜਨਰਲ-ਪ੍ਰਯੋਗ UI ਇੰਜਣ ਭੇਜਦਾ ਹੈ.
ਪ੍ਰਯੋਗਿਕ ਲਾਭ ਆਮ ਤੌਰ 'ਤੇ ਛੋਟੇ ਬੰਡਲ ਅਤੇ ਇੰਟਰੈਕਸ਼ਨਾਂ (ਕਲਿੱਕ, ਟਾਈਪਿੰਗ, ਸਕ੍ਰੋਲਿੰਗ) ਦੌਰਾਨ ਘੱਟ CPU ਕੰਮ ਹੁੰਦਾ ਹੈ।
ਸ਼ੁਰੂਆਤ ਲਈ ਇਹ ਨਾਂ-ਜ਼ਿਆਦਾ metrics ਸ਼ਾਮਲ ਕਰੋ:
ਹਰ ਵਾਰ ਇੱਕੋ ਵਰਕ ਫਲੋਮਾਪਤੇ ਮਾਪੋ ਤਾਂ ਜੋ ਤੁਲਨਾ ਕਰ ਸਕੋ।
ਹਾਂ, ਪਰ ਪਹਿਲਾਂ ਪਤਾ ਕਰੋ ਕਿ ਸਮਾਂ ਕਿੱਥੇ ਲੱਗ ਰਿਹਾ ਹੈ: ਨੈੱਟਵਰਕ, ਜਾਵਾਸਕ੍ਰਿਪਟ CPU, ਰੇਂਡਰਿੰਗ, ਜਾਂ ਬੈਕਐਂਡ। ਜੇ ਸਮੱਸਿਆ ਸਲੋ APIs, ਵੱਡੀਆਂ ਇਮੇਜਾਂ ਜਾਂ ਤੀਸਰੇ-ਪੱਖ ਸਕ੍ਰਿਪਟਾਂ ਨਾਲ ਹੈ ਤਾਂ ਨਵਾਂ ਫ੍ਰੇਮਵਰਕ ਉਹਨਾਂ ਬੋਤਲਨੈਕਸ ਨੂੰ ਹਟਾਏਗਾ ਨਹੀਂ।
ਫ੍ਰੇਮਵਰਕ ਚੋਣ ਇਕ ਹੱਥੀ ਹੈ—ਪਹਿਲਾਂ ਮੈਟਰਿਕਸ ਵੇਖੋ।
ਜਦੋਂ ਤੁਸੀਂ runtime-ਭਾਰੀ ਦੀਨਾਂ ਨੂੰ ਚੁਣਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ ਜ਼ਿਆਦਾ ਲਚੀਲਤਾ ਮਿਲਦੀ ਹੈ:
ਜੇ runtime ਤੁਹਾਡੀ ਮੁੱਖ ਰੁਕਾਵਟ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਹ ਸਹੂਲਤ ਵਧੀਆ ਫੈਸਲਾ ਹੋ ਸਕਦੀ ਹੈ।
ਸਰਲ ਡਿਫਾਲਟ:
Hybrid ਅਕਸਰ ਸਭ ਤੋਂ ਵਧੀਆ ਹੁੰਦਾ ਹੈ—ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ ਲਿਖੋ ਤਾਂ ਕਿ ਐਪ ਨਹੀੰ ਮਿਲੀ-ਝੁਲੀ ਦਸ਼ਾ ਵਿੱਚ ਪੈ ਜਾਵੇ।
ਹਾਲਤ-ਉਪਯੋਗ ਬਜਟ ਜੋ ਟੀਮ ਨੂ਼ਣ ਰੋਕਦਾ ਹੈ ਪਰ ਸ਼ਿਪਿੰਗ ਨਹੀਂ ਰੋਕਦਾ। ਉਦਾਹਰਨ ਲਈ:
ਬਜਟ ਗਾਰਡਰੇਲ ਹਨ, ਆਦਰਸ਼ ਸਕੋਰ ਲਈ ਮੁਕਾਬਲਾ ਨਹੀਂ।
Hydration ਉਹ ਕਦਮ ਹੈ ਜਿੱਥੇ ਸਰਵਰ-ਰੇਂਡਰ ਕੀਤੀ ਹੋਈ ਪੇਜ ਨੂੰ ਇੰਟਰਐਕਟਿਵ ਬਣਾਉਣ ਲਈ ਬ੍ਰਾਉਜ਼ਰ ਵਿੱਚ event handlers ਜੋੜੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਕਾਫੀ state ਦੁਬਾਰਾ ਬਣਾਈ ਜਾਂਦੀ ਹੈ.
ਜੇ ਤੁਸੀਂ ਬਹੁਤ ਵੱਧ ਹਾਈਡ੍ਰੇਟ ਕਰਦੇ ਹੋ ਤਾਂ ਪਹਿਲੀ ਲੋਡ ਦੇ ਦੌਰਾਨ ਪੇਜ ਹਾਲਾਂਕਿ HTML ਤੇਜ਼ ਰਾਹੀਂ ਦਿਖਦੀ ਹੈ ਪਰ ਇੰਟਰਐਕਟਿਵ ਹੋਣ ਵਿੱਚ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗ ਸਕਦਾ ਹੈ। Build-ਟਾਈਮ ਟੂਲ ਇਸਨੂੰ ਕਮ ਕਰ ਸਕਦੇ ਹਨ ਜੇ ਉਹ ਚਿੰਨ੍ਹਾਂ ਲਗਾ ਸਕਣ ਕਿ ਕਿਹੜਾ ਹਿੱਸਾ ਵਾਕਈ ਇੰਟਰਐਕਟਿਵ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਵਧੀਆ “thin slice” ਵਿੱਚ ਅਸਲੀ ਦੁਨੀਆਂ ਦੀਆਂ ගੜਬੜਾਂ ਹੁੰਦੀਆਂ ਹਨ:
ਜੇ ਤੁਸੀਂ ਇਸ ਸ্লਾਈਸ ਦੀ ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ ਕਰ ਰਹੇ ਹੋ ਤਾਂ Koder.ai ਤੁਹਾਨੂੰ ਵੈੱਬ + ਬੈਕਐਂਡ ਫਲੋ ਚੈਟ ਰਾਹੀਂ ਬਣਾਉਣ ਅਤੇ ਸੋਰਸ ਏਕਸਪੋਰਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਜਲਦੀ ਮਾਪ ਸਕੋ ਅਤੇ ਬਿਨਾਂ ਪੂਰੇ ਰੀ-ਰਾਈਟ ਦੇ ਤਊਕੇ ਪੜ੍ਹਾਵੇ ਕਰ ਸਕੋ।