ਆਪਣੀ ਵੈੱਬਸਾਈਟ ਨੂੰ ਤੇਜ਼ ਕਿਵੇਂ ਬਣਾਈਏ: ਵਿਹਾਰਕ ਚੈੱਕਲਿਸਟ
ਵੈੱਬਸਾਈਟ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਣ ਲਈ ਪਹਿਲਾਂ PageSpeed Insights ਨਾਲ ਮਾਪੋ, ਫਿਰ ਉਹ ਸਭ ਤੋਂ ਵੱਡਾ ਕਾਰਨ ਠੀਕ ਕਰੋ ਜੋ ਉਹ ਦਿਖਾਵੇ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਬਹੁਤ ਵੱਡੀਆਂ ਤਸਵੀਰਾਂ, ਬਹੁਤ ਜ਼ਿਆਦਾ JavaScript, ਭਾਰੀ ਫੌਂਟ ਜਾਂ ਤੀਜੀ ਧਿਰ ਸਕ੍ਰਿਪਟਾਂ ਹੁੰਦੀਆਂ ਹਨ। Google ਦੇ Core Web Vitals "ਚੰਗੇ" ਟੀਚਿਆਂ ਤੱਕ ਪਹੁੰਚੋ: ਮੁੱਖ ਸਮੱਗਰੀ 2.5 ਸਕਿੰਟਾਂ ਵਿੱਚ ਦਕਿਸੇ, ਟੈਪ ਦਾ ਜਵਾਬ 200 ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ ਮਿਲੇ, ਅਤੇ ਲੇਆਉਟ ਲਗਭਗ ਨਾ ਹਿੱਲੇ। ਜ਼ਿਆਦਾਤਰ ਸਾਈਟਾਂ ਕੁਝ ਕੁ ਬਦਲਾਅ ਨਾਲ ਇੱਥੇ ਪਹੁੰਚ ਜਾਂਦੀਆਂ ਹਨ, ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ।
ਕੁਝ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਪੋ
ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦਾ ਹੈ। ਦੋ ਮੁਫ਼ਤ ਟੂਲ ਲਗਭਗ ਹਰ ਕਿਸੇ ਦਾ ਕੰਮ ਕਰ ਦਿੰਦੇ ਹਨ:
- PageSpeed Insights (pagespeed.web.dev) — ਕੋਈ ਲਾਈਵ URL ਪੇਸਟ ਕਰੋ। ਇਹ ਅਸਲ Chrome ਯੂਜ਼ਰਾਂ ਤੋਂ ਫੀਲਡ ਡੇਟਾ (ਜੇ ਤੁਹਾਡੀ ਸਾਈਟ 'ਤੇ ਕਾਫ਼ੀ ਆਵਾਜਾਈ ਹੋਵੇ) ਅਤੇ ਸਿਮੂਲੇਟਿਡ ਲੋਡ ਤੋਂ ਲੈਬ ਡੇਟਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਨਾਲ ਹੀ ਖਾਸ ਸਮੱਸਿਆਵਾਂ ਦੀ ਸੂਚੀ।
- Lighthouse Chrome DevTools ਵਿੱਚ — ਉਹੀ ਲੈਬ ਟੈਸਟ, ਕਿਸੇ ਵੀ ਪੰਨੇ 'ਤੇ ਜੋ ਤੁਸੀਂ ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ, ਪ੍ਰੀਵਿਊ ਸਮੇਤ। ਮੋਬਾਈਲ ਮੋਡ ਵਿੱਚ ਟੈਸਟ ਕਰੋ; ਹੌਲੀ ਨੈੱਟਵਰਕ 'ਤੇ ਫ਼ੋਨਾਂ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਸਭ ਤੋਂ ਵੱਧ ਦਿਸਦੀਆਂ ਹਨ।
ਜਿਹੜੇ ਅੰਕੜੇ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ ਉਹ Google ਦੇ Core Web Vitals ਹਨ। ਸਤੰਬਰ 2026 ਤੱਕ, Google ਦੇ web.dev ਦਸਤਾਵੇਜ਼ ਇਨ੍ਹਾਂ "ਚੰਗੇ" ਥ੍ਰੈਸ਼ਹੋਲਡਾਂ ਨੂੰ ਦਿੰਦੇ ਹਨ, ਜੋ ਪੇਜ ਲੋਡਾਂ ਦੇ 75ਵੇਂ ਪਰਸੈਂਟਾਈਲ 'ਤੇ ਮਾਪੇ ਜਾਂਦੇ ਹਨ:
| ਮੈਟ੍ਰਿਕ | ਕੀ ਮਾਪਦਾ ਹੈ | ਚੰਗਾ |
|---|---|---|
| Largest Contentful Paint (LCP) | ਮੁੱਖ ਸਮੱਗਰੀ (ਹੀਰੋ ਤਸਵੀਰ, ਸੁਰਖੀ) ਕਿੰਨੀ ਜਲਦੀ ਦਿਸਦੀ ਹੈ | 2.5 ਸਕਿੰਟ ਜਾਂ ਘੱਟ |
| Interaction to Next Paint (INP) | ਪੰਨਾ ਕਲਿੱਕਾਂ, ਟੈਪਾਂ ਅਤੇ ਟਾਈਪਿੰਗ 'ਤੇ ਕਿੰਨੀ ਜਲਦੀ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦਾ ਹੈ | 200 ms ਜਾਂ ਘੱਟ |
| Cumulative Layout Shift (CLS) | ਲੋਡ ਹੁੰਦੇ ਸਮੇਂ ਲੇਆਉਟ ਕਿੰਨਾ ਹਿੱਲਦਾ ਹੈ | 0.1 ਜਾਂ ਘੱਟ |
INP ਨੇ 2024 ਵਿੱਚ ਪੁਰਾਣੇ First Input Delay ਮੈਟ੍ਰਿਕ ਦੀ ਥਾਂ ਲਈ। ਜੇ ਕੋਈ ਟੂਲ ਅਜੇ ਵੀ FID ਦੱਸਦਾ ਹੈ, ਤਾਂ ਉਹ ਪੁਰਾਣਾ ਹੈ।
ਆਪਣੇ ਸ਼ੁਰੂਆਤੀ ਅੰਕ ਲਿਖ ਲਓ। ਹਰ ਠੀਕ ਕਰਨ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰੋ, ਤਾਂ ਜੋ ਪਤਾ ਲੱਗੇ ਕਿ ਕਿਹੜੀ ਚੀਜ਼ ਮਦਦਗਾਰ ਰਹੀ।
ਸਮਾਂ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ: ਵਿਕਲਪ ਅਤੇ ਵਪਾਰ-ਬੰਦ
ਹਰ ਆਮ ਕਾਰਨ ਦਾ ਹੱਲ ਹੈ, ਅਤੇ ਹਰ ਹੱਲ ਦੀ ਕੀਮਤ ਹੈ। ਸਭ ਤੋਂ ਉੱਪਰ ਵਾਲਿਆਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਕਿਉਂਕਿ ਉਹ ਸਭ ਤੋਂ ਸਸਤੇ ਅਤੇ ਸਭ ਤੋਂ ਆਮ ਹਨ।
| ਕਾਰਨ | ਆਮ ਹੱਲ | ਵਪਾਰ-ਬੰਦ |
|---|---|---|
| ਵੱਡੀਆਂ ਤਸਵੀਰਾਂ | ਦਿਖਾਏ ਆਕਾਰ 'ਤੇ ਕਰੋ, ਕੰਪ੍ਰੈੱਸ ਕਰੋ, WebP ਜਾਂ AVIF ਵਰਤੋ | ਬਹੁਤ ਜ਼ਿਆਦਾ ਕੰਪ੍ਰੈੱਸ ਕਰਨ 'ਤੇ ਕੁਝ ਕੁਆਲਟੀ ਘਟਦੀ ਹੈ |
| ਤਸਵੀਰਾਂ ਗਲਤ ਕ੍ਰਮ ਵਿੱਚ ਲੋਡ ਹੋਣੀਆਂ | ਫੋਲਡ ਤੋਂ ਹੇਠਲੀਆਂ ਤਸਵੀਰਾਂ ਲੇਜ਼ੀ-ਲੋਡ ਕਰੋ; ਹੀਰੋ ਤਸਵੀਰ ਨੂੰ ਉੱਚੀ ਤਰਜੀਹ ਦਿਓ | ਕੋਈ ਨਹੀਂ, ਜੇ ਹੀਰੋ ਲੇਜ਼ੀ ਨਾ ਹੋਵੇ |
| ਬਹੁਤ ਜ਼ਿਆਦਾ JavaScript | ਕੋਡ ਨੂੰ ਪੰਨੇ ਅਨੁਸਾਰ ਵੰਡੋ, ਨਾ ਵਰਤੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਹਟਾਓ | ਕੁਝ ਰੀਫੈਕਟਰਿੰਗ |
| ਕਲਾਇੰਟ-ਸਿਰਫ਼ ਰੈਂਡਰਿੰਗ | ਜਨਤਕ ਪੰਨਿਆਂ ਨੂੰ ਪ੍ਰੀਰੈਂਡਰ ਜਾਂ ਸਰਵਰ-ਰੈਂਡਰ ਕਰੋ | ਵਧੇਰੇ ਬਿਲਡ ਜਾਂ ਸਰਵਰ ਸੈੱਟਅੱਪ |
| ਵੈੱਬ ਫੌਂਟ | ਫੌਂਟ ਪਰਿਵਾਰ ਅਤੇ ਵਜ਼ਨ ਘਟਾਓ, ਮੁੱਖ ਫੌਂਟ ਪ੍ਰੀਲੋਡ ਕਰੋ, font-display: swap | ਟਾਈਪੋਗ੍ਰਾਫੀ ਦੀ ਵਿਭਿੰਨਤਾ ਘਟਦੀ ਹੈ |
| ਤੀਜੀ ਧਿਰ ਸਕ੍ਰਿਪਟਾਂ | ਨਾ ਵਰਤੀਆਂ ਹਟਾਓ, ਬਾਕੀ ਪੰਨੇ ਤੋਂ ਬਾਅਦ ਲੋਡ ਕਰੋ | ਕੋਈ ਵਿਜੇਟ ਜਾਂ ਟਰੈਕਰ ਗੁਆਉਣਾ |
| ਸਰਵਰ ਦਾ ਹੌਲੀ ਜਵਾਬ | ਕੈਸ਼ਿੰਗ, CDN, ਸਮੱਗਰੀ ਪੰਨਿਆਂ ਲਈ ਸਟੈਟਿਕ ਹੋਸਟਿੰਗ | ਕੈਸ਼ ਰੱਦ ਕਰਨ ਬਾਰੇ ਸੋਚਣਾ ਪਵੇਗਾ |
ਤਸਵੀਰਾਂ
ਤਸਵੀਰਾਂ ਸਭ ਤੋਂ ਆਮ ਸਮੱਸਿਆ ਹਨ ਅਤੇ ਠੀਕ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਆਸਾਨ ਵੀ। 4,000 ਪਿਕਸਲ ਦੀ ਫੋਟੋ ਜੋ 800 ਪਿਕਸਲ ਚੌੜੀ ਦਿਖਾਈ ਜਾਂਦੀ ਹੈ, ਹਰ ਵਿਜ਼ਟਰ ਨੂੰ ਉਸ ਤੋਂ ਪੰਜ ਗੁਣਾ ਵੱਧ ਡਾਊਨਲੋਡ ਕਰਵਾਉਂਦੀ ਹੈ ਜਿੰਨਾ ਉਹ ਦੇਖਦਾ ਹੈ।
- ਤਸਵੀਰਾਂ ਉਸੇ ਆਕਾਰ 'ਤੇ ਦਿਓ ਜਿਸ 'ਤੇ ਉਹ ਦਿਖਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਫ਼ੋਨਾਂ ਅਤੇ ਡੈਸਕਟਾਪ ਲਈ ਰਿਸਪਾਂਸਿਵ
srcsetਆਕਾਰਾਂ ਨਾਲ। - ਆਧੁਨਿਕ ਫਾਰਮੈਟ (WebP ਜਾਂ AVIF) ਅਤੇ ਸਮਝਦਾਰ ਕੰਪ੍ਰੈਸ਼ਨ ਵਰਤੋ।
- ਹਰ ਤਸਵੀਰ 'ਤੇ
widthਅਤੇheightਸੈੱਟ ਕਰੋ ਤਾਂ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਜਗ੍ਹਾ ਰਾਖਵੀਂ ਰੱਖੇ। ਇਹ ਇਕੱਲਾ ਹੀ ਜ਼ਿਆਦਾਤਰ ਲੇਆਉਟ ਸ਼ਿਫਟ ਠੀਕ ਕਰ ਦਿੰਦਾ ਹੈ। - ਫੋਲਡ ਤੋਂ ਹੇਠਲੀਆਂ ਤਸਵੀਰਾਂ ਨੂੰ
loading="lazy"ਨਾਲ ਲੇਜ਼ੀ-ਲੋਡ ਕਰੋ। - ਪੰਨੇ ਦੇ ਸਿਖਰ ਵਾਲੀ ਮੁੱਖ ਤਸਵੀਰ ਨੂੰ ਲੇਜ਼ੀ-ਲੋਡ ਨਾ ਕਰੋ। Google ਦੀ LCP ਹਿਦਾਇਤ ਸਾਫ਼ ਹੈ: LCP ਤਸਵੀਰ ਨੂੰ ਲੇਜ਼ੀ-ਲੋਡ ਕਰਨ ਨਾਲ ਉਹ ਹਮੇਸ਼ਾਂ ਦੇਰ ਹੁੰਦੀ ਹੈ। ਇਸ ਦੀ ਥਾਂ
fetchpriority="high"ਦਿਓ।
JavaScript
ਬਹੁਤ ਸਾਰੀਆਂ AI ਨਾਲ ਬਣੀਆਂ ਸਾਈਟਾਂ ਸਿੰਗਲ-ਪੇਜ ਐਪਾਂ (SPA) ਹਨ: ਬ੍ਰਾਊਜ਼ਰ ਇੱਕ JavaScript ਬੰਡਲ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਪੰਨਾ ਬਣਾਉਂਦਾ ਹੈ। ਬੰਡਲ ਜਿੰਨਾ ਵੱਡਾ, ਖਾਲੀ ਸਕਰੀਨ ਓਨੀ ਲੰਮੀ। ਠੀਕ ਕਰਨ ਦੇ ਤਰੀਕੇ, ਮਿਹਨਤ ਦੇ ਕ੍ਰਮ ਵਿੱਚ:
- ਜੋ ਨਹੀਂ ਵਰਤਦੇ ਉਸ ਨੂੰ ਹਟਾਓ। ਨਿਰਭਰਤਾਵਾਂ ਦੀ ਸੂਚੀ ਮੰਗੋ ਅਤੇ ਉਹ ਲਾਇਬ੍ਰੇਰੀਆਂ ਕੱਟੋ ਜੋ ਇੱਕ ਵਾਰ ਜੋੜੀਆਂ ਗਈਆਂ ਅਤੇ ਭੁੱਲ ਗਈਆਂ — ਇੱਕ ਤਾਰੀਖ ਲਈ ਇੱਕ ਪੂਰੀ ਤਾਰੀਖ ਲਾਇਬ੍ਰੇਰੀ, ਜਾਂ ਪੰਜ ਆਈਕਨਾਂ ਲਈ ਪੂਰਾ ਆਈਕਨ ਪੈਕ।
- ਰੂਟ ਅਨੁਸਾਰ ਵੰਡੋ। ਐਡਮਿਨ ਡੈਸ਼ਬੋਰਡ ਦਾ ਕੋਡ ਉਦੋਂ ਹੀ ਲੋਡ ਕਰੋ ਜਦੋਂ ਕੋਈ ਉਸ ਨੂੰ ਖੋਲ੍ਹੇ, ਹੋਮ ਪੰਨੇ 'ਤੇ ਨਹੀਂ।
- ਜਨਤਕ ਪੰਨਿਆਂ ਨੂੰ ਪ੍ਰੀਰੈਂਡਰ ਕਰੋ। ਮਾਰਕੀਟਿੰਗ ਪੰਨਾ ਜੋ ਅਸਲ HTML ਵਜੋਂ ਜਾਂਦਾ ਹੈ, ਕਿਸੇ JavaScript ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ ਦਿਸਦਾ ਹੈ। ਇਸ ਨਾਲ ਖੋਜ ਇੰਜਣਾਂ ਨੂੰ ਵੀ ਮਦਦ ਮਿਲਦੀ ਹੈ; ਵੇਖੋ AI ਨਾਲ ਬਣੀਆਂ ਵੈੱਬਸਾਈਟਾਂ ਲਈ SEO।
ਹੌਲੀ INP ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਲੰਮਾ ਕੰਮ ਹੁੰਦਾ ਹੈ ਜੋ ਪੰਨੇ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਜਿਵੇਂ ਹਰ ਕੀਸਟ੍ਰੋਕ 'ਤੇ ਵੱਡੀ ਸੂਚੀ ਨੂੰ ਫਿਲਟਰ ਕਰਨਾ, ਜਾਂ ਇੱਕ ਸੈੱਲ ਬਦਲਣ 'ਤੇ ਪੂਰੀ ਟੇਬਲ ਦੁਬਾਰਾ ਰੈਂਡਰ ਕਰਨਾ। Chrome DevTools ਦਾ Performance ਪੈਨਲ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜਾ।
ਫੌਂਟ
ਹਰ ਫੌਂਟ ਪਰਿਵਾਰ ਅਤੇ ਵਜ਼ਨ ਇੱਕ ਹੋਰ ਫਾਈਲ ਹੈ। ਦੋ ਪਰਿਵਾਰ ਅਤੇ ਤਿੰਨ-ਚਾਰ ਵਜ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹਨ। ਫੋਲਡ ਤੋਂ ਉੱਪਰ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਫੌਂਟ ਪ੍ਰੀਲੋਡ ਕਰੋ, font-display: swap ਵਰਤੋ ਤਾਂ ਜੋ ਟੈਕਸਟ ਤੁਰੰਤ ਦਕਿਸੇ, ਅਤੇ ਜੇ ਬਾਹਰੀ ਫੌਂਟ ਸੇਵਾ ਤੁਹਾਡੇ ਵਿਜ਼ਟਰਾਂ ਲਈ ਹੌਲੀ ਹੈ ਤਾਂ ਫੌਂਟ ਆਪਣੇ ਸਰਵਰ 'ਤੇ ਰੱਖੋ।
ਤੀਜੀ ਧਿਰ ਸਕ੍ਰਿਪਟਾਂ
ਚੈਟ ਵਿਜੇਟ, ਵਿਸ਼ਲੇਸ਼ਣ, ਹੀਟਮੈਪ, ਐਡ ਪਿਕਸਲ, ਏਮਬੈੱਡ ਕੀਤੇ ਵੀਡੀਓ ਅਤੇ ਸੋਸ਼ਲ ਫੀਡ ਸਭ ਹੋਰ ਸਰਵਰਾਂ ਤੋਂ ਕੋਡ ਲੋਡ ਕਰਦੇ ਹਨ। ਹਰ ਇੱਕ ਛੋਟਾ ਲੱਗਦਾ ਹੈ; ਮਿਲ ਕੇ ਅਕਸਰ ਪੰਨੇ ਦਾ ਸਭ ਤੋਂ ਹੌਲਾ ਹਿੱਸਾ ਬਣਦੇ ਹਨ। ਜਿਹੜੇ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਵੇਖਦੇ ਹੋ ਉਨ੍ਹਾਂ ਨੂੰ ਰੱਖੋ। ਬਾਕੀਆਂ ਨੂੰ ਪੰਨਾ ਇੰਟਰਐਕਟਿਵ ਹੋਣ ਤੋਂ ਬਾਅਦ ਲੋਡ ਕਰੋ, ਅਤੇ ਭਾਰੀ ਏਮਬੈੱਡਾਂ (ਯੂਟਿਊਬ ਪਲੇਅਰ, ਨਕਸ਼ਾ) ਦੀ ਥਾਂ ਹਲਕਾ ਪ੍ਰੀਵਿਊ ਦਿਓ ਜੋ ਕਲਿੱਕ 'ਤੇ ਅਸਲੀ ਚੀਜ਼ ਲੋਡ ਕਰੇ।
ਸਰਵਰ ਜਵਾਬ
Time to first byte (TTFB) — ਸਰਵਰ ਨੂੰ ਜਵਾਬ ਸ਼ੁਰੂ ਕਰਨ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ — ਹਰ ਹੋਰ ਮੈਟ੍ਰਿਕ ਦੇ ਹੇਠਾਂ ਹੁੰਦਾ ਹੈ। CDN ਤੋਂ ਪਰੋਸੇ ਜਾਂਦੇ ਸਟੈਟਿਕ ਪੰਨੇ (ਸਰਵਰਾਂ ਦਾ ਨੈੱਟਵਰਕ ਜੋ ਤੁਹਾਡੇ ਵਿਜ਼ਟਰਾਂ ਦੇ ਨੇੜੇ ਹੈ; ਵੇਖੋ CDN ਕੀ ਹੈ) ਲਗਭਗ ਹਰ ਥਾਂ ਤੇਜ਼ ਹਨ। ਹਰ ਬੇਨਤੀ 'ਤੇ ਸਰਵਰ ਵੱਲੋਂ ਬਣਾਏ ਪੰਨੇ ਉਸ ਸਰਵਰ ਅਤੇ ਉਸ ਦੇ ਡੇਟਾਬੇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਕੈਸ਼ਿੰਗ ਦੁਹਰਾਇਆ ਕੰਮ ਬਚਾਉਂਦੀ ਹੈ, ਅਤੇ ਹੌਲੀ ਕਵੇਰੀਆਂ ਲਈ ਡੇਟਾਬੇਸ ਇੰਡੈਕਸ ਜੋੜਨਾ ਆਮ ਹੱਲ ਹੈ।
ਕੰਮ ਕਰਨ ਵਾਲੇ ਪ੍ਰੰਪਟ
ਖਾਸ ਬਣੋ: ਪੰਨੇ, ਮੈਟ੍ਰਿਕ ਅਤੇ ਸੀਮਾ ਦਾ ਨਾਮ ਲਓ। ਜੇ ਹੋਵੇ ਤਾਂ PageSpeed Insights ਦੀਆਂ ਖੋਜਾਂ ਪੇਸਟ ਕਰੋ।
PageSpeed Insights ਮੁੱਖ ਪੰਨੇ ਲਈ ਮੋਬਾਈਲ 'ਤੇ 4.8 ਸਕਿੰਟ LCP ਦੱਸਦਾ ਹੈ, ਅਤੇ LCP ਤੱਤ ਹੀਰੋ ਤਸਵੀਰ ਹੈ। ਹੀਰੋ ਤਸਵੀਰ ਨੂੰ WebP ਵਿੱਚ ਬਦਲੋ ਅਤੇ ਆਕਾਰ ਘਟਾਓ, ਰਿਸਪਾਂਸਿਵ ਆਕਾਰ ਦਿਓ, width ਅਤੇ height ਸੈੱਟ ਕਰੋ, fetchpriority="high" ਦਿਓ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਉਹ ਲੇਜ਼ੀ ਨਹੀਂ। ਫੋਲਡ ਤੋਂ ਹੇਠਲੀ ਹਰ ਤਸਵੀਰ ਲੇਜ਼ੀ-ਲੋਡ ਕਰੋ। ਡਿਜ਼ਾਈਨ ਨਾ ਬਦਲੋ।
ਇਸ ਐਪ ਦੀਆਂ ਨਿਰਭਰਤਾਵਾਂ ਦਾ ਆਡਿਟ ਕਰੋ। ਹਰ ਪੈਕੇਜ ਦੀ ਸੂਚੀ ਬਣਾਓ, ਦੱਸੋ ਕਿ ਕੌਣ ਉਸ ਨੂੰ ਵਰਤਦਾ ਹੈ ਅਤੇ ਬੰਡਲ ਵਿੱਚ ਲਗਭਗ ਕਿੰਨਾ ਜੋੜਦਾ ਹੈ। ਨਾ ਵਰਤੇ ਪੈਕੇਜ ਹਟਾਓ ਅਤੇ /admin ਅਤੇ /settings ਰੂਟਾਂ ਨੂੰ ਵੱਖਰੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡੋ ਜੋ ਸਿਰਫ਼ ਜਾਣ 'ਤੇ ਲੋਡ ਹੋਣ।
/products 'ਤੇ ਖੋਜ ਬਾਕਸ ਫ਼ੀਲ ਹੋਣ ਵਿੱਚ ਸੁਸਤ ਲੱਗਦਾ ਹੈ। ਫਿਲਟਰ ਨੂੰ ਡੀਬਾਊਂਸ ਕਰੋ, ਹਰ ਕੀਸਟ੍ਰੋਕ 'ਤੇ ਪੂਰੀ ਸੂਚੀ ਦੁਬਾਰਾ ਰੈਂਡਰ ਕਰਨ ਤੋਂ ਬਚੋ, ਅਤੇ ਜੇ ਸੂਚੀ ਵਿੱਚ 200 ਤੋਂ ਵੱਧ ਆਈਟਮ ਹਨ ਤਾਂ ਪੇਜ ਜਾਂ ਵਰਚੁਅਲਾਈਜ਼ ਕਰੋ।
ਕਦਮ-ਦਰ-ਕਦਮ
- ਲਾਈਵ ਪੰਨਾ ਟੈਸਟ ਕਰੋ PageSpeed Insights ਵਿੱਚ ਮੋਬਾਈਲ 'ਤੇ। LCP, INP ਅਤੇ CLS, ਅਤੇ ਸੂਚੀ ਵਿੱਚ ਦਿੱਤੀਆਂ ਤਿੰਨ ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੋਟ ਕਰੋ।
- ਤਸਵੀਰਾਂ ਪਹਿਲਾਂ ਠੀਕ ਕਰੋ: ਆਕਾਰ, ਫਾਰਮੈਟ, ਮਾਪ, ਫੋਲਡ ਤੋਂ ਹੇਠਾਂ ਲੇਜ਼ੀ ਲੋਡਿੰਗ, ਹੀਰੋ ਲਈ ਤਰਜੀਹ।
- ਨਾ ਵਰਤੀਆਂ ਤੀਜੀ ਧਿਰ ਸਕ੍ਰਿਪਟਾਂ ਕੱਟੋ, ਅਤੇ ਬਾਕੀਆਂ ਨੂੰ ਟਾਲੋ।
- ਫੌਂਟ ਘਟਾਓ ਜਿੰਨੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਚਾਹੀਦੇ ਹਨ।
- JavaScript ਘਟਾਓ: ਨਾ ਵਰਤੇ ਪੈਕੇਜ ਹਟਾਓ, ਰੂਟ ਅਨੁਸਾਰ ਵੰਡੋ।
- ਜਨਤਕ ਪੰਨੇ ਪ੍ਰੀਰੈਂਡਰ ਕਰੋ ਜੇ ਉਹ ਅਜੇ ਵੀ ਕਲਾਇੰਟ 'ਤੇ ਰੈਂਡਰ ਹੁੰਦੇ ਹਨ ਅਤੇ LCP ਅਜੇ ਵੀ ਹੌਲੀ ਹੈ।
- ਸਰਵਰ ਜਾਂਚੋ: ਕੈਸ਼ਿੰਗ, ਡੇਟਾਬੇਸ ਇੰਡੈਕਸ, ਅਕਸਰ ਨਾ ਬਦਲਣ ਵਾਲੀ ਸਮੱਗਰੀ ਲਈ ਸਟੈਟਿਕ ਹੋਸਟਿੰਗ।
- ਦੁਬਾਰਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ ਅਤੇ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰੋ। PageSpeed Insights ਦਾ ਫੀਲਡ ਡੇਟਾ ਅਗਲੇ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਅਸਲ ਵਿਜ਼ਿਟਾਂ ਨਾਲ ਅੱਪਡੇਟ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਸ਼ੁਰੂਆਤੀ ਨਤੀਜੇ ਲੈਬ ਡੇਟਾ ਤੋਂ ਪਰਖੋ।
ਆਮ ਗਲਤੀਆਂ
- ਸਿਰਫ਼ ਤੇਜ਼ ਲੈਪਟਾਪ 'ਤੇ ਟੈਸਟ ਕਰਨਾ। ਤੁਹਾਡੇ ਵਿਜ਼ਟਰ ਮੱਧਮ ਫ਼ੋਨਾਂ ਅਤੇ ਕਮਜ਼ੋਰ ਮੋਬਾਈਲ ਡੇਟਾ 'ਤੇ ਹਨ। ਮੋਬਾਈਲ ਮੋਡ ਵਿੱਚ ਟੈਸਟ ਕਰੋ।
- ਸੰਪੂਰਨ 100 ਦਾ ਪਿੱਛਾ ਕਰਨਾ। ਲੈਬ ਸਕੋਰ ਇੱਕ ਗਾਈਡ ਹੈ। ਇੱਕ ਵਾਰ Core Web Vitals ਚੰਗੀ ਰੇਂਜ ਵਿੱਚ ਹੋਣ, ਤਾਂ ਸਮੱਗਰੀ ਅਤੇ ਵਰਤੋਂਯੋਗਤਾ ਆਖਰੀ ਕੁਝ ਅੰਕਾਂ ਨਾਲੋਂ ਵੱਧ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ।
- ਸਾਰੀ ਚੀਜ਼ ਲੇਜ਼ੀ-ਲੋਡ ਕਰਨਾ, ਹੀਰੋ ਤਸਵੀਰ ਸਮੇਤ। ਇਸ ਨਾਲ LCP ਹੋਰ ਵਿਗੜਦਾ ਹੈ।
- ਉੱਪਰ ਇੱਕ ਸਪੀਡ ਪਲੱਗਇਨ ਜਾਂ ਲਾਇਬ੍ਰੇਰੀ ਜੋੜਨਾ। ਭਾਰ ਘਟਾਉਣਾ ਲਗਭਗ ਹਮੇਸ਼ਾਂ ਉਸ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਹੋਰ ਕੋਡ ਜੋੜਨ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ।
- ਪ੍ਰੀਵਿਊ ਨੂੰ ਅਨੁਕੂਲ ਕਰਨਾ, ਲਾਈਵ ਸਾਈਟ ਨੂੰ ਨਹੀਂ। ਡਿਵੈਲਪਮੈਂਟ ਪ੍ਰੀਵਿਊ ਅਣਅਨੁਕੂਲ ਬਿਲਡ ਚਲਾਉਂਦੇ ਹਨ। ਪ੍ਰਕਾਸ਼ਿਤ URL ਨੂੰ ਮਾਪੋ।
- ਸਪੀਡ ਇੱਕ ਵਾਰ ਠੀਕ ਕਰਨਾ। ਹਰ ਨਵਾਂ ਵਿਜੇਟ, ਤਸਵੀਰ ਅਤੇ ਫੀਚਰ ਭਾਰ ਜੋੜਦਾ ਹੈ। ਵੱਡੇ ਬਦਲਾਵਾਂ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰੋ।
ਸਪੀਡ ਚੈੱਕਲਿਸਟ
- ਮੋਬਾਈਲ 'ਤੇ LCP ≤ 2.5 ਸਕਿੰਟ, INP ≤ 200 ms, CLS ≤ 0.1
- ਤਸਵੀਰਾਂ ਦਾ ਆਕਾਰ ਘਟਾਇਆ, ਕੰਪ੍ਰੈੱਸ ਕੀਤਾ, ਆਧੁਨਿਕ ਫਾਰਮੈਟ, width ਅਤੇ height ਸਮੇਤ
- ਹੀਰੋ ਤਸਵੀਰ ਲੇਜ਼ੀ ਨਹੀਂ; ਫੋਲਡ ਤੋਂ ਹੇਠਲੀਆਂ ਲੇਜ਼ੀ-ਲੋਡ
- ਕੋਈ ਨਾ ਵਰਤੀ JavaScript ਲਾਇਬ੍ਰੇਰੀ ਨਹੀਂ; ਭਾਰੀ ਰੂਟ ਵੱਖ ਕੀਤੇ
- ਦੋ ਫੌਂਟ ਪਰਿਵਾਰ ਜਾਂ ਘੱਟ; ਮੁੱਖ ਫੌਂਟ ਪ੍ਰੀਲੋਡ
- ਸਿਰਫ਼ ਉਹੀ ਤੀਜੀ ਧਿਰ ਸਕ੍ਰਿਪਟਾਂ ਜੋ ਵਰਤਦੇ ਹੋ, ਦੇਰ ਨਾਲ ਲੋਡ
- ਜਨਤਕ ਪੰਨੇ ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ ਪ੍ਰੀਰੈਂਡਰ ਜਾਂ ਸਟੈਟਿਕ
- ਪ੍ਰਕਾਸ਼ਿਤ ਹੋਣ ਤੋਂ ਬਾਅਦ ਲਾਈਵ URL 'ਤੇ ਦੁਬਾਰਾ ਟੈਸਟ ਕੀਤਾ
ਸਪੀਡ ਅਤੇ ਮੋਬਾਈਲ ਲੇਆਉਟ ਇਕੱਠੇ ਚੱਲਦੇ ਹਨ; ਵੇਖੋ ਵੈੱਬਸਾਈਟ ਨੂੰ ਮੋਬਾਈਲ ਰਿਸਪਾਂਸਿਵ ਕਿਵੇਂ ਬਣਾਈਏ। ਪੂਰੀ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਜਾਂਚ ਲਈ, AI ਪ੍ਰੋਟੋਟਾਈਪ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਕਿਵੇਂ ਲਿਜਾਈਏ ਬਾਕੀ ਕਵਰ ਕਰਦਾ ਹੈ।
Mythex 'ਤੇ ਸਪੀਡ
Mythex 'ਤੇ ਤੁਸੀਂ ਇਹ ਤਬਦੀਲੀਆਂ ਚੈਟ ਵਿੱਚ ਪੁੱਛ ਕੇ ਕਰਦੇ ਹੋ, ਜਾਂ Pro 'ਤੇ ਕੋਡ ਐਡੀਟਰ ਵਿੱਚ। ਜਾਂਚ ਪ੍ਰੀਵਿਊ ਦੀ ਥਾਂ ਪ੍ਰਕਾਸ਼ਿਤ URL 'ਤੇ ਕਰੋ, ਕਿਉਂਕਿ ਪ੍ਰੀਵਿਊ ਇੱਕ ਡਿਵੈਲਪਮੈਂਟ ਸਰਵਰ ਚਲਾਉਂਦਾ ਹੈ। ਸਟੈਟਿਕ ਫਰੰਟ ਐਂਡ ਪ੍ਰਕਾਸ਼ਿਤ ਹੋਣ 'ਤੇ ਸਟੈਟਿਕ ਸਾਈਟਾਂ ਵਜੋਂ ਡਿਪਲੋਏ ਹੁੰਦੇ ਹਨ (ਸਟੈਟਿਕ ਵੈੱਬਸਾਈਟਾਂ), ਜੋ ਸਮੱਗਰੀ ਪੰਨਿਆਂ ਲਈ ਢੁਕਵੀਆਂ ਹਨ। ਸਰਵਰ ਵਾਲੀਆਂ ਐਪਾਂ ਸਕੇਲ ਟੂ ਜ਼ੀਰੋ ਹੁੰਦੀਆਂ ਹਨ: ਵਿਹਲ ਵਿੱਚ ਸੌਂਦੀਆਂ ਹਨ ਅਤੇ ਅਗਲੀ ਵਿਜ਼ਿਟ 'ਤੇ ਜਾਗਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਸ਼ਾਂਤ ਸਮੇਂ ਤੋਂ ਬਾਅਦ ਪਹਿਲੀ ਬੇਨਤੀ ਹੌਲੀ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਜੁੜਿਆ ਡੇਟਾਬੇਸ 5 ਮਿੰਟ ਦੀ ਵਿਹਲ ਬਾਅਦ ਸੌਂ ਜਾਂਦਾ ਹੈ (ਹੋਸਟਿੰਗ ਹੱਦਾਂ)। ਜੇ ਕੋਈ ਜਨਤਕ ਪੰਨਾ ਸਿਰਫ਼ ਪਹਿਲੀ ਵਿਜ਼ਿਟ 'ਤੇ ਹੌਲੀ ਹੈ, ਤਾਂ ਇਹ ਸੰਭਾਵਿਤ ਕਾਰਨ ਹੈ। ਸਮੱਗਰੀ-ਭਾਰੀ ਪੰਨਿਆਂ ਨੂੰ ਸਟੈਟਿਕ ਰੱਖਣਾ ਮਦਦ ਕਰਦਾ ਹੈ। ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ ਅਤੇ ਹਾਰਡ-ਰਿਫ੍ਰੈਸ਼ ਕਰੋ।
ਸਵਾਲ
ਪੰਨਾ ਲੋਡ ਹੋਣ ਦਾ ਚੰਗਾ ਸਮਾਂ ਕਿਹੜਾ ਹੈ?
Google ਦੇ Core Web Vitals ਸਭ ਤੋਂ ਸਾਫ਼ ਟੀਚੇ ਦਿੰਦੇ ਹਨ: ਮੁੱਖ ਸਮੱਗਰੀ 2.5 ਸਕਿੰਟਾਂ ਵਿੱਚ ਦਿਸਣੀ ਚਾਹੀਦੀ ਹੈ (LCP), ਪੰਨੇ ਨੂੰ ਇਨਪੁਟ ਦਾ ਜਵਾਬ 200 ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ (INP), ਅਤੇ ਲੇਆਉਟ ਸ਼ਿਫਟ 0.1 ਜਾਂ ਘੱਟ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ (CLS), ਅਸਲ ਵਿਜ਼ਿਟਾਂ ਦੇ 75ਵੇਂ ਪਰਸੈਂਟਾਈਲ 'ਤੇ ਮਾਪੀ ਗਈ।
ਕੀ ਵੈੱਬਸਾਈਟ ਦੀ ਸਪੀਡ SEO 'ਤੇ ਅਸਰ ਪਾਉਂਦੀ ਹੈ?
ਥੋੜ੍ਹਾ, ਹਾਂ। Google ਪੰਨਾ ਅਨੁਭਵ ਦੇ ਸੰਕੇਤ ਵਰਤਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ Core Web Vitals ਸ਼ਾਮਲ ਹਨ, ਪਰ ਢੁਕਵੀਂ ਸਮੱਗਰੀ ਕਿਤੇ ਵੱਧ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ। ਸਪੀਡ ਦਾ ਅਸਰ ਵਿਜ਼ਟਰਾਂ 'ਤੇ ਵੱਡਾ ਹੈ, ਕਿਉਂਕਿ ਉਹ ਹੌਲੀ ਪੰਨੇ ਨੂੰ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਛੱਡ ਦਿੰਦੇ ਹਨ।
ਮੇਰਾ PageSpeed Insights ਸਕੋਰ ਹਰ ਵਾਰ ਵੱਖਰਾ ਕਿਉਂ ਆਉਂਦਾ ਹੈ?
ਲੈਬ ਸਕੋਰ ਇੱਕ ਸਿਮੂਲੇਟਿਡ ਲੋਡ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਨੈੱਟਵਰਕ ਅਤੇ ਸਰਵਰ ਦਾ ਸਮਾਂ ਹਰ ਵਾਰ ਬਦਲਦਾ ਹੈ। ਇਸ ਨੂੰ ਕਈ ਵਾਰ ਚਲਾਓ ਅਤੇ ਰੁਝਾਨ ਵੇਖੋ, ਅਤੇ ਫੀਲਡ ਡੇਟਾ ਵਾਲੇ ਭਾਗ ਨੂੰ ਵੱਧ ਅਹਮੀਅਤ ਦਿਓ, ਜੋ ਅਸਲ Chrome ਯੂਜ਼ਰਾਂ ਤੋਂ ਆਉਂਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਵੈੱਬਸਾਈਟਾਂ ਨੂੰ ਕੀ ਹੌਲੀ ਕਰਦਾ ਹੈ?
ਆਮ ਤੌਰ 'ਤੇ ਬਹੁਤ ਵੱਡੀਆਂ ਤਸਵੀਰਾਂ, ਬਹੁਤ ਜ਼ਿਆਦਾ JavaScript, ਵੈੱਬ ਫੌਂਟ ਅਤੇ ਤੀਜੀ ਧਿਰ ਸਕ੍ਰਿਪਟਾਂ, ਜਿਵੇਂ ਚੈਟ ਵਿਜੇਟ, ਐਡ ਪਿਕਸਲ ਅਤੇ ਏਮਬੈੱਡ। ਸਰਵਰ ਦਾ ਹੌਲੀ ਜਵਾਬ ਜਾਂ ਠੰਡੇ ਤੋਂ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲਾ ਬੈਕਐਂਡ ਇਨ੍ਹਾਂ ਸਭ ਵਿੱਚ ਹੋਰ ਵਾਧਾ ਕਰਦਾ ਹੈ।