ਵੈੱਬ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਕੰਪਾਇਲਰ ਪਹੁੰਚ: ਰਿਚ ਹੈਰਿਸ ਦੀ ਰਾਏ

ਕਿਉਂ ਕੁਝ ਵੈੱਬ ਐਪ ਚੰਗੀਆਂ ਡਿਵਾਈਸਾਂ 'ਤੇ ਵੀ ਧੀਰੇ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ

ਯੂਜ਼ਰ ਕਮ technical ਸ਼ਬਦ ਵਰਤਦੇ ਹਨ। ਉਹ ਕਹਿੰਦੇ ਹਨ ਕਿ ਐਪ ਭਾਰੀ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਪੇਜ ਨੂੰ ਕੁਝ ਵਕਤ ਲੱਗਦਾ ਹੈ kujh ਵੀ ਦਿਖਾਉਣ ਲਈ, ਬਟਨ ਦੇ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਦੇਰੀ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਆਮ ਕਾਰਵਾਈਆਂ ਜਿਵੇਂ ਮੇਨੂ ਖੋਲ੍ਹਣਾ, search ਬਾਕਸ ਵਿੱਚ ਲਿਖਣਾ, ਜਾਂ ਟੈਬ ਬਦਲਣਾ, ਜ਼ਬਰਦਸਤੀ ਜਾਂ ਜਿਰਟ ਹੋ ਜਾਂਦੇ ਹਨ।

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

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

ਪਰਫੋਰਮੈਂਸ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦੇ ਨਤੀਜੇ ਬਾਅਦ ਵਿੱਚ ਵੀ ਦਿੱਸਦੇ ਹਨ। ਪਹਿਲਾਂ ਐਪ ਛੋਟਾ ਹੁੰਦਾ ਹੈ: ਕੁਝ ਸਕਰੀਨ, ਹਲਕਾ ਡਾਟਾ, ਸਾਧਾਰਣ UI। ਫਿਰ ਪ੍ਰੋਡਕਟ ਵਧਦਾ ਹੈ। ਮਾਰਕੀਟਿੰਗ ਟਰੇਕਰ ਜੋੜਦੀ ਹੈ, ਡਿਜ਼ਾਈਨ ਰਿਚਰ ਕੰਪੋਨੈਂਟ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ, ਟੀਮਾਂ ਸਟੇਟ, ਫੀਚਰ, ਡਿਪੈਂਡਨਸੀਜ਼, ਅਤੇ personalization ਜੋੜਦੀਆਂ ਹਨ। ਹਰ ਬਦਲਾਅ ਅਕਸਰ ਨੁਕਸਾਨ-ਰਹਿਤ ਲੱਗਦਾ ਹੈ, ਪਰ ਕੁੱਲ ਕੰਮ ਵਧਦਾ ਜਾਂਦਾ ਹੈ।

ਇਸੇ ਲਈ ਟੀਮਾਂ ਕੰਪਾਇਲਰ-ਪਹਿਲਾਂ ਦੀ ਸੋਚ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਨ। ਮਕਸਦ ਅਕਸਰ ਪਰਫੈਕਟ ਸਕੋਰ ਨਹੀਂ ਹੁੰਦਾ। ਮਕਸਦ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ship ਕਰਦੇ ਰਹੋ ਬਿਨਾਂ ਐਪ ਹਰ ਮਹੀਨੇ ਧੀਰਾ ਹੋਣ ਦੇ।

runtime-ਭਾਰੀ ਵਿਰੁੱਧ build-ਟਾਈਮ: ਮੁਢਲੀਆਂ ਗੱਲਾਂ

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

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

compile-time ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਨਾਲ, ਵੱਧ ਕੰਮ build ਦੌਰਾਨ ਹੋ ਜਾਂਦਾ ਹੈ। build ਟੂਲ ਤੁਹਾਡੇ ਕੰਪੋਨੈਂਟਾਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ ਅਤੇ ਵਧੇਰੇ ਸਿੱਧਾ, ਐਪ-ਖਾਸ ਕੋਡ ਜਨਰੇਟ ਕਰਦਾ ਹੈ।

ਇੱਕ ਮਦਦਗਾਰ ਮਾਨਸਿਕ ਮਾਡਲ:

• Runtime-ਭਾਰੀ ਨੂੰ ਐਸਾ ਸੋਚੋ: ਤੁਹਾਨੂੰ ਹਦਾਇਤਾਂ ਅਤੇ ਟੂਲਬਾਕਸ ਭੇਜ ਦਿਤਾ ਗਿਆ ਹੈ, ਫਿਰ ਗ੍ਰਾਹਕ ਦੇ ਘਰ 'ਤੇ ਅਸੈਂਬਲ ਕਰਨਾ।
• Compile-time ਨੂੰ ਐਸਾ ਸੋਚੋ: ਹਿੱਸੇ ਪਹਿਲਾਂ ਹੀ ਕੱਟੇ ਤੇ ਲੇਬਲ ਕੀਤੇ ਹੋਏ ਹਨ, ਤਾਂ ਅਸੈਂਬਲੀ ਤੇਜ਼ ਹੋਵੇਗੀ।

ਅਕਸਰ ਅਸਲੀ ਉਤਪਾਦ ਦੋਨਾਂ ਵਿਚਕਾਰ ਕਿਸੇ ਜਗ੍ਹਾ 'ਤੇ ਹੁੰਦੇ ਹਨ। ਕੰਪਾਇਲਰ-ਪਹਿਲਾਂ ਵਾਲੇ ਐਪ ਵੀ ਕੁਝ runtime ਕੋਡ ਭੇਜਦੇ ਹਨ (routing, ਡਾਟਾ ਫੇਚਿੰਗ, animations, error handling)। runtime-ਭਾਰੀ ਫ੍ਰੇਮਵਰਕ ਵੀ build-ਟਾਈਮ ਤਕਨੀਆਂ 'ਤੇ ਨਿਰਭਰ ਰਹਿੰਦੇ ਹਨ (minification, code splitting, server rendering) ਤਾਂ ਕਿ ਕਲਾਇੰਟ ਕੰਮ ਘੱਟ ਹੋਵੇ। ਪ੍ਰਯੋਗਿਕ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ ਕਿਹੜਾ ਕੈਂਪ "ਸਹੀ" ਹੈ, ਬਲਕਿ ਇਹ ਕਿ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਲਈ ਕਿਹੜਾ ਮਿਲਾਪ ਵਧੀਆ ਹੈ।

Rich Harris ਅਤੇ “ਫ੍ਰੇਮਵਰਕ ਇੱਕ ਕੰਪਾਇਲਰ ਹੈ” ਕਿਉਂ ਮਾਤਲਬ ਰੱਖਦਾ ਹੈ

Rich Harris ਕੰਪਾਇਲਰ-ਪਹਿਲਾਂ ਫਰੰਟਐਂਡ ਸੋਚ ਦੇ ਸਭ ਤੋਂ ਸਪਸ਼ਟ ਬੋਲਣ ਵਾਲਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਉਸਦਾ ਦਲੀਲ ਸਿੱਧਾ ਹੈ: ਅੱਗੇ ਤੋਂ ਵਧੇਰੇ ਕੰਮ ਕਰੋ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਘੱਟ ਕੋਡ ਡਾਊਨਲੋਡ ਕਰਨ ਅਤੇ ਬ੍ਰਾਉਜ਼ਰ ਘੱਟ ਕੰਮ ਕਰਨ।

ਮਕਸਦ ਵਰਤੋਂਯੋਗ ਹੈ। ਬਹੁਤ ਸਾਰੇ runtime-ਭਾਰੀ ਫ੍ਰੇਮਵਰਕ ਇੱਕ general-purpose ਇੰਜਣ ਭੇਜਦੇ ਹਨ: ਕੰਪੋਨੈਂਟ ਲੌਜਿਕ, reactivity, diffing, scheduling, ਅਤੇ ਮਦਦਗਾਰ ਜੋ ਹਰ ਸੰਭਵ ਐਪ ਲਈ ਕੰਮ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। ਉਹ ਲਚੀਲਤਾ bytes ਅਤੇ CPU ਦੀ ਕੀਮਤ 'ਤੇ ਆਉਂਦੀ ਹੈ। ਭਾਵੇ ਤੁਹਾਡਾ UI ਛੋਟਾ ਹੋਵੇ, ਫਿਰ ਵੀ ਤੁਸੀਂ ਇੱਕ ਵੱਡੇ runtime ਲਈ ਭੁਗਤਾਨ ਕਰ ਸਕਦੇ ਹੋ।

ਕੰਪਾਇਲਰ ਪਹੁੰਚ ਮਾਡਲ ਨੂੰ ਉਲਟ ਕਰਦੀ ਹੈ। build ਸਮੇਂ, ਕੰਪਾਇਲਰ ਤੁਹਾਡੇ ਅਸਲ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਵੇਖਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਲਈ ਖਾਸ DOM ਅਪਡੇਟ ਕੋਡ ਜਨਰੇਟ ਕਰਦਾ ਹੈ। ਜੇ ਇੱਕ label ਕਦੇ ਨਹੀਂ ਬਦਲਦਾ, ਉਹ ਸਧਾਰਨ HTML ਬਣ ਜਾਂਦੀ ਹੈ। ਜੇ ਸਿਰਫ ਇੱਕ value ਬਦਲਦੀ ਹੈ, ਤਾਂ ਉਸ value ਲਈ ਹੀ ਅਪਡੇਟ ਪਾਥ ਜਾਰੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜਨਰਿਕ UI ਮਸ਼ੀਨ ਭੇਜਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਆਪਣੀ ਉਤਪਾਦ-ਖਾਸ ਆਉਟਪੁੱਟ ਭੇਜਦੇ ਹੋ।

ਇਸਦਾ ਨਤੀਜਾ ਅਕਸਰ ਸਧਾਰਨ ਹੁੰਦਾ ਹੈ: ਯੂਜ਼ਰਾਂ ਨੂੰ ਘੱਟ ਫ੍ਰੇਮਵਰਕ ਕੋਡ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਹਰ ਇੰਟਰੈਕਸ਼ਨ 'ਤੇ ਘੱਟ ਕੰਮ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਘੱਟ-ਅੰਤ ਵਾਲੀਆਂ ਡਿਵਾਈਸਾਂ 'ਤੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ, ਜਿੱਥੇ ਵਾਧੂ runtime ਖਪਤ ਤੇਜ਼ੀ ਨਾਲ ਦਿਖਾਈ ਦੇਂਦੀ ਹੈ।

ਟਰੇਡ-ਆਫ਼ ਫਿਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ:

• ਕੁਝ ਡਾਇਨਾਮਿਕ ਪੈਟਰਨ ਉਹਨਾਂ ਵੇਲੇ ਔਖੇ ਹੋ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਕੰਪਾਇਲਰ ਉਨ੍ਹਾਂ ਨੂੰ ਪਹਿਲਾਂ ਸਮਝ ਨਹੀਂ ਸਕਦਾ।
• tooling ਦੀ ਗੁਣਵੱਤਾ ਜ਼ਿਆਦਾ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ (build ਦੀ ਗਤੀ, debugging, source maps)।
• ecosystem ਪਰੰਪਰਾਵਾਂ ਵਿੱਚ ਫ਼ਰਕ ਹੋ ਸਕਦਾ ਹੈ, ਜੋ hiring ਅਤੇ reuse ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।
• ਤੁਹਾਨੂੰ ਫਿਰ ਵੀ 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 ਵਿੱਚ ਫੈਸਲੇ, ਬਹੁਤ ਸਾਰੇ ਤੀਸਰੇ-ਪੱਖ ਕੰਪੋਨੈਂਟ, ਅਤੇ ਸਾਲਾਂ ਤੋਂ ਸਥਿਰ ਵਰਕਫਲੋ।

runtime-ਭਾਰੀ ਫ੍ਰੇਮਵਰਕ ਉਹਨਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਚਮਕਦੇ ਹਨ ਜਦੋਂ UI ਨਿਯਮ ਬਾਰ-ਬਾਰ ਬਦਲਦੇ ਹਨ। ਜੇ ਤੁਹਾਨੂੰ ਜਟਿਲ routing, nested layouts, ਰਿਚ forms, ਅਤੇ ਡੂੰਘਾ state ਮਾਡਲ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਪੱਕਾ runtime ਇੱਕ ਸੇਫਟੀ ਨੈਟ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ।

runtime ਸਹੂਲਤ ਲਈ ਪੈਸਾ ਦੇ ਰਿਹਾ ਹੈ

Runtime ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਫ੍ਰੇਮਵਰਕ ਚਲਦੇ ਸਮੇਂ ਬਹੁਤ ਕੁਝ ਸੰਭਾਲੇ, ਨ ਕਿ ਸਿਰਫ build ਦੌਰਾਨ। ਇਸ ਨਾਲ ਟੀਮਾਂ ਰੋਜ਼ਾਨਾ ਤੇਜ਼ ਮਹਿਸੂਸ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਭਾਵੇ ਇਹ ਥੋੜ੍ਹਾ ਜ਼ਿਆਦਾ ਓਵਰਹੈੱਡ ਜੋੜਦਾ ਹੋਵੇ।

ਆਮ ਫਾਇਦੇ ਵਿੱਚ ਵੱਡਾ ecosystem, ਸਟੇਟ ਅਤੇ ਡਾਟਾ ਫੈਚਿੰਗ ਲਈ ਜਾਣ-ਪਛਾਣ ਪੈਟਰਨ, ਮਜ਼ਬੂਤ dev tools, ਪਲੱਗਿਨ-ਸਟਾਈਲ ਵਿਸਥਾਰ ਲਈ ਆਸਾਨੀ, ਅਤੇ hiring ਲਈ ਜਾਣ-ਪਛਾਣ ਸ਼ਾਮਲ ਹਨ।

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

ਜਦੋਂ runtime ਓਵਰਹੈੱਡ ਬੋਤਲਨੇਕ ਨਹੀਂ ਹੈ

ਬਹੁਤ ਸਾਰੀਆਂ “ਧੀਰੀ ਐਪ” ਸ਼ਿਕਾਇਤਾਂ ਫ੍ਰੇਮਵਰਕ runtime ਨਾਲ ਨਹੀਂ ਜੁੜਦੀਆਂ। ਜੇ ਤੁਹਾਡਾ ਪੇਜ ਸੁਸਤ APIs, ਭਾਰੀ ਇਮੇਜਾਂ, ਬਹੁਤ ਫੋਂਟਸ, ਜਾਂ ਤੀਸਰੇ-ਪੱਖ ਸਕ੍ਰਿਪਟਾਂ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਫ੍ਰੇਮਵਰਕ ਬਦਲਨ ਨਾਲ ਮੂਲ ਸਮੱਸਿਆ ਹਟੇਗੀ ਨਹੀਂ।

ਇੱਕ ਅੰਦਰੂਨੀ admin ਡੈਸ਼ਬੋਰਡ ਜੋ ਲੌਗਿਨ ਦੇ ਪਿੱਛੇ ਹੈ ਅਕਸਰ ਇੱਕ ਵੱਡੇ runtime ਨਾਲ ਠੀਕ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਯੂਜ਼ਰ ਤਕਨਾਲੋਜੀਕਲ ਤੌਰ 'ਤੇ ਮਜ਼ਬੂਤ ਡਿਵਾਈਸਾਂ ਤੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਕੰਮ backend ਕਵੇਰੀਆਂ ਅਤੇ ਟੇਬਲਾਂ ਨਾਲ ਪ੍ਰਭਾਵਤ ਹੁੰਦਾ ਹੈ।

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

ਟੀਮਾਂ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਬਨਾਮ ਇਟਰੇਸ਼ਨ ਗਤੀ: ਅਸਲ ਤਜਰਬਾ

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

ਪਰ ਪ੍ਰਦਰਸ਼ਨ ਕੰਮ ਜਦੋਂ ਜ਼ਰੂਰਤ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂ ਬਹੁਤ ਵਿਆਪਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਉਹ ਇਸ ਲੂਪ ਨੂੰ ਮੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਜੇ ਹਰ pull request ਇੱਕ ਮਾਈਕ੍ਰੋ-ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਦੀ ਚਰਚਾ ਬਣ ਜਾਂਦੀ ਹੈ, ਟੀਮ ਜੋਖਮ ਲੈਣਾ ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਕਠੋਰ ਪਾਈਪਲਾਈਨ ਬਣਾਉਂਦੇ ਹੋ ਪਹਿਲਾਂ ਹੀ ਪਤਾ ਨਾ ਹੋਣ ਤੇ ਕਿ ਪ੍ਰੋਡਕਟ ਕੀ ਹੈ, ਲੋਕ tooling ਨਾਲ ਲੜਾਈ ਕਰਨ ਲੱਗਦੇ ਹਨ ਬਜਾਏ ਯੂਜ਼ਰਾਂ ਨਾਲ ਗੱਲ ਕਰਨ ਦੇ।

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

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਬਜਟ ਸ਼ਾਮਲ ਹੋ ਸਕਦਾ ਹੈ:

• ਮਿਡ-ਰੇਂਜ ਫੋਨਾਂ 'ਤੇ ਪੇਜ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਵਰਤਣਯੋਗ ਬਣੇ।
• ਰੂਟ ਪ੍ਰਤੀ ਜਾਵਾਸਕ੍ਰਿਪਟ ਇਕ ਟੀਮ-ਸਹਿਮਤ ਕੈਪ ਤੋਂ ਘੱਟ ਰਹੇ।
• ਮੁੱਖ ਇੰਟਰੈਕਸ਼ਨ (search, add to cart, save) ਤੇਜ਼ ਜਵਾਬ ਦੇਣ।
• ਕੋਈ ਇਕ ਫੀਚਰ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ JS ਜਾਂ CSS ਨਾ ਜੋੜੇ।

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

ਕੰਪਾਇਲਰ-ਪਹਿਲਾਂ tooling ਇਸ ਤਜਰਬੇ ਨੂੰ ਬਦਲ ਸਕਦੀ ਹੈ। ਤੁਸੀਂ ਸ਼ਾਇਦ ਥੋੜ੍ਹਾ ਲੰਬਾ build ਸਵੀਕਾਰ ਕਰੋ, ਪਰ ਹਰ ਡਿਵਾਈਸ ਤੇ, ਹਰ ਵਿਜ਼ਿਟ ਤੇ ਹੋਣ ਵਾਲੇ ਕੰਮ ਨੂੰ ਘਟਾ ਦਿਓ।

ਬਜਟ ਨੂੰ ਉਹ ਵੇਲੇ ਫਿਰੋ ਜਦੋਂ ਪ੍ਰੋਡਕਟ ਸਾਬਤ ਹੋ ਜਾਵੇ। ਸ਼ੁਰੂ ਵਿੱਚ ਮੂਲ ਗਾਰਡਰੇਲ ਰੱਖੋ। ਜਿਵੇਂ ਟ੍ਰੈਫਿਕ ਅਤੇ ਰੈਵਨਿュー ਵਧਦਾ ਹੈ, ਬਜਟ ਤੰਗ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਜਗ੍ਹਾਂ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰੋ ਜਿੱਥੇ ਅਸਲੀ ਮੈਟ੍ਰਿਕਸ 'ਤੇ ਅਸਰ ਪੈਂਦਾ ਹੈ, ਨਾ ਕਿ ਸ਼ੋਖੀ 'ਤੇ।

ਪਰફੋਰਮੈਂਸ ਨੂੰ ਮਾਪਣ ਦਾ ਸਹੀ ਤਰੀਕਾ

ਪਰਫੋਰਮੈਂਸ ਦੀਆਂ ਚਰਚਾਵਾਂ ਗੜਬੜ ਹੋ ਜਾਦੀਆਂ ਹਨ ਜਦੋਂ ਕੋਈ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦਾ ਕਿ “ਤੇਜ਼” ਦਾ ਮਤਲਬ ਕੀ ਹੈ। ਕੁਝ metrics ਚੁਣੋ, ਉਹਨਾਂ ਨੂੰ ਲਿਖੋ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੇ ਸਕੋਰਬੋਰਡ ਵਾਂਗ ਸਮਝੋ।

ਇੱਕ ਸਰਲ ਸ਼ੁਰੂਆਤ:

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

ਨੁਮਰੇ ਪ੍ਰਤੀਨਿਧੀ ਡਿਵਾਈਸਾਂ 'ਤੇ ਮਾਪੋ, ਕੇਵਲ ਡੈਵਲਪਰ ਲੈਪਟੌਪ 'ਤੇ ਨਹੀਂ। ਤੇਜ਼ CPU, ਗਰਮ cache, ਅਤੇ ਸਥਾਨਕ ਸਰਵਰ ਉਹ ਦੇਰੀਆਂ ਲੁਕਾ ਕੇ ਰੱਖ ਸਕਦੇ ਹਨ ਜੋ ਮਿਡ-ਰੇਂਜ ਫੋਨ ਤੇ ਆਉਂਦੀਆਂ ਹਨ।

ਇਸ ਨੂੰ ਜ਼ਮੀਨੀ ਰੱਖੋ: 2-3 ਡਿਵਾਈਸ ਚੁਣੋ ਜੋ ਅਸਲੀ ਯੂਜ਼ਰਾਂ ਨੂੰ ਮਿਲਦੇ ਹਨ ਅਤੇ ਹਰ ਵਾਰ ਉਹੀ ਫਲੋ ਚਲਾਓ (ਹੋਮ ਸਕ੍ਰੀਨ, ਲੌਗਿਨ, ਇਕ ਆਮ ਟਾਸਕ)। ਇਹ ਨਿਰੰਤਰ ਕਰੋ।

ਫ੍ਰੇਮਵਰਕ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਬੇਸਲਾਈਨ ਕੈਪਚਰ ਕਰੋ। ਅੱਜ ਦੀ build ਲਓ, ਇਕੋ ਫਲੋ ਲਈ ਨੰਬਰ ਰیکارਡ ਕਰੋ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਨੇੜੇ ਰੱਖੋ। ਇਹ ਤੁਹਾਡਾ “ਪਹਿਲਾਂ” ਫੋਟੋ ਹੋਵੇਗਾ।

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

ਜਦੋਂ ਨੰਬਰ ਖਰਾਬ ਹੋਣ, ਅਨੁਮਾਨ ਨਾ ਲਗਾਓ। ਵੇਖੋ ਕੀ ਸ਼ਿਪ ਹੋਇਆ, ਕੀ rendering ਰੋਕ ਰਿਹਾ ਸੀ, ਅਤੇ ਸਮਾਂ ਕਿੱਥੇ ਗਿਆ: ਨੈੱਟਵਰਕ, ਜਾਵਾਸਕ੍ਰਿਪਟ, ਜਾਂ API।

ਇੱਕ ਕਦਮ-ਦਰ-ਕਦਮ ਫੈਸਲਾ ਫਰੇਮਵਰਕ ਜੋ ਤੁਸੀਂ ਵਰਤ ਸਕਦੇ ਹੋ

ਫ੍ਰੇਮਵਰਕ ਅਤੇ ਰੇਂਡਰਿੰਗ ਦੇ ਫੈਸਲੇ ਨੂੰ ਪ੍ਰੋਡਕਟ ਫੈਸਲਿਆਂ ਵਾਂਗ ਸੋਚੋ। ਮਕਸਦ ਸਭ ਤੋਂ ਵਧੀਆ ਟੈਕ ਨਹੀਂ, ਬਲਕਿ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਟੀਮ ਦੀ ਰਫ਼ਤਾਰ ਵਿਚਕਾਰ ਸਹੀ ਸੰਤੁਲਨ ਹੈ।

1. ਆਪਣੇ ਪ੍ਰੋਡਕਟ ਸਰਫੇਸ ਪਰिभਾਸ਼ਿਤ ਕਰੋ। ਮਾਰਕੀਟਿੰਗ ਪੇਜ, ਲੌਗਡ-ਇਨ ਡੈਸ਼ਬੋਰਡ, ਮੋਬਾਈਲ, ਅਤੇ ਅੰਦਰੂਨੀ ਐਡਮਿਨ ਟੂਲਾਂ ਨੂੰ ਵੱਖ ਕਰੋ। ਹਰ ਸਰਫੇਸ ਦੇ ਵੱਖ-ਵੱਖ ਯੂਜ਼ਰ, ਡਿਵਾਈਸ, ਅਤੇ ਉਮੀਦਾਂ ਹੁੰਦੀਆਂ ਹਨ।
2. ਇੱਕ ਪਰਫੋਰਮੈਂਸ ਬਜਟ ਸੈੱਟ ਕਰੋ। 2-3 ਨੰਬਰ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਰੱਖੋਗੇ, ਜਿਵੇਂ mid-range ਫੋਨ 'ਤੇ ਪਹਿਲੀ ਲੋਡ ਅਤੇ ਇਕ ਮੁੱਖ ਇੰਟਰੈਕਸ਼ਨ ਦਾ ਸਮਾਂ।
3. ਆਪਣੀਆਂ ਪਾਬੰਦੀਆਂ ਰੈਂਕ ਕਰੋ। ਸਚ ਬੋਲੋ ਕਿ ਹੁਣ ਕੀ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮੱਹਤਵਪੂਰਨ ਹੈ: ਟੀਮ ਸKillਜ਼, ਡੈਡਲਾਈਨ, SEO, ਡੇਟਾ ਗੋਪਨੀਯਤਾ ਨਿਯਮ, ਅਤੇ ਕਿੱਥੇ ਐਪ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ।
4. ਇਕ ਪਹੁੰਚ ਚੁਣੋ। ਜੇ ਪਹਿਲੀ ਲੋਡ ਅਤੇ ਇੰਟਰੈਕਸ਼ਨ ਦੀ ਤੇਜ਼ੀ ਗੈਰ-ਬਹਿਸੀ ਹੈ ਤਾਂ ਕੰਪਾਇਲਰ-ਪਹਿਲਾਂ ਫਿੱਟ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਲਚੀਲਤਾ ਅਤੇ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਚਾਹੀਦੀ ਹੈ ਤਾਂ runtime-ਪਹਿਲਾਂ ਚੁਣੋ। ਅਕਸਰ ਹਾਈਬ੍ਰਿਡ ਜੇਤੂ ਹੁੰਦਾ ਹੈ: ਪ੍ਰਦਰਸ਼ਨ-ਸੰਵੇਦਨਸ਼ੀਲ ਸਰਫੇਸ ਨੂੰ ਪਤਲਾ ਰੱਖੋ, ਅਤੇ ਜਿੱਥੇ runtime ਸਪੱਸ਼ਟ ਤੌਰ ਤੇ ਪ੍ਰਯੋਗਕਾਰੀ ਵਾਧਾ ਕਰਦਾ ਹੈ ਓਥੇ ਭਾਰੀ runtime ਵਰਤੋ।
5. ਇੱਕ ਪਤਲਾ ਇੰਡ-ਟੂ-ਏਂਡ ਫਲੋ ਬਣਾਓ, ਫਿਰ ਉਸਨੂੰ ਲਾਕ ਕਰੋ। ਇੱਕ ਹਕੀਕਤੀ ਯੂਜ਼ਰ ਫਲੋ ਨੂੰ end-to-end ਬਣਾਉ, ਉਸਨੂੰ ਬਜਟ ਨਾਲ ਤੁਲਨਾ ਕਰੋ, ਅਤੇ ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਕੀ ਚੁਣਿਆ ਅਤੇ ਕਿਉਂ।

ਇੱਕ 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 ਜਾਦੂ 'ਤੇ, ਤਾਂ ਸਮਝਣਯੋਗ ਨਿਯਮ ਨਹੀਂ ਰਹਿੰਦੇ ਅਤੇ ਨਿਰਾਸ਼ਾਵੇਂ ਖਾਮੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।

ਕੁਝ ਰੱਖਵਾਲੀ ਨਿਯਮ ਜੋ ਅਸਲੀ ਟੀਮਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ:

• ਪ੍ਰਤੀ-ਮੁੱਖ ਰੂਟ ਬੰਡਲ-ਸਾਈਜ਼ ਬਜਟ ਸੈੱਟ ਕਰੋ, ਸਿਰਫ ਸਮੂਹ-ਐਪ ਲਈ ਨਹੀਂ।
• ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਿਹੜੇ ਰੂਟ ਪਹਿਲੀ ਲੋਡ ਤੇ ਤੇਜ਼ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ entsprechend rendering ਡਿਜ਼ਾਈਨ ਕਰੋ।
• ਕੋਈ ਲਾਇਬ੍ਰੇਰੀ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਦੀ production weight ਚੈਕ ਕਰੋ।
• ਸੀਮਾਵਾਂ ਲਿਖੋ (ਕਿਹੜੇ ਹਿੱਸੇ ਕੰਪਾਇਲਰ-ਅਪਟੀਮਾਈਜ਼ਡ ਹਨ, ਕਿਹੜੇ runtime)।
• ਅਸਲੀ ਯੂਜ਼ਰ ਡੇਟਾ ਆਉਣ ਤੋਂ ਬਾਅਦ ਫੈਸਲੇ ਮੁੜ-ਵਿੱਚਾਰੋ, ਪਹਿਲਾਂ ਨਹੀਂ।

ਇਕ ਹਕੀਕਤੀ ਉਦਾਹਰਨ: SaaS ship ਕਰਨਾ ਬਿਨਾਂ ਆਪਣੇ ਆਪ ਨੂੰ ਕੋਣ ਵਿੱਚ ਪਾਉਣ ਦੇ

ਸੋਚੋ ਇੱਕ 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), ਅਤੇ ਕਿਹੜੇ ਡਿਪੈਂਡਨਸੀਜ਼ ਸਭ ਤੋਂ ਜਿਆਦਾ ਯੋਗਦਾਨ ਪਾ ਰਹੇ ਹਨ। ਫਿਰ ਇੱਕ ਬੋਤਲਨੈਕ ਚੁਣੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਬਿਨਾਂ ਹੋਰ ਸਟੈਕ ਰੀ-ਰਾਈਟ ਕੀਤੇ ਸੁਧਾਰ ਸਕਦੇ ਹੋ।

ਇਸ ਹਫਤੇ ਲਈ, ਛੋਟੀ ਰੱਖੋ:

• ਇੱਕ ਬੇਸਲਾਈਨ ਮਾਪੋ: ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਸਲੇ route ਦੀ cold load ਅਤੇ ਇੱਕ ਆਮ ਕਾਰਵਾਈ।
• ਇੱਕ ਬਜਟ ਸੈੱਟ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਨੂੰ ਮਿਲਦਾ ਹੋਏ।
• ਇੱਕ ਬੋਤਲਨੈਕ ਫਿਕਸ ਕਰੋ (ਇੱਕ ਡਿਪੈਂਡੇੰਸੀ ਹਟਾਓ, route ਨੂੰ ਸਪਲਿਟ ਕਰੋ, ਇੱਕ ਭਾਰੀ ਕੰਪੋਨੈਂਟ lazy-load ਕਰੋ, ਗੈਰ-ਜ਼ਰੂਰੀ renders ਘਟਾਓ)।
• ਮੁੜ-ਮਾਪੋ ਅਤੇ ਲਿਖੋ ਕਿ ਕੀ ਬਦਲਿਆ।

ਚੋਣਾਂ ਨੂੰ ਵਾਪਸ-ਲੈਣਯੋਗ ਰੱਖਣ ਲਈ routes ਅਤੇ ਫੀਚਰਾਂ ਦਰਮਿਆਨ ਸਾਫ਼ ਸੀਮਾਵਾਂ ਖਿੱਚੋ। ਐਸੇ ਮਾਡਿਊਲਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਬਦਲ ਸਕੋ (charts, rich text editors, analytics SDKs) ਬਿਨਾਂ ਪੂਰੇ ਐਪ ਵਿੱਚ ਹੱਥ ਪਾਏ।