07 ਜੁਲਾ 2025·8 ਮਿੰਟ
ਸ਼ੁਰੂਆਤੀਆਂ ਲਈ ਵੈੱਬਸਾਈਟ ਸਪੀਡ: ਕੀ ਸੱਚਮੁੱਚ ਲੋਡ ਸਮਾਂ ਸੁਧਾਰਦਾ ਹੈ
ਇੱਕ ਸ਼ੁਰੂਆਤੀ-ਦੋਸਤ ਗਾਈਡ ਜੋ ਦੱਸਦੀ ਹੈ ਕੀ ਵਾਸਤਵ ਵਿੱਚ ਵੈੱਬਸਾਈਟ ਲੋਡ ਸਮਾਂ ਸੁਧਾਰਦਾ ਹੈ: ਇਮੇਜ, ਕੈਸ਼ਿੰਗ, ਹੋਸਟਿੰਗ, ਕੋਡ ਅਤੇ Core Web Vitals—ਨਾਲ ਹੀ ਪਹਿਲਾਂ ਅਜ਼ਮਾਉਣ ਲਈ ਤੁਰੰਤ ਨੁਕਤੇ।
ਇੱਕ ਸ਼ੁਰੂਆਤੀ-ਦੋਸਤ ਗਾਈਡ ਜੋ ਦੱਸਦੀ ਹੈ ਕੀ ਵਾਸਤਵ ਵਿੱਚ ਵੈੱਬਸਾਈਟ ਲੋਡ ਸਮਾਂ ਸੁਧਾਰਦਾ ਹੈ: ਇਮੇਜ, ਕੈਸ਼ਿੰਗ, ਹੋਸਟਿੰਗ, ਕੋਡ ਅਤੇ Core Web Vitals—ਨਾਲ ਹੀ ਪਹਿਲਾਂ ਅਜ਼ਮਾਉਣ ਲਈ ਤੁਰੰਤ ਨੁਕਤੇ।
ਜਦ ਲੋਕ ਕਹਿੰਦੇ ਹਨ “ਮੇਰੀ ਵੈੱਬਸਾਈਟ ਧੀਮੀ ਹੈ,” ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਚੀਜ਼ਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦਾ ਮਤਲਬ ਲੈਂਦੇ ਹਨ:
“ਲੋਡ ਸਮਾਂ” ਇੱਕ ਹੀ ਸਟਾਪਵਾਚ ਨੰਬਰ ਨਹੀਂ ਹੈ। ਪੇਜ਼ ਪੜਾਅਾਂ ਵਿੱਚ ਲੋਡ ਹੁੰਦਾ ਹੈ: ਤੁਹਾਡਾ ਬਰਾਊਜ਼ਰ ਫਾਈਲਾਂ (HTML, ਇਮੇਜ, ਫੋਂਟ, ਸਕ੍ਰਿਪਟ) ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਵਰਤਣਯੋਗ ਪੇਜ਼ ਵਿੱਚ ਬਦਲਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਦੁਕਾਨ ਖੋਲ੍ਹਣ ਵਾਂਗ ਸੋਚ ਸਕਦੇ ਹੋ: ਦੁਆਰ ਖੋਲ੍ਹਣਾ, ਲਾਈਟ ਚਾਲੂ ਕਰਨੀ, ਸ਼ੈਲਫ ਭਰਨਾ, ਅਤੇ ਆਖ਼ਰ ਵਿੱਚ ਗ੍ਰਾਹਕਾਂ ਨੂੰ ਸਰਵ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋਣਾ।
ਗਤੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ:
ਤੁਹਾਨੂੰ 50 ਸੁੱਖਣ-ਸੁਧਾਰਾਂ ਦੀ ਲੋੜ ਨਹੀਂ। ਬਹੁਤੇ ਸ਼ੁਰੂਆਤੀ ਸਾਈਟਾਂ ਲਈ ਸਭ ਤੋਂ ਵੱਡੇ ਸੁਧਾਰ ਇੱਕ ਛੋਟੀ ਸੂਚੀ ਤੋਂ ਆਉਂਦੇ ਹਨ: ਇਮੇਜ, ਜ਼ਿਆਦਾ JavaScript/CSS, ਤੀਜੇ-ਪੱਖ ਵਿਡਜੈਟ, ਅਤੇ ਸਰਵਰ/ਹੋਸਟਿੰਗ ਰਿਸਪਾਂਸ ਸਮਾਂ।
ਇਹ ਗਾਈਡ ਪ੍ਰਯੋਗਿਕ, ਘੱਟ‑ਖਤਰੇ ਵਾਲੇ ਕਦਮਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਕਰਦੀ ਹੈ ਜੋ ਹਕੀਕਤੀ ਦੁਨੀਆ ਦੇ ਪੇਜ਼ ਲੋਡ ਸਮੇ 'ਤੇ ਸੁਧਾਰ ਲਿਆਉਂਦੇ ਹਨ, ਖ਼ਾਸ ਕਰਕੇ ਮੋਬਾਈਲ 'ਤੇ। ਇਹ ਤੁਹਾਨੂੰ ਆਪਣੀ ਐਪ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਮੁੜ ਲਿਖਣ, ਕਸਟਮ ਕੈਸ਼ਿੰਗ ਲੇਅਰ ਬਣਾਉਣ ਜਾਂ ਵੱਡੀ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ ਲਈ ਪਰਫਾਰਮੈਂਸ ਬਜਟਿੰਗ ਵਰਗੀਆਂ ਉन्नਤ ਵਿਸ਼ਿਆਂ ਵਿੱਚ ਡੁੱਬੋਣ ਤੋਂ ਨਹੀਂ ਰੋਕੇਗੀ। ਲਕਸ਼ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਐਸੇ ਬਦਲਾਅ ਕਰੋ ਜੋ ਤੁਸੀਂ ਅੰਤ ਤੱਕ ਖਤਮ ਕਰ ਸਕੋ—ਅਤੇ ਟੈਸਟ ਕਰਕੇ ਪੁਸ਼ਟੀ ਕਰ ਸਕੋ—ਬਿਨਾਂ ਸਾਈਟ ਨੂੰ ਤੋੜੇ।
ਜਦ ਲੋਕ ਕਹਿੰਦੇ ਹਨ “ਮੇਰੀ ਸਾਈਟ ਧੀਮੀ ਹੈ,” ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਚੀਜ਼ਾਂ ਵਿੱਚੋਂ ਇੱਕ ਮਤਲਬ ਰੱਖਦੇ ਹਨ: ਮੁੱਖ ਸਮੱਗਰੀ ਦੇਰ ਨਾਲ ਦਿਖਦੀ ਹੈ, ਪੇਜ਼ ਟੈਪ ਕਰਨ 'ਤੇ ਲੈਗੀ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਲੇਆਉਟ ਲੋਡ ਹੋਣ ਦੌਰਾਨ ਖਿਸਕਦਾ ਹੈ। Google ਦੇ Core Web Vitals ਇਹ ਸ਼ਿਕਾਇਤਾਂ ਅਚ্ছੀ ਤਰ੍ਹਾਂ ਮੈਪ ਕਰਦੇ ਹਨ।
LCP (Largest Contentful Paint): ਸਭ ਤੋਂ ਵੱਡੀ “ਮੁੱਖ” ਚੀਜ਼ (ਅਕਸਰ ਹੀਰੋ ਇਮੇਜ ਜਾਂ ਹੈਡਲਾਈਨ ਬਲੌਕ) ਦਿਖਣ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ। ਜੇ LCP ਵੱਧ ਹੈ, ਯੂਜ਼ਰ ਖਾਲੀ ਪੇਜ਼ ਵੱਲ ਤੱਕਦੇ ਰਹਿ ਜਾਂਦੇ ਹਨ।
INP (Interaction to Next Paint): ਉਪਭੋਗਤਾ ਇੰਟਰੈਕਟ ਕਰਨ (ਟੈਪ, ਕਲਿੱਕ, ਟਾਈਪ) ਤੋਂ ਬਾਅਦ ਪੇਜ਼ ਕਿੰਨਾ ਤੇਜ਼ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਜੇ INP ਵੱਧ ਹੈ, ਸਾਈਟ ਚਿਪਚਿਪੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ—ਬਟਨ ਦੇਰੀ ਨਾਲ ਰਹਿੰਦੇ ਹਨ, ਮੈਨੂਜ਼ ਦੇਰ ਨਾਲ ਖੁਲਦੇ ਹਨ।
CLS (Cumulative Layout Shift): ਲੋਡ ਹੌਣ ਦੌਰਾਨ ਪੇਜ਼ ਕਿੰਨਾ ਖਿਸਕਦਾ ਹੈ। ਜੇ ਟੈਕਸਟ ਖਿਸਕਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਗਲਤ ਬਟਨ 'ਤੇ ਕਲਿੱਕ ਕਰ ਲੈਂਦੇ ਹੋ, ਇਹ CLS ਹੈ।
TTFB (Time to First Byte) ਇਹ ਵੇਲਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡਾ ਸਰਵਰ (ਅਤੇ ਰਸਤੇ ਵਿੱਚ ਜੋ ਕੁਝ ਵੀ ਹੈ) ਕੁਝ ਭੇਜਣ ਲਈ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਧੀਮਾ TTFB ਹਰ ਚੀਜ਼ ਨੂੰ ਦੇਰ ਨਾਲ ਕਰਦਾ ਹੈ: ਇਮੇਜ ਡਾਊਨਲੋਡ ਨਹੀਂ ਹੋ ਸਕਦੇ, ਫੋਂਟ ਲੋਡ ਨਹੀਂ ਹੋ ਸਕਦੇ, ਅਤੇ LCP ਆਮ ਤੌਰ 'ਤੇ ਖਰਾਬ ਹੁੰਦਾ ਹੈ। TTFB ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਹੁੰਟਿੰਗ, ਭਾਰੀ ਬੈਕਐਂਡ ਵਰਕ, ਜਾਂ ਕੈਸ਼ਿੰਗ ਨਾ ਹੋਣ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀਆਂ ਹਨ।
ਲੈਬ ਟੈਸਟ (ਜਿਵੇਂ Lighthouse) ਇੱਕ ਸੈਟ ਸ਼ਰਤਾਂ ਹੇਠਾਂ ਪੇਜ਼ ਲੋਡ ਦੀ ਨਕਲ ਕਰਦੇ ਹਨ। ਇਹ ਡੀਬੱਗਿੰਗ ਅਤੇ ਪਹਿਲਾਂ/ਬਾਅਦ ਤੁਲਨਾ ਲਈ ਉੱਤਮ ਹਨ।
ਰੀਅਲ‑ਯੂਜ਼ਰ ਡੇਟਾ (ਅਕਸਰ field data, ਜਿਵੇਂ CrUX PageSpeed Insights ਵਿੱਚ) ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਯੂਜ਼ਰ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਅਨੁਭਵ ਕਰਦੇ ਹਨ। ਇਹ ਉਹੀ ਹੈ ਜੋ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਗਿਣਤੀ ਰੱਖਦੀ ਹੈ: “ਕੀ ਲੋਕਾਂ ਲਈ ਇਹ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ?”
ਜੇ ਤੁਸੀਂ ਬਿਨਾਂ ਬੇਸਲਾਈਨ ਦੇ “ਅਪਟੀਮਾਈਜ਼” ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਮਾਂ ਬਰਬਾਦ ਹੋ ਜਾ ਸਕਦਾ ਹੈ—ਜਾਂ ਗਲਤੀਆਂ ਕਰਕੇ ਸਾਈਟ ਹੋਰ ਧੀਮੀ ਹੋ ਸਕਦੀ ਹੈ। ਪਹਿਲਾਂ 20 ਮਿੰਟ ਲੈ ਕੇ ਮਾਪ-ਪਰਖ ਕਰੋ, ਤਾਂ ਜੋ ਤੁਹਾਨੂੰ ਪਤਾ ਹੋ ਸਕੇ ਕਿ ਕਿਸ ਬਦਲਾਅ ਨੇ ਸਹੀ ਸਹਾਇਤਾ ਕੀਤੀ।
PageSpeed Insights ਵਰਤੋ (ਸਿਰਫ਼ ਨਾਮ): PageSpeed Insights। ਇਹ field data (ਜਦ ਉਪਲਬਧ) ਅਤੇ lab data ਦੋਹਾਂ ਦਿਖਾਉਂਦਾ ਹੈ। ਧਿਆਨ ਦਿਓ:
ਗਹਿਰਾਈ ਵਾਲੇ ਲੈਬ ਟੈਸਟ ਲਈ, Chrome ਵਿੱਚ Lighthouse ਚਲਾਓ:
ਜੇ ਤੁਹਾਨੂੰ ਵੇਖਣਾ ਹੈ ਕਿ ਸਟੀਕ ਤੌਰ 'ਤੇ ਕੀ ਦੇਰ ਕਰ ਰਿਹਾ ਹੈ ਤਾਂ WebPageTest (ਸਿਰਫ਼ ਨਾਮ) ਇੱਕ ਸਾਫ਼ ਟੂਲ ਹੈ। ਵਾਟਰਫਾਲ ਵਿਊ ਹਰ ਫਾਈਲ ਦੇ ਲੋਡ ਹੋਣ ਦਾ ਹੁਸੂਲ ਦਿਖਾਉਂਦੀ—HTML, ਇਮੇਜ, ਫੋਂਟ, ਸਕ੍ਰਿਪਟ ਅਤੇ ਤੀਜੇ‑ਪੱਖ ਟੈਗ—ਅਤੇ ਕਿੱਥੇ ਬਰਾਊਜ਼ਰ ਰੁਕਦਾ ਹੈ।
ਇੱਕ ਮੁੱਖ ਪੇਜ਼ (ਹੁਮ ਪੇਜ ਜਾਂ ਪ੍ਰਮੁੱਖ ਲੈਂਡਿੰਗ) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਟੈਸਟ ਕਰੋ:
ਹਰ ਟੈਸਟ ਲਈ ਲਿਖੋ:
ਇੱਕ ਛੋਟਾ ਲਾਗ (ਸਪ੍ਰੈਡਸ਼ੀਟ ਠੀਕ ਹੈ): date, tool used, URL, ਨਤੀਜੇ, ਅਤੇ ਕੀ ਬਦਲਿਆ। ਇੱਕ ਸਮੇਂ 'ਚ ਕੇਵਲ ਇੱਕ ਜਾਂ ਦੋ ਚੀਜ਼ਾਂ ਬਦਲੋ, ਫਿਰ ਉਹੀ ਹਾਲਾਤ ਵਿੱਚ ਮੁੜ‑ਟੈਸਟ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਐਪ 'ਤੇ ਇਟਰੇਟ ਕਰ ਰਹੇ ਹੋ (ਸਿਰਫ਼ ਸਟੈਟਿਕ ਸਾਈਟ ਨਹੀਂ), ਤਾਂ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਯੋਗਾਂ ਲਈ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸ਼ਿਪ ਅਤੇ ਰੋਲਬੈਕ ਕਰਨ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਹੋਵੇ ਤਾਂ ਚੰਗਾ ਹੁੰਦਾ ਹੈ। Koder.ai ਵਰਗੇ ਪிளੈਟਫ਼ਾਰਮ ਇਸ ਵਿੱਚ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਤੁਸੀਂ snapshots ਲੈ ਸਕਦੇ ਹੋ, ਬਦਲਾਅ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਜੇ ਕੋਈ “ਸਪੀਡ ਫਿਕਸ” ਗਲਤੀ ਨਾਲ UX ਨੂੰ ਖ਼ਰਾਬ ਕਰ ਦੇਵੇ ਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਰੋਲਬੈਕ ਕਰ ਸਕਦੇ ਹੋ।
ਧੀਮੇ ਪੇਜ਼ ਅਕਸਰ ਇਕ ਰਹੱਸਮਈ ਸਮੱਸਿਆ ਨਾਲ ਨਹੀਂ ਹੁੰਦੇ—ਉਹ ਕੁਝ ਆਮ “ਭਾਰ ਅਤੇ ਦੇਰੀ” ਸਮੱਸਿਆਵਾਂ ਦਾ ਨਤੀਜਾ ਹੁੰਦੇ ਹਨ ਜੋ ਮਿਲ ਕੇ ਪ੍ਰਭਾਵ ਬਣਾ ਲੈਂਦੇ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਮੋਬਾਈਲ 'ਤੇ।
ਇਮੇਜ ਆਮ ਤੌਰ 'ਤੇ ਪੇਜ਼ ਦਾ ਸਭ ਤੋਂ ਭਾਰੀ ਹਿੱਸਾ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਹੀਰੋ ਇਮੇਜ ਜੋ ਗਲਤ ਆਕਾਰ 'ਤੇ ਐਕਸਪੋਰਟ ਕੀਤਾ ਗਿਆ ਹੋਵੇ (ਜਾਂ ਪੁਰਾਣੇ ਫਾਰਮੈਟ ਵਿੱਚ) ਮੇਗਾਬਾਈਟ ਅਤੇ ਸਕਿੰਡ ਵਧਾ ਸਕਦਾ ਹੈ।
ਆਮ ਗਿਲਤੀਆਂ:
JavaScript ਪੇਜ਼ ਦੇ ਵਰਤੋਂਯੋਗ ਹੋਣ ਦੀ ਗਤੀ ਨੂੰ ਦੇਰੀ ਕਰ ਸਕਦਾ ਹੈ। ਭਾਵੇਂ ਕਿ ਪੇਜ਼ “ਦੇਖਣ ਵਿੱਚ” ਲੋਡ ਹੋ ਜਾਏ, ਇਹ ਧੀਮਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ ਜਦ ਤੱਕ ਸਕ੍ਰਿਪਟ ਲੋਡ, ਪਾਰਸ ਅਤੇ ਚਲਦੇ ਰਹਿੰਦੇ ਹਨ।
ਤੀਜੇ‑ਪੱਖ ਸਕ੍ਰਿਪਟ ਅਕਸਰ অপরਾਧੀ ਹੁੰਦੇ ਹਨ: ਚੈਟ ਵਿਡਜੈਟ, ਪਾਪ‑ਅਪ, heatmaps, A/B ਟੈਸਟਿੰਗ ਟੂਲ, ਐਡ ਟੈਗ, ਅਤੇ ਸੋਸ਼ਲ ਐਂਬੇਡ। ਹਰ ਇਕ ਵੱਖਰਾ ਨੈਟਵਰਕ ਕਾਲ ਜੋੜਦਾ ਹੈ ਅਤੇ ਬਰਾਊਜ਼ਰ ਦੇ ਜ਼ਰੂਰੀ ਕੰਮ ਨੂੰ ਦੇਰੀ ਵਿੱਚ ਪਾ ਸਕਦਾ ਹੈ।
ਕਦੇ‑ਕਦੇ ਬਰਾਊਜ਼ਰ ਤੁਹਾਡੇ ਸਰਵਰ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ ਪਹਿਲਾਂ ਕਿ ਉਹ ਕੁਝ ਵੀ ਲੋਡ ਕਰ ਸਕੇ। ਇਹ ਅਕਸਰ ਇੱਕ ਸਲੋ ਇਨੀਸ਼ੀਅਲ ਰਿਸਪਾਂਸ (TTFB) ਵਜੋਂ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਕਾਰਨਾਂ ਵਿੱਚ ਸ਼ਾਮِل ਹਨ: ਘੱਟ ਸ਼ਕਤੀ ਵਾਲੀ ਹੋਸਟਿੰਗ, ਬਰਜ਼ੀ ਡੇਟਾਬੇਸ, ਅਣ-ਉਪਟੀਮਾਈਜ਼ਡ ਥੀਮ/ਪਲੱਗਇਨ, ਜਾਂ ਐਸੇ ਪੰਨੇ ਜੋ ਹਰ ਦੌਰੇ 'ਤੇ ਡਾਇਨਾਮਿਕ ਤੌਰ 'ਤੇ ਬਣਦੇ ਹਨ।
ਜੇ ਤੁਹਾਡੀ ਸਾਈਟ ਹਰ ਦੌਰੇ 'ਤੇ ਅਫ਼ਸੋਸਨਾ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ, ਤਾਂ ਦੁਬਾਰਾ ਆਉਣ ਵਾਲੇ ਯੂਜ਼ਰ ਸਜ਼ਾ ਭੁਗਤਦੇ ਹਨ। ਬਿਨਾਂ ਕੈਸ਼ਿੰਗ ਦੇ, ਸਰਵਰ ਪੇਜ਼ ਨੂੰ ਬਾਰ‑ਬਾਰ ਦੁਬਾਰਾ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਬਰਾਊਜ਼ਰ ਉਹ ਫਾਈਲਾਂ ਦੁਬਾਰਾ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ ਜੋ ਸ਼ਾਇਦ ਬਦਲੇ ਨਹੀਂ ਹੁੰਦੀਆਂ।
ਛੋਟੀਆਂ ਫਾਈਲਾਂ (ਫੋਂਟ, ਸਕ੍ਰਿਪਟ, ਸਟਾਈਲ, ਟ੍ਰੈਕਰ) ਦੀ ਬਹੁਤਤਾ “ਰਿਕੁਐਸਟ ਓਵਰਹੈਡ” ਪੈਦਾ ਕਰਦੀ ਹੈ। ਹਰੇਕ ਫਾਈਲ ਛੋਟੀ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਮਿਲ ਕੇ ਇੰਤਜ਼ਾਰ ਦਾ ਸਮਾਂ ਜ਼ਿਆਦਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਚੰਗੀ ਖ਼ਬਰ ਇਹ ਹੈ ਕਿ ਇਹ ਕਾਰਨ ਠੀਕ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ—ਅਤੇ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਵੱਡੇ ਨਤੀਜੇ ਇਸ ਕ੍ਰਮ ਅਨੁਸਾਰ ਹਾਸਲ ਕਰੋਗੇ।
ਜੇ ਤੁਸੀਂ ਕੇਵਲ ਇੱਕ ਪਰਫਾਰਮੈਂਸ ਸੁਧਾਰ ਕਰੋ, ਤਾਂ ਉਹ ਇਮੇਜ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੀਆਂ ਸ਼ੁਰੂਆਤੀ ਸਾਈਟਾਂ 'ਤੇ, ਇਮੇਜ ਪੇਜ਼ ਦੇ ਡਾਊਨਲੋਡ ਕੀਤੇ ਭਾਰ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਹੁੰਦੇ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਮੋਬਾਈਲ 'ਤੇ। ਚੰਗੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਮੇਜ ਫਿਕਸ ਆਮ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ, ਤੇਜ਼, ਅਤੇ ਡਿਜ਼ਾਈਨ ਬਦਲਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ।
ਆਮ ਗਲਤੀ ਹੈ ਇਕ ਬਹੁਤ ਵੱਡੀ ਫੋਟੋ ਅੱਪਲੋਡ ਕਰਨਾ (ਉਦਾਹਰਣ ਲਈ 4000px) ਅਤੇ ਉਹਨੂੰ 800px 'ਤੇ ਦਿਖਾਉਣਾ। ਬਰਾਊਜ਼ਰ ਫਿਰ ਵੀ ਵੱਡੀ ਫਾਈਲ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ।
ਉਹਨਾਂ ਨੂੰ ਐਸੇ ਆਕਾਰ 'ਤੇ ਐਕਸਪੋਰਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਜੋ ਅਸਲ ਵਿੱਚ ਸਾਈਟ 'ਤੇ ਦਿਖਣ ਦੀ ਅਧਿਕਤਮ ਸੀਮਾ ਹੋ। ਉਦਾਹਰਣ ਲਈ, ਜੇ ਤੁਹਾਡੇ ਬਲੌਗ ਦੀ ਕੰਟੈਂਟ ਖੇਤਰ 800px ਹੈ, ਤਾਂ 3000–4000px ਫਾਈਲਾਂ ਨਾ ਅੱਪਲੋਡ ਕਰੋ “ਸਿਰਫ਼ ਸੁਰੱਖਿਆ ਲਈ।”
JPEG ਅਤੇ PNG ਅਜੇ ਵੀ ਚੰਗੇ ਹਨ, ਪਰ moderne ਫਾਰਮੈਟ ਅਕਸਰ ਇੱਕੋ ਦਰਸ਼ਨੀ ਗੁਣਵੱਤਾ 'ਤੇ ਕਾਫ਼ੀ ਘੱਟ ਫਾਈਲ ਸਾਈਜ਼ ਦਿੰਦੇ ਹਨ।
ਜੇ ਤੁਹਾਡਾ CMS ਜਾਂ ਇਮੇਜ ਪਲੱਗਇਨ WebP/AVIF ਨੂੰ fallback ਨਾਲ ਆਟੋਮੈਟਿਕ ਤਰੀਕੇ ਨਾਲ ਸਰਵ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਉਹ ਆਦਰਸ਼ ਹੈ।
ਕੰਪ੍ਰੈਸ਼ਨ ਵਹੀ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਤੁਰੰਤ ਸਪੀਡ ਫਾਇਦੇ ਮਿਲਦੇ ਹਨ। “ਦ੍ਰਿਸ਼ਯਤਮਕ ਤੌਰ 'ਤੇ ਇੱਕੋ ਜਿਹਾ” ਇਮੇਜ ਅਕਸਰ 30–70% ਤੱਕ ਘਟ ਸਕਦੀ ਹੈ।
ਅਤਿਰਿਕਤ metadata (ਕੈਮਰਾ ਜਾਣਕਾਰੀ, ਸਥਾਨਕਤਾ ਡੇਟਾ) ਹਟਾਓ—ਇਸ ਨਾਲ ਇਮੇਜ ਦੇ ਦੇਖਣ 'ਤੇ ਕੋਈ ਅਸਰ ਨਹੀਂ ਪਏਗਾ, ਪਰ ਬਾਈਟ ਘਟਦੇ ਹਨ।
ਵਿਆਵਹਾਰਿਕ ਨਿਯਮ: ਜਦ ਤੱਕ ਤੁਸੀਂ ਗੰਭੀਰ ਗੁਣਵੱਤਾ ਘਟਦੀ ਨਹੀਂ ਵੇਖਦੇ, ਤਦ ਤੱਕ ਕੰਪ੍ਰੈੱਸ ਕਰੋ, ਫਿਰ ਇੱਕ ਪੱਧਰ ਪਿੱਛੇ ਹਟੋ।
srcset)ਮੋਬਾਈਲ ਯੂਜ਼ਰਾਂ ਨੂੰ ਡੈਸਕਟਾਪ-ਆਕਾਰ ਦੀਆਂ ਇਮੇਜਾਂ ਡਾਊਨਲੋਡ ਨਹੀਂ ਕਰਵਾਉਣੀਆਂ ਚਾਹੀਦੀਆਂ। Responsive images ਨਾਲ ਬਰਾਊਜ਼ਰ ਸਕ੍ਰੀਨ ਚੌੜਾਈ ਅਨੁਸਾਰ ਸਹੀ ਆਕਾਰ ਚੁਣ ਲੈਂਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡੀ ਸਾਈਟ ਕਈ ਇਮੇਜ ਸਾਈਜ਼ ਆਪਣੇ ਆਪ ਜਨਰੇਟ ਕਰਦੀ ਹੈ, ਤਾਂ ਯਕੀਨ ਕਰੋ ਕਿ ਤੁਹਾਡਾ ਥੀਮ ਠੀਕ ਢੰਗ ਨਾਲ ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਤ ਰਿਹਾ ਹੈ। ਤੁਸੀਂ ਪੇਜ਼ HTML ਵਿੱਚ srcset ਵਰਗੀ ਚੀਜ਼ ਖੋਜੋ, ਇੱਕ ਹੀ ਵੱਡੀ ਫਾਈਲ ਦੀ ਥਾਂ।
ਕੋਡ ਮਿਨੀਫਾਈ ਜਾਂ ਹੋਰ ਉन्नਤ ਟਿਊਨਿੰਗ 'ਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ, ਸਿਰਫ਼ ਆਪਣੇ ਟੌਪ ਇਮੇਜਾਂ ਦੀ ਆਡਿਟ ਕਰੋ:
ਇਹ ਚਾਰ ਚੀਜ਼ਾਂ ਮੁਸਲਸਲ ਕਰੋ, ਅਤੇ ਤੁਹਾਡੀ ਵੈੱਬਸਾਈਟ ਸਪੀਡ ਅਤੇ ਪੇਜ਼ ਲੋਡ ਸਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਰੰਤ ਸੁਧਰ ਜਾਵੇਗਾ—ਕਈ ਵਾਰ Core Web Vitals ਵੀ ਸਹੀ ਦਿਸ਼ਾ ਵੱਲ ਚਲਣਗੇ।
Lazy loading ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡਾ ਪੇਜ਼ ਕੁਝ ਇਮੇਜਾਂ (ਅਤੇ ਕਈ ਵਾਰੀ iframes) ਨੂੰ ਉਹਨਾਂ ਦੇ ਸਕ੍ਰੀਨ 'ਤੇ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਡਾਊਨਲੋਡ ਕਰਨ ਵਿਚ ਦੇਰੀ ਕਰਦਾ ਹੈ। ਇਸ ਨਾਲ ਸ਼ੁਰੂਆਤੀ ਪੇਜ਼ ਲੋਡ ਸਮਾਂ ਘਟ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਬਰਾਊਜ਼ਰ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਇਕੱਠੇ ਨਹੀਂ ਲੈ ਰਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਲੰਬੇ ਪੇਜ਼ਾਂ 'ਤੇ ਜਿੱਥੇ ਬਹੁਤ ਸਾਰੀਆਂ ਇਮੇਜਾਂ ਹਨ।
Lazy loading ਸਭ ਤੋਂ ਉਪਯੋਗੀ ਹੈ:
ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਵਰਤਿਆ ਜਾਵੇ ਤਾਂ ਇਹ “ਸ਼ੁਰੂਆਤੀ ਕੰਮ” ਘਟਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਪੇਜ਼ ਨੂੰ ਤੇਜ਼ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ।
ਤੁਹਾਡਾ ਸਭ ਤੋਂ ਵੱਡਾ above-the-fold ਇਮੇਜ ਆਮ ਤੌਰ 'ਤੇ ਹੀਰੋ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ lazy-load ਕਰੋਗੇ, ਤਾਂ ਬਰਾਊਜ਼ਰ ਇਸਨੂੰ ਮੰਗ ਕਰਨ ਵਿੱਚ ਜ਼ਿਆਦਾ ਦੇਰੀ ਕਰ ਸਕਦਾ ਹੈ, ਜੋ Largest Contentful Paint (LCP) ਨੂੰ ਨੁਕਸਾਨ ਪੁਹੁੰਚਾ ਸਕਦਾ ਹੈ।
ਨਿਯਮ: ਮੁੱਖ ਹੀਰੋ ਇਮੇਜ ਜਾਂ ਪਹਿਲੀ ਸਕ੍ਰੀਨ ਦੀਆਂ ਜ਼ਰੂਰੀ ਚੀਜ਼ਾਂ ਨੂੰ ਕਦੇ lazy-load ਨਾ ਕਰੋ।
Lazy loading ਕਦੇ‑ਕਦੇ ਸਮੱਗਰੀ ਆਉਣ 'ਤੇ “ਛਲਾਂਗ” ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀ ਹੈ। CLS ਰੋਕਣ ਲਈ ਸਦਾ ਖ਼ਾਲੀ ਜਗ੍ਹਾ ਰਾਖੋ:
width ਅਤੇ height ਸੈੱਟ ਕਰੋ, ਜਾਂਇਸ ਤਰ੍ਹਾਂ ਪੇਜ਼ ਲੇਆਉਟ ਸਥਿਰ ਰਹਿੰਦਾ ਹੈ ਜਦ ਤੱਕ ਇਮੇਜ ਲੋਡ ਹੁੰਦੇ ਹਨ।
ਜੇ ਕੋਈ above-the-fold ਇਮੇਜ ਜਾਂ ਫੋਂਟ ਪਹਿਲੀ ਛਾਪ ਲਈ ਜ਼ਰੂਰੀ ਹੈ, ਤਾਂ ਉਸਨੂੰ preload ਕਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਤਾਂ ਕਿ ਬਰਾਊਜ਼ਰ ਇਸਨੂੰ ਜਲਦੀ ਖਿੱਚੇ। ਪਰ ਇਹ ਸੰਭਲ ਕੇ ਵਰਤੋ—ਬਹੁਤ ਜ਼ਿਆਦਾ preloading bandwidth ਲਈ ਮੁਕਾਬਲਾ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਚਾਹੋਗੇ ਤਾਂ ਇਸਨੂੰ ਆਪਣੇ ਮਾਪ‑ਪਰਖ ਕਦਮ ਨਾਲ ਜੋੜ ਕੇ /blog/how-to-measure-site-speed-before-you-change-anything ਵੇਖੋ।
ਕੈਸ਼ਿੰਗ ਬ੍ਰਾਉਜ਼ਰ ਲਈ ਇਹ ਕਹਿਣ ਵਰਗੀ ਹੈ: “ਮੈਂ ਇਹ ਪਹਿਲਾਂ ਹੀ ਡਾਊਨਲੋਡ ਕੀਤਾ—ਕੀ ਮੈਂ ਇਹ ਮੁੜ ਵਰਤ ਸਕਦਾ ਹਾਂ?” ਇਥੋਂ ਹੀ ਲੋਗੋ, CSS ਫਾਈਲ ਜਾਂ JavaScript ਬੰਡਲ ਹਰ ਪੇਜ਼ ਵਿਜ਼ਟ 'ਤੇ ਮੁੜ ਡਾਊਨਲੋਡ ਨਾ ਹੋਵੇ ਤਾਂ ਦੁਬਾਰਾ ਵਿਜ਼ਿਟਾਂ ਨੇਜ਼ਦੀਕੀ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਹੋ ਜਾਂਦੀਆਂ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਮੋਬਾਈਲ 'ਤੇ।
ਜਦ ਤੁਹਾਡੀ ਸਾਈਟ ਕੋਈ ਫਾਈਲ ਭੇਜਦੀ ਹੈ (ਜਿਵੇਂ styles.css ਜਾਂ app.js), ਤਾਂ ਇਹ ਦੱਸ ਸਕਦੀ ਹੈ ਕਿ ਉਹ ਫਾਈਲ ਕਿੰਨੇ ਸਮੇਂ ਲਈ ਮੁੜ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਜੇ ਬਰਾਊਜ਼ਰ ਨੂੰ 30 ਦਿਨਾਂ ਲਈ ਰੱਖਣ ਦੀ ਆਗਿਆ ਹੈ, ਤਾਂ ਅਗਲੀ ਵਾਰੀ ਲੋਕ ਸਾਈਟ 'ਤੇ ਆਉਣ 'ਤੇ ਉਹ ਫਾਈਲ ਆਪਣੇ ਡਿਵਾਈਸ ਤੋਂ ਤੁਰੰਤ ਲੋਡ ਹੋ ਜਾਵੇਗੀ, ਸਰਵਰ ਤੋਂ ਨਹੀਂ।
ਇੱਲੀ ਮੌਕੇ 'ਤੇ ਇਹ ਪਹਿਲੀ ਵਿਜ਼ਟ ਨੂੰ ਤੇਜ਼ ਨਹੀਂ ਕਰਦਾ, ਪਰ ਇਹ ਨਿਮਨ ਚੀਜ਼ਾਂ ਨੂੰ ਗਤੀਵਾਨ ਰੱਖਦਾ ਹੈ:
ਸਟੈਟਿਕ ਫਾਈਲਾਂ ਉਹ ਚੀਜ਼ਾਂ ਹਨ ਜੋ ਹਰ ਮਿੰਟ ਬਦਲਦੀਆਂ ਨਹੀਂ: ਇਮੇਜ, CSS, JavaScript, ਫੋਂਟ। ਇਹ ਲੰਬੇ ਕੈਸ਼ ਸਮਿਆਂ ਲਈ ਉੱਤਮ ਉਮੀਦਵਾਰ ਹਨ।
ਆਪਣੇ ਨਾਲ ਦੋਸ਼ਾ:
ਤੁਹਾਡਾ ਹੋਸਟ, CMS, ਜਾਂ ਫਰੇਮਵਰਕ ਇੱਕ ਸਧਾਰਨ “static asset caching” ਓਪਸ਼ਨ ਦਿੰਦਾ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਡਿਵੈਲਪਰ ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ assets ਲਈ ਯੋਗ Cache-Control headers ਸੈੱਟ ਕਰਨ ਲਈ ਕਹੋ।
ਲੋਕਾਂ ਦੀ ਆਮ ਚਿੰਤਾ: “ਜੇ ਅਸੀਂ ਫਾਈਲਾਂ ਨੂੰ ਇੱਕ ਮਹੀਨੇ ਲਈ cache ਕਰ ਰੱਖੀਏ, ਤਾਂ ਉਪਭੋਗਤਾ ਕਿਵੇਂ ਸਾਡਾ ਨਵਾਂ ਡਿਜ਼ਾਈਨ ਅਗਲੇ ਦਿਨ ਦੇਖ ਲੈਣਗੇ?” ਹੱਲ ਹੈ versioned filenames।
ਤੁਹਾਡੇ ਬਿਲਡ ਪ੍ਰਕਿਰਿਆ (ਜਾਂ ਡਿਵੈਲਪਰ) ਇਹ ਆਉਟਪੁੱਟ ਕਰ ਸਕਦੀ ਹੈ:
app.3f2a1c.jsstyles.a81b09.cssਜਦੋਂ ਸਮੱਗਰੀ ਬਦਲਦੀ ਹੈ, ਫਾਈਲਨਾॅਮ ਬਦਲ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਬਰਾਊਜ਼ਰ ਉਸਨੂੰ ਨਵੀਂ ਫਾਈਲ ਸਮਝ ਕੇ ਤੁਰੰਤ ਡਾਊਨਲੋਡ ਕਰ ਲੈਂਦਾ ਹੈ—ਇਸਦੀਆਂ ਪੁਰਾਣੀਆਂ ਵਰਜਨਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕੈਸ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਸਰਵਿਸ ਵਰਕਰ caching ਨੂੰ ਹੋਰ ਅੱਗੇ ਲੈ ਜਾ ਸਕਦੇ ਹਨ—ਤੁਹਾਡੀ ਸਾਈਟ ਨੂੰ ਇਹ ਨਿਰਣਯ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ ਕਿ ਕਿਹੜੀ ਚੀਜ਼ ਕਦੋਂ ਸਟੋਰ ਹੋਵੇ, ਅਤੇ ਕਈ ਵਾਰੀ offline ਵਰਤੋਂ ਯੋਗਤਾ ਵੀ ਦਿੰਦੇ ਹਨ। ਪਰ ਉਹ ਗ਼ਲਤ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕੀਤੇ ਜਾਣ ਤੇ “stale content” ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ। ਸ਼ੁਰੂਆਤੀ ਲਈ, ਸਰਵਿਸ ਵਰਕਰਾਂ ਨੂੰ ਉन्नਤ ਵਿਕਲਪ ਸਮਝੋ—ਉਹ ਵਧੀਆ ਹਨ ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਸਾਫ਼ ਮਕਸਦ ਹੋਵੇ ਅਤੇ ਕੋਈ ਅਨੁਭਵੀ ਵਿਅਕਤੀ ਉਹਨਾਂ ਦੀ ਦੇਖਭਾਲ ਕਰੇ।
CDN (Content Delivery Network) ਸਰਵਰਾਂ ਦਾ ਇੱਕ ਗਰੁੱਪ ਹੁੰਦਾ ਹੈ ਜੋ ਵੱਖ-ਵੱਖ ਖੇਤਰਾਂ ਵਿੱਚ ਫੈਲਾ ਹੋਇਆ ਹੁੰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਸਾਈਟ ਦੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਯਾਤਰੀ ਦੇ ਨੇੜੇ ਸਥਾਨ ਤੋਂ ਡਿਲਿਵਰ ਕਰ ਸਕਦਾ ਹੈ। ਹਰ ਨਿਵੇਦਨ ਨੂੰ ਤੁਹਾਡੇ ਇਕਲੋਤੇ ਹੋਸਟ ਸਰਵਰ ਤੱਕ ਬਦਨੌਲ ਨਾ ਜਾਣ ਦੇ ਬਜਾਏ, ਕਈ ਨਿਵੇਦਨਾਂ ਨੂੰ “ਨੇੜੇ” ਤੋਂ ਹਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
CDN ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਸਟੈਟਿਕ.assets ਲਈ—ਅਜਿਹੀਆਂ ਚੀਜ਼ਾਂ ਜੋ ਹਰ ਨਿਵੇਦਨ ਤੇ ਨਹੀਂ ਬਦਲਦੀਆਂ, ਜਿਵੇਂ ਇਮੇਜ, CSS, JavaScript ਫਾਈਲਾਂ, ਫੋਂਟ, ਅਤੇ ਵੀਡੀਓ। ਇਹ ਫਾਈਲਾਂ CDN ਸਰਵਰਾਂ 'ਤੇ ਨਕਲ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਕਈ ਯੂਜ਼ਰਾਂ ਲਈ ਦੁਬਾਰਾ ਵਰਤੀ ਜਾ ਸਕਦੀਆਂ ਹਨ।
ਕਿਸੇ ਲਈ ਜ਼ਿਆਦਾ ਲਾਭ: ਉਹ ਸਾਈਟਾਂ ਜਿਨ੍ਹਾਂ ਦੇ ਯੂਜ਼ਰ ਵੱਖ-ਵੱਖ ਸ਼ਹਿਰ/ਦੇਸ਼ਾਂ ਤੋਂ ਹਨ, ਮੀਡੀਆ-ਭਾਰੀ ਸਾਈਟਾਂ, ਅਤੇ ਕੋਈ ਵੀ ਕਾਰੋਬਾਰ ਜੋ ਪੇਦਸ਼ ਕੀਤੀਆਂ ਮੁਹਿੰਮਾਂ ਤੋਂ ਟਰੈਫਿਕ ਲੈਂਦਾ ਹੈ।
ਦੂਰੀ ਦੇ ਨਾਲ ਦੇਰੀ ਵਧਦੀ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਸਰਵਰ ਇੱਕ ਦੇਸ਼ ਵਿੱਚ ਹੈ ਅਤੇ ਯੂਜ਼ਰ ਹੋਰ ਕਾਂਟੀਨੈਂਟ 'ਚ ਹੈ, ਤਾਂ ਹਰ ਫਾਈਲ ਨਿਵੇਦਨ ਨੂੰ ਲੈਟੈਂਸੀ ਮਿਲਦੀ ਹੈ। CDN cached files ਨੂੰ edge ਸਰਵਰ ਤੋਂ serve ਕਰਕੇ ਉਸ ਦੇਰੀ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਪੇਜ਼ ਲੋਡ ਸਮਾਂ ਸੁਧਾਰਦਾ ਹੈ ਅਤੇ ਖ਼ਾਸ ਕਰਕੇ ਮੋਬਾਈਲ ਕਨੈਕਸ਼ਨ 'ਤੇ Core Web Vitals ਤੇ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ।
ਗਲਤ cache headers پوری caching ਨੂੰ ਰੋਕ ਸਕਦੇ ਹਨ (ਜਾਂ ਬਹੁਤ ਘੱਟ cache ਕਰਦੇ ਹਨ)। ਉਲਟ ਸਮੱਸਿਆ ਹੈ stale cache: ਤੁਸੀਂ ਫਾਈਲ ਅਪਡੇਟ ਕਰਦੇ ਹੋ ਪਰ ਉਪਭੋਗਤਾ ਪੁਰਾਣੀ ਫਾਈਲ ਹੀ ਵੇਖਦੇ ਰਹਿੰਦੇ ਹਨ। ਇਸ ਤੋਂ ਬਚਣ ਲਈ cache-busting filenames (ਜਿਵੇਂ app.1234.js) ਵਰਤੋ ਅਤੇ ਆਪਣੇ CDN ਦੀ "purge" ਵਿਸ਼ੇਸ਼ਤਾ ਸਿੱਖੋ।
CDN ਭਾਰੀ ਇਮੇਜ, ਬਲਾਟ ਸਕ੍ਰਿਪਟ ਜਾਂ ਧੀਮੇ ਹੋਸਟਿੰਗ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦੀ—ਪਰ ਜਦ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਠੀਕ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਇਹ ਇੱਕ ਬਲਦਾਰ multiplier ਹੋ ਸਕਦਾ ਹੈ।
CSS ਅਤੇ JavaScript ਅਕਸਰ ਉਹ “ਅਦਿੱਖਾ ਭਾਰ” ਹੁੰਦੇ ਹਨ ਜੋ ਪੇਜ਼ ਨੂੰ ਧੀਮਾ ਕਰਦੇ ਹਨ। ਇਮੇਜਾਂ ਵਾਂਗ ਨਹੀਂ, ਤੁਸੀਂ ਹਮੇਸ਼ਾ ਸਮੱਸਿਆ ਨੂੰ ਦੇਖ ਨਹੀਂ ਸਕਦੇ—ਪਰ ਤੁਹਾਡਾ ਬਰਾਊਜ਼ਰ ਫਿਰ ਵੀ ਇਹ ਫਾਈਲਾਂ ਡਾਊਨਲੋਡ, ਪਾਰਸ ਅਤੇ ਚਲਾਉਂਦਾ ਹੈ।
Minifying ਅਤਿਰਿਕਤ ਖ਼ਾਲੀਆਂ ਜਗ੍ਹਾ, ਟਿੱਪਣੀਆਂ, ਅਤੇ ਫਾਰਮੈਟਿੰਗ ਹਟਾਉਂਦਾ ਹੈ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਫਾਈਲਾਂ ਨੂੰ ਛੋਟਾ ਕਰਦਾ ਹੈ ਅਤੇ ਡਾਊਨਲੋਡ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ।
ਇਸ ਦਾ ਜੋ ਫ਼ਰਕ ਪੈਂਦਾ ਹੈ: ਫਾਈਲ ਸਾਈਜ਼ ਘਟਦੀ ਹੈ।
ਇਹ ਜੋ ਫ਼ਰਕ ਨਹੀਂ ਪਾਂਦਾ: ਬਰਾਊਜ਼ਰ ਨੂੰ ਕੋਡ ਪਾਰਸ ਅਤੇ ਚਲਾਉਣ ਲਈ ਜਿੰਨਾ ਕੰਮ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਉਹ ਘਟਦਾ ਨਹੀਂ। ਜੇ ਤੁਹਾਡੇ ਸਕ੍ਰਿਪਟ ਲੋਡ 'ਤੇ ਬਹੁਤ ਕੰਮ ਕਰ ਰਹੇ ਹਨ, ਮਿਨੀਫਾਈ ਇਸਨੂੰ ਸਹੀ ਨਹੀਂ ਕਰੇਗੀ—ਇਸ ਲਈ ਮਿਨੀਫਾਈ ਨੂੰ ਇੱਕ ਤੁਰੰਤ ਜਿੱਤ ਸਮਝੋ, ਪੂਰਾ ਹੱਲ ਨਹੀਂ।
ਬਹੁਤ ਸਾਰੀਆਂ ਸਾਈਟ ਇੱਕ "one size fits all" stylesheet ਲੋਡ ਕਰਦੀਆਂ ਹਨ ਜਿਸ ਵਿੱਚ ਉਹਨਾਂ ਪੇਜ਼ਾਂ ਅਤੇ ਕੰਪੋਨੈਂਟਾਂ ਲਈ ਨਿਯਮ ਹੁੰਦੇ ਹਨ ਜੋ ਮੌਜੂਦਾ ਪੇਜ਼ 'ਤੇ ਵਰਤੇ ਨਹੀਂ ਜਾ ਰਹੇ। ਉਹ ਵਾਧੂ CSS ਫਿਰ ਵੀ ਡਾਊਨਲੋਡ ਹੁੰਦੀ ਹੈ ਅਤੇ ਰੇਂਡਰਿੰਗ ਨੂੰ ਧੀਮਾ ਕਰ ਸਕਦੀ ਹੈ।
ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ:
ਲਕਸ਼ ਸਧਾਰਨ ਹੈ: homepage ਨੂੰ ਤੁਹਾਡੇ ਸਾਰੇ ਸਾਈਟ ਦਾ ਭਾਰ ਨਹੀਂ ਢੋਣਾ ਚਾਹੀਦਾ।
ਕੁਝ ਸਕ੍ਰਿਪਟ ਪੇਜ਼ ਨੂੰ ਇੰਟਰੈਕਟਿਵ ਬਣਨ ਤੋਂ ਰੋਕਦੇ ਹਨ ਕਿਉਂਕਿ ਬਰਾਊਜ਼ਰ ਉਨ੍ਹਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਰੁਕਦਾ ਹੈ।
defer ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਆਪਣੇ ਸਕ੍ਰਿਪਟਾਂ ਲਈ ਭਲਾ ਹੈ ਜੋ HTML ਪਾਰਸ ਹੋ ਜਾਣ ਤੋਂ ਬਾਅਦ ਚੱਲ ਸਕਦੇ ਹਨ।async ਉਹ ਸਕ੍ਰਿਪਟਾਂ ਲਈ ਚੰਗਾ ਹੈ ਜੋ ਅਜ਼ਾਦ ਹਨ ਅਤੇ ਹੋਰ ਕੋਡ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ।ਜੇ ਤੁਹਾਨੂੰ ਪਤਾ ਨਹੀਂ, ਤਾਂ ਜੋ ਕੁਝ ਵੀ ਪਹਿਲੀ ਸਕ੍ਰੀਨ ਲਈ ਜ਼ਰੂਰੀ ਨਹੀਂ ਉਹਨਾਂ ਨੂੰ defer ਕਰਕੇ ਸ਼ੁਰੂ ਕਰੋ (ਮੈਨੂਜ਼, ਐਨੀਮੇਸ਼ਨ, ਸਲਾਈਡਰ, ਟਰੇਕਿੰਗ extra)।
ਵੱਡੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਇੱਕ ਸੌ বা ਸੈਂਕੜੇ KB (ਜਾਂ ਇਸ ਤੋਂ ਵੱਧ) ਜੋੜ ਸਕਦੀਆਂ ਹਨ। ਅਗਲੇ ਵਾਰ ਕੋਈ ਫੀਚਰ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛੋ:
ਘੱਟ ਸਕ੍ਰਿਪਟ ਆਮ ਤੌਰ 'ਤੇ ਘੱਟ ਅਚਾਨਕ ਮੁਸ਼ਕਿਲਾਂ ਲਿਆਂਦੇ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਮੋਬਾਈਲ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ, ਜਿੱਥੇ CPU ਸਮਾਂ ਡਾਊਨਲੋਡ ਸਾਈਜ਼ 만큼 ਮਹੱਤਵਪੂਰਣ ਹੈ।
ਤੀਜੇ-ਪੱਖ ਸਕ੍ਰਿਪਟ ਉਹ ਕੁਛ ਹਨ ਜੋ ਤੁਹਾਡੀ ਸਾਈਟ ਕਿਸੇ ਹੋਰ ਕੰਪਨੀ ਦੇ ਸਰਵਰਾਂ ਤੋਂ ਲੋਡ ਕਰਦੀ ਹੈ। ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਫੀਚਰ ਜੋੜਦੇ ਹਨ—ਪਰ ਇਹ ਵੀ ਪੇਜ਼ ਲੋਡ ਨੂੰ ਕੁਝ ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਅਤੇ ਅਣਪਿਛਾਣੀਆਂ ਕਾਰਨਾਂ ਵਿੱਚੋਂ ਹੋ ਸਕਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਧੀਮੀਆਂ ਭਾਗਾਂ ਵਿੱਚ ਆਮ ਹਨ:
ਇਹ ਸਕ੍ਰਿਪਟ ਅਕਸਰ ਵਾਧੂ ਫਾਈਲਾਂ ਡਾਊਨਲੋਡ ਕਰਦੇ ਹਨ, ਬਹੁਤ JavaScript ਚਲਾਉਂਦੇ ਹਨ, ਅਤੇ ਕਈ ਵਾਰੀ ਬਰਾਊਜ਼ਰ ਨੂੰ ਪੇਜ਼ ਖ਼ਤਮ ਕਰਨ ਤੋਂ ਰੋਕ ਦਿੰਦੇ ਹਨ।
Chrome DevTools → Performance ਖੋਲ੍ਹੋ, ਇੱਕ ਪੇਜ਼ ਲੋਡ ਰਿਕਾਰਡ ਕਰੋ, ਅਤੇ ਵੇਖੋ:
ਤੁਸੀਂ Lighthouse ਵੀ ਚਲਾ ਸਕਦੇ ਹੋ (Chrome DevTools → Lighthouse) ਅਤੇ “Reduce JavaScript execution time” ਅਤੇ “Eliminate render-blocking resources” ਸੰਬੰਧੀ ਸਿਫਾਰਿਸ਼ਾਂ ਦੇਖੋ।
ਕੁਝ ਸ਼ੁਰੂਆਤੀ-ਦੋਸਤ ਨੁਕਤੇ:
ਪੂਰੇ YouTube/Facebook/Map ਐਂਬੇਡ ਨੂੰ ਲੋਡ ਕਰਨ ਦੀ ਥਾਂ, ਇੱਕ ਸਧਾਰਨ ਪ੍ਰੀਵਿਊ (ਥੰਬਨੇਲ + ਪਲੇ ਬਟਨ) ਦਿਖਾਓ। ਯੂਜ਼ਰ ਜਦੋਂ ਕਲਿੱਕ ਕਰੇਗਾ ਤਾਂ ਹੀ ਅਸਲੀ ਐਂਬੇਡ ਲੋਡ ਕਰੋ।
ਇਸ ਨਾਲ ਪੇਜ਼ ਹਰ ਕਿਸੇ ਲਈ ਤੇਜ਼ ਰਹਿੰਦਾ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਮੋਬਾਈਲ 'ਤੇ—ਬਿਨਾਂ ਫੀਚਰ ਨੂੰ ਹਟਾਏ।
TTFB (Time to First Byte) ਉਹ ਸਮਾਂ ਹੈ ਜੋ ਤੁਹਾਡੇ ਸਰਵਰ ਨੂੰ ਪੇਜ਼ ਦੀ ਮੰਗ ਕਰਨ ਤੋਂ ਬਾਅਦ ਪਹਿਲਾ ਬਾਈਟ ਭੇਜਣ ਵਿੱਚ ਲੱਗਦਾ ਹੈ। ਇਸਨੂੰ ਸੋਚੋ: “ਰਸੋਈ ਕਿੰਨੀ ਦੇਰ ਵਿੱਚ ਕਿਚਨ ਸਟਾਰਟ ਕਰਦੀ ਹੈ,” ਨਾ ਕਿ ਪੂਰਾ ਖਾਣਾ ਕਿੰਨੀ ਦੇਰ ਵਿੱਚ ਤਿਆਰ ਹੋਵੇ।
ਚੰਗੀ ਦਿੱਖ ਵਾਲੀ ਸਾਈਟ ਵੀ ਧੀਮੀ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ ਜੇ TTFB ਉੱਚਾ ਹੋ—ਖ਼ਾਸ ਕਰਕੇ ਮੋਬਾਈਲ ਨੈਟਵਰਕ 'ਤੇ ਜਿੱਥੇ ਹਰ ਦੇਰੀ ਵੱਧ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ।
TTFB ਆਮ ਤੌਰ 'ਤੇ ਸਰਵਰ‑ਸਾਈਡ ਕੰਮ ਨਾਲ ਸੰਬੰਧਿਤ ਹੁੰਦਾ ਹੈ:
ਭਾਵੇਂ ਕਿ ਤੁਹਾਡੀਆਂ ਇਮੇਜਾਂ ਅਤੇ ਸਕ੍ਰਿਪਟ ਠੀਕ ਹੋਣ, ਇੱਕ ਧੀਮਾ ਸਰਵਰ ਰਿਸਪਾਂਸ ਬਰਾਊਜ਼ਰ ਨੂੰ ਖਾਲੀ ਸਕ੍ਰੀਨ 'ਤੇ ਰੱਖ ਸਕਦੀ ਹੈ।
ਜੇ ਤੁਹਾਡੀ ਸਾਈਟ CMS ਨਾਲ ਬਣੀ ਹੈ ਜਾਂ ਡਾਇਨਾਮਿਕ ਤਰੀਕੇ ਨਾਲ ਪੇਜ਼ ਜਨਰੇਟ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਸਰਵਰ‑ਸਾਈਡ ਕੈਸ਼ਿੰਗ ਅਕਸਰ ਸਭ ਤੋਂ ਵੱਡੀ TTFB ਸੁਧਾਰ ਹੁੰਦੀ ਹੈ। ਸਰਵਰ ਹਰ ਯੂਜ਼ਰ ਲਈ ਇੱਕੋ ਪੇਜ਼ ਨੂੰ ਹਰ ਵਾਰੀ ਨਹੀਂ ਬਣਾਉਂਦਾ—ਉਸ ਦੀ ਥਾਂ ਇੱਕ ਤਿਆਰ ਵਰਜਨ ਸਟੋਰ ਕਰ ਲੈਂਦਾ ਹੈ।
ਪ੍ਰਯੋਗਿਕ ਉਦਾਹਰਣ:
ਟੈਕਸਟ-ਆਧਾਰਿਤ ਫਾਈਲਾਂ (HTML, CSS, JavaScript) ਲਈ Brotli (ਪਸੰਦیدہ) ਜਾਂ Gzip ਕੰਪ੍ਰੈਸ਼ਨ ਚਾਲੂ ਕਰੋ। ਇਸ ਨਾਲ ਨੈੱਟਵਰਕ 'ਤੇ ਜਾਣ ਵਾਲੇ ਡੇਟਾ ਦੀ مقدار ਘਟਦੀ ਹੈ, ਜੋ ਖ਼ਾਸ ਕਰਕੇ ਰੀਪਿਟ ਲੋਡ ਅਤੇ ਮੋਬਾਈਲ ਯੂਜ਼ਰਾਂ ਲਈ ਪ੍ਰਤੀਤਾਵਾਦੀ ਗਤੀ ਵਿੱਚ ਸੁਧਾਰ ਕਰ ਸਕਦੀ ਹੈ।
ਚੰਗੀ ਹੋਸਟਿੰਗ TTFB ਘਟਾ ਸਕਦੀ ਹੈ, ਪਰ ਸਭ ਤੋਂ ਸਮਝਦਾਰ ਹੈ ਪਹਿਲਾਂ ਮੌਕੇ ਦੀਆਂ ਅਸੂਲੀਆਂ (ਵੱਡੇ ਇਮੇਜ, ਬਲਾਟ ਸਕ੍ਰਿਪਟ, ਭਾਰੀ JavaScript) ਨੂੰ ਠੀਕ ਕਰਨਾ। ਜੇ ਬਰਾਊਜ਼ਰ MBs ਡਾਊਨਲੋਡ ਕਰ ਰਿਹਾ ਹੈ, ਤੇਜ਼ ਹੋਸਟਿੰਗ ਪੇਜ਼ ਨੂੰ ਸੱਚਮੁੱਚ ਤੇਜ਼ ਮਹਿਸੂਸ ਨਹੀਂ ਕਰਾਏਗੀ।
ਜਦ ਤੁਸੀਂ ਮੂਲ ਗੱਲਾਂ ਹੱਲ ਕਰ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਹੋਸਟਿੰਗ ਅਪਗਰੇਡ (ਵੱਧ CPU/RAM, tuned database, ਬਿਹਤਰ runtime) ਆਖ਼ਰੀ ਕਦਮ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਤੁਹਾਡੀ ਸਾਈਟ ਨੂੰ ਸਥਿਰ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਨਵੀਂ ਉਤਪਾਦ ਬਣਾ ਰਹੇ ਹੋ ਅਤੇ ਸ਼ੁਰੂ ਤੋਂ ਘੱਟ ਹੋਸਟਿੰਗ ਵੈਰੀਏਬਲ ਚਾਹੀਦੇ ਹੋ, ਤਾਂ managed platform ਬਾਰੇ ਸੋਚੋ ਜੋ sensible defaults ਨਾਲ ਆਉਂਦੇ ਹਨ। ਉਦਾਹਰਣ ਵਜੋਂ, Koder.ai AWS 'ਤੇ ਐਪ ਹੋਸਟ ਕਰਦਾ ਹੈ ਅਤੇ deployments, custom domains, ਅਤੇ environment rollbacks ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ—ਉਹ ਲਾਭ ਹਨ ਜੇ ਤੁਸੀਂ ਖੇਤਰ-ਅਨੁਸਾਰ ਪ੍ਰਦਰਸ਼ਨ ਚੈੱਕ ਕਰ ਰਹੇ ਹੋ ਜਾਂ ਡੇਟਾ ਰਿਹਾਇਸ਼ ਦੀ ਲੋੜ ਹੈ।
ਤੁਹਾਨੂੰ ਵੱਡਾ ਪ੍ਰੋਜੈਕਟ ਪਲਾਨ ਨਹੀਂ ਲੋੜੀਦਾ—ਤੁਹਾਨੂੰ ਇੱਕ ਸਧਾਰਨ ਕ੍ਰਮ, ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਦਾ ਤਰੀਕਾ, ਅਤੇ ਐਸੇ ਸੁਧਾਰਾਂ ਵੱਲ ਐਗਰਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਪੇਜ਼ ਲੋਡ ਸਮਾਂ ਘਟਾਉਂਦੇ ਹਨ।
Day 1: ਮਾਪ (ਕੁਝ ਵੀ ਛੇੜਨ ਤੋਂ ਪਹਿਲਾਂ).
2–3 ਮਹੱਤਵਪੂਰਨ ਪੇਜ਼ ਚੁਣੋ (ਹੁਮ ਪੇਜ, ਇੱਕ ਮੁੱਖ ਲੈਂਡਿੰਗ, ਇੱਕ ਲੋਕਪ੍ਰਿਯ ਬਲੌਗ ਪੋਸਟ/ਉਤਪਾਦ ਪੇਜ਼). ਚਲਾਓ:
ਮੋਬਾਈਲ ਪਰਫਾਰਮੈਂਸ ਅਤੇ ਡੈਸਕਟਾਪ ਦਾ ਬੇਸਲਾਈਨ ਲਿਖ ਲਵੋ। ਜੇ ਹੋ ਸਕੇ ਤਾਂ ਇੱਕ ਅਸਲੀ ਫੋਨ 'ਤੇ cellular ਤੇ ਵੀ ਟੈਸਟ ਕਰੋ—ਇਹ ਅਕਸਰ ਲੈਬ ਟੈਸਟਾਂ ਵਿੱਚ ਲੁਕੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਿਖਾਉਂਦਾ ਹੈ।
Days 2–3: ਇਮੇਜ ਠੀਕ ਕਰੋ (ਸਭ ਤੋਂ ਤੇਜ਼, ਭਰੋਸੇਯੋਗ ਜਿੱਤ).
ਤਰਜੀਹ:
ਸਿਰਫ਼ ਕੁਝ ਇਮੇਜਾਂ ਅਪਡੇਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਮੁੜ‑ਟੈਸਟ ਕਰੋ ਤਾਂ ਕਿ ਪ੍ਰਭਾਵ ਨੂੰ ਦੇਖਿਆ ਜਾ ਸਕੇ।
Days 4–5: ਕੈਸ਼ਿੰਗ ਠੀਕ ਕਰੋ (ਦੁਬਾਰਾ ਵਿਜ਼ਿਟ ਤੇਜ਼ ਬਣਾਓ).
ਸਧਾਰਨ ਬ੍ਰਾਉਜ਼ਰ ਕੈਸ਼ਿੰਗ ਅਤੇ ਸਰਵਰ/ਪੇਜ਼ ਕੈਸ਼ਿੰਗ ਚਾਲੂ ਕਰੋ ਜਿਵੇਂ ਉਚਿਤ ਹੋਵੇ। ਲਕਸ਼ ਸਧਾਰਨ ਹੈ: ਇੱਕੋ ਫਾਈਲ ਹਰ ਦੌਰ ਤੇ ਦੁਬਾਰਾ ਨਾ ਬਣਾਈ ਜਾਵੇ। ਕੈਸ਼ਿੰਗ ਚਾਲੂ ਕਰਨ ਤੋਂ ਬਾਅਦ ਜਾਂਚ ਕਰੋ ਕਿ ਪੇਜ਼ ਨੂੰ ਮੁੜ ਆਉਣ 'ਤੇ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।
Days 6–7: JavaScript ਘਟਾਓ (ਲੰਬੇ ਸਮੇਂ ਲਈ ਸਭ ਤੋਂ ਵੱਡਾ ਨਫ਼ਾ).
ਖੋਜੋ:
ਇਥੋਂ ਛੋਟੇ ਬਦਲਾਅ ਇੰਟਰਐਕਟਿਵਟੀ ਅਤੇ Core Web Vitals ਵਿੱਚ ਡਰਾਮੇਟਿਕ ਸੁਧਾਰ ਲਿਆ ਸਕਦੇ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਮੋਬਾਈਲ 'ਤੇ।
ਹਰ ਵੱਡੇ ਸੋਧ (ਇਮੇਜ, ਕੈਸ਼ਿੰਗ, ਸਕ੍ਰਿਪਟ) ਤੋਂ ਬਾਅਦ ਤਿੰਨ ਜਲਦੀ ਚੈੱਕ ਕਰੋ:
ਜੇ ਤੁਸੀਂ ਇਮੇਜ ਅਤੇ ਕੈਸ਼ਿੰਗ ਠੀਕ ਕਰਨ ਦੇ ਬਾਅਦ ਵੀ ਟਿਕਾਕਾਰ TTFB ਵੇਖਦੇ ਹੋ, ਤਾਂ ਅਕਸਰ ਇਹ ਹੋਸਟਿੰਗ/ਸਰਵਰ ਸੈਟਅੱਪ, ਧੀਮਾ ਡੇਟਾਬੇਸ, ਜਾਂ ਭਾਰੀ ਬੈਕਐਂਡ ਵਰਕ ਵੱਲ ਇਸ਼ਾਰਾ ਹੁੰਦਾ ਹੈ। ਨਾਲ ਹੀ ਜੇ ਤੁਹਾਡੀ ਸਾਈਟ ਇੱਕ پیچیدہ ਐਪ ਹੈ (ਮੈਂਬਰਸ਼ਿਪ, ਮਾਰਕੀਟਪਲੇਸ, ਬਹੁਤ personalization) ਜਿੱਥੇ “ਕੈਸ਼ ਕਰ ਦਿਓ” ਆਮ ਤੌਰ 'ਤੇ ਸਿੱਧਾ ਹੱਲ ਨਹੀਂ, ਤਾਂ ਮਦਦ ਲੈਣ 'ਤੇ ਵਿਚਾਰ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਸਰਵਰ ਰਿਸਪਾਂਸ ਸਮਾਂ 'ਤੇ ਡੂੰਘੀ ਗਾਈਡ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ /blog/ttfb-explained ਵੇਖੋ।
ਵੈੱਬਸਾਈਟ ਦੀ ਗਤੀ ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਚੀਜ਼ਾਂ ਦਾ ਮਤਲਬ ਹੁੰਦੀ ਹੈ:
ਇੱਕ ਪੇਜ਼ ਦਿਖਾਈ ਦੇ ਸਕਦਾ ਹੈ ਕਿ ਲੋਡ ਹੋ ਗਿਆ ਹੈ ਪਰ ਫਿਰ ਵੀ ਧੀਮਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ ਜੇ JavaScript ਬਿਜੀ ਹੋਵੇ ਜਾਂ ਲੇਆਉਟ ਖਿਸਕ ਰਿਹਾ ਹੋਵੇ।
Core Web Vitals ਆਮ ਯੂਜ਼ਰ ਸ਼ਿਕਾਇਤਾਂ ਨਾਲ ਮਿਲਦੇ ਹਨ:
ਇਨ੍ਹਾਂ ਨੂੰ ਸੁਧਾਰ ਕੇ ਅਕਸਰ ਲੋਕਾਂ ਨੂੰ ਹਕੀਕਤੀ ਤੇਜ਼ੀ ਮਹਿਸੂਸ ਹੋਣੀ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੀ ਹੈ, ਸਿਰਫ਼ ਸਕੋਰ ਨਹੀਂ।
ਇਹ ਪ੍ਰਯੋਗਿਕ ਟārਗੇਟ ਵਰਤੋ:
ਇਹਨਾਂ ਨੂੰ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ ਵਜੋਂ ਲੋ—ਸਭ ਤੋਂ ਖਰਾਬ मीਟਰਿਕ ਨੂੰ ਪਹਿਲਾਂ ਸੁਧਾਰੋ।
ਬਿਨਾਂ ਅਨਮੋਲਨਾ ਦੇ ਬੇਸਲਾਈਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਓ:
ਡਿਵਾਇਸ, ਨੈਟਵਰਕ, ਟੈਸਟ ਦੀ ਜਗ੍ਹਾ ਅਤੇ ਵਾਸਤਵਿਕ URL ਲਿਗਭਗ ਦਰਜ ਕਰੋ, ਅਤੇ ਇਕ ਵਾਰੀ ਵਿੱਚ 1–2 ਚੀਜ਼ਾਂ ਹੀ ਬਦਲੋ।
ਵੱਡੇ ਕਾਰਨ ਆਮ ਤੌਰ 'ਤੇ:
ਇਹਨਾਂ ਨੂੰ ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਠੀਕ ਕਰਨ ਨਾਲ ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਨਤੀਜੇ ਮਿਲਦੇ ਹਨ।
ਕਿਉਂਕਿ ਇਮੇਜ ਆਮ ਤੌਰ 'ਤੇ ਪੇਜ਼ ਦੇ ਸਭ ਤੋਂ ਵੱਡੇ ਫਾਇਲ ਹੁੰਦੇ ਹਨ ਅਤੇ ਇਹ ਡਾਊਨਲੋਡ ਸਮਾਂ ਅਤੇ LCP ਦੋਹਾਂ 'ਤੇ ਅਸਰ ਪਾਉਂਦੇ ਹਨ। ਚਾਰ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ:
Lazy loading ਲੰਬੇ ਪੇਜ਼ਾਂ ਜਾਂ ਬਹੁਤ ਸਾਰੀਆਂ ਓਫ-ਸਕ੍ਰੀਨ ਸਮਗਰੀ ਲਈ ਬਹੁਤ ਫਾਇਦੇਮੰਦ ਹੁੰਦੀ ਹੈ।
ਅਮਲ ਵਿੱਚ ਨਿਯਮ:
width ਅਤੇ height ਸੈੱਟ ਕਰੋ ਜਾਂ CSS ਨਾਲ ਫਿਕਸਡ ਅਸਪੈਕਟ ਰੇਸ਼ਿਓ ਵਰਤੋ.ਕੈਸ਼ਿੰਗ ਮੁੱਖ ਤੌਰ 'ਤੇ ਦੁਬਾਰਾ ਵਿਜ਼ਿਟਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ:
app.3f2a1c.js) ਵਰਤੋ ਤਾਂ ਕਿ ਨਵੀਆਂ ਫਾਈਲਾਂ ਤੁਰੰਤ ਲਿਆ ਜਾਣ।ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕੈਸ਼ਿੰਗ ਨਾਲ ਰੀ-ਡਾਊਨਲੋਡ ਅਤੇ ਸਰਵਰ ਕੰਮ ਘਟ ਜਾਂਦਾ ਹੈ ਬਿਨਾਂ ਅਪਡੇਟ ਟ੍ਰੈਪ ਹੋਏ।
CDN ਉਹਨਾਂ ਸਾਈਟਾਂ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦੇ ਯੂਜ਼ਰ ਵੱਖ-ਵੱਖ ਸ਼ਹਿਰਾਂ/ਦੇਸ਼ਾਂ ਵਿੱਚ ਹਨ ਅਤੇ ਜਿਨ੍ਹਾਂ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਸਟੈਟਿਕ ਫਾਇਲ ਹਨ।
ਵਧੀਆ ਲਈ:
ਧਿਆਨ ਰੱਖੋ:
CDN ਆਪਣੇ ਆਪ ਭਾਰੀ ਪੇਜ਼ਾਂ ਨੂੰ ਸਹੀ ਨਹੀਂ ਕਰਦੇ—ਪਹਿਲਾਂ ਇਮੇਜ/ਸਕ੍ਰਿਪਟ ਠੀਕ ਕਰੋ, ਫਿਰ CDN ਇੱਕ ਗੁਣਾ ਵਜੋਂ ਜੋੜੋ।
ਸਧਾਰਨ ਕ੍ਰਮ ਜੋ ਤੁਸੀਂ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹੋ:
ਹਰ ਕਦਮ ਤੋਂ ਬਾਅਦ ਉਨ੍ਹਾਂ ਹੀ ਪੇਜ਼ਾਂ 'ਤੇ ਉਹੀ ਟੈਸਟ ਰਾਹੀਂ ਮੁੜ ਚੈੱਕ ਕਰੋ ਅਤੇ ਸਾਈਟ 'ਤੇ ਕਲਿੱਕ ਕਰਕੇ ਯੂਜ਼ਰ ਦਿੱਲਚਸਪੀ ਦੀ ਜਾਂਚ ਕਰੋ।
srcset)ਇਹ ਬਦਲਾਅ ਆਮ ਤੌਰ 'ਤੇ ਘੱਟ-ਖਤਰਨਾਕ ਅਤੇ ਤੁਰੰਤ ਮਾਪਯੋਗ ਹੁੰਦੇ ਹਨ।
ਜੇ ਕੁਝ ਪਹਿਲੀ ਸਕ੍ਰੀਨ ਲਈ ਅਹੰਕਾਰ ਹੈ ਤਾਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੋਚ ਕੇ ਹੀ preload ਵਰਤੋ।