JavaScript ਫਰੇਮਵਰਕ ਦੀ ਕੀਮਤ

ਕਿਸੇ ਵੈਬਸਾਈਟ ਨੂੰ ਹੌਲੀ ਕਰਨ ਦਾ ਕੋਈ ਤੇਜ਼ ਤਰੀਕਾ ਨਹੀਂ ਹੈ (ਕੋਈ ਸ਼ਬਦ ਦਾ ਇਰਾਦਾ ਨਹੀਂ) ਇਸ 'ਤੇ ਜਾਵਾ ਸਕ੍ਰਿਪਟ ਕੋਡ ਦਾ ਇੱਕ ਸਮੂਹ ਚਲਾਉਣ ਨਾਲੋਂ। JavaScript ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਘੱਟੋ-ਘੱਟ ਚਾਰ ਵਾਰ ਪ੍ਰੋਜੈਕਟ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਇਸਦਾ ਭੁਗਤਾਨ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਇੱਥੇ ਇਹ ਹੈ ਕਿ ਸਾਈਟ ਦਾ JavaScript ਕੋਡ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਸਿਸਟਮਾਂ ਨੂੰ ਇਸ ਨਾਲ ਲੋਡ ਕਰਦਾ ਹੈ:

• ਨੈੱਟਵਰਕ ਉੱਤੇ ਇੱਕ ਫਾਈਲ ਅੱਪਲੋਡ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ।
• ਡਾਉਨਲੋਡ ਕਰਨ ਤੋਂ ਬਾਅਦ ਅਨਪੈਕ ਕੀਤੇ ਸਰੋਤ ਕੋਡ ਨੂੰ ਪਾਰਸ ਕਰਨਾ ਅਤੇ ਕੰਪਾਇਲ ਕਰਨਾ।
• JavaScript ਕੋਡ ਚਲਾਇਆ ਜਾ ਰਿਹਾ ਹੈ।
• ਮੈਮੋਰੀ ਦੀ ਖਪਤ.

ਇਹ ਸੁਮੇਲ ਨਿਕਲਦਾ ਹੈ ਬਹੁਤ ਮਹਿੰਗਾ.

ਅਤੇ ਅਸੀਂ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਵੱਧ ਤੋਂ ਵੱਧ JS ਕੋਡ ਸ਼ਾਮਲ ਕਰ ਰਹੇ ਹਾਂ। ਜਿਵੇਂ ਕਿ ਸੰਸਥਾਵਾਂ ਫਰੇਮਵਰਕ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੁਆਰਾ ਸੰਚਾਲਿਤ ਸਾਈਟਾਂ ਵੱਲ ਵਧਦੀਆਂ ਹਨ ਜਿਵੇਂ ਕਿ React, Vue ਅਤੇ ਹੋਰ, ਅਸੀਂ ਸਾਈਟਾਂ ਦੀ ਮੁੱਖ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ JavaScript 'ਤੇ ਬਹੁਤ ਨਿਰਭਰ ਬਣਾ ਰਹੇ ਹਾਂ।

ਮੈਂ JavaScript ਫਰੇਮਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਬਹੁਤ ਸਾਰੀਆਂ ਭਾਰੀ ਵੈਬਸਾਈਟਾਂ ਦੇਖੀਆਂ ਹਨ. ਪਰ ਇਸ ਮੁੱਦੇ ਬਾਰੇ ਮੇਰਾ ਨਜ਼ਰੀਆ ਬਹੁਤ ਪੱਖਪਾਤੀ ਹੈ। ਤੱਥ ਇਹ ਹੈ ਕਿ ਜਿਨ੍ਹਾਂ ਕੰਪਨੀਆਂ ਨਾਲ ਮੈਂ ਕੰਮ ਕਰਦਾ ਹਾਂ ਉਹ ਬਿਲਕੁਲ ਮੇਰੇ ਕੋਲ ਆਉਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹਨਾਂ ਕੋਲ ਗੁੰਝਲਦਾਰ ਵੈਬਸਾਈਟ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਹਨ. ਨਤੀਜੇ ਵਜੋਂ, ਮੈਂ ਇਹ ਜਾਣਨ ਲਈ ਉਤਸੁਕ ਹੋ ਗਿਆ ਕਿ ਇਹ ਸਮੱਸਿਆ ਕਿੰਨੀ ਵਿਆਪਕ ਹੈ, ਅਤੇ ਜਦੋਂ ਅਸੀਂ ਕਿਸੇ ਖਾਸ ਸਾਈਟ ਦੇ ਆਧਾਰ ਵਜੋਂ ਇੱਕ ਜਾਂ ਦੂਜੇ ਫਰੇਮਵਰਕ ਦੀ ਚੋਣ ਕਰਦੇ ਹਾਂ ਤਾਂ ਅਸੀਂ ਕਿਹੜੇ "ਜੁਰਮਾਨਾ" ਅਦਾ ਕਰਦੇ ਹਾਂ।

ਇਸ ਪ੍ਰੋਜੈਕਟ ਨੇ ਮੈਨੂੰ ਇਹ ਪਤਾ ਲਗਾਉਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ. HTTP ਪੁਰਾਲੇਖ.

ਡਾਟਾ

HTTP ਆਰਕਾਈਵ ਪ੍ਰੋਜੈਕਟ ਰੈਗੂਲਰ ਡੈਸਕਟੌਪ ਸਾਈਟਾਂ ਦੇ ਕੁੱਲ 4308655 ਲਿੰਕ ਅਤੇ ਮੋਬਾਈਲ ਸਾਈਟਾਂ ਦੇ 5484239 ਲਿੰਕਾਂ ਨੂੰ ਟਰੈਕ ਕਰਦਾ ਹੈ। ਇਹਨਾਂ ਲਿੰਕਾਂ ਨਾਲ ਜੁੜੇ ਬਹੁਤ ਸਾਰੇ ਸੂਚਕਾਂ ਵਿੱਚੋਂ ਸੰਬੰਧਿਤ ਸਾਈਟਾਂ 'ਤੇ ਪਾਈਆਂ ਗਈਆਂ ਤਕਨਾਲੋਜੀਆਂ ਦੀ ਸੂਚੀ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਹਜ਼ਾਰਾਂ ਸਾਈਟਾਂ ਦਾ ਨਮੂਨਾ ਲੈ ਸਕਦੇ ਹਾਂ ਜੋ ਵੱਖੋ-ਵੱਖਰੇ ਫਰੇਮਵਰਕ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਇਹ ਸਿੱਖ ਸਕਦੀਆਂ ਹਨ ਕਿ ਉਹ ਗਾਹਕਾਂ ਨੂੰ ਕਿੰਨਾ ਕੋਡ ਭੇਜਦੇ ਹਨ ਅਤੇ ਉਹ ਕੋਡ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਸਿਸਟਮਾਂ 'ਤੇ ਕਿੰਨਾ ਲੋਡ ਪਾਉਂਦਾ ਹੈ।

ਮੈਂ ਮਾਰਚ 2020 ਤੋਂ ਡਾਟਾ ਇਕੱਠਾ ਕੀਤਾ, ਜੋ ਸਭ ਤੋਂ ਤਾਜ਼ਾ ਡਾਟਾ ਸੀ ਜਿਸ ਤੱਕ ਮੇਰੀ ਪਹੁੰਚ ਸੀ।

ਮੈਂ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਲਈ ਐਗਰੀਗੇਟਿਡ HTTP ਆਰਕਾਈਵ ਡੇਟਾ ਦੀ ਤੁਲਨਾ ਰੀਐਕਟ, ਵਿਊ, ਅਤੇ ਐਂਗੁਲਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀਆਂ ਸਾਈਟਾਂ ਦੇ ਡੇਟਾ ਨਾਲ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਹਾਲਾਂਕਿ ਮੈਂ ਹੋਰ ਸਰੋਤ ਸਮੱਗਰੀ ਦੀ ਵਰਤੋਂ ਕਰਨ 'ਤੇ ਵੀ ਵਿਚਾਰ ਕੀਤਾ ਹੈ।

ਇਸ ਨੂੰ ਹੋਰ ਦਿਲਚਸਪ ਬਣਾਉਣ ਲਈ, ਮੈਂ ਉਹਨਾਂ ਸਾਈਟਾਂ ਨੂੰ ਵੀ ਜੋੜਿਆ ਹੈ ਜੋ ਸਰੋਤ ਡੇਟਾ ਸੈੱਟ ਵਿੱਚ jQuery ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ. ਇਹ ਲਾਇਬ੍ਰੇਰੀ ਅੱਜ ਵੀ ਬਹੁਤ ਮਸ਼ਹੂਰ ਹੈ। ਇਹ ਵੈਬਸਾਈਟ ਡਿਵੈਲਪਮੈਂਟ ਲਈ ਇੱਕ ਪਹੁੰਚ ਵੀ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਜੋ ਪ੍ਰਤੀਕਿਰਿਆ, Vue ਅਤੇ Angular ਦੁਆਰਾ ਪੇਸ਼ ਕੀਤੇ ਸਿੰਗਲ ਪੇਜ ਐਪਲੀਕੇਸ਼ਨ (SPA) ਮਾਡਲ ਤੋਂ ਵੱਖਰਾ ਹੈ।

HTTP ਆਰਕਾਈਵ ਵਿੱਚ ਲਿੰਕ ਉਹਨਾਂ ਸਾਈਟਾਂ ਦੀ ਨੁਮਾਇੰਦਗੀ ਕਰਦੇ ਹਨ ਜੋ ਸਾਡੇ ਲਈ ਦਿਲਚਸਪੀ ਵਾਲੀਆਂ ਤਕਨਾਲੋਜੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਪਾਈਆਂ ਗਈਆਂ ਹਨ

ਫਰੇਮਵਰਕ ਜਾਂ ਲਾਇਬ੍ਰੇਰੀ
ਮੋਬਾਈਲ ਸਾਈਟਾਂ ਦੇ ਲਿੰਕ
ਨਿਯਮਤ ਸਾਈਟਾਂ ਦੇ ਲਿੰਕ

ਜੇਕਉਐਰੀ
4615474
3714643

ਪ੍ਰਤੀਕਿਰਿਆ
489827
241023

ਵੀ
85649
43691

angular
19423
18088

ਉਮੀਦਾਂ ਅਤੇ ਸੁਪਨੇ

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

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

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

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

ਡੇਟਾ ਦੇ ਮੱਧਮ ਮੁੱਲਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਨਾਲ ਸਾਨੂੰ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਨਹੀਂ ਮਿਲੇਗੀ। ਅਤੇ, ਅਸਲ ਵਿੱਚ, ਇਹ ਪਹੁੰਚ ਸਾਡੇ ਧਿਆਨ ਤੋਂ ਪਰੇ ਹੈ ਬਹੁਤ ਸਾਰੀਆਂ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ਾਂ. ਇਸਦੀ ਬਜਾਏ, ਮੈਂ ਮੇਰੇ ਕੋਲ ਮੌਜੂਦ ਡੇਟਾ ਤੋਂ ਪ੍ਰਤੀਸ਼ਤ ਅੰਕ ਪ੍ਰਾਪਤ ਕੀਤੇ। ਇਹ 10, 25, 50 (ਮੀਡੀਅਨ), 75, 90 ਪ੍ਰਤੀਸ਼ਤ ਹਨ।

ਮੈਨੂੰ 10ਵੇਂ ਅਤੇ 90ਵੇਂ ਪਰਸੈਂਟਾਈਲ ਵਿੱਚ ਖਾਸ ਤੌਰ 'ਤੇ ਦਿਲਚਸਪੀ ਹੈ। 10ਵਾਂ ਪਰਸੈਂਟਾਈਲ ਕਿਸੇ ਖਾਸ ਫਰੇਮਵਰਕ ਲਈ ਸਰਵੋਤਮ ਪ੍ਰਦਰਸ਼ਨ (ਜਾਂ ਘੱਟੋ-ਘੱਟ ਵੱਧ ਜਾਂ ਘੱਟ ਵਧੀਆ ਦੇ ਨੇੜੇ) ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਇੱਕ ਖਾਸ ਫਰੇਮਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀਆਂ ਸਾਈਟਾਂ ਵਿੱਚੋਂ ਸਿਰਫ 10% ਇਸ ਪੱਧਰ, ਜਾਂ ਇੱਕ ਉੱਚ ਪੱਧਰ ਤੱਕ ਪਹੁੰਚਦੀਆਂ ਹਨ। ਦੂਜੇ ਪਾਸੇ, 90ਵਾਂ ਪ੍ਰਤੀਸ਼ਤ ਸਿੱਕੇ ਦਾ ਦੂਜਾ ਪਾਸਾ ਹੈ - ਇਹ ਸਾਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਚੀਜ਼ਾਂ ਕਿੰਨੀਆਂ ਮਾੜੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। 90ਵਾਂ ਪਰਸੈਂਟਾਈਲ ਟ੍ਰੇਲਿੰਗ ਸਾਈਟਾਂ ਹਨ—ਉਹ ਆਖਰੀ 10% ਸਾਈਟਾਂ ਜਿਹਨਾਂ ਕੋਲ JS ਕੋਡ ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਮਾਤਰਾ ਹੈ ਜਾਂ ਉਹਨਾਂ ਦੇ ਕੋਡ ਨੂੰ ਮੁੱਖ ਥ੍ਰੈੱਡ 'ਤੇ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਲੰਬਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ।

JavaScript ਕੋਡ ਦੀ ਮਾਤਰਾ

ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਨੈੱਟਵਰਕ ਉੱਤੇ ਵੱਖ-ਵੱਖ ਸਾਈਟਾਂ ਦੁਆਰਾ ਪ੍ਰਸਾਰਿਤ ਕੀਤੇ ਜਾਵਾ ਸਕ੍ਰਿਪਟ ਕੋਡ ਦੇ ਆਕਾਰ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨਾ ਸਮਝਦਾਰ ਹੈ।

JavaScript ਕੋਡ (KB) ਦੀ ਮਾਤਰਾ ਮੋਬਾਈਲ ਡੀਵਾਈਸਾਂ 'ਤੇ ਟ੍ਰਾਂਸਫ਼ਰ ਕੀਤੀ ਗਈ

ਪ੍ਰਤੀਸ਼ਤ
10
25
50
75
90

ਸਾਰੀਆਂ ਸਾਈਟਾਂ
93.4 
196.6 
413.5 
746.8 
1201.6 

jQuery ਸਾਈਟਾਂ
110.3 
219.8 
430.4 
748.6 
1162.3 

Vue ਵੈੱਬਸਾਈਟਾਂ
244.7 
409.3 
692.1 
1065.5 
1570.7 

ਐਂਗੁਲਰ ਵੈੱਬਸਾਈਟਾਂ
445.1 
675.6 
1066.4 
1761.5 
2893.2 

ਵੈੱਬਸਾਈਟਾਂ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰੋ
345.8 
441.6 
690.3 
1238.5 
1893.6 

ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ ਨੂੰ ਭੇਜੇ ਗਏ JavaScript ਕੋਡ ਦੀ ਮਾਤਰਾ

JavaScript ਕੋਡ (KB) ਦੀ ਮਾਤਰਾ ਡੈਸਕਟੌਪ ਡਿਵਾਈਸਾਂ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕੀਤੀ ਗਈ

ਪ੍ਰਤੀਸ਼ਤ
10
25
50
75
90

ਸਾਰੀਆਂ ਸਾਈਟਾਂ
105.5 
226.6 
450.4 
808.8 
1267.3 

jQuery ਸਾਈਟਾਂ
121.7 
242.2 
458.3 
803.4 
1235.3 

Vue ਵੈੱਬਸਾਈਟਾਂ
248.0 
420.1 
718.0 
1122.5 
1643.1 

ਐਂਗੁਲਰ ਵੈੱਬਸਾਈਟਾਂ
468.8 
716.9 
1144.2 
1930.0 
3283.1 

ਵੈੱਬਸਾਈਟਾਂ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰੋ
308.6 
469.0 
841.9 
1472.2 
2197.8 

JavaScript ਕੋਡ ਦੀ ਮਾਤਰਾ ਡੈਸਕਟੌਪ ਡਿਵਾਈਸਾਂ 'ਤੇ ਟ੍ਰਾਂਸਫਰ ਕੀਤੀ ਗਈ

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

ਇਸ ਡੇਟਾ ਬਾਰੇ ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ ਕੁਝ ਫਰੇਮਵਰਕ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਕਿਸੇ ਪ੍ਰੋਜੈਕਟ ਲਈ ਦੂਜਿਆਂ ਨਾਲੋਂ ਬਿਹਤਰ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ। jQuery ਵਾਲੀਆਂ ਵੈੱਬਸਾਈਟਾਂ ਵਧੀਆ ਲੱਗਦੀਆਂ ਹਨ। ਉਹਨਾਂ ਦੀਆਂ ਡੈਸਕਟੌਪ ਸਾਈਟਾਂ ਵਿੱਚ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਨਾਲੋਂ 15% ਵੱਧ JavaScript ਸ਼ਾਮਲ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਮੋਬਾਈਲ ਸਾਈਟਾਂ ਵਿੱਚ 18% ਵਧੇਰੇ JavaScript ਸ਼ਾਮਲ ਹਨ। (ਸੱਚਮੁੱਚ, ਇੱਥੇ ਡੇਟਾ ਵਿੱਚ ਕੁਝ ਤਿੱਖਾ ਹੈ। ਤੱਥ ਇਹ ਹੈ ਕਿ jQuery ਬਹੁਤ ਸਾਰੀਆਂ ਸਾਈਟਾਂ 'ਤੇ ਮੌਜੂਦ ਹੈ, ਇਸ ਲਈ ਇਹ ਸੁਭਾਵਕ ਹੈ ਕਿ ਅਜਿਹੀਆਂ ਸਾਈਟਾਂ ਹੋਰਾਂ ਨਾਲੋਂ ਸਾਈਟਾਂ ਦੀ ਕੁੱਲ ਸੰਖਿਆ ਨਾਲ ਵਧੇਰੇ ਨੇੜਿਓਂ ਸਬੰਧਤ ਹਨ। ਹਾਲਾਂਕਿ, ਇਹ ਇਸ ਗੱਲ ਨੂੰ ਪ੍ਰਭਾਵਤ ਨਹੀਂ ਕਰਦਾ ਹੈ ਕਿ ਕਿਵੇਂ. ਸਰੋਤ ਡੇਟਾ ਹਰੇਕ ਫਰੇਮਵਰਕ ਲਈ ਆਉਟਪੁੱਟ ਹੈ।)

ਜਦੋਂ ਕਿ 15-18% ਕੋਡ ਵਾਧਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਅੰਕੜਾ ਹੈ, ਜਦੋਂ ਹੋਰ ਫਰੇਮਵਰਕ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਤੁਲਨਾ ਵਿੱਚ, jQuery ਦੁਆਰਾ ਲਗਾਇਆ ਗਿਆ ਟੈਕਸ ਬਹੁਤ ਘੱਟ ਹੈ। 10ਵੇਂ ਪਰਸੈਂਟਾਈਲ ਵਿੱਚ ਐਂਗੁਲਰ ਸਾਈਟਾਂ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਨਾਲੋਂ ਡੈਸਕਟੌਪ ਡਿਵਾਈਸਾਂ ਨੂੰ 344% ਜ਼ਿਆਦਾ ਡਾਟਾ ਭੇਜਦੀਆਂ ਹਨ, ਅਤੇ ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ ਲਈ 377% ਜ਼ਿਆਦਾ। ਰੀਐਕਟ ਸਾਈਟਾਂ ਅਗਲੀਆਂ ਸਭ ਤੋਂ ਭਾਰੀਆਂ ਹਨ, ਜੋ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਨਾਲੋਂ ਡੈਸਕਟੌਪ ਡੀਵਾਈਸਾਂ 'ਤੇ 193% ਜ਼ਿਆਦਾ ਕੋਡ ਭੇਜਦੀਆਂ ਹਨ, ਅਤੇ ਮੋਬਾਈਲ ਡੀਵਾਈਸਾਂ 'ਤੇ 270% ਜ਼ਿਆਦਾ।

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

ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ jQuery ਸਾਈਟਾਂ ਇਸ ਵਿਚਾਰ ਦੀ ਪਾਲਣਾ ਕਰਦੀਆਂ ਹਨ. ਹਾਲਾਂਕਿ ਉਹ, 10ਵੇਂ ਪਰਸੈਂਟਾਈਲ ਪੱਧਰ 'ਤੇ, ਸਾਰੀਆਂ ਸਾਈਟਾਂ (15-18% ਦੁਆਰਾ) ਨਾਲੋਂ ਥੋੜ੍ਹਾ ਭਾਰੇ ਹਨ, ਉਹ, 90ਵੇਂ ਪਰਸੈਂਟਾਈਲ ਪੱਧਰ 'ਤੇ, ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਨਾਲੋਂ ਥੋੜੇ ਹਲਕੇ ਹਨ - ਡੈਸਕਟੌਪ ਅਤੇ ਮੋਬਾਈਲ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਲਗਭਗ 3% ਦੁਆਰਾ। ਇਹ ਕਹਿਣ ਦਾ ਮਤਲਬ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਇੱਕ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਲਾਭ ਹੈ, ਪਰ ਇਹ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ ਕਿ jQuery ਸਾਈਟਾਂ ਵਿੱਚ ਘੱਟੋ ਘੱਟ ਉਹਨਾਂ ਦੇ ਸਭ ਤੋਂ ਵੱਡੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਵੀ ਜਾਵਾਸਕ੍ਰਿਪਟ ਕੋਡ ਦੇ ਆਕਾਰ ਨਹੀਂ ਹੁੰਦੇ ਹਨ.

ਪਰ ਦੂਜੇ ਢਾਂਚੇ ਬਾਰੇ ਵੀ ਇਹੀ ਨਹੀਂ ਕਿਹਾ ਜਾ ਸਕਦਾ।

ਜਿਵੇਂ ਕਿ 10ਵੇਂ ਪਰਸੈਂਟਾਈਲ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਐਂਗੁਲਰ ਅਤੇ ਰੀਐਕਟ 'ਤੇ 90ਵੇਂ ਪਰਸੈਂਟਾਈਲ ਸਾਈਟਾਂ 'ਤੇ ਦੂਜੀਆਂ ਸਾਈਟਾਂ ਨਾਲੋਂ ਵੱਖਰੀਆਂ ਹਨ, ਪਰ ਬਦਕਿਸਮਤੀ ਨਾਲ, ਬਦਕਿਸਮਤੀ ਨਾਲ, ਉਹ ਵੱਖਰੀਆਂ ਹਨ।

90ਵੇਂ ਪ੍ਰਤੀਸ਼ਤ 'ਤੇ, ਐਂਗੁਲਰ ਸਾਈਟਾਂ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਨਾਲੋਂ ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ ਨੂੰ 141% ਜ਼ਿਆਦਾ ਡਾਟਾ ਭੇਜਦੀਆਂ ਹਨ, ਅਤੇ ਡੈਸਕਟੌਪ ਡਿਵਾਈਸਾਂ ਨੂੰ 159% ਜ਼ਿਆਦਾ। ਰੀਐਕਟ ਸਾਈਟਾਂ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਨਾਲੋਂ ਡੈਸਕਟੌਪ ਡੀਵਾਈਸਾਂ 'ਤੇ 73% ਜ਼ਿਆਦਾ, ਅਤੇ ਮੋਬਾਈਲ ਡੀਵਾਈਸਾਂ 'ਤੇ 58% ਜ਼ਿਆਦਾ ਭੇਜਦੀਆਂ ਹਨ। 90ਵੇਂ ਪਰਸੈਂਟਾਈਲ 'ਤੇ ਰੀਐਕਟ ਸਾਈਟਾਂ ਦਾ ਕੋਡ ਆਕਾਰ 2197.8 KB ਹੈ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਇਹ ਸਾਈਟਾਂ ਆਪਣੇ ਨਜ਼ਦੀਕੀ Vue-ਅਧਾਰਿਤ ਪ੍ਰਤੀਯੋਗੀਆਂ ਨਾਲੋਂ ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ ਨੂੰ 322.9 KB ਵਧੇਰੇ ਡੇਟਾ ਭੇਜਦੀਆਂ ਹਨ। ਐਂਗੁਲਰ ਅਤੇ ਰੀਐਕਟ ਅਤੇ ਹੋਰ ਸਾਈਟਾਂ 'ਤੇ ਆਧਾਰਿਤ ਡੈਸਕਟੌਪ ਸਾਈਟਾਂ ਵਿਚਕਾਰ ਪਾੜਾ ਹੋਰ ਵੀ ਜ਼ਿਆਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, React ਡੈਸਕਟਾਪ ਸਾਈਟਾਂ ਸਮਾਨ Vue ਸਾਈਟਾਂ ਨਾਲੋਂ ਡਿਵਾਈਸਾਂ ਨੂੰ 554.7 KB ਜ਼ਿਆਦਾ JS ਕੋਡ ਭੇਜਦੀਆਂ ਹਨ।

ਮੁੱਖ ਥ੍ਰੈੱਡ 'ਤੇ JavaScript ਕੋਡ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਲਈ ਸਮਾਂ ਲੱਗਾ

ਉਪਰੋਕਤ ਡੇਟਾ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਅਧਿਐਨ ਕੀਤੇ ਗਏ ਫਰੇਮਵਰਕ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀਆਂ ਸਾਈਟਾਂ ਵਿੱਚ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ JavaScript ਕੋਡ ਸ਼ਾਮਲ ਹਨ। ਪਰ, ਬੇਸ਼ੱਕ, ਇਹ ਸਾਡੇ ਸਮੀਕਰਨ ਦਾ ਸਿਰਫ ਇੱਕ ਹਿੱਸਾ ਹੈ।

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

HTTP ਆਰਕਾਈਵ ਡੇਟਾਬੇਸ ਵਿੱਚ V8 ਇੰਜਣ ਦੇ ਮੁੱਖ ਥ੍ਰੈਡ 'ਤੇ JavaScript ਕੋਡ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਸ਼ਾਮਲ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਇਸ ਡੇਟਾ ਨੂੰ ਇਕੱਠਾ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ ਸਿੱਖ ਸਕਦੇ ਹਾਂ ਕਿ ਮੁੱਖ ਥ੍ਰੈਡ ਵੱਖ-ਵੱਖ ਸਾਈਟਾਂ ਦੀ ਜਾਵਾਸਕ੍ਰਿਪਟ ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਲੈਂਦਾ ਹੈ।

ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ 'ਤੇ ਸਕ੍ਰਿਪਟ ਪ੍ਰੋਸੈਸਿੰਗ ਨਾਲ ਸਬੰਧਤ CPU ਸਮਾਂ (ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ)

ਪ੍ਰਤੀਸ਼ਤ
10
25
50
75
90

ਸਾਰੀਆਂ ਸਾਈਟਾਂ
356.4
959.7
2372.1
5367.3
10485.8

jQuery ਸਾਈਟਾਂ
575.3
1147.4
2555.9
5511.0
10349.4

Vue ਵੈੱਬਸਾਈਟਾਂ
1130.0
2087.9
4100.4
7676.1
12849.4

ਐਂਗੁਲਰ ਵੈੱਬਸਾਈਟਾਂ
1471.3
2380.1
4118.6
7450.8
13296.4

ਵੈੱਬਸਾਈਟਾਂ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰੋ
2700.1
5090.3
9287.6
14509.6
20813.3

ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ 'ਤੇ ਸਕ੍ਰਿਪਟ ਪ੍ਰੋਸੈਸਿੰਗ ਨਾਲ ਸਬੰਧਤ CPU ਸਮਾਂ

ਡੈਸਕਟੌਪ ਡਿਵਾਈਸਾਂ 'ਤੇ ਸਕ੍ਰਿਪਟ ਪ੍ਰੋਸੈਸਿੰਗ ਨਾਲ ਸੰਬੰਧਿਤ CPU ਸਮਾਂ (ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ)

ਪ੍ਰਤੀਸ਼ਤ
10
25
50
75
90

ਸਾਰੀਆਂ ਸਾਈਟਾਂ
146.0
351.8
831.0
1739.8
3236.8

jQuery ਸਾਈਟਾਂ
199.6
399.2
877.5
1779.9
3215.5

Vue ਵੈੱਬਸਾਈਟਾਂ
350.4
650.8
1280.7
2388.5
4010.8

ਐਂਗੁਲਰ ਵੈੱਬਸਾਈਟਾਂ
482.2
777.9
1365.5
2400.6
4171.8

ਵੈੱਬਸਾਈਟਾਂ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰੋ
508.0
1045.6
2121.1
4235.1
7444.3

ਡੈਸਕਟੌਪ ਡਿਵਾਈਸਾਂ 'ਤੇ ਸਕ੍ਰਿਪਟ ਪ੍ਰੋਸੈਸਿੰਗ ਨਾਲ ਸੰਬੰਧਿਤ CPU ਸਮਾਂ

ਇੱਥੇ ਤੁਸੀਂ ਕੁਝ ਬਹੁਤ ਜਾਣੂ ਦੇਖ ਸਕਦੇ ਹੋ।

ਸ਼ੁਰੂਆਤ ਕਰਨ ਵਾਲਿਆਂ ਲਈ, jQuery ਵਾਲੀਆਂ ਸਾਈਟਾਂ ਦੂਜਿਆਂ ਨਾਲੋਂ ਮੁੱਖ ਥ੍ਰੈਡ 'ਤੇ JavaScript ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਵਿੱਚ ਕਾਫ਼ੀ ਘੱਟ ਖਰਚ ਕਰਦੀਆਂ ਹਨ। 10ਵੇਂ ਪ੍ਰਤੀਸ਼ਤ 'ਤੇ, ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਦੇ ਮੁਕਾਬਲੇ, ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ 'ਤੇ jQuery ਸਾਈਟਾਂ ਮੁੱਖ ਥ੍ਰੈੱਡ 'ਤੇ JS ਕੋਡ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਵਿੱਚ 61% ਜ਼ਿਆਦਾ ਸਮਾਂ ਬਿਤਾਉਂਦੀਆਂ ਹਨ। ਡੈਸਕਟੌਪ jQuery ਸਾਈਟਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਪ੍ਰੋਸੈਸਿੰਗ ਸਮਾਂ 37% ਵਧਦਾ ਹੈ। 90ਵੇਂ ਪ੍ਰਤੀਸ਼ਤ 'ਤੇ, jQuery ਸਾਈਟਾਂ ਦੇ ਸਕੋਰ ਕੁੱਲ ਸਕੋਰਾਂ ਦੇ ਬਹੁਤ ਨੇੜੇ ਹਨ। ਖਾਸ ਤੌਰ 'ਤੇ, ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ 'ਤੇ jQuery ਸਾਈਟਾਂ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਨਾਲੋਂ ਮੁੱਖ ਥ੍ਰੈਡ ਵਿੱਚ 1.3% ਘੱਟ ਸਮਾਂ ਬਿਤਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਡੈਸਕਟੌਪ ਡਿਵਾਈਸਾਂ 'ਤੇ ਉਹ ਮੁੱਖ ਥ੍ਰੈਡ ਵਿੱਚ 0.7% ਘੱਟ ਸਮਾਂ ਬਿਤਾਉਂਦੀਆਂ ਹਨ।

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

10ਵੇਂ ਪਰਸੈਂਟਾਈਲ 'ਤੇ, ਐਂਗੁਲਰ ਡੈਸਕਟੌਪ ਸਾਈਟਾਂ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਨਾਲੋਂ JS ਕੋਡ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਲਈ 230% ਜ਼ਿਆਦਾ ਮੁੱਖ ਥ੍ਰੈਡ ਟਾਈਮ ਖਰਚ ਕਰਦੀਆਂ ਹਨ। ਮੋਬਾਈਲ ਸਾਈਟਾਂ ਲਈ ਇਹ ਅੰਕੜਾ 313% ਹੈ। ਪ੍ਰਤੀਕਿਰਿਆ ਸਾਈਟਾਂ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਸਭ ਤੋਂ ਮਾੜਾ ਹੈ। ਡੈਸਕਟੌਪ ਡਿਵਾਈਸਾਂ 'ਤੇ ਉਹ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਨਾਲੋਂ 248% ਜ਼ਿਆਦਾ ਸਮਾਂ ਕੋਡ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਵਿੱਚ ਖਰਚ ਕਰਦੇ ਹਨ, ਅਤੇ ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ 'ਤੇ ਉਹ ਕੋਡ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਵਿੱਚ 658% ਜ਼ਿਆਦਾ ਸਮਾਂ ਬਿਤਾਉਂਦੇ ਹਨ। 658% ਕੋਈ ਟਾਈਪੋ ਨਹੀਂ ਹੈ। 10ਵੇਂ ਪ੍ਰਤੀਸ਼ਤ 'ਤੇ, ਰੀਐਕਟ ਸਾਈਟਾਂ ਆਪਣੇ ਮੌਜੂਦਾ ਕੋਡ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਲਈ ਮੁੱਖ ਥ੍ਰੈਡ ਟਾਈਮ ਦੇ 2.7 ਸਕਿੰਟ ਖਰਚ ਕਰਦੀਆਂ ਹਨ।

ਇਹਨਾਂ ਵੱਡੀਆਂ ਸੰਖਿਆਵਾਂ ਦੀ ਤੁਲਨਾ ਵਿੱਚ 90ਵੇਂ ਪਰਸੈਂਟਾਈਲ ਨੰਬਰ ਘੱਟੋ-ਘੱਟ ਥੋੜੇ ਬਿਹਤਰ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਦੇ ਮੁਕਾਬਲੇ, ਐਂਗੁਲਰ ਪ੍ਰੋਜੈਕਟ, ਡੈਸਕਟੌਪ ਡਿਵਾਈਸਾਂ 'ਤੇ ਮੁੱਖ ਥ੍ਰੈਡ ਵਿੱਚ 29% ਹੋਰ ਸਮਾਂ ਬਿਤਾਉਂਦੇ ਹਨ, ਅਤੇ ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ 'ਤੇ 27% ਹੋਰ ਸਮਾਂ ਬਿਤਾਉਂਦੇ ਹਨ। ਰੀਐਕਟ ਸਾਈਟਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਸਮਾਨ ਸੂਚਕ ਕ੍ਰਮਵਾਰ 130% ਅਤੇ 98% ਵਰਗੇ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ।

90ਵੇਂ ਪ੍ਰਤੀਸ਼ਤ ਲਈ ਭਟਕਣ ਪ੍ਰਤੀਸ਼ਤ 10ਵੇਂ ਪ੍ਰਤੀਸ਼ਤ ਦੇ ਸਮਾਨ ਮੁੱਲਾਂ ਨਾਲੋਂ ਬਿਹਤਰ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। ਪਰ ਇੱਥੇ ਇਹ ਯਾਦ ਰੱਖਣ ਯੋਗ ਹੈ ਕਿ ਸਮੇਂ ਨੂੰ ਦਰਸਾਉਣ ਵਾਲੇ ਨੰਬਰ ਕਾਫ਼ੀ ਡਰਾਉਣੇ ਲੱਗਦੇ ਹਨ. ਦੱਸ ਦੇਈਏ - React 'ਤੇ ਬਣੀ ਸਾਈਟ ਲਈ ਮੋਬਾਈਲ ਡਿਵਾਈਸ ਦੇ ਮੁੱਖ ਥ੍ਰੈਡ ਵਿੱਚ 20.8 ਸਕਿੰਟ। (ਮੇਰਾ ਮੰਨਣਾ ਹੈ ਕਿ ਇਸ ਸਮੇਂ ਦੌਰਾਨ ਅਸਲ ਵਿੱਚ ਕੀ ਵਾਪਰਦਾ ਹੈ ਦੀ ਕਹਾਣੀ ਇੱਕ ਵੱਖਰੇ ਲੇਖ ਦੇ ਯੋਗ ਹੈ)।

ਇੱਥੇ ਇੱਕ ਸੰਭਾਵੀ ਪੇਚੀਦਗੀ ਹੈ (ਧੰਨਵਾਦ ਯਿਰਮਿਯਾਹ ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਵੱਲ ਮੇਰਾ ਧਿਆਨ ਖਿੱਚਣ ਲਈ, ਅਤੇ ਇਸ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਡੇਟਾ ਦੀ ਧਿਆਨ ਨਾਲ ਜਾਂਚ ਕਰਨ ਲਈ)। ਤੱਥ ਇਹ ਹੈ ਕਿ ਬਹੁਤ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਕਈ ਫਰੰਟ-ਐਂਡ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ. ਖਾਸ ਤੌਰ 'ਤੇ, ਮੈਂ ਬਹੁਤ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਨੂੰ React ਜਾਂ Vue ਦੇ ਨਾਲ jQuery ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਦੇਖਿਆ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਾਈਟਾਂ jQuery ਤੋਂ ਦੂਜੇ ਫਰੇਮਵਰਕ ਜਾਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚ ਮਾਈਗਰੇਟ ਹੁੰਦੀਆਂ ਹਨ। ਨਤੀਜੇ ਵਜੋਂ, ਮੈਂ ਡਾਟਾਬੇਸ ਤੇ ਵਾਪਸ ਚਲਾ ਗਿਆ, ਇਸ ਵਾਰ ਸਿਰਫ ਉਹਨਾਂ ਲਿੰਕਾਂ ਦੀ ਚੋਣ ਕੀਤੀ ਜੋ ਉਹਨਾਂ ਸਾਈਟਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ ਜੋ ਸਿਰਫ React, jQuery, Angular ਜਾਂ Vue ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ, ਪਰ ਉਹਨਾਂ ਦਾ ਕੋਈ ਸੁਮੇਲ ਨਹੀਂ. ਇੱਥੇ ਮੈਨੂੰ ਕੀ ਮਿਲਿਆ ਹੈ.

ਪ੍ਰੋਸੈਸਰ ਸਮਾਂ (ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ) ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਜਿੱਥੇ ਸਾਈਟਾਂ ਸਿਰਫ਼ ਇੱਕ ਫਰੇਮਵਰਕ ਜਾਂ ਸਿਰਫ਼ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ, ਮੋਬਾਈਲ ਡੀਵਾਈਸਾਂ 'ਤੇ ਸਕ੍ਰਿਪਟ ਪ੍ਰੋਸੈਸਿੰਗ ਨਾਲ ਸਬੰਧਿਤ

ਪ੍ਰਤੀਸ਼ਤ
10
25
50
75
90

ਸਾਈਟਾਂ ਜੋ ਸਿਰਫ਼ jQuery ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ
542.9
1062.2
2297.4
4769.7
8718.2

ਸਾਈਟਾਂ ਜੋ ਸਿਰਫ਼ Vue ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ
944.0
1716.3
3194.7
5959.6
9843.8

ਸਾਈਟਾਂ ਜੋ ਸਿਰਫ਼ ਐਂਗੁਲਰ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ
1328.9
2151.9
3695.3
6629.3
11607.7

ਵੈੱਬਸਾਈਟਾਂ ਜੋ ਸਿਰਫ਼ React ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ
2443.2
4620.5
10061.4
17074.3
24956.3

ਮੋਬਾਈਲ ਡਿਵਾਈਸਿਸ 'ਤੇ ਪ੍ਰੋਸੈਸਿੰਗ ਸਕ੍ਰਿਪਟਾਂ ਨਾਲ ਸਬੰਧਤ ਪ੍ਰੋਸੈਸਰ ਸਮਾਂ ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ ਜਿੱਥੇ ਸਾਈਟਾਂ ਸਿਰਫ ਇੱਕ ਫਰੇਮਵਰਕ, ਜਾਂ ਸਿਰਫ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਕੁਝ ਅਜਿਹਾ ਜੋ ਹੈਰਾਨੀਜਨਕ ਨਹੀਂ ਹੈ: ਜਦੋਂ ਕੋਈ ਸਾਈਟ ਸਿਰਫ਼ ਇੱਕ ਫਰੇਮਵਰਕ ਜਾਂ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ, ਤਾਂ ਅਜਿਹੀ ਸਾਈਟ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਸੁਧਾਰ ਅਕਸਰ ਨਹੀਂ ਹੁੰਦਾ. ਹਰੇਕ ਸਾਧਨ ਲਈ ਪ੍ਰਦਰਸ਼ਨ 10ਵੇਂ ਅਤੇ 25ਵੇਂ ਪਰਸੈਂਟਾਈਲ 'ਤੇ ਬਿਹਤਰ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਇਹ ਅਰਥ ਰੱਖਦਾ ਹੈ. ਇੱਕ ਸਾਈਟ ਜੋ ਇੱਕ ਫਰੇਮਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਣਾਈ ਗਈ ਹੈ, ਇੱਕ ਸਾਈਟ ਨਾਲੋਂ ਤੇਜ਼ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਦੋ ਜਾਂ ਦੋ ਤੋਂ ਵੱਧ ਫਰੇਮਵਰਕ ਜਾਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਣਾਈ ਗਈ ਹੈ।

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

ਇਹ ਥੋੜਾ ਅਜੀਬ ਹੈ, ਪਰ ਮੈਂ ਅਜੇ ਵੀ ਇਸ ਅਜੀਬਤਾ ਲਈ ਸਪੱਸ਼ਟੀਕਰਨ ਲੱਭਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗਾ.

ਜੇਕਰ ਕੋਈ ਪ੍ਰੋਜੈਕਟ React ਅਤੇ jQuery ਦੋਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹ ਪ੍ਰੋਜੈਕਟ jQuery ਤੋਂ React ਵਿੱਚ ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਕਿਤੇ ਅੱਧਾ ਰਹਿ ਜਾਂਦਾ ਹੈ। ਸ਼ਾਇਦ ਉਸ ਕੋਲ ਇੱਕ ਕੋਡਬੇਸ ਹੈ ਜਿਸ ਵਿੱਚ ਇਹ ਲਾਇਬ੍ਰੇਰੀਆਂ ਮਿਲੀਆਂ ਹੋਈਆਂ ਹਨ। ਕਿਉਂਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਦੇਖਿਆ ਹੈ ਕਿ jQuery ਸਾਈਟਾਂ ਰੀਐਕਟ ਸਾਈਟਾਂ ਨਾਲੋਂ ਮੁੱਖ ਥ੍ਰੈਡ 'ਤੇ ਘੱਟ ਸਮਾਂ ਬਿਤਾਉਂਦੀਆਂ ਹਨ, ਇਹ ਸਾਨੂੰ ਦੱਸ ਸਕਦਾ ਹੈ ਕਿ jQuery ਵਿੱਚ ਕੁਝ ਕਾਰਜਕੁਸ਼ਲਤਾ ਲਾਗੂ ਕਰਨ ਨਾਲ ਸਾਈਟ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਥੋੜਾ ਜਿਹਾ ਬਿਹਤਰ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਮਿਲਦੀ ਹੈ।

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

ਮੋਬਾਈਲ ਅਤੇ ਡੈਸਕਟਾਪ ਡਿਵਾਈਸਾਂ ਵਿਚਕਾਰ ਅੰਤਰ

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

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

ਡੈਸਕਟੌਪ ਦੇ ਮੁਕਾਬਲੇ ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ 'ਤੇ ਸਕ੍ਰਿਪਟ ਪ੍ਰੋਸੈਸਿੰਗ ਨਾਲ ਸਬੰਧਤ ਸਮੇਂ (ਪ੍ਰਤੀਸ਼ਤ ਵਿੱਚ) ਵਿੱਚ ਵਾਧਾ

ਪ੍ਰਤੀਸ਼ਤ
10
25
50
75
90

ਸਾਰੀਆਂ ਸਾਈਟਾਂ
144.1
172.8
185.5
208.5
224.0

jQuery ਸਾਈਟਾਂ
188.2
187.4
191.3
209.6
221.9

Vue ਵੈੱਬਸਾਈਟਾਂ
222.5
220.8
220.2
221.4
220.4

ਐਂਗੁਲਰ ਵੈੱਬਸਾਈਟਾਂ
205.1
206.0
201.6
210.4
218.7

ਵੈੱਬਸਾਈਟਾਂ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰੋ
431.5
386.8
337.9
242.6
179.6

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

ਨਤੀਜੇ

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

ਇਹ ਵੈਬ ਪ੍ਰੋਜੈਕਟਾਂ ਦੇ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ (ਅਤੇ ਜ਼ਾਹਰ ਤੌਰ' ਤੇ ਉਹਨਾਂ ਦੇ ਪਹੁੰਚਯੋਗਤਾ).

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

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

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

ਢੁਕਵੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਕੁਝ ਸਮਝੌਤਾ ਕਰਨਾ ਸੰਭਵ ਹੈ, ਪਰ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਵਿਕਾਸਕਾਰ ਅਜਿਹੇ ਸਮਝੌਤਾ ਸੁਚੇਤ ਤੌਰ 'ਤੇ ਕਰਨ।

ਪਰ ਸਾਡੇ ਕੋਲ ਆਸ਼ਾਵਾਦੀ ਹੋਣ ਦਾ ਕਾਰਨ ਵੀ ਹੈ। ਮੈਂ ਇਸ ਗੱਲ ਤੋਂ ਉਤਸ਼ਾਹਿਤ ਹਾਂ ਕਿ ਕ੍ਰੋਮ ਡਿਵੈਲਪਰ ਉਹਨਾਂ ਟੂਲਸ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ ਸਾਡੇ ਦੁਆਰਾ ਕਵਰ ਕੀਤੇ ਕੁਝ ਫਰੰਟ-ਐਂਡ ਟੂਲਸ ਦੇ ਪਿੱਛੇ ਉਹਨਾਂ ਨਾਲ ਕਿੰਨੀ ਨੇੜਿਓਂ ਕੰਮ ਕਰ ਰਹੇ ਹਨ।

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

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

• ਆਪਣੇ ਆਪ ਨੂੰ ਆਮ ਸਮਝ ਨਾਲ ਚੈੱਕ ਕਰੋ. ਕੀ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਆਪਣੇ ਚੁਣੇ ਹੋਏ ਢਾਂਚੇ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ? ਸ਼ੁੱਧ JavaScript ਅੱਜ ਬਹੁਤ ਕੁਝ ਕਰ ਸਕਦੀ ਹੈ।
• ਕੀ ਤੁਹਾਡੀ ਪਸੰਦ ਦੇ ਫਰੇਮਵਰਕ (ਜਿਵੇਂ ਪ੍ਰੈਕਟ, ਸਵੇਲਟ ਜਾਂ ਕੁਝ ਹੋਰ) ਦਾ ਕੋਈ ਹਲਕਾ ਬਦਲ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਉਸ ਫਰੇਮਵਰਕ ਦੀਆਂ 90% ਸਮਰੱਥਾਵਾਂ ਦੇ ਸਕਦਾ ਹੈ?
• ਜੇਕਰ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਫਰੇਮਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਸ ਬਾਰੇ ਸੋਚੋ ਕਿ ਕੀ ਕੋਈ ਅਜਿਹੀ ਚੀਜ਼ ਹੈ ਜੋ ਬਿਹਤਰ, ਵਧੇਰੇ ਰੂੜੀਵਾਦੀ, ਮਿਆਰੀ ਵਿਕਲਪਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ, Vue ਦੀ ਬਜਾਏ Nuxt.js, React ਦੀ ਬਜਾਏ Next.js, ਆਦਿ)।
• ਤੁਹਾਡਾ ਕੀ ਹੋਵੇਗਾ ਬਜਟ JavaScript ਪ੍ਰਦਰਸ਼ਨ?
• ਤੁਸੀਂ ਕਿਵੇਂ ਕਰ ਸਕਦੇ ਹੋ ਸੀਮਾ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਵਧੇਰੇ ਜਾਵਾ ਸਕ੍ਰਿਪਟ ਕੋਡ ਪੇਸ਼ ਕਰਨਾ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਬਣਾਉਣ ਲਈ ਬਿਲਕੁਲ ਜ਼ਰੂਰੀ ਹੈ?
• ਜੇਕਰ ਤੁਸੀਂ ਵਿਕਾਸ ਦੀ ਸੌਖ ਲਈ ਇੱਕ ਫਰੇਮਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਵਿਚਾਰ ਕਰੋ ਕੀ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ ਗਾਹਕਾਂ ਨੂੰ ਫਰੇਮਵਰਕ ਕੋਡ ਭੇਜੋ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸਰਵਰ 'ਤੇ ਸਾਰੇ ਮੁੱਦਿਆਂ ਨੂੰ ਹੱਲ ਕਰ ਸਕਦੇ ਹੋ?

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

ਪਿਆਰੇ ਪਾਠਕ! ਤੁਸੀਂ ਆਦਰਸ਼ JavaScript ਫਰੇਮਵਰਕ ਵਜੋਂ ਕੀ ਦੇਖਦੇ ਹੋ?

ਸਰੋਤ: www.habr.com