ਤੁਹਾਡੇ ਵੈੱਬਸਾਈਟ 'ਤੇ ਜ਼ਖ਼ਰੀ ਜਾਵਾਸਕ੍ਰਿਪਟ ਲੋਡਿੰਗ ਨਾਲ TBT ਸਮੇਂ ਨੂੰ ਘਟਾਉਣਾ

ਜ਼ਖ਼ਰੀ ਜਾਵਾਸਕ੍ਰਿਪਟ ਲੋਡਿੰਗ, ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਪੇਜ ਸਮੱਗਰੀ ਨੂੰ ਰੂਪ ਵਿੱਚ ਲਿਆਉਣ 'ਚ ਰੁਕਾਵਟ ਪੈਦਾ ਕਰਨ ਵਾਲੀਆਂ ਜਾਵਾਸਕ੍ਰਿਪਟ ਫਾਈਲਾਂ ਨੂੰ ਸਹੀ ਕ੍ਰਮ ਵਿੱਚ ਰੋਕ ਕੇ Total Blocking Time (TBT) ਸਮੇਂ ਨੂੰ ਘਟਾਉਣ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੈ। ਸਿੱਧਾ ਦੇਖਦੇ ਹੋਏ, ਅਹਮ ਨਹੀਂ ਹੋਣ ਵਾਲੀਆਂ ਸਕ੍ਰਿਪਟ ਫਾਈਲਾਂ 'ਤੇ defer ਜਾਂ async ਸ਼ਾਮਿਲ ਕਰਕੇ ਮੂਲ ਕੰਮ ਧਾਗੇ ਦੇ ਘੱਟ ਰੁਕਾਵਟ ਹੋਣ ਦੀ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹੋ; ਇਸ ਤਰ੍ਹਾਂ ਉਪਭੋਗਤਾ ਪੇਜ ਨੂੰ ਜਲਦੀ ਦੇਖ ਸਕਦਾ ਹੈ, ਜਲਦੀ ਕਲਿੱਕ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੋਰ ਵੈਬ ਵਿਟਲਸ ਮੈਟ੍ਰਿਕਸ ਵਿੱਚ ਸੁਧਾਰ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਡੇ ਵੈੱਬਸਾਈਟ 'ਤੇ ਜ਼ਖ਼ਰੀ ਜਾਵਾਸਕ੍ਰਿਪਟ ਲੋਡਿੰਗ ਲਾਗੂ ਕਰਨ ਲਈ, ਪਹਿਲਾਂ ਇਹ ਪਤਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਫਾਈਲਾਂ ਅਹਮ ਹਨ, ਆਮ ਤੌਰ 'ਤੇ defer ਅਤੇ ਆਜ਼ਾਦ ਤੀਜੀ ਪੱਖੀ ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ async ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ PageSpeed Insights, Lighthouse ਅਤੇ Chrome DevTools ਨਾਲ TBT ਦੀ ਮਾਪਣਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਆਧੁਨਿਕ ਵੈੱਬਸਾਈਟਾਂ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਸਮੱਸਿਆ ਅਕਸਰ ਚਿੱਤਰਾਂ ਤੋਂ ਨਹੀਂ, ਬਲਕਿ ਬੇਹਿਸਾਬ ਜਾਵਾਸਕ੍ਰਿਪਟ ਦੀ ਵਰਤੋਂ ਤੋਂ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਇੱਕ ਈ-ਕਾਮਰਸ ਵੈੱਬਸਾਈਟ 'ਤੇ ਉਤਪਾਦ ਫਿਲਟਰ, ਜੀਵੰਤ ਸਹਾਇਤਾ, ਵਿਗਿਆਪਨ ਪਿਕਸਲ, ਵਿਸ਼ਲੇਸ਼ਣ ਕੋਡ, ਟਿੱਪਣੀ ਪਲੱਗਇਨ, A/B ਟੈਸਟਿੰਗ ਟੂਲ ਅਤੇ ਥੀਮ ਸਕ੍ਰਿਪਟ ਇੱਕਸਾਥ ਲੋਡ ਹੋ ਰਹੇ ਹਨ ਤਾਂ ਬ੍ਰਾਊਜ਼ਰ ਦਾ ਮੂਲ ਕੰਮ ਧਾਗਾ ਲੰਬੇ ਸਮੇਂ ਲਈ ਮਸ਼ਗੂਲ ਰਹਿੰਦਾ ਹੈ। ਇਹ ਸਥਿਤੀ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ 'ਤੇ ਹੋਰ ਪ੍ਰਮੁੱਖ ਹੁੰਦੀ ਹੈ। ਉਪਭੋਗਤਾ ਜੇਕਰ ਸਕ੍ਰੀਨ 'ਤੇ ਸਿਰਲੇਖ ਦੇਖ ਰਿਹਾ ਹੋਵੇ ਤਾਂ ਵੀ ਮੈਨੂੰ 'ਤੇ ਟੱਪਣ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਨਹੀਂ ਮਿਲ ਸਕਦੀ; Lighthouse ਰਿਪੋਰਟ ਵਿੱਚ Total Blocking Time ਉੱਚ ਦਿੱਸਦਾ ਹੈ।

ਇਸ ਗਾਈਡ ਵਿੱਚ ਅਸੀਂ defer ਅਤੇ async ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਕੀ ਕਰਦੀਆਂ ਹਨ, ਤੁਹਾਨੂੰ ਕਦੋਂ ਇਹਨਾਂ ਨੂੰ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ, WordPress ਅਤੇ ਵਿਸ਼ੇਸ਼ ਸਾਫਟਵੇਅਰ ਪ੍ਰੋਜੈਕਟਾਂ 'ਤੇ ਇਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ, ਮਾਪਣ ਕਰਦਿਆਂ ਤੁਹਾਨੂੰ ਕੀ ਧਿਆਨ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਵਾਸਤਵਿਕ TBT ਲਾਭਾਂ ਨੂੰ ਕਦਮ-दਰ-ਕਦਮ ਚਰਚਾ ਕਰਾਂਗੇ। Hostragons ਦੇ ਆਧਾਰ 'ਤੇ ਮੇਜ਼ਬਾਨੀ ਕੀਤੀਆਂ ਵੈੱਬਸਾਈਟਾਂ ਲਈ ਸੁਝਾਵ ਆਮ ਵੈੱਬ ਸਟੈਂਡਰਡਾਂ ਦੇ ਅਨੁਕੂਲ ਹਨ; ਇਸ ਦੇ ਨਾਲ ਹੀ ਸਹੀ ਹੋਸਟਿੰਗ, CDN, SSL ਅਤੇ ਕੈਸ਼ ਫੈਸਲਿਆਂ ਦੇ ਜਾਵਾਸਕ੍ਰਿਪਟ ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਕਿਵੇਂ ਸਮਰਥਨ ਮਿਲਦਾ ਹੈ, ਇਸ ਬਾਰੇ ਵੀ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ। Hostragons ਵੈੱਬ ਹੋਸਟਿੰਗ ਪੈਕੇਜ

TBT ਕੀ ਹੈ ਅਤੇ ਇਹ ਜਾਵਾਸਕ੍ਰਿਪਟ ਨਾਲ ਕਿਉਂ ਸੰਬੰਧਿਤ ਹੈ?

TBT, Total Blocking Time ਦਾ ਸੰਕੁਚਨ ਹੈ ਅਤੇ ਪੇਜ ਦੇ ਉਪਭੋਗੀ ਦੀ ਸੰਚਾਰ ਲਈ ਤਿਆਰ ਹੋਣ ਵਿੱਚ ਦੇਰੀ ਪੈਦਾ ਕਰਨ ਵਾਲੇ ਮੂਲ ਕੰਮ ਧਾਗੇ ਦੀ ਰੁਕਾਵਟ ਨੂੰ ਮਾਪਦਾ ਹੈ। Lighthouse ਲੈਬ ਟੈਸਟਾਂ ਵਿੱਚ, First Contentful Paint ਅਤੇ Time to Interactive ਵਿਚਕਾਰ 50 ਮਿਲੀਸਕਿੰਟ ਤੋਂ ਵੱਧ ਦੇ ਲੰਬੇ ਕੰਮਾਂ ਦੀ ਵਾਧੂਤਾ TBT ਮੁੱਲ ਨੂੰ ਵਧਾਉਂਦੀ ਹੈ। ਉਦਾਹਰਣ ਵਜੋਂ ਜੇਕਰ ਇੱਕ ਜਾਵਾਸਕ੍ਰਿਪਟ ਕੰਮ 180 ਮਿਲੀਸਕਿੰਟ ਚੱਲਦਾ ਹੈ, ਤਾਂ ਇਸ ਦੇ ਪਹਿਲੇ 50 ਮਿਲੀਸਕਿੰਟ ਬਾਅਦ ਦੇ 130 ਮਿਲੀਸਕਿੰਟ ਦੀ ਰੁਕਾਵਟ ਸਮੇਂ ਵਿੱਚ ਯੋਗਦਾਨ ਦਿੰਦਾ ਹੈ।

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

ਉੱਚ TBT ਮੁੱਲ ਦੇ ਆਮ ਲਕਸ਼ਣ

• ਮੋਬਾਈਲ PageSpeed Insights ਰਿਪੋਰਟ ਵਿੱਚ TBT ਮੁੱਲ 300 ਮਿਲੀਸਕਿੰਟ ਤੋਂ ਉੱਪਰ ਜਾਣਾ।
• Lighthouse ਰਿਪੋਰਟ ਵਿੱਚ Reduce JavaScript execution time ਜਾਂ Minimize main-thread work ਦੀ ਚੇਤਾਵਨੀ ਦੇਖਣਾ।
• ਪੇਜ ਵੇਖਿਆ ਜਾਣ ਦੇ ਬਾਵਜੂਦ ਮੈਨੂੰ, ਸਲਾਈਡਰ, ਫਿਲਟਰ ਜਾਂ ਫਾਰਮ ਖੇਤਰਾਂ ਦਾ ਦੇਰ ਨਾਲ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਨਾ।
• ਤੀਜੇ ਪੱਖ ਦੇ ਵਿਗਿਆਪਨ, ਜੀਵੰਤ ਸਹਾਇਤਾ ਜਾਂ ਵਿਸ਼ਲੇਸ਼ਣ ਸਕ੍ਰਿਪਟਾਂ ਦਾ ਰਿਪੋਰਟ ਵਿੱਚ ਉੱਚ ਕੀਮਤ ਵਾਲਾ ਦਿਖਾਈ ਦੇਣਾ।
• ਖਾਸ ਤੌਰ 'ਤੇ ਮੁਢਲੇ ਜਨਰਲ Android ਡਿਵਾਈਸਾਂ 'ਤੇ ਸਕ੍ਰੋਲਿੰਗ ਅਤੇ ਕਲਿੱਕ ਦੇਰੀ ਦਾ ਅਨੁਭਵ ਹੋਣਾ।

ਇੱਕ ਚੰਗਾ ਲਕਸ਼ਯ TBT ਮੁੱਲ ਨੂੰ 200 ਮਿਲੀਸਕਿੰਟ ਦੇ ਹੇਠਾਂ ਰੱਖਣਾ ਬਹੁਤ ਸਾਰੇ ਸਮੱਗਰੀ ਵੈੱਬਸਾਈਟਾਂ ਲਈ ਸਿਹਤਮੰਦ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਹੋਰ ਜਟਿਲ ਈ-ਕਾਮਰਸ ਜਾਂ SaaS ਇੰਟਰਫੇਸਾਂ ਵਿੱਚ ਇਸ ਲਕਸ਼ਯ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਸਿਰਫ defer ਅਤੇ async ਹੀ ਕਾਫੀ ਨਹੀਂ ਹੋ ਸਕਦੇ; ਕੋਡ ਵੰਡਣ, ਬੇਕਾਰ ਪੈਕੇਜਾਂ ਨੂੰ ਹਟਾਉਣ, ਕੈਸ਼ਿੰਗ, ਸਰਵਰ ਦੇ ਜਵਾਬ ਦੇ ਸਮੇਂ ਨੂੰ ਸੁਧਾਰਨ ਅਤੇ ਅਹਮ CSS ਸੈਟਿੰਗਾਂ ਦੀ ਵੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਫਿਰ ਵੀ ਜ਼ਖ਼ਰੀ ਜਾਵਾਸਕ੍ਰਿਪਟ ਲੋਡਿੰਗ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਪਹਿਲਾਂ ਲਾਗੂ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਅਤੇ ਤੇਜ਼ ਨਤੀਜੇ ਪ੍ਰਦਾਨ ਕਰਨ ਵਾਲੇ ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਵਿੱਚੋਂ ਇੱਕ ਹੈ।

Defer ਅਤੇ Async ਕੀ ਹਨ?

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

Defer ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ?

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

ਉਦਾਹਰਣ ਲਈ ਵਰਤੋਂ ਇਸ ਤਰ੍ਹਾਂ ਹੈ: <script defer src=/js/app.js></script>. ਇਸ ਵਰਤੋਂ ਵਿੱਚ app.js ਫਾਈਲ ਪੇਜ ਦੀ ਪਹਿਲੀ ਰੇਖਾ ਨੂੰ ਰੋਕਣ ਤੋਂ ਬਿਨਾਂ ਡਾਊਨਲੋਡ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, DOM ਤਿਆਰ ਹੋਣ 'ਤੇ ਕ੍ਰਮਵਾਰ ਚਲਾਈ ਜਾਂਦੀ ਹੈ। ਆਧੁਨਿਕ ਬ੍ਰਾਊਜ਼ਰਾਂ ਵਿੱਚ defer ਬਹੁਤ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਸਹਿਯੋਗ ਪ੍ਰਦਾਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਲਾਸਿਕ ਸਕ੍ਰਿਪਟ ਫਾਈਲਾਂ ਲਈ ਇੱਕ ਭਰੋਸੇਮੰਦ ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਟੂਲ ਹੈ।

Async ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ?

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

ਉਦਾਹਰਣ ਲਈ ਵਰਤੋਂ: <script async src=/js/analytics.js></script>. ਇਸ ਫਾਈਲ ਨੂੰ ਕਿਸੇ ਹੋਰ ਸਥਾਨਕ ਸਕ੍ਰਿਪਟ ਦੇ ਪਹਿਲਾਂ ਚੱਲਣ ਦੀ ਉਮੀਦ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ। ਜੇਕਰ analytics.js, ਪੇਜ 'ਤੇ ਬਾਅਦ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੇ ਗਏ ਕਿਸੇ ਚਲਾਈ ਜਾਂਦੀ ਬਦਲਵੀਂ ਜਾਂ jQuery ਵਰਗੇ ਹੋਰ ਲਾਈਬ੍ਰੇਰੀ ਨਾਲ ਨਿਰਭਰ ਹੈ, ਤਾਂ async ਗਲਤੀ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ async ਤੇਜ਼ ਹੈ ਪਰ ਧਿਆਨ ਨਾਲ ਵੰਡਣ ਦੀ ਲੋੜ ਹੈ।

Defer ਅਤੇ Async ਦੀ ਤੁਲਨਾ ਟੇਬਲ

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

ਜ਼ਖ਼ਰੀ ਜਾਵਾਸਕ੍ਰਿਪਟ ਲੋਡਿੰਗ ਲਈ ਕਦਮ-ਦਰ-ਕਦਮ ਲਾਗੂ ਕਰਨ ਦੀ ਯੋਜਨਾ

ਬੇਹਿਸਾਬ ਹਰ ਸਕ੍ਰਿਪਟ ਟੈਗ ਵਿੱਚ defer ਜਾਂ async ਸ਼ਾਮਿਲ ਕਰਨਾ ਛੋਟੇ ਸਮੇਂ ਵਿੱਚ ਸਕੋਰ ਨੂੰ ਵਧਾਉਣ ਵਾਲਾ ਦਿਖਾਈ ਦੇ ਸਕਦਾ ਹੈ ਪਰ ਉਤਪਾਦਨ ਵੈੱਬਸਾਈਟ 'ਤੇ ਭੁਗਤਾਨ, ਖੋਜ, ਮੈਨੂੰ, ਫਾਰਮ ਦੀ ਪੁਸ਼ਟੀ ਜਾਂ ਕਾਰਟ ਜਿਵੇਂ ਮਹੱਤਵਪੂਰਨ ਫੰਕਸ਼ਨ ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦਾ ਹੈ। ਸਿਹਤਮੰਦ ਲਾਗੂ ਕਰਨ ਲਈ ਮਾਪ, ਵਰਗੀਕਰਨ, ਛੋਟੇ ਬਦਲਾਅ, ਟੈਸਟ ਅਤੇ ਨਿਗਰਾਨੀ ਦੇ ਚੱਕਰ ਦੀ ਲੋੜ ਹੈ।

1. ਮੌਜੂਦਾ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਮਾਪੋ

ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬੇਜ਼ ਮੁੱਲ ਬਣਾਓ। PageSpeed Insights ਨਾਲ ਮੋਬਾਈਲ ਅਤੇ ਡੈਸਕਟਾਪ ਸਕੋਰਾਂ ਨੂੰ ਦਰਜ ਕਰੋ। Lighthouse ਰਿਪੋਰਟ ਵਿੱਚ TBT, First Contentful Paint, Largest Contentful Paint ਅਤੇ Speed Index ਮੁੱਲਾਂ ਨੂੰ ਨੋਟ ਕਰੋ। Chrome DevTools Performance ਸੈਕਸ਼ਨ ਵਿੱਚ ਮੂਲ ਕੰਮ ਧਾਗੇ ਦੀ ਜਾਂਚ ਕਰੋ; ਲੰਬੇ ਪੀਲੇ ਬਲਾਕ ਆਮ ਤੌਰ 'ਤੇ ਜਾਵਾਸਕ੍ਰਿਪਟ ਪਾਰਸਿੰਗ, ਕੰਪਾਈਲਿੰਗ ਅਤੇ ਚਲਾਉਣ ਦੇ ਖਰਚ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ।

ਤੁਸੀਂ ਇੱਕ ਉਦਾਹਰਣ ਦੇ ਤੌਰ 'ਤੇ ਸ਼ੁਰੂਆਤੀ ਟੇਬਲ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹੋ: ਮੋਬਾਈਲ TBT 780 ਮਿਲੀਸਕਿੰਟ, ਜਾਵਾਸਕ੍ਰਿਪਟ ਐਗਜ਼ਿਕਿਊਸ਼ਨ ਸਮਾਂ 2.8 ਸੈਕੰਡ, ਮੂਲ ਕੰਮ 4.5 ਸੈਕੰਡ। ਜੇਕਰ ਇਕ ਵਾਰਪ੍ਰਕਿਰਿਆ ਤੋਂ ਬਾਅਦ ਮੋਬਾਈਲ TBT 280 ਮਿਲੀਸਕਿੰਟ ਤੱਕ ਘਟਦਾ ਹੈ ਤਾਂ ਤੁਸੀਂ ਲਗਭਗ 64% ਸੁਧਾਰ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦੇ ਹੋ। ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਸੱਚੇ ਰਿਕਾਰਡ ਟੀਮ ਵਿੱਚ ਦੇਖਣਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ ਕਿ ਕਿਹੜਾ ਬਦਲਾਅ ਕਾਰਗਰ ਹੋਇਆ।

2. ਸਕ੍ਰਿਪਟ ਇਨਵੈਂਟਰੀ ਤਿਆਰ ਕਰੋ

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

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

ਸਭ ਤੋਂ ਵਧੀਆ ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਕਈ ਵਾਰੀ defer ਸ਼ਾਮਿਲ ਕਰਨ ਨਾਲ ਨਹੀਂ, ਬਲਕਿ ਕੋਈ ਵੀ ਲੋੜੀਂਦੀ ਫਾਈਲ ਹਟਾਉਣ ਨਾਲ ਹੁੰਦੀ ਹੈ। 90 KB ਸੰਕੋਚਿਤ ਫਾਈਲ ਮੋਬਾਈਲ ਡਿਵਾਈਸ 'ਤੇ ਪਾਰਸਿੰਗ ਅਤੇ ਚਲਾਉਣ ਸਮੇਤ 300 ਮਿਲੀਸਕਿੰਟ ਤੋਂ ਉੱਪਰ ਖਰਚ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ। ਇਸ ਲਈ ਪਹਿਲਾਂ ਬੇਕਾਰ ਨੂੰ ਸਾਫ਼ ਕਰਨਾ, ਫਿਰ ਬਾਕੀ ਨੂੰ ਜ਼ਖ਼ਰੀ ਕਰਨਾ ਇੱਕ ਸਹੀ ਪਹੁੰਚ ਹੈ।

3. Defer ਲਾਗੂ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਫਾਈਲਾਂ ਦੀ ਪਛਾਣ ਕਰੋ

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

ਇੱਕ WordPress ਥੀਮ ਵਿੱਚ jquery-migrate, ਥੀਮ ਦੀ ਮੁੱਖ ਫਾਈਲ ਅਤੇ ਪਲੱਗਇਨ ਸਕ੍ਰਿਪਟਾਂ ਜਟਿਲ ਨਿਰਭਰਤਾ ਦਾ ਸ਼ਾਮਲ ਕਰ ਸਕਦੇ ਹਨ। jQuery ਮੂਲ ਨੂੰ async ਕਰਨਾ ਬਹੁਤ ਸਾਰੀਆਂ ਵੈੱਬਸਾਈਟਾਂ 'ਤੇ ਖਤਰਨਾਕ ਹੈ; ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੇ ਪਲੱਗਇਨ jQuery ਦੇ ਕ੍ਰਮ ਦੀ ਉਡੀਕ ਕਰਦੇ ਹਨ। ਇਸ ਦੀ ਬਜਾਏ jQuery ਨਾਲ ਨਿਰਭਰ ਫਾਈਲਾਂ 'ਤੇ ਨਿਯੰਤਰਿਤ defer ਲਾਗੂ ਕਰਨਾ ਜਾਂ ਪਲੱਗਇਨ ਪੱਧਰ 'ਤੇ ਓਪਟੀਮਾਈਜ਼ ਕੀਤੇ ਗਏ ਲੋਡਿੰਗ ਵਿਕਲਪਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਿਹਤਰ ਹੈ। WordPress ਗਤੀ ਅਡਜਸਟਮੈਂਟ ਗਾਈਡ

4. Async ਲਾਗੂ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਫਾਈਲਾਂ ਦੀ ਚੋਣ ਕਰੋ

Google Analytics, ਵਿਗਿਆਪਨ ਟੈਗ, Facebook ਪਿਕਸਲ, LinkedIn Insight ਟੈਗ, ਕੁਝ ਬਾਹਰੀ ਚੈਟ ਵਿਜ਼ਟ ਅਤੇ ਸਮਾਜਿਕ ਸਾਂਝਾ ਕੋਡ async ਲਈ ਉਮੀਦਵਾਰ ਹਨ। ਪਰ ਹਰ ਤੀਜੇ ਪੱਖ ਦੇ ਸਕ੍ਰਿਪਟ ਇੱਕੋ ਜਿਹੇ ਨਹੀਂ ਹੁੰਦੇ। ਕੁਝ ਜੀਵੰਤ ਸਹਾਇਤਾ ਟੂਲ ਪੇਜ ਲੋਡ ਹੋਣ 'ਤੇ ਉਪਭੋਗਤਾ ਸੈਸ਼ਨ ਬਣਾਉਣ ਦੀ ਇੱਛਾ ਕਰ ਸਕਦੇ ਹਨ, ਕੁਝ ਵਿਗਿਆਪਨ ਪ੍ਰਣਾਲੀਆਂ ਨਿਰਧਾਰਿਤ ਕੰਟੇਨਰ ਦੇ ਕ੍ਰਮ ਦੀ ਉਡੀਕ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਇਸ ਲਈ ਦਸਤਾਵੇਜ਼ ਦੀ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

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

5. ਸ਼ਰਤੀ ਅਤੇ ਘਟਨਾ ਆਧਾਰਿਤ ਲੋਡਿੰਗ ਸ਼ਾਮਿਲ ਕਰੋ

defer ਅਤੇ async ਇੱਕ ਚੰਗੀ ਸ਼ੁਰੂਆਤ ਹਨ; ਪਰ ਉੱਚ ਪੱਧਰ 'ਤੇ ਜਾਵਾਸਕ੍ਰਿਪਟ ਫਾਈਲਾਂ ਨੂੰ ਉਪਭੋਗੀ ਦੇ ਵਿਹਾਰ ਦੇ ਅਧੀਨ ਲੋਡ ਕਰਨ ਨਾਲ TBT 'ਤੇ ਵੱਡਾ ਪ੍ਰਭਾਵ ਪੈ ਸਕਦਾ ਹੈ। ਜੀਵੰਤ ਸਹਾਇਤਾ ਬਾਕਸ ਪੇਜ ਖੁਲਣ 'ਤੇ ਨਹੀਂ, ਬਲਕਿ ਉਪਭੋਗੀ 5 ਸੈਕੰਡਾਂ ਲਈ ਰਹਿੰਦਾ ਹੈ ਜਾਂ ਸਹਾਇਤਾ ਬਟਨ 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ ਤਾਂ ਲੋਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਨਕਸ਼ਾ ਐਂਬੈਡ ਕੋਡ, ਉਪਭੋਗੀ ਦੇ ਸੰਪਰਕ ਖੇਤਰ 'ਤੇ ਸਕ੍ਰੋਲ ਕਰਨ 'ਤੇ ਲੋਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਵੀਡੀਓ ਪਲੇਅਰ ਸਕ੍ਰਿਪਟ, ਉਪਭੋਗੀ ਪਲੇਅ ਬਟਨ 'ਤੇ ਕਲਿੱਕ ਕਰਨ 'ਤੇ ਕਾਲ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

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

6. ਟੈਸਟ ਕਰੋ ਅਤੇ ਪਦਰਥਕ ਰਾਹੀਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ

ਬਦਲਾਅ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਜੀਵੰਤ ਵੈੱਬਸਾਈਟ 'ਤੇ ਲੈ ਜਾਣ ਦੀ ਬਜਾਏ ਟੈਸਟ ਵਾਤਾਵਰਨ ਵਿੱਚ ਅਜ਼ਮਾਓ। ਮੁੱਖ ਪੇਜ, ਸ਼੍ਰੇਣੀ ਪੇਜ, ਉਤਪਾਦ ਜਾਂ ਸੇਵਾ ਪੇਜ, ਸੰਪਰਕ ਪੇਜ, ਦਾਖਲਾ ਫਾਰਮ ਅਤੇ ਭੁਗਤਾਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਰਗੇ ਮਹੱਤਵਪੂਰਨ ਪੇਜਾਂ 'ਤੇ ਮੈਨੂਅਲ ਟੈਸਟ ਕਰੋ। ਬ੍ਰਾਊਜ਼ਰ ਕੰਸੋਲ ਵਿੱਚ ਕੋਈ ਗਲਤੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਜਾਂਚੋ। ਖਾਸ ਕਰਕੇ Cannot read property, is not defined ਅਤੇ undefined function ਵਰਗੀਆਂ ਗਲਤੀਆਂ ਕ੍ਰਮ ਜਾਂ ਨਿਰਭਰਤਾ ਸਮੱਸਿਆ ਦਾ ਸੰਕੇਤ ਦਿੰਦੀਆਂ ਹਨ।

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

WordPress ਸਾਈਟਾਂ 'ਤੇ Defer ਅਤੇ Async ਲਾਗੂ ਕਰਨ ਦੇ ਨੋਟਸ

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

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

WordPress ਲਈ ਪ੍ਰਯੋਗਾਤਮਕ ਕ੍ਰਮ ਇਹ ਹੋ ਸਕਦਾ ਹੈ: ਪਹਿਲਾਂ ਬੇਕਾਰ ਪਲੱਗਇਨਾਂ ਨੂੰ ਹਟਾਓ। ਫਿਰ ਕੇਵਲ ਲੋੜੀਂਦੇ ਪੇਜਾਂ 'ਤੇ ਲੋਡ ਹੋਣ ਵਾਲੇ ਪਲੱਗਇਨ ਫਾਈਲਾਂ ਨੂੰ ਸ਼ਰਤੀ ਬਣਾਓ। ਫਿਰ ਥੀਮ ਅਤੇ ਪਲੱਗਇਨ ਸਕ੍ਰਿਪਟਾਂ 'ਤੇ defer ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਅਖੀਰ ਵਿੱਚ ਆਜ਼ਾਦ ਤੀਜੇ ਪੱਖ ਦੇ ਕੋਡਾਂ 'ਤੇ async ਜਾਂ ਜ਼ਖ਼ਰੀ ਲੋਡਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਇਹ ਤਰੀਕਾ ਇਕ ਵਾਰੀ ਵਿੱਚ ਵੱਡੇ ਤੋੜਨ ਦੇ ਖਤਰੇ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।

ਵਿਸ਼ੇਸ਼ ਸਾਫਟਵੇਅਰ ਅਤੇ ਫਰੇਮਵਰਕ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਧਿਆਨ ਰੱਖਣ ਵਾਲੀਆਂ ਗੱਲਾਂ

React, Vue, Angular, Next.js, Nuxt ਜਾਂ ਸਮਾਨ ਆਧੁਨਿਕ ਬਣਾਉਂਦਿਆਂ ਵਿੱਚ ਜਾਵਾਸਕ੍ਰਿਪਟ ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਸਿਰਫ HTML ਟੈਗ 'ਚ defer ਸ਼ਾਮਿਲ ਕਰਨ ਤੱਕ ਸੀਮਿਤ ਨਹੀਂ ਹੈ। ਪੈਕੇਜ ਦਾ ਆਕਾਰ, ਕੋਡ ਵੰਡਣਾ, ਟ੍ਰੀ ਸ਼ੇਕਿੰਗ, ਗਤੀਸ਼ੀਲ ਆਯਾਤ ਅਤੇ ਹਾਈਡ੍ਰੇਸ਼ਨ ਦੀ ਲਾਗਤ TBT 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਂਦੀ ਹੈ। ਜੇਕਰ ਇੱਕ ਵੱਡੀ ਬੰਡਲ ਫਾਈਲ 700 KB ਹੈ ਤਾਂ defer ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਵੇ ਤਾਂ ਵੀ ਚਲਾਉਣ ਦੇ ਪੜਾਅ 'ਤੇ ਮੂਲ ਕੰਮ ਧਾਗਾ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਬਲਾਕ ਹੋ ਸਕਦਾ ਹੈ।

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

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

ਹੋਸਟਿੰਗ, ਸਰਵਰ ਜਵਾਬ ਦੇ ਸਮੇਂ ਅਤੇ ਜਾਵਾਸਕ੍ਰਿਪਟ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਦਾ ਸੰਬੰਧ

TBT ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਜਾਵਾਸਕ੍ਰਿਪਟ ਚਲਾਉਣ ਦੇ ਸਮੇਂ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ; ਪਰ ਹੋਸਟਿੰਗ ਢਾਂਚਾ ਅਪਰੋਖ ਤੌਰ 'ਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਮੰਦ TTFB, ਸੰਕੋਚਨ ਦੀ ਕਮੀ, HTTP/2 ਜਾਂ HTTP/3 ਦਾ ਸਹਾਰਾ ਨਾ ਹੋਣਾ, ਕਮਜ਼ੋਰ ਕੈਸ਼ਿੰਗ ਅਤੇ ਦੂਰ ਦੇ ਸਥਾਨ ਦੇ ਕਾਰਨ ਦੇਰੀ ਜਾਵਾਸਕ੍ਰਿਪਟ ਫਾਈਲਾਂ ਦੇ ਦੇਰ ਨਾਲ ਪਹੁੰਚਣ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ। ਜਦੋਂ ਫਾਈਲਾਂ ਦੇਰ ਨਾਲ ਪਹੁੰਚਦੀਆਂ ਹਨ ਤਾਂ ਪੇਜ ਦੇ ਜੀਵਨ ਚੱਕਰ ਦੀ ਮਿਆਦ ਵੱਧ ਜਾਂਦੀ ਹੈ ਅਤੇ ਉਪਭੋਗੀ ਦਾ ਅਨੁਭਵ ਕਮਜ਼ੋਰ ਹੁੰਦਾ ਹੈ।

ਗੁਣਵੱਤਾ ਵਾਲਾ ਹੋਸਟਿੰਗ ਢਾਂਚਾ, Brotli ਜਾਂ Gzip ਸੰਕੋਚਨ, ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬ੍ਰਾਊਜ਼ਰ ਕੈਸ਼, ਨਵਾਂ PHP ਸੰਸਕਰਣ, ਤੇਜ਼ ਡਿਸਕ ਤਕਨਾਲੋਜੀ ਅਤੇ CDN ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਨਾਲ ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਸਮਰਥਨ ਦਿੰਦਾ ਹੈ। SSL ਸਰਟੀਫਿਕੇਟ ਦਾ ਸਹੀ ਸਥਾਪਨ ਵੀ ਆਧੁਨਿਕ ਬ੍ਰਾਊਜ਼ਰ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, HTTP/2 ਅਤੇ ਸੁਰੱਖਿਅਤ ਤੀਜੇ ਪੱਖ ਦੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਦੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ। Hostragons SSL ਸਰਟੀਫਿਕੇਟ Hostragons ਡੋਮੇਨ ਪੁੱਛਗਿੱਛ

ਉਦਾਹਰਣ ਵਜੋਂ, ਜੇਕਰ ਇੱਕ ਹੀ ਜਾਵਾਸਕ੍ਰਿਪਟ ਫਾਈਲ ਬਿਨਾਂ ਸੰਕੋਚਨ ਦੇ 320 KB ਹੈ, ਤਾਂ Brotli ਨਾਲ 95 KB ਦੇ ਪੱਧਰ 'ਤੇ ਘਟ ਸਕਦੀ ਹੈ। ਇਹ TBT ਮੁੱਲ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਹੀ ਅਨੁਪਾਤ ਵਿੱਚ ਘਟਾਉਂਦਾ ਨਹੀਂ; ਕਿਉਂਕਿ TBT ਚਲਾਉਣ ਦੀ ਲਾਗਤ ਨੂੰ ਮਾਪਦਾ ਹੈ। ਪਰ ਡਾਊਨਲੋਡ ਸਮੇਂ ਵਿੱਚ ਕਮੀ, ਸਰੋਤ ਪ੍ਰਾਥਮਿਕਤਾ ਦਾ ਸੁਧਾਰ ਅਤੇ ਕੁੱਲ ਲੋਡਿੰਗ ਅਨੁਭਵ ਵਿੱਚ ਸੁਧਾਰ ਹੁੰਦਾ ਹੈ। ਇਸ ਲਈ defer, async, ਕੈਸ਼ਿੰਗ ਅਤੇ ਸਹੀ ਹੋਸਟਿੰਗ ਨੂੰ ਸਾਥ ਵਿੱਚ ਸੋਚਣਾ ਚਾਹੀਦਾ ਹੈ।

ਮਾਪਣ ਅਤੇ ਸਹੀ ਕਰਨ ਦੀ ਜਾਂਚ ਪੱਟੀ

ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਦੀ ਸਫਲਤਾ ਨੂੰ ਸਮਝਣ ਲਈ ਸਿਰਫ PageSpeed ਸਕੋਰ 'ਤੇ ਨਜ਼ਰ ਰੱਖਣਾ ਕਾਫੀ ਨਹੀਂ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਜਾਂਚ ਪੱਟੀ ਵਾਸਤਵਿਕ ਪ੍ਰਭਾਵ ਦੇ ਸਹੀ ਮੁਲਾਂਕਣ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰਦੀ ਹੈ:

• ਮੋਬਾਈਲ TBT ਮੁੱਲ ਨੂੰ ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਤੁਲਨਾ ਕੀਤੀ ਗਈ ਹੈ?
• ਜਾਵਾਸਕ੍ਰਿਪਟ ਐਗਜ਼ਿਕਿਊਸ਼ਨ ਸਮਾਂ ਰਿਪੋਰਟ ਵਿੱਚ ਸਭ ਤੋਂ ਮਹਿੰਗੀਆਂ ਫਾਈਲਾਂ ਘਟ ਰਹੀਆਂ ਹਨ?
• Chrome DevTools Performance ਰਿਕਾਰਡ ਵਿੱਚ ਲੰਬੇ ਕੰਮਾਂ ਦੀ ਗਿਣਤੀ ਘਟੀ ਹੈ?
• ਕੰਸੋਲ ਵਿੱਚ ਜਾਵਾਸਕ੍ਰਿਪਟ ਦੀ ਗਲਤੀ ਹੈ?
• ਮੈਨੂੰ, ਖੋਜ, ਫਿਲਟਰ, ਫਾਰਮ, ਕਾਰਟ ਅਤੇ ਭੁਗਤਾਨ ਦੇ ਚੱਕਰ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਕੰਮ ਕਰ ਰਹੇ ਹਨ?
• ਤੀਜੇ ਪੱਖ ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਵਿਗਿਆਪਨ ਟੈਗਾਂ ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਟਿਗਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ?
• ਵਾਸਤਵਿਕ ਉਪਭੋਗੀ ਦੇ ਡਾਟਾ ਵਿੱਚ INP ਅਤੇ ਸੰਚਾਰ ਦੀ ਦੇਰੀ ਸੁਧਰ ਰਹੀ ਹੈ?
• ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਕੈਸ਼ ਸਾਫ਼ ਕੀਤਾ ਗਿਆ ਹੈ?

ਇੱਥੇ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਲੈਬ ਅਤੇ ਫੀਲਡ ਡਾਟਾ ਨੂੰ ਵੱਖਰਾ ਕਰਨਾ ਹੈ। TBT, Lighthouse ਲੈਬ ਮੈਟ੍ਰਿਕ ਹੈ। ਵਾਸਤਵਿਕ ਉਪਭੋਗੀ ਅਨੁਭਵ ਵਿੱਚ Interaction to Next Paint (INP) ਹੋਰ ਨਿਰਧਾਰਕ ਬਣ ਗਿਆ ਹੈ। ਪਰ TBT ਦੀ ਕਮੀ ਅਕਸਰ INP ਵਿੱਚ ਸੁਧਾਰ ਦੀ ਸਹਾਇਤਾ ਕਰਦੀ ਹੈ; ਕਿਉਂਕਿ ਮੂਲ ਕੰਮ ਧਾਗੇ ਵਿੱਚ ਘੱਟ ਰੁਕਾਵਟ ਬਣਦੀ ਹੈ।

ਅਕਸਰ ਕੀਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਅਤੇ ਬਚਣ ਦੇ ਤਰੀਕੇ

ਸਾਰੇ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਇੱਕੋ ਵਾਰੀ async ਕਰਨਾ

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