04 ਮਾਰਚ 2025·8 ਮਿੰਟ
ਮੋਬਾਈਲ-ਅਨੁਕੂਲ, ਲਾਇਟਨਿੰਗ-ਫਾਸਟ ਵੈੱਬਸਾਈਟ ਕਿਵੇਂ ਬਣਾਈਏ
ਫੋਨ ਲਈ ਮਿੱਤਰ-ਅਨੁਕੂਲ ਅਤੇ ਤੇਜ਼ ਸਾਈਟ ਬਣਾਉਣਾ ਸਿਖੋ: ਰਿਸਪਾਂਸਿਵ ਲੇਆਊਟ, ਤਸਵੀਰਾਂ ਦੀ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ, ਹਲਕਾ ਕੋਡ, ਕੈਸ਼ਿੰਗ, ਟੈਸਟਿੰਗ ਅਤੇ ਲਗਾਤਾਰ ਨਿਗਰਾਨੀ।
ਫੋਨ ਲਈ ਮਿੱਤਰ-ਅਨੁਕੂਲ ਅਤੇ ਤੇਜ਼ ਸਾਈਟ ਬਣਾਉਣਾ ਸਿਖੋ: ਰਿਸਪਾਂਸਿਵ ਲੇਆਊਟ, ਤਸਵੀਰਾਂ ਦੀ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ, ਹਲਕਾ ਕੋਡ, ਕੈਸ਼ਿੰਗ, ਟੈਸਟਿੰਗ ਅਤੇ ਲਗਾਤਾਰ ਨਿਗਰਾਨੀ।
ਜ਼ਿਆਦਾਤਰ ਵਿਜ਼ਟਰ ਤੁਹਾਡੀ ਸਾਈਟ ਨੂੰ ਫੋਨ 'ਤੇ ਵੇਖਦੇ ਹਨ—ਅਕਸਰ ਝਟਕਿਓਂ ਭਰੇ ਨੈੱਟਵਰਕ ਤੇ, ਇਕੱਠੇ ਕਈ ਕੰਮ ਕਰਦਿਆਂ। ਜੇ ਪੇਜ ਧੀਮਾ ਜਾਂ ਅਟਪਟਾਹਟਾ ਹੋਵੇ, ਉਹ "ਰੁਕਦੇ" ਨਹੀਂ—ਉਹ ਚਲੇ ਜਾਂਦੇ ਹਨ। ਇਸੀ ਲਈ mobile-optimized website ਅਤੇ website speed optimization ਸਿਰਫ਼ ਤਕਨੀਕੀ ਚੀਜ਼ਾਂ ਨਹੀਂ ਹਨ: ਇਹ ਬਾਉਂਸ ਰੇਟ, ਭਰੋਸਾ ਅਤੇ ਕਨਵਰਸ਼ਨਾਂ (ਸਾਈਨਅਪ, ਖਰੀਦ, ਕਾਲ, ਬੁਕਿੰਗ) 'ਤੇ ਸਿੱਧਾ ਅਸਰ ਪਾਉਂਦੇ ਹਨ।
ਮੋਬਾਈਲ 'ਤੇ ਹਰ ਵਾਧੂ ਸਕਿੰਟ friction ਵਧਾਉਂਦਾ ਹੈ: ਬਟਨ ਦਬਾਉਣਾ ਮੁਸ਼ਕਲ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ, ਟੈਕਸਟ ਪੜ੍ਹਨ ਵਿੱਚ ਔਖਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਪੇਜ ਲੋਡ ਹੋਣ ਦੌਰਾਨ "ਟੁੱਟਿਆ" ਦਿੱਸ ਸਕਦਾ ਹੈ। ਤੇਜ਼, ਸਥਿਰ ਪੇਜ ਲੋਕਾਂ ਨੂੰ ਅੱਗੇ ਵਧਣ ਦਿੰਦਾਂ ਹੈ—ਸਕ੍ਰੋਲ, ਪੜ੍ਹਾਈ ਅਤੇ ਐਕਸ਼ਨ ਪੂਰੇ ਕਰਨ ਲਈ—ਬਜਾਏ ਛੱਡ ਦੇਣ ਦੇ।
Google ਦੇ Core Web Vitals ਉਹ ਪੈਰਾਮੀਟਰ ਹਨ ਜੋ ਲੋਕਾਂ ਦੇ ਮਹਿਸੂਸ ਕਰਨ ਨਾਲ ਘੁੰਮਦੇ ਹਨ:
ਇਹ ਮੈਟ੍ਰਿਕਸ ਵਧੀਆ ਸਮੱਗਰੀ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦੇ, ਪਰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਨ ਕਿ ਤੁਹਾਡੀ ਸਮੱਗਰੀ ਫੋਨ 'ਤੇ ਵਰਤਣਯੋਗ ਹੈ।
ਸਪਸ਼ਟ ਟੀਚੇ ਰੱਖੋ ਤਾਂ ਕਿ ਬਾਅਦ ਦੀਆਂ ਫੈਸਲਿਆਂ ਨੂੰ ਆਸਾਨੀ ਹੋਵੇ:
ਨਾਲ ਹੀ ਇੱਕ ਐਸਾ ਪੇਜ ਜੋ "ਮਹਿਸੂਸ" ਤੌਰ 'ਤੇ ਮਿੱਠਾ ਹੋਵੇ: ਦਿੱਖੀ ਸਮੱਗਰੀ ਤੇਜ਼ੀ ਨਾਲ ਆਏ, ਇੰਟਰੈਕਸ਼ਨ ਤੁਰੰਤ ਜਵਾਬ ਦੇ, ਅਤੇ ਕੁਝ ਵੀ ਯੂਜ਼ਰ ਦੀ ਉਂਗਲ ਹੇਠਾਂ ਹਿਲੇ ਨਾ।
ਅਕਸਰ ਇਹ ਇੱਕ ਵੱਡੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੁੰਦੀ—ਇਹ ਕਈ ਛੋਟੀਆਂ ਚੀਜ਼ਾਂ ਦਾ ਜੋੜ ਹੁੰਦਾ ਹੈ:
ਕੋਈ ਵੀ redesign ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਜਾਣੋ ਕਿ ਤੁਹਾਡੀ ਸਾਈਟ ਅਸਲੀ ਵਿਜ਼ਟਰਾਂ ਲਈ ਕਿਵੇਂ ਵਰਤ ਰਹੀ ਹੈ। ਡੈਸਕਟਾਪ Chrome 'ਚ ਤੇਜ਼ ਕਨੈਕਸ਼ਨ ਇਕੱਤਰ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਛੁਪਾ ਸਕਦਾ ਹੈ: ਧੀਮਾ ਲੋਡ, ਹਿਲਦਾ-ਡੁੱਲਦਾ ਲੇਆਊਟ, ਅਤੇ ਲੱਗਦੇ ਟੈਪ।
ਆਪਣੇ ਮੁੱਖ ਪੇਜ (ਹੋਮਪੇਜ, ਇੱਕ ਲੋਕਪ੍ਰਿਯ ਬਲੌਗ ਪੋਸਟ, ਪ੍ਰੋਡਕਟ/ਪ੍ਰਾਇਸਿੰਗ, ਚੈੱਕਆਊਟ/ਕਾਂਟੈਕਟ) ਘੱਟੋ-ਘੱਟ ਇੱਕ iPhone ਅਤੇ ਇੱਕ Android 'ਤੇ ਖੋਲ੍ਹੋ ਜੇ ਸੰਭਵ ਹੋਵੇ। ਧਿਆਨ ਦਿਓ ਕਿ ਤੁਸੀਂ ਕੀ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ ਬਿਨਾਂ ਖਾਸ ਤੌਰ 'ਤੇ ਸਮੱਸਿਆ ਲੱਭਣ ਦੇ:
Safari ਅਤੇ Chrome ਵਿੱਚ ਵੀ ਟੈਸਟ ਕਰੋ। ਖਾਸ ਕਰਕੇ Mobile Safari ਫੋਂਟ, sticky header ਅਤੇ viewport ਕੁਝ ਖਾਸ ਸਮੱਸਿਆਵਾਂ ਦਿਖਾ ਸਕਦਾ ਹੈ ਜੋ ਡੈਸਕਟਾਪ ਟੈਸਟ ਨਹੀਂ ਦਿਖਾਉਂਦਾ।
ਅਗਲੇ ਕਦਮ ਵਜੋਂ Chrome DevTools (Mobile mode) ਵਿੱਚ Lighthouse ਆਡਿਟ ਚਲਾਓ ਅਤੇ PageSpeed Insights ਵੇਖੋ। ਸਿਰਫ਼ ਸਕੋਰ 'ਤੇ ਹੀ ਧਿਆਨ ਨਾ ਦਿਓ—ਰਿਪੋਰਟ ਵਰਤ ਕੇ ਵੱਡੇ ਸਮੱਸਿਆ-ਖੇਤਰ ਲੱਭੋ ਜਿਵੇਂ:
ਮੁੱਖ ਪੇਜਾਂ 'ਤੇ ਵਾਰ-ਵਾਰ ਆਉਣ ਵਾਲੀਆਂ ਟੋਪ 5 ਤਰਤੀਬਾਂ ਲਿਖੋ—ਉਹੀ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾਂ ਠੀਕ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਚੀਜ਼ਾਂ ਹੁੰਦੀਆਂ ਹਨ।
Core Web Vitals "ਗਤੀ" ਨੂੰ ਯੂਜ਼ਰ ਅਨੁਭਵ ਵਿੱਚ ਬਦਲਦੇ ਹਨ:
ਆਪਣੇ ਮੁੱਖ ਪੇਜਾਂ ਲਈ ਇਹ ਮੈਟ੍ਰਿਕ ਟਰੈਕ ਕਰੋ। ਇਹ ਤੁਹਾਡੇ "ਪਹਿਲਾਂ" ਸਨੈਪਸ਼ਾਟ ਵਜੋਂ ਕੰਮ ਕਰੇਗਾ।
ਕਈ ਯੂਜ਼ਰ perfect Wi‑Fi 'ਤੇ ਨਹੀਂ ਹੁੰਦੇ। Chrome DevTools ਵਿੱਚ धीਮੇ ਕਨੈਕਸ਼ਨ (3G/4G) ਸਿਮਿਊਲੇਟ ਕਰੋ ਅਤੇ ਦੇਖੋ ਪਹਿਲਾਂ ਕੀ ਖਰਾਬ ਹੁੰਦਾ ਹੈ। ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਇੱਕ ਓਲਡਰ ਜਾਂ ਨੀਚੇ-ਮੱਧ ਪਡ਼੍ਹਤ Android ਡਿਵਾਈਸ 'ਤੇ ਵੀ ਟੈਸਟ ਕਰੋ—CPU ਸੀਮਾਵਾਂ INP ਸਮੱਸਿਆਵਾਂ ਨੁਹਾਂ ਲਿਆ ਸਕਦੀਆਂ ਹਨ ਜੋ ਆਧੁਨਿਕ ਫੋਨਾਂ ਨੇਛੁਪਾ ਦਿੰਦੀਆਂ ਹਨ।
ਇਸਨੂੰ ਹਲਕਾ ਰੱਖੋ: ਇੱਕ ਪੇਜ ਦਾ ਡੌਕ ਜਾਂ ਸਪ੍ਰੈਡਸ਼ੀਟ ਜੋ ਪ੍ਰਤੀ ਪੇਜ ਤੁਹਾਡਾ ਮੌਜੂਦਾ LCP/INP/CLS, ਕੁੱਲ ਪੇਜ ਵਜ਼ਨ ਅਤੇ ਕੁਝ ਨੋਟ (ਉਦਾਹਰਨ: "hero image 1.8MB ਹੈ", "ਚੈਟ ਵਿਜ਼ਿਟ ਲੋਡ ਰੋਕਦਾ ਹੈ") ਦਰਸਾਵੇ। ਤੁਸੀਂ ਇਸ ਬੇਸਲਾਈਨ ਨੂੰ ਵਰਤੋਂਗੇ ਤਾਂ ਜੋ ਹਰ ਬਦਲਾਅ ਨਾਲ ਅਸਲ ਪ੍ਰਦਰਸ਼ਨ ਸੁਧਾਰ ਪ੍ਰਮਾਣਿਤ ਕਰ ਸਕੋ—ਕੇਵਲ ਸਕੋਰ ਨਹੀਂ।
ਇੱਕ ਤੇਜ਼ ਸਾਈਟ ਫਿਰ ਵੀ ਮੋਬਾਈਲ 'ਤੇ "ਧੀਮੀ" ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ ਜੇ ਲੋਕ ਪੜ੍ਹ ਨਹੀਂ ਸਕਦੇ, ਟੈਪ ਨਹੀਂ ਕਰ ਸਕਦੇ ਜਾਂ ਆਪਣੀ ਲੋੜ ਦੀ ਚੀਜ਼ ਨਹੀਂ ਲੱਭ ਸਕਦੇ। ਮੋਬਾਈਲ-ਫਰਸਟ UX ਦਾ ਮਤਲਬ ਸਭ ਤੋਂ ਛੋਟੇ ਸਕਰੀਨ ਅਤੇ ਟਚ ਇਨਪੁਟ ਲਈ ਪਹਿਲਾਂ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਹੈ—ਫਿਰ ਵੱਡੇ ਸਕਰੀਨਾਂ ਲਈ ਸੁਧਾਰ ਕਰਨਾ।
ਰਿਸਪਾਂਸਿਵ ਗ੍ਰਿਡ ਅਤੇ ਫਲੂਇਡ ਐਲਿਮੈਂਟ ਵਰਤੋਂ ਤਾਂ ਜੋ ਲੇਆਊਟ ਕਿਸੇ ਵੀ ਸਕਰੀਨ ਆਕਾਰ 'ਤੇ ਸੁਚਜੀਵ ਤਰੀਕੇ ਨਾਲ ਅਡੈਪਟ ਹੋ ਜਾਵੇ। ਫਿਕਸਡ-ਚੌੜਾਈ ਕੰਟੇਨਰ ਅਤੇ Overflow ਕਰਨ ਵਾਲੇ ਕੰਪੋਨੈਂਟਾਂ ਤੋਂ ਬਚੋ। ਆਮ ਬ੍ਰੇਕਪੋਇੰਟ (360–430px ਫੋਨਾਂ, ਛੋਟੇ ਟੈਬਲੇਟ) 'ਤੇ ਟੈਸਟ ਕਰੋ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਮੁੱਖ ਸੈਕਸ਼ਨ ਸੀਧੇ-ਸਪਸਟ ਦਿਸਦੇ ਹਨ ਤੇ pinch-zoom ਦੀ ਲੋੜ ਨਾ ਪਏ।
ਪੜ੍ਹਨ ਯੋਗਤਾ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ: ਆਰਾਮਦਾਇਕ ਫੋਂਟ-ਸਾਈਜ਼, ਮਜ਼ਬੂਤ ਕੰਟ੍ਰਾਸਟ ਅਤੇ ਵਧੇਰੇ ਲਾਈਨ ਸਪੇਸਿੰਗ। ਟਚ ਲਈ, ਟੈਪ ਟਾਰਗੇਟ (ਬਟਨ, ਲਿੰਕ, ਫਾਰਮ ਇਨਪੁਟ) ਵੱਡੇ ਅਤੇ ਅਲੱਗ-ਅਲੱਗ ਹੋਣ ਚਾਹੀਦੇ ਹਨ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਗਲਤ-ਟੈਪ ਨਾ ਕਰੇ—ਖ਼ਾਸ ਕਰਕੇ ਮੀਨੂ, ਫਿਲਟਰ ਅਤੇ ਚੈੱਕਆਊਟ/ਕਾਂਟੈਕਟ ਫਾਰਮਾਂ ਵਿੱਚ।
ਅਚਾਨਕ ਹਿਲਨਾ ਭਰੋਸਾ ਘਟਾਉਂਦਾ ਹੈ।
ਸਥਾਨ ਰਿਜਰਵ ਕਰੋ:
ਇਸ ਨਾਲ ਪੇਜ ਲੋਡ ਦੌਰਾਨ ਸਥਿਰ ਰਹੇਗਾ ਅਤੇ Core Web Vitals, ਖ਼ਾਸ ਕਰਕੇ CLS, ਸੁਧਰੇਗਾ।
ਮੋਬਾਈਲ ਨੈਵੀਗੇਸ਼ਨ ਨੂੰ ਆਪੇ-ਮਾਨਯੋਗ ਰੱਖੋ:
ਹੁੰਮਾਰਾ ਫੋਕਸ ਸਿਰਫ ਹੋਮਪੇਜ ਨਾ ਰੱਖੋ—ਉਹ ਪੇਜ ਡਿਜ਼ਾਈਨ ਕਰੋ ਜੋ ਮੋਬਾਈਲ ਯੂਜ਼ਰ ਲਈ ਨਤੀਜੇ ਲਿਆਉਂਦੇ ਹਨ:
ਜੇ ਤੁਹਾਨੂੰ ਪੇਜ ਸਟਰੱਕਚਰ ਲਈ ਚੈਕਲਿਸਟ ਚਾਹੀਦੀ ਹੈ ਤਾਂ /blog/mobile-first-checklist ਨੂੰ ਵੇਖੋ।
ਗਤੀ ਕੰਮ ਅਸਾਨ ਹੁੰਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਪਰਫਾਰਮੈਂਸ ਨੂੰ ਇੱਕ ਬਜਟ ਵਾਂਗTreat ਕਰੋ, ਨਾ ਕਿ ਇਕ ਅਣਜਾਣ ਟੀਚਾ। ਇੱਕ performance budget ਸਪਸ਼ਟ ਹੱਦਾਂ ਰੱਖਦਾ ਹੈ (ਬਾਈਟਸ, ਰੀਕਵੇਸਟ, ਅਤੇ ਸਮਾਂ) ਤਾਂ ਕਿ ਨਵੇਂ ਫੀਚਰ ਚੁਪ-ਚਾਪ ਸਾਈਟ ਨੂੰ ਧੀਮਾ ਨਾ ਕਰ ਦਿਉਂ।
ਕੁਝ ਮਾਪਦੰਡ ਚੁਣੋ ਜੋ ਮਾਪਣ ਵਿੱਚ ਆਸਾਨ ਅਤੇ ਵਿਵਾਦ-ਰਹਿਤ ਹੋਣ:
ਇਹਨਾਂ ਨੂੰ pass/fail ਨੰਬਰ ਵੱਜੋਂ ਲਿਖੋ। ਉਦਾਹਰਨ: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1, ਨਾਲ ਹੀ ਪਹਿਲੀ ਵਿਊ ਲਈ ਇੱਕ ਵੱਧੋ-ਵੱਧ ਟ੍ਰਾਂਸਫਰ ਸਾਈਜ਼।
ਸਭ ਕੁਝ ਇਕੱਠਾ ਤੇਜ਼ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਅਕਸਰ ਕੁਝ ਨਹੀਂ ਛੱਡਦੀ। ਉਹ ਫਲੋਜ਼ ਚੁਣੋ ਜੋ ਬਿਜ਼ਨਸ ਲਈ ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਹਨ:
ਇਨ੍ਹਾਂ ਯਾਤਰਾਵਾਂ ਨੂੰ ਮੋਬਾਈਲ 'ਤੇ ਮਾਪੋ ਅਤੇ ਪਹਿਲਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਅਪਟੀਮਾਈਜ਼ ਕਰੋ।
ਹਰ ਮੁੱਖ ਪੇਜ ਲਈ ਆਸਟ-ਐਸੈਟਸ ਨੂੰ ਵਰਗੀਕ੍ਰਿਤ ਕਰੋ:
ਇਸ ਸੋਚ ਨਾਲ lazy loading, non-essential JavaScript defer, ਅਤੇ ਤੀਜੀ-ਪਾਰਟੀ ਟੂਲ ਸਿਰਫ ਯੂਜ਼ਰ ਇੰਟਰੈਕਸ਼ਨ ਤੋਂ ਬਾਅਦ ਲੋਡ ਕਰਨ ਵਰਗੀਆਂ ਤਕਨੀਕਾਂ ਆਸਾਨੀ ਨਾਲ ਆਉਂਦੀਆਂ ਹਨ।
ਆਪਣਾ ਬਜਟ ਅਤੇ Core Web Vitals ਟੀਚੇ ਸਾਝੇ ਡੌਕ ਜਾਂ ਪ੍ਰੋਜੈਕਟ ਬੋਰਡ 'ਤੇ ਰੱਖੋ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਆਪਣੀ ਡਿਵ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਜੋੜੋ। ਫਿਰ ਹਰ ਨਵੇਂ ਕੰਪੋਨੈਂਟ ਨੂੰ ਇੱਕ ਲਾਗਤ ਵਜੋਂ ਦੇਖੋ—ਜੇ ਇਹ ਬਜਟ ਤੋਂ ਵੱਧ ਹੈ ਤਾਂ ਕੁਝ ਹੋਰ ਕੱਟੋ।
ਤਸਵੀਰਾਂ ਅਕਸਰ ਪੇਜ 'ਤੇ ਸਭ ਤੋਂ ਵੱਡੀ ਫਾਈਲ ਹੁੰਦੀਆਂ ਹਨ—ਅਤੇ ਮੋਬਾਈਲ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਲੋਡ ਸਮਾਂ ਵਾਪਸ ਲੈਣ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਥਾਂ। ਮਕਸਦ ਇਹ ਨਹੀਂ ਕਿ ਹਰ ਚੀਜ਼ ਛੋਟੀ ਕਰ ਦਿਉ—ਮਕਸਦ ਹੈ ਸਹੀ ਤਸਵੀਰ, ਸਹੀ ਫਾਰਮੈਟ, ਸਹੀ ਵੇਲੇ ਪਹੁੰਚੇ, ਬਿਨਾਂ ਅਚਾਨਕ ਕੁੱਦ-ਭਾਰ ਦੇ।
srcset ਵਰਤੋਂ)ਆਮ ਗਲਤੀ ਇਹ ਹੈ ਕਿ 2000px-ਚੌੜਾਈ ਵਾਲੀ ਡੈਸਕਟਾਪ ਤਸਵੀਰ 375px-ਚੌੜਾਈ ਵਾਲੇ ਫੋਨ ਨੂੰ ਭੇਜ ਦਿੱਤੀ ਜਾਵੇ। ਬਦਲੇ ਵਿੱਚ ਕੁਝ ਸਮਝਦਾਰ ਆਕਾਰ ਨਿਕਾਲੋ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਬਿਹਤਰ ਆਕਾਰ ਚੁਣਨ ਦਿਓ।
\u003cimg
src=\"/images/hero-800.jpg\"
srcset=\"/images/hero-400.jpg 400w,
/images/hero-800.jpg 800w,
/images/hero-1200.jpg 1200w\"
sizes=\"(max-width: 600px) 92vw, 1200px\"
alt=\"Your product in use\"
width=\"1200\"
height=\"675\"
/\u003e
ਇਸ ਨਾਲ ਮੋਬਾਈਲ ਡਾਊਨਲੋਡ ਛੋਟੇ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਵੱਡੇ ਸਕਰੀਨਾਂ 'ਤੇ ਵੀ ਤਸਵੀਰ ਤੇਜ਼ ਤੇ ਕ੍ਰਿਸਪ ਰਹਿੰਦੀ ਹੈ।
ਆਧੁਨਿਕ ਫਾਰਮੈਟ ਬਿਨਾਂ ਮਹੱਤਵਪੂਰਨ ਦਿੱਖੀ ਫਰਕ ਦੇ ਫਾਈਲ ਨਾਪ ਘਟਾ ਸਕਦੇ ਹਨ।
\u003cpicture\u003e ਐਲਿਮੈਂਟ ਵਰਤੋ ਤਾਂ ਜੋ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਉਹ ਆਧੁਨਿਕ ਵਰਜਨ ਲਏ ਅਤੇ ਹੋਰ fallback ਨੂੰ gracefully ਦਿਖਾਏ:
\u003cpicture\u003e
\u003csource type=\"image/avif\" srcset=\"/images/hero-800.avif 800w\" /\u003e
\u003csource type=\"image/webp\" srcset=\"/images/hero-800.webp 800w\" /\u003e
\u003cimg src=\"/images/hero-800.jpg\" alt=\"Your product in use\" width=\"1200\" height=\"675\" /\u003e
\u003c/picture\u003e
Compression ਨੂੰ ਆਪਣੇ ਵਰਕਫਲੋ ਜਾਂ build pipeline ਦਾ ਹਿੱਸਾ ਬਣਾਓ। aim ਕਰੋ ਕਿ "ਸਧਾਰਨ ਦੂਰੀ 'ਤੇ ਇੱਕੋ ਵਰਗਾ ਲੱਗੇ"—pixel-peeping ਲਈ ਨਹੀਂ।
ਅਣ-ਲੋੜੀਂਦੇ metadata (ਜਿਵੇਂ camera info) ਹਟਾ ਦਿਓ—ਇਸ ਨਾਲ ਫਾਈਲ ਨਾਪ ਘਟਦੀ ਹੈ ਅਤੇ privacy ਵੀ ਸੁਧਰਦੀ ਹੈ।
Lazy loading ਉਨ੍ਹਾਂ images ਲਈ ਬਿਹਤਰ ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਤੁਰੰਤ ਨਹੀਂ ਵੇਖਣਗੇ। Above-the-fold images ਨੂੰ ਆਮ ਤਰ੍ਹਾਂ ਲੋਡ ਰਹਿਣ ਦਿਓ ਤਾਂ ਜੋ ਪੇਜ ਖਾਲੀ ਨਾ ਲੱਗੇ।
\u003cimg src=\"/images/gallery-1.webp\" loading=\"lazy\" alt=\"Gallery item\" width=\"800\" height=\"600\" /\u003e
ਜੇ ਕੋਈ lazy-loaded ਤਸਵੀਰ ਪਰਸੈਪਟਿਵ ਸਕਾਰਾਤਮਕਤਾ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ (ਜਿਵੇਂ ਸੈਕਸ਼ਨ ਦੀ ਪਹਿਲੀ ਦਿੱਖੀ ਤਸਵੀਰ), ਤਾਂ ਉਸ ਨੂੰ lazy-load ਕਰਨ ਦੀ ਥਾਂ preload ਕਰਨ ਬਾਰੇ ਸੋਚੋ।
width ਅਤੇ height ਸੈਟ ਕਰੋਅਣ-ਉਮੀਦਤ ਲੇਆਊਟ ਮੂਵਮੈਂਟ ਮੋਬਾਈਲ 'ਤੇ ਨਿਰਾਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ Core Web Vitals ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ। ਹਮੇਸ਼ਾ dimension ਦੇਣਾ ਯਕੀਨੀ ਬਣਾਓ (ਜਾਂ CSS ਨਾਲ ਸਪੇਸ ਰਿਜ਼ਰਵ ਕਰੋ) ਤਾਂ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਤਸਵੀਰ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਠੀਕ ਖੇਤਰ ਅਲੋਕੇਟ ਕਰ ਸਕੇ।
ਰਿਸਪਾਂਸਿਵ ਸਾਈਜ਼ਿੰਗ, ਆਧੁਨਿਕ ਫਾਰਮੈਟ, ਕੰਪਰੈਸ਼ਨ ਅਤੇ ਸੋਚ-ਵਿਚਾਰ ਨਾਲ lazy loading ਮਿਲਾ ਕੇ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਤੇਜ਼ ਪੇਜ ਅਤੇ ਤੇਜ਼ visuals ਦੋਹਾਂ ਮਿਲ ਜਾਂਦੇ ਹਨ।
ਤੁਹਾਡੇ CSS ਅਤੇ JavaScript ਅਕਸਰ ਉਹ ਛੁਪੇ ਕਾਰਨ ਹੁੰਦੇ ਹਨ ਜੋ mobile-optimized website ਨੂੰ ਧੀਮਾ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੇ ਹਨ। ਮਕਸਦ ਸਧਾਰਣ: ਘੱਟ ਕੋਡ ਭੇਜੋ, ਅਤੇ ਹੋਸ਼ਿਆਰ ਢੰਗ ਨਾਲ ਭੇਜੋ।
ਮੁਢਲੀ ਗੱਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: CSS/JS ਨੂੰ minify ਕਰੋ (ਵੈਠਕ ਅਤੇ ਆਅਖਰੀ ਅੱਖਰ ਹਟਾਓ) ਅਤੇ ਸਰਵਰ 'ਤੇ compression ਚਾਲੂ ਕਰੋ। ਆਧੁਨਿਕ ਸਟੈਕ ਫਾਈਲਾਂ ਨੂੰ Brotli (ਸਰਵੋৎਮ) ਜਾਂ gzip (ਚੰਗਾ) ਨਾਲ ਸਰਵ ਕਰ ਸਕਦੇ ਹਨ, ਜੋ ਖ਼ਾਸ ਕਰਕੇ ਮੋਬਾਈਲ ਨੈੱਟਵਰਕ 'ਤੇ ਟ੍ਰਾਂਸਫਰ ਨਾਪ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।
ਕਈ ਵਾਰ ਸਾਈਟਾਂ ਨੂੰ "ਕਦੇ ਲੋੜ ਆ ਸਕਦੀ" ਸੋਚਕੇ ਸਟਾਇਲ ਅਤੇ ਸਕ੍ਰਿਪਟ ਲੋਡ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਇਹ ਲਾਗਤ ਹਰ ਪੇਜ ਵਿਅੂ 'ਤੇ ਆਉਂਦੀ ਹੈ।
ਨਾਂਵ ਵੱਡਾ dependency ਜਿਵੇਂ slider, animation library ਜਾਂ UI kit ਸ਼ਾਮਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛੋ: "ਕੀ ਅਸੀਂ ਇਹ CSS ਜਾਂ ਇਕ ਛੋਟੇ ਸਕ੍ਰਿਪਟ ਨਾਲ ਕਰ ਸਕਦੇ ਹਾਂ?" ਵੱਡੇ dependency ਨੂੰ ਰੀਪਲੇਸ ਕਰਨਾ ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ website speed optimization ਵਿੱਚ ਤੇਜ਼ ਨਤੀਜੇ ਦੇ ਸਕਦਾ ਹੈ।
ਪਹਿਲੀ ਸਕ੍ਰੀਨ ਨੂੰ ਜਲਦੀ interactive ਬਣਾਓ:
defer ਵਰਤੋਂ)ਚੈਟ ਵਿਜ਼ਿਟ, ਟ੍ਰੈਕਰ ਅਤੇ ਐਡ ਸਕ੍ਰਿਪਟ Core Web Vitals ਨੂੰ ਧੀਮਾ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਅਣਪੂਰੇਯੋਗ ਬਣਾਉਂਦੇ ਹਨ। ਜੇ ਉਨ੍ਹਾਂ ਦੀ ਅਸਲ ਲੋੜ ਨਹੀਂ ਹੈ ਤਾਂ ਹਟਾਓ, ਅਤੇ ਬਾਕੀ ਨੂੰ ਦੇਰ ਨਾਲ ਲੋਡ ਕਰੋ (ਯੂਜ਼ਰ ਇੰਟਰੈਕਸ਼ਨ ਤੋਂ ਬਾਅਦ)।
ਜੇ ਤੁਹਾਨੂੰ ਸਪਸ਼ਟ ਚੈਕਲਿਸਟ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਇਸ ਕੰਮ ਨੂੰ /blog/lighthouse-audit ਨਾਲ ਜੋੜੋ ਤਾਂ ਕਿ ਕਿਸ ਫਾਈਲ ਨੇ ਅਸਲ ਵਿੱਚ ਲੋਡ ਸਮਾਂ ਵਧਾਇਆ ਹੈ ਉਹ ਪਤਾ ਲੱਗੇ।
ਜੇ ਤੁਹਾਡਾ ਲੇਆਊਟ ਸਾਫ਼ ਹੈ ਅਤੇ ਤਸਵੀਰਾਂ optimize ਕੀਤੀਆਂ ਹੋਈਆਂ ਹਨ, ਫਿਰ ਵੀ ਫੋਂਟ ਅਤੇ "ਆਨ-ਫ਼ੀਚਰ" UI ਪ੍ਰਭਾਵ ਮੋਬਾਈਲ ਲੋਡ ਸਮੇਂ ਵਿੱਚ ਸ਼ਾਂਤੀ ਨਾਲ ਵਾਧਾ ਕਰ ਸਕਦੇ ਹਨ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਪੜ੍ਹਨਯੋਗ ਸਮੱਗਰੀ ਤੁਰੰਤ ਦਿਖੇ, ਫਿਰ ਬਿਨਾਂ ਪੇਜ ਨੂੰ ਬਲਾਕ ਕੀਤੇEnhancements ਲਿਆਉ।
ਪਹਿਲਾਂ ਘੱਟ ਫੋਂਟ ਫਾਈਲਾਂ ਲੋਡ ਕਰੋ। ਹਰ weight (300/400/700) ਅਤੇ style (italic) ਆਮ ਤੌਰ 'ਤੇ ਵੱਖਰੀ ਡਾਉਨਲੋਡ ਹੁੰਦੀ ਹੈ—ਇਸ ਲਈ ਕੇਵਲ ਉਹੀ ਚੁਣੋ ਜੋ ਡਿਜ਼ਾਇਨ ਨੂੰ ਸੱਚਮੁੱਚ ਲੋੜ ਹੈ।
ਜੇ ਤੁਹਾਡੇ brand ਨਿਯਮ ਮਨਜ਼ੂਰ ਕਰਨ, ਤਾਂ system fonts ਸਭ ਤੋਂ ਤੇਜ਼ ਵਿਕਲਪ ਹਨ ਕਿਉਂਕਿ ਉਹ ਪਹਿਲਾਂ ਹੀ ਡਿਵਾਈਸ 'ਤੇ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਆਧੁਨਿਕ system stack ਫਿਰ ਵੀ polished ਦਿੱਸ ਸਕਦਾ ਹੈ।
ਸਿਰਫ ਉਹ ਫੋਂਟ preload ਕਰੋ ਜੋ above-the-fold ਟੈਕਸਟ 'ਤੇ ਅਸਰ ਪਾ ਰਹੇ ਹਨ ਤਾਂ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਉਨ੍ਹਾਂ ਨੂੰ ਦੇਰ ਨਾਲ "ਖੋਜੇ" ਨਾ।
\u003clink rel=\"preload\" href=\"/fonts/Inter-400.woff2\" as=\"font\" type=\"font/woff2\" crossorigin\u003e
ਹਮੇਸ਼ਾ invisible text ਤੋਂ ਬਚਣ ਲਈ font-display: swap ਵਰਤੋਂ, ਤਾਂ ਜੋ ਵਿਜ਼ਟਰ ਤੁਰੰਤ ਪੜ੍ਹ ਸਕੇ ਜਦੋਂ custom font ਲੋਡ ਹੋ ਰਿਹਾ ਹੋਵੇ।
@font-face {
font-family: \"Inter\";
src: url(\"/fonts/Inter-400.woff2\") format(\"woff2\");
font-display: swap;
}
ਵੱਡੇ hero sliders, autoplay ਵੀਡੀਓ ਅਤੇ ਜਟਿਲ ਐਨੀਮੇਸ਼ਨ ਮੋਬਾਈਲ ਬੈਂਡਵਿਡਥ ਅਤੇ CPU ਉੱਤੇ ਛਾ ਜਾ ਸਕਦੇ ਹਨ। ਇੱਕ ਸਿੰਗਲ ਸਟੈਟਿਕ ਹੀਰੋ ਤਸਵੀਰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ (ਜਾਂ ਉਹ ਵੀਡੀਓ ਜੋ ਸਿਰਫ ਟੈਪ 'ਤੇ ਚਲਦੇ ਹੋਵੇ)। ਜੇ ਮੋਸ਼ਨ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਵੱਡੀਆਂ ਐਨੀਮੇਸ਼ਨ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਥਾਂ ਸੁਖਾਵਣੇ CSS ਟ੍ਰਾਂਜ਼িশਨ ਵਰਤੋ।
ਉਸ UI ਨੂੰ ਚੁਣੋ ਜੋ ਤੇਜ਼ ਰੇਂਡਰ ਹੁੰਦਾ ਹੈ: ਨੈਟਿਵ ਇਨਪੁੱਟ, ਸਧਾਰਨ ਨੈਵੀਗੇਸ਼ਨ, ਅਤੇ ਹਲਕੇ modals। ਇਹ ਆਮ ਤੌਰ 'ਤੇ accessibility ਨੂੰ ਵੀ ਸੁਧਾਰਦਾ ਹੈ (ਸਪਸ਼ਟ focus states, ਵੱਡੇ ਟੈਪ ਟਾਰਗੇਟ, ਘੱਟ ਹਿਲਦੇ-ਡੁੱਲਦੇ ਹਿੱਸੇ)।
ਜੇ ਤੁਸੀਂ ਤੀਜੀ-ਪਾਰਟੀ ਵਿਜ਼ਿਟ ਵਰਤ ਰਹੇ ਹੋ (ਚੈਟ, ਐਂਬੇਡ, ਸੋਸ਼ਲ ਫੀਡ), ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਸਿਰਫ ਲੋੜ 'ਤੇ (ਸਹਿਮਤੀ ਤੋਂ ਬਾਅਦ ਜਾਂ ਇੰਟਰੈਕਸ਼ਨ 'ਤੇ) ਲੋਡ ਕਰੋ ਤਾਂ ਜੋ ਉਹ ਮੁੱਖ ਪੇਜ ਅਨੁਭਵ ਨੂੰ ਬлок ਨਾ ਕਰਨ।
ਗਤੀ ਸਿਰਫ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਬਣਾਈ ਗਈ ਚੀਜ਼ਾਂ 'ਤੇ ਨਹੀਂ ਨਿਰਭਰ ਕਰਦੀ—ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਵੀ ਹੈ ਕਿ ਤੁਹਾਡਾ ਸਰਵਰ ਫਾਈਲਾਂ ਅਤੇ ਪੇਜ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਡਿਲੀਵਰ ਕਰਦਾ ਹੈ, ਖ਼ਾਸ ਕਰਕੇ ਮੋਬਾਈਲ ਨੈਟਵਰਕਾਂ 'ਤੇ। ਕੁਝ ਪ੍ਰਯੋਗਿਕ ਇੰਨਫ੍ਰਾਸਟਰੱਕਚਰ ਚੋਣਾਂ ਸਕਿੰਟਾਂ ਦੀ ਬਚਤ ਕਰ ਸਕਦੀਆਂ ਹਨ ਬਿਨਾਂ ਤੁਹਾਡਾ ਡਿਜ਼ਾਇਨ ਬਦਲੇ।
ਵਿਜ਼ਟਰ ਹਰ ਪੇਜ ਵਿਊ 'ਤੇ ਇੱਕੋ ਲੋਗੋ, CSS ਜਾਂ JS ਦੁਬਾਰਾ ਡਾਊਨਲੋਡ ਨਹੀਂ ਕਰਨੇ ਚਾਹੀਦੇ। Cache-Control ਹੈਡਰਾਂ ਰਾਹੀਂ static assets ਨੂੰ ਲੋਕਲ ਵਿੱਚ ਰੱਖਣ ਲਈ ਕੰਫਿਗਰ ਕਰੋ।
ਆਮ ਤਰੀਕਾ:
app.v3.css) ਅਤੇ ਲੰਬਾ cache ਸਮਾਂ ਸੈੱਟ ਕਰੋ (30 ਦਿਨ ਤੋਂ 1 ਸਾਲ)ਇਹ ਦੁਬਾਰਾ ਆਉਣ ਵਾਲੀਆਂ ਯਾਤਰਾਵਾਂ ਨੂੰ ਫੌਰਨ ਤੇਜ਼ ਮਹਿਸੂਸ ਕਰਾਉਣ ਦਾ ਸਭ ਤੋਂ ਸਧਾਰਣ ਰਸਤਾ ਹੈ।
CDN (Content Delivery Network) ਤੁਹਾਡੀਆਂ ਸਟੈਟਿਕ ਫਾਈਲਾਂ ਨੂੰ ਦੁਨੀਆਂ ਭਰ ਵਿੱਚ ਸਰਵਰਾਂ 'ਤੇ ਨਕਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਜੋ ਮੋਬਾਈਲ ਯੂਜ਼ਰ ਨੇੜੇ ਸਥਿਤ ਸਰਵਰ ਤੋਂ ਡਾਊਨਲੋਡ ਕਰਨ।
CDN ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਯੂਜ਼ਫੁਲ ਹੁੰਦਾ ਹੈ:
ਕਈ CDN ਆਟੋਮੈਟਿਕ ਕੰਪ੍ਰੈਸ਼ਨ ਅਤੇ ਆਧੁਨਿਕ ਪ੍ਰੋਟੋਕਾਲ ਵੀ ਸਹਾਰਨ ਕਰਦੇ ਹਨ, ਜੋ Core Web Vitals ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ।
ਜੇ ਤੁਹਾਡਾ ਹੋਸਟ ਇਸਨੂੰ support ਕਰਦਾ ਹੈ, ਤਾਂ HTTP/2 (ਜਾਂ HTTP/3) enable ਕਰੋ ਤਾਂ ਜੋ ਫਾਈਲਾਂ ਇੱਕਕੋਨੈਕਸ਼ਨ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਡਿਲੀਵਰ ਹੋਣ। ਇਹ ਮੋਬਾਈਲ 'ਤੇ ਜ਼ਿਆਦਾ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ ਜਿੱਥੇ latency ਅਕਸਰ ਰੋਕ ਬਣਦਾ ਹੈ।
ਆਮ ਤੌਰ 'ਤੇ HTTPS ਨਾਲ HTTP/2 ਆਟੋਮੈਟਿਕ ਮਿਲ ਜਾਦਾ ਹੈ। HTTP/3 ਦਾ support ਤੁਹਾਡੇ ਪ੍ਰੋਵਾਈਡਰ ਅਤੇ CDN 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।
ਜੇ ਸਰਵਰ ਜਵਾਬ ਦੇਣ 'ਚ ਦੇਰ ਕਰੇ ਤਾਂ ਤੇਜ਼ ਫਰੰਟ-ਐਂਡ ਵੀ ਧੀਮਾ ਮਹਿਸੂਸ ਕਰੇਗਾ। ਲਕੜੀ:
Lighthouse ਰਿਪੋਰਟਾਂ ਵਿੱਚ Time to First Byte (TTFB) ਦੇ ਮੁੱਦਿਆਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ—ਧੀਮਾ TTFB ਅਕਸਰ ਹੋਸਟਿੰਗ ਜਾਂ ਬੈਕਐਂਡ ਬੋਤਲਨੇਕ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡੇ ਪੇਜ ਯੂਜ਼ਰ-ਵਿਸ਼ੇਸ਼ ਨਹੀਂ ਬਦਲਦੇ ਤਾਂ full-page caching ਵੱਡਾ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ। ਜੇ ਕੇਵਲ ਕੁਝ ਹਿੱਸੇ dynamic ਹਨ (ਜਿਵੇਂ cart count), ਤਾਂ fragment caching ਵਰਤੋਂ ਤਾਂ ਜੋ ਪੇਜ ਦਾ ਜ਼ਿਆਦਾ ਹਿੱਸਾ ਤੇਜ਼ੀ ਨਾਲ ਸਰਵ ਹੋਵੇ।
ਰੋਲ ਆਫ਼ ਥੰਬ: ਜਿੰਨਾ ਜ਼ਿਆਦਾ ਤੁਸੀਂ cache ਕਰ ਸਕਦੇ ਹੋ ਕਰੋ, ਫਿਰ ਧਿਆਨ ਨਾਲ ਉਹਨਾਂ ਥਾਵਾਂ ਲਈ ਰਿੰਧੇ ਬਣਾਓ ਜੋ ਵਾਸਤਵ ਵਿੱਚ dynamic ਹਨ।
ਇੱਕ ਤੇਜ਼ ਮੋਬਾਈਲ ਅਨੁਭਵ ਸਿਰਫ HTML/CSS/JS ਨੂੰ ਭੇਜਣ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ—ਇਹ ਵੀ ਮਾਮਲਾ ਹੈ ਕਿ ਪਹਿਲਾ ਬਾਈਟ ਕਿਵੇਂ ਅਤੇ ਕਿੰਨੀ ਜਲਦੀ ਆਉਂਦਾ ਹੈ ਅਤੇ ਹਰ ਰੀਕਵੇਸਟ ਨੈੱਟਵਰਕ 'ਚ ਕਿਵੇਂ ਸਫ਼ਰ ਕਰਦੀ ਹੈ।
Redirect chains ਮੋਬਾਈਲ 'ਤੇ ਖਾਸ ਤੌਰ 'ਤੇ ਨੁਕਸਾਨਦਾਇਕ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਹਰ ਹੌਪ DNS, TLS ਅਤੇ ਰਿਕਵੇਸਟ/ਰਿਸਪਾਂਸ ਸਮਾਂ ਵਧਾਉਂਦਾ ਹੈ।
ਮੁੱਖ ਸਮੱਗਰੀ (ਹੋਮ, ਪ੍ਰੋਡਕਟ/ਸੇਵਾ ਪੇਜ, ਉਦਯੋਗ-ਟਾਪ ਬਲੌਗ) ਲਈ server-side rendering ਜਾਂ static generation ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਖਾਲੀ HTML shell ਭੇਜ ਕੇ JavaScript 'ਤੇ ਸਮੱਗਰੀ ਲੈਣ ਦਾ ਤਰੀਕਾ LCP ਨੂੰ ਦੇਰੀ ਕਰ ਸਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਕਿਸੇ JS framework ਨੂੰ ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਮੁੱਖ ਸਮੱਗਰੀ ਸ਼ੁਰੂਆਤੀ HTML ਵਿੱਚ ਮੌਜੂਦ ਹੈ ਅਤੇ ਸਰਗਰਮੀ ਨੂੰ progressive hydrate ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
Analytics, chat widgets, video embeds ਅਤੇ A/B ਟੂਲ ਅਕਸਰ ਵੱਖ-ਵੱਖ origins ਬਣਾਉਂਦੇ ਹਨ। ਜੇ ਉਹ ਮਹੱਤਵਪੂਰਨ ਹਨ ਤਾਂ connection hints ਜੋੜੋ ਤਾਂ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਪਹਿਲਾਂ ਤੋਂ ਤਿਆਰ ਹੋ ਸਕੇ:
\u003clink rel=\"dns-prefetch\" href=\"//example-third-party.com\"\u003e
\u003clink rel=\"preconnect\" href=\"https://example-third-party.com\" crossorigin\u003e
ਇਹਨਾਂ ਨੂੰ ਸਾਵਧਾਨੀ ਨਾਲ ਵਰਤੋ—ਬਹੁਤ ਸਾਰਿਆਂ origins ਨੂੰ preconnect ਕਰਨਾ ਮੋਬਾਈਲ ਬੈਂਡਵਿਡਥ ਬਰਬਾਦ ਕਰ ਸਕਦਾ ਹੈ।
\u003chead\u003e ਵਿੱਚ blocking requests ਤੋਂ ਬਚੋਕ੍ਰਿਟੀਕਲ CSS ਛੋਟੀ ਰੱਖੋ, ਗੈਰ-ਜ਼ਰੂਰੀ ਸਕ੍ਰਿਪਟਾਂ defer ਕਰੋ, ਅਤੇ ਭਾਰੀ ਤੀਜੀ-ਪਾਰਟੀ ਟੈਗਾਂ ਨੂੰ ਪੇਜ ਰੈਂਡਰ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਲੋਡ ਕਰਨ ਤੋਂ ਬਚੋ। ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਦੇ ਅਖੀਰ 'ਤੇ ਸਥਾਨਾਂਤਰਨ ਕਰੋ ਜਾਂ defer ਵਰਤੋਂ।
ਪੱਕਾ ਕਰੋ ਕਿ ਸਰਵਰ compressed assets ਭੇਜਦਾ ਹੈ:
ਨਾਲ ਹੀ HTTP/2 (ਜਾਂ HTTP/3) enable ਹੋਵੇ ਤਾਂ concurrency ਅਤੇ parallel loading ਮੋਬਾਈਲ 'ਤੇ ਬਿਹਤਰ ਹੁੰਦਾ ਹੈ।
ਤੇਜ਼ ਪੇਜ ਆਪਣੇ ਆਪ ਕਨਵਰਟ ਨਹੀਂ ਕਰਵਾਉਂਦੇ—ਤੁਹਾਡਾ ਇੰਟਰਫੇਸ ਵੀ ਛੋਟੀ ਸਕਰੀਨ 'ਤੇ ਆਸਾਨ ਮਹਿਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਟ੍ਰਿਕ ਇਹ ਹੈ ਕਿ friction ਘਟਾਇਆ ਜਾਵੇ ਬਿਨਾਂ ਭਾਰੀ ਵਿਜ਼ਿਟ, ਵਾਧੂ ਸਕ੍ਰਿਪਟ ਜਾਂ ਧਿਆਨ ਖਿੱਚਣ ਵਾਲੇ ਇੰਟਰਸਟਿਸ਼ੀਅਲ ਜੋ ਪੇਜ ਨੂੰ ਧੀਮਾ ਕਰ ਦੇਂ।
ਮੋਬਾਈਲ 'ਤੇ ਹਰ ਵਾਧੂ ਫੀਲਡ ਛੱਡਣ ਦੀ ਇੱਕ ਵਜ੍ਹਾ ਹੁੰਦੀ ਹੈ। ਕੇਵਲ ਉਹੀ ਲਵੋ ਜੋ ਅਗਲੇ ਕਦਮ ਲਈ ਜ਼ਰੂਰੀ ਹੈ।
ਸਮਾਰਟ defaults ਵਰਤੋਂ (ਦੇਸ਼, ਮਾਤਰਾ, ਸ਼ਿਪਿੰਗ ਵਿਧੀ) ਅਤੇ autofill ਦੇ ਫਾਇਦੇ ਲਓ ਸਹੀ input ਕਿਸਮਾਂ (email, tel, name) ਅਤੇ autocomplete attributes ਨਾਲ।
ਜੇ ਹੋਰ ਡੇਟਾ ਲੈਣਾ ਲਾਜ਼ਮੀ ਹੈ ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਕਦਮ-ਦਰ-ਕਦਮ ਵੰਡੋ—ਪਰ ਨੈਵੀਗੇਸ਼ਨ ਤੁਰੰਤ ਰੱਖੋ ਅਤੇ ਐਸੇ ਮਾਡਲ ਨਾ ਵਰਤੋ ਜੋ ਵਾਧੂ ਪੇਜ ਲੋਡਾਂ ਨੂੰ ਲਦਾਂ।
Validation ਨੂੰ ਹਦਾਇਤਕ ਰੱਖੋ, ਰੋਕਣਾ ਨਹੀਂ। ਹਰ ਕੀ-ਸਟ੍ਰੋਕ 'ਤੇ validate ਕਰਨ ਵਾਲੇ ਪੈਟਰਨ ਜੋ ਟਾਈਪਿੰਗ ਠਹਿਰਾਉਣਾ ਜਾਂ ਲੇਆਊਟ ਨੂੰ ਝਟਕਾ ਦੇਣ, ਉਹੋਂ ਤੋਂ ਬਚੋ।
ਅਗਰ ਲੋੜ ਹੋਵੇ ਤਾਂ client-side checks ਨੂੰ blur 'ਤੇ (ਜਦ ਫੀਲਡ ਦਾ ਫੋਕਸ ਖਤਮ ਹੋਵੇ) ਜਾਂ submit 'ਤੇ ਚਲਾਓ, ਅਤੇ ਸੁਨੇਹੇ inline ਹੀ ਦਿਖਾਓ। ਐਰਰ ਟੈਕਸਟ ਛੋਟਾ, ਵਿਸ਼ੇਸ਼ ਅਤੇ ਸਥਿਰ ਆਕਾਰ ਦਾ ਰੱਖੋ ਤਾਂ ਕਿ ਉਹ ਪੇਜ ਨੂੰ ਧੱਕੇ ਨਾ।
ਤੁਹਾਡੀ ਪ੍ਰਾਇਮਰੀ ਐਕਸ਼ਨ ਆਸਾਨੀ ਨਾਲ ਵੇਖਣਯੋਗ ਅਤੇ ਦਬਾਉਣ ਯੋਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:
ਗਲਤੀ-ਟੈਪ ਘਟਾਉਣ ਲਈ, destructive actions (ਜਿਵੇਂ "Remove") ਨੂੰ "Pay" ਜਾਂ "Submit" ਕੋਲ ਨਾ ਰੱਖੋ।
ਪੌਪ-ਅੱਪ ਅਤੇ ਇੰਟਰਸਟਿਸ਼ੀਅਲ ਯੂਜ਼ਰ ਭਰੋਸਾ ਅਤੇ ਮੋਬਾਈਲ ਫਲੋ ਦੋਹਾਂ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਤਦੇ ਹੋ ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਦਰਦ-ਨਾਭੀ, ਛੋਟੇ ਅਤੇ ਆਸਾਨੀ ਨਾਲ dismissable ਰੱਖੋ।
ਭਾਰੀ ਤੀਜੀ-ਪਾਰਟੀ ਸਕ੍ਰਿਪਟ ਸਿਰਫ਼ ਇੱਕ ਛੂਟ ਦੇਣ ਵਾਲਾ ਡਿਸਕਾਊਂਟ ਮੋਡਲ ਦਿਖਾਉਣ لاءِ ਲੋਡ ਨਾ ਕਰੋ। ਥੋੜੇ ਹਲਕੇ ਵਿਕਲਪ ਸੋਚੋ ਜਿਵੇਂ inline ਬੈਨਰ ਜਾ non-blocking slide-in।
Accessibility ਸੁਧਾਰ ਅਕਸਰ ਸਭ ਲਈ completion rates ਵਧਾਉਂਦੇ ਹਨ:
ਜਦੋਂ ਤੁਹਾਡਾ conversion UI ਸਧਾਰਨ, ਸਥਿਰ ਅਤੇ ਟੈਪ-ਫਰੈਂਡਲੀ ਹੁੰਦਾ ਹੈ, ਤੁਸੀਂ ਵਧੀਆ ਨਤੀਜੇ ਪਾਉਂਦੇ ਹੋ—ਅਤੇਪੇਜ ਇਹਨਾ ਬਦਲਾਵਾਂ ਨਾਲ ਵੀ ਹਕੀਕਤ ਵਿੱਚ ਤੇਜ਼ ਰਹਿੰਦੀ ਹੈ।
Google ਮੁੱਖਤੌਰ 'ਤੇ ਤੁਹਾਡੀ ਸਾਈਟ ਨੂੰ ਮੋਬਾਈਲ ਯੂਜ਼ਰ ਵਜੋਂ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ—ਇਸ ਲਈ ਮੋਬਾਈਲ ਯੂਜ਼ਬਿਲਟੀ ਅਤੇ ਗਤੀ ਸਿੱਧੇ ਰੂਪ ਵਿੱਚ ਵਿਖਾਰ 'ਤੇ ਅਸਰ ਕਰਦੀਆਂ ਹਨ। ਚੰਗੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਕਈ "SEO ਸੁਧਾਰ" ਵੀ ਯੂਜ਼ਰ ਅਨੁਭਵ ਸੁਧਾਰਦੇ ਹਨ।
Core Web Vitals (LCP, INP, CLS) ਸਿਰਫ਼ ਤਕਨੀਕੀ ਮੈਟਰਿਕਸ ਨਹੀਂ—ਇਹ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਤੁਹਾਡੀ ਮੁੱਖ ਸਮੱਗਰੀ ਕਿੰਨੀ ਤੇਜ਼ ਆਉਂਦੀ ਹੈ, ਇੰਟਰਐਕਸ਼ਨ ਕਿੰਨੇ ਜਵਾਬਦਾਰ ਹਨ, ਅਤੇ ਲੇਆਊਟ ਕਿੰਨਾ ਸਥਿਰ ਹੈ।
SEO ਲਈ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਮੁੱਖ ਪੇਜ ਸਮੱਗਰੀ ਤੁਰੰਤ ਮੌਜੂਦ ਹੈ, ਨਾ ਕਿ client-side rendering ਜਾਂ ਵੱਡੇ ਬੰਡਲਾਂ ਦੇ ਪਿੱਛੇ ਲਾ ਕੇ।
ਪ੍ਰਯੋਗਿਕ ਜਾਂਚ:
ਤੇਜ਼ ਪੇਜ ਫਿਰ ਵੀ relevance ਸੰਕੇਤ ਚਾਹੀਦੇ ਹਨ:
ਮੋਬਾਈਲ ਯੂਜ਼ਰ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਨੈਵੀਗੇਟ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਅੰਦਰੂਨੀ ਲਿੰਕ ਸਪਸ਼ਟ ਅਤੇ ਹਲਕੇ ਰੱਖੋ।
ਉਦਾਹਰਨ: /pricing, /contact ਅਤੇ ਮੁੱਖ ਸੇਵਾ ਪੇਜਾਂ ਤੋਂ descriptive anchor text ਵਰਤ ਕੇ ਲਿੰਕ ਕਰੋ—"click here" ਦੇ ਭਰੋਸੇ 'ਤੇ ਨਹੀਂ।
ਦੇਰ ਨਾਲ ਲੋਡ ਹੋਣ ਵਾਲੇ cookie notices, promo bars ਅਤੇ chat widgets CLS spikes ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੇ ਹਨ। ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਉਨ੍ਹਾਂ ਲਈ ਸਥਾਨ ਰੱਖੋ (ਜਾਂ overlays ਵਰਤੋਂ ਜੋ ਕੰਟੈਂਟ ਨੂੰ ਧੱਕਦੇ ਨਹੀਂ), ਅਤੇ ਪੇਜ ਪਹਿਲਾਂ ਹੀ ਦਿਖਣ ਲੱਗਣ ਤੋਂ ਬਾਅਦ ਵੱਡੇ ਬੈਨਰ inject ਕਰਨ ਤੋਂ ਬਚੋ।
ਗਤੀ ਕੋਈ ਐਸੀ ਚੀਜ਼ ਨਹੀਂ ਜੋ ਤੁਸੀਂ "ਮੁਕੰਮਲ" ਕਰ ਲਓ—ਇਹ ਇੱਕ ਰੱਖ-ਰਖਾਅ ਵਾਲੀ ਚੀਜ਼ ਹੈ। ਇੱਕ ਨਵੀਂ ਤਸਵੀਰ, ਇੱਕ ਮਾਰਕੇਟਿੰਗ ਟੈਗ ਜਾਂ ਇੱਕ ਵਿਜ਼ਿਟ ਹਫ਼ਤੇ ਕੰਮ ਦੀਆਂ ਮਹਨਤਾਂ ਨੂੰ ਚੁੱਪਕੇ ਨਾਲ ਮੁੜ-ਖਰਾਬ ਕਰ ਸਕਦੇ ਹਨ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਪਰਫਾਰਮੈਂਸ ਚੈਕਸ ਤੁਹਾਡੇ ਨਿਯਮਤ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਣ।
ਪਰਫਾਰਮੈਂਸ ਨੂੰ ਇੱਕ ਫੀਚਰ ਵਾਂਗTreat ਕਰੋ ਜਿਨ੍ਹਾਂ ਲਈ pass/fail ਮਿਆਰ ਹੋਣ:
ਜੇ ਤੁਸੀਂ ਪਰਫਾਰਮੈਂਸ ਬਜਟ ਰੱਖਦੇ ਹੋ ਤਾਂ build warnings ਜਾਂ fail ਕਰਵਾਓ ਜਦ bundles, images ਜਾਂ third-party scripts ਤੁਹਾਨੂੰ ਲਿਮਿਟ ਤੋਂ ਉੱਪਰ ਲੈ ਜਾਂਦੇ ਹਨ।
ਲੈਬ ਟੈਸਟਜ਼ ਲਾਭਦਾਇਕ ਹਨ, ਪਰ ਤੁਹਾਡੇ ਵਿਜ਼ਟਰਾਂ ਦੇ ਫੋਨਾਂ ਅਤੇ ਨੈੱਟਵਰਕ ਸੱਚ ਹਨ।
Analytics, chat widgets, A/B testing, ਅਤੇ ad pixels ਅਕਸਰ ਮੋਬਾਈਲ ਅਨੁਭਵ ਦਾ ਸਭ ਤੋਂ ਭਾਰੀ ਹਿੱਸਾ ਬਣ ਜਾਂਦੇ ਹਨ।
ਸਿਰਫ ਇੱਕ ਸਧਾਰਣ “performance checklist” ਬਣਾਓ:
ਜੇ ਤੁਸੀਂ ਨਵਾਂ ਪ੍ਰੋਜੈਕਟ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਉਹ stack ਅਤੇ workflow ਚੁਣੋ ਜੋ responsive web design ਅਤੇ ਵਧੀਆ defaults ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰੇ। ਉਦਾਹਰਨ ਵਜੋਂ, Koder.ai ਟੀਮਾਂ ਨੂੰ chat ਇੰਟਰਫੇਸ ਰਾਹੀਂ web apps ਬਣਾਉਣ ਦਿੰਦੀ ਹੈ ਜਦੋਂ ਕਿ ਅਸਲੀ source code ਐਕਸਪੋਰਟ ਵੀ ਕਰਦੀ ਹੈ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ iterate ਕਰ ਸਕੋ, ਫਿਰ performance budgets, SSR/static generation ਜੇ ਲੋੜ ਹੋਵੇ ਲਗਾ ਸਕੋ, ਅਤੇ dependency ਚੋਣਾਂ 'ਤੇ ਨਿਯੰਤਰਣ ਰੱਖ ਸਕੋ ਜਿਵੇਂ ਪ੍ਰੋਡਕਟ ਵਧਦਾ ਹੈ।
ਜਿਵੇਂ ਜਿਵੇਂ ਪੇਜ ਅਤੇ ਐਸੈਟ ਵਧਦੇ ਹਨ, ਨਿਯਮਿਤ ਸਮੀਖਿਆਆਂ ਯੋਜਨਾ ਕਰੋ। ਆਪਣੇ ਟਾਪ ਪੇਜਾਂ 'ਤੇ 30 ਮਿੰਟ ਦੀ ਮਹੀਨਾਵਾਰ ਜਾਂਚ ਮੈਂਟੇਨੈਂਸ ਨੂੰ ਰੋਕਦੇ ਹੋਏ ਵੱਡੇ ਪਲਟਾਅ ਤੋਂ ਬਚਾ ਸਕਦੀ ਹੈ।
ਇੱਕ ਮੋਬਾਈਲ-ਅਨੁਕੂਲ ਤੇ ਤੇਜ਼ ਸਾਈਟ ਬਾਉਂਸ ਰੇਟ ਘਟਾਉਂਦੀ ਹੈ ਅਤੇ ਕਨਵਰਸ਼ਨਾਂ ਵਧਾਉਂਦੀ ਹੈ ਕਿਉਂਕਿ ਮੋਬਾਈਲ ਵਿਜ਼ਟਰਾਂ ਦੀ ਧਿਆਨ-ਸੀਮਾ ਛੋਟੀ ਹੁੰਦੀ ਹੈ, ਸਕਰੀਨ ਛੋਟੀ ਹੁੰਦੀ ਹੈ ਅਤੇ ਨੈੱਟਵਰਕ ਕਈ ਵਾਰੀ ਕਮਜ਼ੋਰ ਹੁੰਦਾ ਹੈ। ਜੇ ਪੇਜ ਧੀਮੀ, ਬੇ-ਜਵਾਬ ਜਾਂ ਦਿੱਖ ਵਿੱਚ ਹਿਲਦਾ-ਡੁੱਲਦਾ ਮਹਿਸੂਸ ਹੋਵੇ ਤਾਂ ਯੂਜ਼ਰ ਪੜ੍ਹਨ ਜਾਂ ਖਰੀਦਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਚਲੇ ਜਾਂਦੇ ਹਨ।
ਇਹ ਉਹ ਯੂਜ਼ਰ-ਐਕਸਪੀਰੀਅਂਸ ਮੈਟਰਿਕਸ ਹਨ ਜੋ ਅਸਲ ਵਿੱਚ ਲੋਕਾਂ ਨੂੰ ਜੋ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਉਸ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ:
ਇਹਨਾਂ ਨੂੰ “ਉਤਰਾਂ-ਵਾਲਾ ਸਕੋਰ” ਵਜੋਂ ਨਾ ਦੇਖੋ—ਇਹ ਪ੍ਰਯੋਗਸ਼ੀਲ ਟੀਚੇ ਹਨ ਜੋ ਇਹ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਪੇਜ ਮੋਬਾਈਲ 'ਤੇ ਵਰਤਣਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ।
ਡੈਸਕਟਾਪ ਟੈਸਟਿੰਗ ਮੋਬਾਈਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਛੁਪਾ ਸਕਦੀ ਹੈ। ਇਹ ਕਰੋ:
ਆਮ ਗਲਤੀਆਂ:
ਮੋਬਾਈਲ-ਫਰਸਟ ਦਾ ਮਤਲਬ ਪੜ੍ਹਨ ਅਤੇ ਟੈੱਪ ਕਰਨ ਨੂੰ ਪਹਿਲਾਂ ਰੱਖਣਾ ਹੈ:
ਲੋਡ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਸਪੇਸ ਰਿਜ਼ਰਵ ਕਰੋ:
width/height ਜਾਂ CSS aspect-ratio ਸੈਟ ਕਰੋਸਰਲ ਰਸਤਾ:
srcset ਰਾਹੀਂ ਕਈ ਆਕਾਰ ਦਿਓ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਸਭ ਤੋਂ ਚੰਗਾ ਇਕ ਚੁਣਨ ਦਿਓ\u003cpicture\u003e)ਕੋਡ ਘੱਟ ਭੇਜੋ ਅਤੇ ਹੋਸ਼ਿਆਰ ਢੰਗ ਨਾਲ ਭੇਜੋ:
defer ਕਰੋ, code-split ਕਰੋ ਅਤੇ lazy-load ਕਰੋਇੱਕ performance budget ਸਖ਼ਤ ਹੱਦਾਂ ਰੱਖਦਾ ਹੈ ਤਾਂ ਜੋ ਪੇਜ ਸਮੇਂ ਦੇ ਨਾਲ ਧੀਰੇ-ਧੀਰੇ ਭਾਰ ਨਹੀਂ ਬਣਦੇ। ਕੁਝ ਮਾਪਦੰਡ:
ਫਿਰ 1–2 ਮੁੱਖ ਯੂਜ਼ਰ ਜਰਨੀਆਂ (ਜਿਵੇਂ landing → product → checkout) ਪਹਿਲਾਂ optimize ਕਰੋ ਅਤੇ ਹਰ ਨਵੇਂ ਕਾਰਜਕੁੰਡੀ ਨੂੰ ਇੱਕ “ਲਾਗਤ” ਸਮਝੋ।
ਲੈਬ ਚੈਕਾਂ ਅਤੇ ਰੀਅਲ-ਯੂਜ਼ਰ ਮੈਟਰਿਕਸ ਦੋਹਾਂ ਮਿਲ ਕੇ ਜਰੂਰੀ ਹਨ:
ਹਮੇਸ਼ਾ ਅਯਾਮ ਦਿਓ ਤਾਂ ਜੋ CLS ਨਾ ਵਧੇ।