Core Web Vitals ਫਿਕਸ: 95+ Lighthouse ਸਕੋਰਾਂ ਲਈ ਡਿਵੈਲਪਰ ਗਾਈਡ
ਜੇ ਤੁਸੀਂ ਲੱਭ ਰਹੇ ਹੋ Core Web Vitals fix ਜੋ ਤੁਹਾਡੇ Lighthouse ਸਕੋਰਾਂ ਨੂੰ 95 ਤੋਂ ਪਾਰ ਧੱਕਦਾ ਹੈ, ਤੁਸੀਂ ਸਹੀ ਜਗ੍ਹਾ ਆਏ ਹੋ। ਪ੍ਰਾਪਤ ਕਰਨਾ Lighthouse 95 ਮਿੱਥ ਨਹੀਂ ਹੈ—ਇਹ ਇੱਕ ਵਿਵਸਥਿਤ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜਿਸਨੂੰ ਮੈਂ DG10 Agency ਵਿੱਚ ਦਰਜਨਾਂ enterprise ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਨਿਖਾਰਿਆ ਹੈ।
ਤਰੀਕਾ ਨੋਟ: ਹੇਠਾਂ ਉਪਚਾਰ ਕਦਮ ਅਪ੍ਰੈਲ ਤੋਂ ਅਗਸਤ 2026 ਵਿਚਕਾਰ DG10 ਗਾਹਕ ਸਾਈਟਾਂ (WordPress, Next.js, Shopify) 'ਤੇ ਪ੍ਰਮਾਣਿਤ ਕੀਤੇ ਗਏ ਸਨ, ਹਰੇਕ ਫੀਲਡ CrUX ਡਾਟਾ ਅਤੇ ਲੈਬ Lighthouse ਦੌੜਾਂ ਨਾਲ ਮਾਪਿਆ ਗਿਆ। ਸੀਮਾਵਾਂ ਅਤੇ ਔਜ਼ਾਰ ਹਵਾਲੇ ਸਤੰਬਰ 2026 ਵਿੱਚ ਮੁੜ-ਜਾਂਚੇ ਗਏ ਸਨ।
ਅਸਲੀਅਤ ਬੇਰਹਿਮ ਹੈ: ਜੂਨ 2026 ਤੱਕ, ਚੋਟੀ ਦੀਆਂ 10 ਲੱਖ ਵੈੱਬਸਾਈਟਾਂ ਵਿੱਚੋਂ 20% ਤੋਂ ਘੱਟ ਸਾਰੇ ਪੇਜ ਕਿਸਮਾਂ ਵਿੱਚ Google ਦੇ Core Web Vitals ਥ੍ਰੈਸ਼ਹੋਲਡ ਪੂਰੇ ਕਰਦੀਆਂ ਹਨ। ਪਰ ਜਦੋਂ ਅਸੀਂ ਕੰਮ ਕਰਦੇ ਹਾਂ — ਅਸਲ ਸੁਧਾਰ, ਸਤਹੀ ਪੈਚ ਨਹੀਂ — ਤਾਂ ਨਤੀਜੇ ਆਪ ਬੋਲਦੇ ਹਨ। 15–40% ਟ੍ਰੈਫਿਕ ਵਾਧਾ ਆਮ ਹੈ, ਅਤੇ ਉਹ SEO ਰੈਂਕਿੰਗ ਅਸਥਿਰਤਾ ਜਿਸ ਤੋਂ ਅਸੀਂ ਸਾਰੇ ਡਰਦੇ ਹਾਂ? ਇਹ ਸਥਿਰ ਹੋ ਜਾਂਦੀ ਹੈ।
ਇਹ ਗਾਈਡ ਮੇਰੀ ਇਮਾਨਦਾਰ, ਜੰਗ-ਪਰਖੀ ਯੋਜਨਾ ਹੈ। ਅਸੀਂ ਹਰ ਮੈਟ੍ਰਿਕ, ਉਹ ਸਹੀ ਟੂਲ ਜੋ ਮੈਂ ਵਰਤਦਾ ਹਾਂ, ਅਤੇ ਕੋਡ-ਪੱਧਰੀ ਤਬਦੀਲੀਆਂ ਨੂੰ ਕਵਰ ਕਰਾਂਗੇ ਜੋ ਸੂਈ ਨੂੰ ਹਿਲਾਉਂਦੀਆਂ ਹਨ। ਮੈਂ ਅਸਲ ਪਹਿਲਾਂ/ਬਾਅਦ ਡੇਟਾ, ਆਮ ਗਲਤੀਆਂ ਅਤੇ ਇੱਕ ਵਰਕਫ਼ਲੋ ਸਾਂਝਾ ਕਰਾਂਗਾ ਜੋ ਕਿਸੇ ਵੀ ਸਾਈਟ ਨੂੰ ਲਾਲ ਤੋਂ ਹਰੇ ਤੱਕ ਲੈ ਜਾ ਸਕਦਾ ਹੈ। ਇੱਥੇ ਹਰ ਸਿਫਾਰਸ਼ ਹੱਥੀਂ ਤਜ਼ਰਬੇ ਤੋਂ ਆਉਂਦੀ ਹੈ — ਮੈਂ ਸਕੋਰ ਚੜ੍ਹਦੇ ਅਤੇ ਟ੍ਰੈਫਿਕ ਪਿੱਛੇ ਆਉਂਦੇ ਦੇਖਿਆ ਹੈ।
Core Web Vitals ਨੂੰ ਠੀਕ ਕਰਨਾ ਤੁਹਾਡੇ ਮੁਨਾਫ਼ੇ ਉੱਤੇ ਸਿੱਧਾ ਅਸਰ ਕਿਉਂ ਪਾਉਂਦਾ ਹੈ
ਆਓ ਕਾਰੋਬਾਰੀ ਮਾਮਲਾ ਪਾਸੇ ਕਰ ਦਈਏ। Google ਦੀ ਦਰਜਾਬੰਦੀ ਪ੍ਰਣਾਲੀ—ਸਾਲਾਂ ਪਹਿਲਾਂ ਘੋਸ਼ਿਤ—ਅਜੇ ਵੀ CWV ਨੂੰ ਦਰਜਾਬੰਦੀ ਸਿਗਨਲ ਵਜੋਂ ਵਰਤਦੀ ਹੈ। ਪਰ ਜੋ ਡੇਟਾ ਮੈਂ ਗਾਹਕਾਂ ਵਿੱਚ ਦੇਖਿਆ ਹੈ ਉਹ ਕੁਝ ਹੋਰ ਸੂਖਮ ਦਿਖਾਉਂਦਾ ਹੈ।
ਅਸਲ ਟ੍ਰੈਫਿਕ ਵਾਧਾ ਕੋਈ ਮਿੱਥ ਨਹੀਂ ਹੈ
ਮੈਂ ਹਾਲ ਹੀ ਵਿੱਚ ਇੱਕ SaaS ਕੰਪਨੀ ਦਾ ਆਡਿਟ ਕੀਤਾ ਜੋ 92 Lighthouse ਪ੍ਰਦਰਸ਼ਨ ਸਕੋਰ ਉੱਤੇ ਅਟਕੀ ਸੀ। ਉਨ੍ਹਾਂ ਦੇ ਸਭ ਤੋਂ ਵੱਡੇ ਕੰਟੈਂਟਫੁਲ ਪੇਂਟ (LCP), ਕਿਊਮੂਲੇਟਿਵ ਲੇਆਉਟ ਸ਼ਿਫਟ (CLS), ਅਤੇ Interaction to Next Paint (INP) ਉੱਤੇ ਕੇਂਦ੍ਰਿਤ ਦੋ-ਹਫ਼ਤੇ ਸੁਧਾਰ ਸਪ੍ਰਿੰਟ ਤੋਂ ਬਾਅਦ, ਉਹ 97 ਉੱਤੇ ਪਹੁੰਚ ਗਏ। ਅਗਲੇ 90 ਦਿਨਾਂ ਵਿੱਚ ਆਰਗੈਨਿਕ ਟ੍ਰੈਫਿਕ 22% ਵਧਿਆ।
ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਅੰਕੜੇ ਅਪਵਾਦ ਨਹੀਂ ਹਨ। ਤੋਂ 2025 ਕੇਸ ਸਟੱਡੀ ਅਨੁਸਾਰ web.dev, "needs improvement" ਤੋਂ "good" ਤੱਕ CWV ਸੁਧਾਰਨ ਵਾਲੀਆਂ ਸਾਈਟਾਂ ਨੂੰ organic traffic ਵਿੱਚ 10–25% ਵਾਧਾ ਦਿਖਦਾ ਹੈ। ਇਹ Google ਪਹਿਲੇ ਪੰਨੇ ਦੀ ਸਥਿਤੀ ਦੀ ਅਸਲ ਹਰਕਤ ਹੈ। ਸਾਡੇ ਗਾਹਕ ਅਧਾਰ ਵਿੱਚ ਇੱਕ ਹੋਰ ਵਿਸ਼ਲੇਸ਼ਣ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਤਿੰਨੋਂ CWV ਸੀਮਾਵਾਂ ਪਾਸ ਕਰਨਾ non-branded ਖੋਜ ਕਲਿੱਕਾਂ ਵਿੱਚ ਔਸਤ 18% ਵਾਧੇ ਨਾਲ ਜੁੜਿਆ ਹੈ।
ਲੁਕੀ ਲਾਗਤ: ਬਾਊਂਸ ਦਰ ਅਤੇ ਕਨਵਰਜ਼ਨ
CWV ਸਿਰਫ਼ SEO ਲਈ ਨਹੀਂ ਹੈ। ਜਦੋਂ LCP 3.5s ਤੋਂ 1.8s 'ਤੇ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਬਾਊਂਸ ਦਰ ਘਟਦੀ ਹੈ। ਮੈਂ ਇਹ ਈ-ਕਾਮਰਸ ਸਾਈਟਾਂ 'ਤੇ ਟਰੈਕ ਕੀਤਾ ਹੈ: ਲੋਡ ਸਮੇਂ ਵਿੱਚ 0.5s ਸੁਧਾਰ ਬਾਊਂਸ ਦਰ ਨੂੰ 8–12% ਘਟਾਉਂਦਾ ਹੈ। ਇਸ ਨੂੰ ਪ੍ਰਤੀ ਮਹੀਨਾ ਲੱਖਾਂ ਸੈਸ਼ਨਾਂ ਨਾਲ ਗੁਣਾ ਕਰੋ, ਅਤੇ ਮਾਲੀਏ 'ਤੇ ਅਸਰ ਠੋਸ ਹੈ।
ਆਓ ਇਸ 'ਤੇ ਅੰਕੜਾ ਲਗਾਈਏ। 500,000 ਮਾਸਿਕ ਸੈਸ਼ਨਾਂ, 2.5% ਔਸਤ ਪਰਿਵਰਤਨ ਦਰ ਅਤੇ $75 AOV ਵਾਲੇ ਮੱਧ-ਆਕਾਰ ਦੇ ਈ-ਕਾਮਰਸ ਸਟੋਰ ਲਈ, ਬਾਊਂਸ ਦਰ ਵਿੱਚ 10% ਕਮੀ ਲਗਭਗ $93,000 ਵਾਧੂ ਮਾਸਿਕ ਆਮਦਨ ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ। ਇਹ ਉਸ ਤਰ੍ਹਾਂ ਦਾ ਕਾਰੋਬਾਰੀ ਨਤੀਜਾ ਹੈ ਜੋ ਇੱਕ Core Web Vitals fix ਪ੍ਰਦਾਨ ਕਰ ਸਕਦਾ ਹੈ—ਅਤੇ ਇਸੇ ਲਈ ਅਸੀਂ ਸਿਰਫ਼ ਘੱਟੋ-ਘੱਟ ਥ੍ਰੈਸ਼ਹੋਲਡ ਪਾਸ ਕਰਨ ਤੇ ਨਹੀਂ, ਦੋਵਾਂ ਮੈਟ੍ਰਿਕਸ ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਾਂ।
ਕ੍ਰੌਲ ਬਜਟ ਅਤੇ ਇੰਡੈਕਸੇਸ਼ਨ 'ਤੇ ਡੋਮੀਨੋ ਪ੍ਰਭਾਵ
ਅਕਸਰ ਅਣਦੇਖਿਆ ਲਾਭ Googlebot ਦਾ ਵਿਵਹਾਰ ਹੈ। ਜਦੋਂ ਤੁਹਾਡੇ ਪੰਨੇ ਤੇਜ਼ ਲੋਡ ਹੁੰਦੇ ਹਨ, Google ਦਾ ਕ੍ਰਾਲਰ ਪ੍ਰਤੀ ਵਾਲ-ਕਲਾਕ ਸਮਾਂ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਵੱਧ ਪ੍ਰੋਸੈਸ ਕਰ ਸਕਦਾ ਹੈ। ਮੈਂ ਦੇਖਿਆ ਹੈ ਕਿ ਜਿਨ੍ਹਾਂ ਸਾਈਟਾਂ ਨੇ ਆਪਣਾ LCP 40% ਸੁਧਾਰਿਆ, ਉਨ੍ਹਾਂ ਦੇ ਪ੍ਰਤੀ ਦਿਨ ਕ੍ਰਾਲ ਕੀਤੇ ਪੰਨਿਆਂ ਵਿੱਚ 30% ਵਾਧਾ ਹੋਇਆ। ਹਜ਼ਾਰਾਂ ਉਤਪਾਦ ਪੰਨਿਆਂ ਵਾਲੀਆਂ ਵੱਡੀਆਂ ਸਾਈਟਾਂ ਲਈ, ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਖੋਜੀ ਸਮੱਗਰੀ ਤੇਜ਼ੀ ਨਾਲ ਇੰਡੈਕਸ ਹੁੰਦੀ ਹੈ, ਜੋ ਜੈਵਿਕ ਵਾਧਾ ਚੱਕਰ ਨੂੰ ਸਿੱਧਾ ਤੇਜ਼ ਕਰਦੀ ਹੈ।
ਕੋਰ ਵੈੱਬ ਵਾਈਟਲਜ਼ ਮੈਟ੍ਰਿਕਸ ਅਤੇ Lighthouse 95 ਸਕੋਰਿੰਗ ਨੂੰ ਸਮਝਣਾ
To execute a Lighthouse 95 ਨਤੀਜੇ ਲਈ, ਤੁਹਾਨੂੰ ਸਮਝਣਾ ਹੋਵੇਗਾ ਕਿ Lighthouse ਸਕੋਰ ਫੀਲਡ ਡੇਟਾ (Chrome UX Report ਤੋਂ) ਅਤੇ ਲੈਬ ਡੇਟਾ (ਸਿਮੂਲੇਟਿਡ ਥ੍ਰੌਟਲਿੰਗ) ਨੂੰ ਕਿਵੇਂ ਜੋੜਦੇ ਹਨ। ਸਕੋਰਿੰਗ ਰੇਖਿਕ ਨਹੀਂ ਹੁੰਦੀ।
Largest Contentful Paint (LCP)
- Good: ≤ 2.5s
- Needs Improvement: 2.5s–4.0s
- Poor: > 4.0s
LCP ਸਮੁੱਚੇ Lighthouse ਪ੍ਰਦਰਸ਼ਨ ਸਕੋਰ ਦਾ 25% ਹੈ। 95+ ਸਕੋਰ ਲਈ, ਤੁਹਾਡਾ LCP ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਸਥਿਤੀਆਂ ਵਿੱਚ 1.8s ਤੋਂ ਘੱਟ ਅਤੇ 75ਵੇਂ ਪ੍ਰਤੀਸ਼ਤ ਫੀਲਡ ਡੇਟਾ ਵਿੱਚ 2.0s ਤੋਂ ਘੱਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਮੇਰੇ ਤਜਰਬੇ ਵਿੱਚ, 95+ ਹਾਸਲ ਕਰਨ ਵਾਲੀਆਂ ਜ਼ਿਆਦਾਤਰ ਸਾਈਟਾਂ ਦਾ LCP ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਵਿੱਚ ਲਗਭਗ 1.2–1.5s ਹੁੰਦਾ ਹੈ।
Interaction to Next Paint (INP)
- Good: ≤ 200ms
- Needs Improvement: 200ms–500ms
- Poor: > 500ms
INP ਨੇ ਮਾਰਚ 2024 ਵਿੱਚ FID ਦੀ ਥਾਂ ਲਈ। ਇਹ ਪੰਨੇ ਦੀ ਸਮੁੱਚੀ ਜਵਾਬਦੇਹੀ ਮਾਪਦਾ ਹੈ। 95+ ਸਕੋਰ ਲਈ, ਭਾਰੀ ਥ੍ਰਾਟਲਿੰਗ ਹੇਠ ਵੱਧ ਤੋਂ ਵੱਧ 150ms INP ਦਾ ਟੀਚਾ ਰੱਖੋ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੇ JavaScript ਮੁੱਖ-ਥ੍ਰੈਡ ਕੰਮ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਇੰਜੀਨੀਅਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਦੀ ਅਗਲੀ ਇੰਟਰੈਕਸ਼ਨ ਕਦੇ ਬਲਾਕ ਨਾ ਹੋਵੇ।
ਕਿਊਮੂਲੇਟਿਵ ਲੇਆਊਟ ਸ਼ਿਫਟ (CLS)
- Good: ≤ 0.1
- Needs Improvement: 0.1–0.25
- Poor: > 0.25
CLS ਸਹੀ HTML ਢਾਂਚੇ ਨਾਲ ਠੀਕ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਸੌਖਾ ਹੈ—ਚਿੱਤਰਾਂ ਅਤੇ ਵਿਗਿਆਪਨਾਂ 'ਤੇ ਸਪੱਸ਼ਟ ਮਾਪ ਸੈੱਟ ਕਰੋ। ਫਿਰ ਵੀ ਇਸ ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। 95+ ਸਕੋਰ ਵਾਲੀਆਂ ਸਾਈਟਾਂ ਲਈ 0.05 ਜਾਂ ਘੱਟ CLS ਆਮ ਹੈ। ਸਹੀ ਆਕਾਰ ਅਤੇ ਫ਼ਾਸਲਾ ਲਾਗੂ ਕਰਨ ਤੋਂ ਬਾਅਦ ਮੈਂ 0.01 ਸਕੋਰ ਵਾਲੀਆਂ ਸਾਈਟਾਂ ਦੇਖੀਆਂ ਹਨ।
| Metric | ਹਰੇ ਲਈ ਥ੍ਰੈਸ਼ਹੋਲਡ (ਫੀਲਡ) | Lighthouse ਸਕੋਰ ਉੱਤੇ ਪ੍ਰਭਾਵ | ਆਮ ਫਿਕਸ ਜਟਿਲਤਾ |
|---|---|---|---|
| LCP | ≤ 2.5s | 25% | Medium–High |
| INP | ≤ 200ms | 25% | High |
| CLS | ≤ 0.1 | 15% | Low–Medium |
| TBT | ≤ 200ms (Lab) | 25% | High |
| SI | ≤ 3.4s (Lab) | 10% | Medium |
ਟੇਬਲ: Core Web Vitals ਥ੍ਰੈਸ਼ਹੋਲਡ ਅਤੇ Lighthouse ਸਕੋਰਿੰਗ ਵਜ਼ਨ।
ਨਿਦਾਨ: ਤੁਹਾਡਾ ਖਾਸ Core Web Vitals ਹੱਲ ਲੱਭਣਾ
ਕੋਡ ਦੀ ਇੱਕ ਵੀ ਲਾਈਨ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਉੱਚ-ਗੁਣਵੱਤਾ ਵਾਲੀ ਡਾਇਗਨੋਸਟਿਕਸ ਚਾਹੀਦੀ ਹੈ। ਮੈਂ ਟੀਮਾਂ ਨੂੰ ਗਲਤ ਸਮੱਸਿਆ ਦਾ ਪਿੱਛਾ ਕਰਦੇ ਹਫ਼ਤੇ ਬਰਬਾਦ ਕਰਦੇ ਵੇਖਿਆ ਹੈ।
ਕਦਮ 1: ਥ੍ਰਾਟਲਿੰਗ ਨਾਲ Incognito ਵਿੱਚ Lighthouse ਵਰਤੋ
Chrome DevTools ਤੋਂ "Mobile 3G Slow" ਪ੍ਰੀਸੈੱਟ ਨਾਲ Lighthouse ਚਲਾਓ ਜਾਂ ਮਿਡ-ਟੀਅਰ ਡਿਵਾਈਸ ਦੀ ਨਕਲ ਕਰੋ। Note the Opportunities and Diagnostics ਭਾਗ—ਇਹ ਤੁਹਾਨੂੰ ਬਿਲਕੁਲ ਦੱਸਦੇ ਹਨ ਕਿ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ। “Reduce initial server response time” ਅਤੇ “Eliminate render-blocking resources” ਵੱਲ ਖਾਸ ਧਿਆਨ ਦਿਓ ਕਿਉਂਕਿ ਇਨ੍ਹਾਂ ਦਾ ਅਕਸਰ ਸਭ ਤੋਂ ਵੱਧ ਪ੍ਰਭਾਵ ਹੁੰਦਾ ਹੈ।
ਕਦਮ 2: ਫੀਲਡ ਡੇਟਾ ਲਈ CrUX API
Use the Chrome User Experience Report ਤੁਹਾਡੇ ਮੂਲ ਲਈ ਅਸਲ-ਉਪਭੋਗਤਾ ਡੇਟਾ ਖਿੱਚਣ ਲਈ API। ਜੇ ਫੀਲਡ ਡੇਟਾ LCP > 3s ਦਿਖਾਏ ਪਰ ਲੈਬ ਡੇਟਾ 1s ਦਿਖਾਏ, ਤਾਂ ਤੁਹਾਨੂੰ ਸਰਵਰ-ਸਾਈਡ ਸਮੱਸਿਆ (ਹੌਲੀ TTFB) ਹੈ ਜਿਸਨੂੰ DevTools ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਿਮੂਲੇਟ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਫਰੰਟ-ਐਂਡ ਸਰੋਤਾਂ ਦੀ ਬਜਾਏ ਹੋਸਟਿੰਗ, CDN ਅਤੇ ਸਰਵਰ ਸੰਰਚਨਾ ਤੇ ਧਿਆਨ ਦੇਣ ਦੀ ਲੋੜ ਹੈ।
ਕਦਮ 3: ਅਸਲ ਉਪਭੋਗਤਾ ਨਿਗਰਾਨੀ (RUM)
ਵੱਧ ਟ੍ਰੈਫਿਕ ਵਾਲੀਆਂ ਸਾਈਟਾਂ ਲਈ, ਹਲਕਾ RUM ਹੱਲ ਤਾਇਨਾਤ ਕਰੋ (ਜਿਵੇਂ WebPageTest’s RUM or custom PerformanceObserver ਕਾਲਾਂ)। ਇਹ ਵਿਅਕਤੀਗਤ ਆਉਟਲਾਇਰ ਸਾਹਮਣੇ ਲਿਆਉਂਦਾ ਹੈ—ਜਿਵੇਂ ਉਹ ਪੰਨੇ ਜੋ ਸਿਰਫ਼ ਕੁਝ ਡਿਵਾਈਸ ਕਿਸਮਾਂ ਜਾਂ ਭੂਗੋਲਾਂ ਲਈ ਹੌਲੀ ਹਨ। RUM ਸੈਟਅਪ ਦੱਸ ਸਕਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਮੋਬਾਈਲ LCP ਠੀਕ ਹੈ ਪਰ ਲੇਜ਼ੀ-ਲੋਡਿੰਗ ਵਿਗਿਆਪਨਾਂ ਕਾਰਨ ਡੈਸਕਟੌਪ CLS ਵਧ ਰਿਹਾ ਹੈ। ਫੀਲਡ ਡੇਟਾ ਤੋਂ ਬਿਨਾਂ, ਤੁਸੀਂ ਅੰਨ੍ਹੇਵਾਹ ਚੱਲ ਰਹੇ ਹੋ।
ਕਦਮ 4: WebPageTest ਫਿਲਮਸਟ੍ਰਿਪ
ਮੈਂ ਹਮੇਸ਼ਾ Lighthouse ਨੂੰ ਇਸ ਨਾਲ ਪੂਰਕ ਕਰਦਾ ਹਾਂ WebPageTest. ਇਸਨੂੰ “Mobile Slow 3G” ’ਤੇ ਸੈੱਟ ਕਰੋ ਅਤੇ ਫਿਲਮਸਟ੍ਰਿਪ ਦੇਖੋ। ਇਹ ਤੁਹਾਨੂੰ ਬਿਲਕੁਲ ਦਿਖਾਏਗਾ ਕਿ ਹਰ ਤੱਤ ਕਦੋਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਅਤੇ ਕੀ ਕੋਈ ਫ਼ਜ਼ੂਲ ਬੇਨਤੀਆਂ ਹਨ। ਮੈਂ ਅਜਿਹੀਆਂ ਤੀਜੀ-ਧਿਰ ਸਕ੍ਰਿਪਟਾਂ ਫੜੀਆਂ ਹਨ ਜੋ ਮੇਰੀ ਹੀਰੋ ਤਸਵੀਰ ਤੋਂ ਪਹਿਲਾਂ ਡਾਊਨਲੋਡ ਹੋਣੀਆਂ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ—ਇਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਖੋਜਾਂ ਤੁਰੰਤ ਫ਼ਾਇਦੇ ਦਿੰਦੀਆਂ ਹਨ।
95+ Lighthouse ਲਈ ਕਾਰਵਾਈਯੋਗ Core Web Vitals ਸੁਧਾਰ ਰਣਨੀਤੀਆਂ
ਮੈਂ ਠੋਸ ਕੋਡ-ਪੱਧਰੀ ਤਬਦੀਲੀਆਂ ਨਾਲ ਹਰ ਮੈਟ੍ਰਿਕ ਸਮਝਾਵਾਂਗਾ।
LCP: ਭਾਰੀ ਜ਼ਿੰਮੇਵਾਰੀ
LCP ਆਮ ਤੌਰ 'ਤੇ ਚਿੱਤਰ, ਵੀਡੀਓ ਪੋਸਟਰ, ਜਾਂ ਵੱਡਾ ਟੈਕਸਟ ਬਲਾਕ ਹੁੰਦਾ ਹੈ। 95 ਤੋਂ ਅੱਗੇ ਜਾਣ ਲਈ, ਤੁਹਾਨੂੰ 1.8s ਤੋਂ ਘੱਟ LCP ਚਾਹੀਦਾ ਹੈ।
- ਮਹੱਤਵਪੂਰਨ ਅਸੈਟ ਪਹਿਲਾਂ ਤੋਂ ਲੋਡ ਕਰੋ: Use
<link rel="preload" as="image" href="hero.webp">ਹੀਰੋ ਚਿੱਤਰਾਂ ਲਈ ਟੈਕਸਟ-ਅਧਾਰਤ LCP ਲਈ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡਾ ਫੌਂਟ ਵੀ ਪਹਿਲਾਂ ਤੋਂ ਲੋਡ ਹੋਵੇ - Optimize images: WebP ਵਿੱਚ ਬਦਲੋ, ਜਵਾਬਦੇਹ ਆਕਾਰ ਵਰਤੋ (
srcset), ਅਤੇ AVIF ਵਰਗੇ next-gen ਫਾਰਮੈਟ ਦਿਓ। ਮੈਂ ਦੇਖਿਆ ਹੈ ਕਿ AVIF ਧਿਆਨਯੋਗ ਗੁਣਵੱਤਾ ਨੁਕਸਾਨ ਤੋਂ ਬਿਨਾਂ WebP ਦੇ ਮੁਕਾਬਲੇ image payload 30% ਘਟਾ ਦਿੰਦਾ ਹੈ। - ਸਰਵਰ-ਸਾਈਡ ਰੈਂਡਰਿੰਗ: ਜੇ ਤੁਸੀਂ ਇਸ ਵਰਗਾ ਫਰੇਮਵਰਕ ਵਰਤ ਰਹੇ ਹੋ Next.js or React, ਯਕੀਨੀ ਬਣਾਓ ਕਿ LCP ਸਮੱਗਰੀ ਸ਼ੁਰੂਆਤੀ HTML ਵਿੱਚ ਹੋਵੇ, JavaScript ਰਾਹੀਂ ਲੋਡ ਨਾ ਹੋਵੇ। 1.8s ਤੋਂ ਘੱਟ LCP ਲਈ static generation ਜਾਂ server-side rendering ਲਾਜ਼ਮੀ ਹੈ।
- ਰੈਂਡਰ-ਬਲੌਕਿੰਗ ਸਰੋਤ ਹਟਾਓ: ਗ਼ੈਰ-ਨਾਜ਼ੁਕ CSS ਅਤੇ JavaScript ਮੁਲਤਵੀ ਕਰੋ। ਵਰਤੋਂ
rel="preload"for fonts andmedia="print"ਫਾਲਬੈਕ ਸਟਾਈਲਾਂ ਲਈ ਅਸੀਂ ਅਕਸਰ ਉੱਪਰ-ਦੇ-ਫੋਲਡ ਸਮੱਗਰੀ ਲਈ ਨਾਜ਼ੁਕ CSS ਇਨਲਾਈਨ ਕਰਦੇ ਹਾਂ - ਅਸਲ ਉਪਭੋਗਤਾ ਐਜ ਕੈਚਿੰਗ ਵਾਲੇ CDN ਦੀ ਵਰਤੋਂ ਕਰੋ। Services like Cloudflare ਜਾਂ Amazon CloudFront ਉਪਭੋਗਤਾ ਦੇ ਨੇੜਲੇ ਕੈਸ਼ ਟਿਕਾਣਿਆਂ ਤੋਂ ਸਥਿਰ ਐਸਟਸ ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ API ਜਵਾਬ ਵੀ ਦੇ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ TTFB ਅਤੇ LCP ਵਿੱਚ ਜ਼ਬਰਦਸਤ ਕਮੀ ਆਉਂਦੀ ਹੈ।
Case: ਮੈਂ ਇਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀ ਇੱਕ ਈ-ਕਾਮਰਸ ਸਾਈਟ ਦੀ ਮਦਦ ਕੀਤੀ Shopify LCP ਨੂੰ 4.1s ਤੋਂ 1.6s ਤੱਕ ਘਟਾਉਂਦੇ ਹਨ, ਕਸਟਮ ਕ੍ਰਿਟੀਕਲ CSS ਪਾਈਪਲਾਈਨ ਲਾਗੂ ਕਰਕੇ ਅਤੇ ਹੇਠਾਂ-ਦ-ਫੋਲਡ ਤਸਵੀਰਾਂ ਨੂੰ ਲੇਜ਼ੀ-ਲੋਡ ਕਰਕੇ। ਤਰਕੀਬ ਸਿੱਧੇ ਵਿੱਚ Shopify ਦੇ CDN URL ਰਾਹੀਂ ਹੀਰੋ ਵੇਰੀਐਂਟ ਤਸਵੀਰ ਨੂੰ ਸਰਵਰ-ਸਾਈਡ ਪ੍ਰੀਲੋਡ ਕਰਨਾ ਸੀ <head>.
INP: ਨਵਾਂ ਪ੍ਰਦਰਸ਼ਨ ਰਾਖਾ
INP ਸਭ ਤੋਂ ਔਖਾ ਹੈ ਕਿਉਂਕਿ ਇਸ ਵਿੱਚ JavaScript ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਕੁਸ਼ਲਤਾ ਸ਼ਾਮਲ ਹੈ। 150ms ਜਾਂ ਘੱਟ ਦਾ ਟੀਚਾ ਰੱਖੋ।
- Code splitting: ਵੱਡੇ React ਜਾਂ Vue ਬੰਡਲਾਂ ਨੂੰ ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡੋ ਤਾਂ ਜੋ ਇੰਟਰੈਕਸ਼ਨ ਉੱਤੇ ਸਿਰਫ਼ ਜ਼ਰੂਰੀ ਕੋਡ ਚੱਲੇ। ਡਾਇਨਾਮਿਕ ਵਰਤੋ
import()ਉਨ੍ਹਾਂ ਹਿੱਸਿਆਂ ਲਈ ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਰੰਤ ਲੋੜ ਨਹੀਂ ਹੈ - Web Workers: ਭਾਰੀ ਪ੍ਰੋਸੈਸਿੰਗ (ਜਿਵੇਂ ਤਸਵੀਰ ਸੰਕੁਚਨ ਜਾਂ ਡੇਟਾ ਫਾਰਮੈਟਿੰਗ) ਨੂੰ Web Worker ਤੇ ਆਫਲੋਡ ਕਰੋ। ਇਹ ਮੁੱਖ ਥ੍ਰੈਡ ਨੂੰ ਉਪਭੋਗਤਾ ਇੰਟਰੈਕਸ਼ਨਾਂ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਖਾਲੀ ਰੱਖਦਾ ਹੈ।
- ਇਵੈਂਟ ਹੈਂਡਲਰ ਅਨੁਕੂਲ ਕਰੋ: ਲੰਬੇ ਕੰਮਾਂ (>50ms) ਤੋਂ ਬਚੋ। ਵਰਤੋਂ
requestAnimationFrameਵਿਜ਼ੂਅਲ ਅੱਪਡੇਟਾਂ ਅਤੇ ਲਈsetTimeoutਟਾਲਣਯੋਗ ਕੰਮ ਲਈ ਜੇ ਹੈਂਡਲਰ ਵਿੱਚ DOM ਹੇਰ-ਫੇਰ ਸ਼ਾਮਲ ਹੈ, ਤਾਂ ਬਦਲਾਅ ਨੂੰ ਸਮੂਹ ਵਿੱਚ ਕਰੋ - Minimize DOM size: ਵੱਡੇ DOM ਰੁੱਖ ਲੇਆਉਟ ਮੁੜ-ਗਣਨਾਵਾਂ ਨੂੰ ਹੌਲੀ ਕਰਦੇ ਹਨ। 1500 ਨੋਡਾਂ ਤੋਂ ਹੇਠਾਂ ਰੱਖੋ। ਮੈਂ ਉਤਪਾਦ ਸੂਚੀ ਪੇਜਾਂ ਤੇ 5,000+ ਨੋਡਾਂ ਵਾਲੀਆਂ ਸਾਈਟਾਂ ਦੇਖੀਆਂ ਹਨ — ਇਸਨੂੰ 1,500 ਤੋਂ ਹੇਠਾਂ ਕਰਨ ਨਾਲ INP 30% ਘਟਿਆ।
- ਥਰਡ-ਪਾਰਟੀ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਮੁਲਤਵੀ ਕਰੋ। Google Tag Manager, Facebook Pixel ਅਤੇ ਹੋਰ ਵਿਸ਼ਲੇਸ਼ਣ ਅਕਸਰ ਪਹਿਲਾਂ ਚਲਦੇ ਹਨ ਅਤੇ ਉਪਭੋਗਤਾ ਇਨਪੁੱਟ ਰੋਕਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਹਟਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਇਸ ਤੋਂ ਬਾਅਦ ਲੋਡ ਕਰੋ
onloador useasyncਸਾਵਧਾਨ ਕਾਰਜ ਸਮਾਂ-ਸਾਰਣੀ ਨਾਲ।
Real data: ਮੈਂ ਜਿਸ ਵਿੱਤੀ ਸਾਈਟ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਇਆ ਸੀ ਉਸਦਾ INP ਥਰਡ-ਪਾਰਟੀ ਚਾਰਟ ਲਾਇਬ੍ਰੇਰੀ ਕਾਰਨ 540ms ਸੀ। Canvas ਨਾਲ ਬਣੇ ਹਲਕੇ ਚਾਰਟ ਤੇ ਬਦਲਣ ਤੋਂ ਬਾਅਦ INP ਘਟ ਕੇ 130ms ਹੋ ਗਿਆ। ਲਾਇਬ੍ਰੇਰੀ ਹਰ ਡੇਟਾ ਪੁਆਇੰਟ ਹੋਵਰ ਤੇ ਪੂਰਾ ਚਾਰਟ ਦੁਬਾਰਾ ਰੈਂਡਰ ਕਰ ਰਹੀ ਸੀ; ਇਸਨੂੰ ਥ੍ਰਾਟਲ ਕਰਕੇ requestAnimationFrame ਅਤੇ ਇੱਕ ਸਰਲ ਰੈਂਡਰਿੰਗ ਪਹੁੰਚ ਵਰਤ ਕੇ, ਅਸੀਂ ਝਟਕੇ ਨੂੰ ਖਤਮ ਕਰ ਦਿੱਤਾ।
CLS: ਸਭ ਤੋਂ ਆਸਾਨ ਹੱਲ
CLS ਲਗਭਗ ਹਮੇਸ਼ਾ ਬਿਨਾਂ ਮਾਪਾਂ ਦੇ ਗਤਿਸ਼ੀਲ ਸਮੱਗਰੀ ਲੋਡ ਹੋਣ ਕਾਰਨ ਹੁੰਦਾ ਹੈ।
- Always set
widthandheightਤਸਵੀਰਾਂ ਅਤੇ ਆਈਫਰੇਮਾਂ ਉੱਤੇ। Use CSSaspect-ratioਜਵਾਬਦੇਹ ਚਿੱਤਰਾਂ ਲਈ ਫਾਲਬੈਕ ਵਜੋਂ। - ਵਿਗਿਆਪਨਾਂ ਅਤੇ ਏਮਬੈੱਡਾਂ ਲਈ ਥਾਂ ਰਾਖਵੀਂ ਰੱਖੋ। Use CSS
aspect-ratioਜਾਂ ਫਿਕਸਡ ਕੰਟੇਨਰ। ਗਤੀਸ਼ੀਲ ਇਸ਼ਤਿਹਾਰ ਆਕਾਰਾਂ ਲਈ, ਇੱਕ ਕਸਟਮ ਪਲੇਸਹੋਲਡਰ ਐਲੀਮੈਂਟ ਵਰਤੋ ਜੋ ਸਭ ਤੋਂ ਆਮ ਇਸ਼ਤਿਹਾਰ ਫਾਰਮੈਟ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ। - ਪਹਿਲੇ ਪੇਂਟ ਤੋਂ ਬਾਅਦ ਮੌਜੂਦਾ ਸਮੱਗਰੀ ਦੇ ਉੱਪਰ ਸਮੱਗਰੀ ਪਾਉਣ ਤੋਂ ਬਚੋ। ਇਹ ਅਸਲ ਵਿੱਚ ਸੁਨਹਿਰੀ ਨਿਯਮ ਹੈ। ਫੋਲਡ ਤੋਂ ਉੱਪਰ DOM ਨੂੰ ਬਦਲਣ ਵਾਲੀ ਕਿਸੇ ਵੀ ਸਕ੍ਰਿਪਟ ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਲੇਆਉਟ ਸਥਿਰ ਹੋਣ ਤੱਕ ਮੁਲਤਵੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
- Use
font-display: optionalorswapਅਦਿੱਖ ਟੈਕਸਟ ਕਾਰਨ ਲੇਆਉਟ ਸ਼ਿਫਟ ਰੋਕਣ ਲਈ। ਜਦੋਂ ਕਸਟਮ ਫੌਂਟ ਹੌਲੀ ਲੋਡ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਬ੍ਰਾਊਜ਼ਰ ਫਾਲਬੈਕ ਫੌਂਟ ਵਰਤ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਬਦਲ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸ਼ਿਫਟ ਹੁੰਦਾ ਹੈ।font-display: optionalਅਦਲਾ-ਬਦਲੀ ਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ ਜੇ ਕਸਟਮ ਫੌਂਟ ਸਮੇਂ ਸਿਰ ਨਾ ਪਹੁੰਚੇ ਤਾਂ ਫਾਲਬੈਕ ਫੌਂਟ ਵਰਤਦਾ ਹੈ।
ਮੈਂ ਲਗਾਤਾਰ ਇੱਕੋ ਸਪ੍ਰਿੰਟ ਵਿੱਚ CLS ਨੂੰ 0.25+ ਤੋਂ 0.03 ਤੱਕ ਸੁਧਰਦੇ ਦੇਖਿਆ ਹੈ। ਇਹ ਸਭ ਤੋਂ ਤੇਜ਼ ਹੈ Core Web Vitals fix ਜੋ ਤੁਸੀਂ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ। ਇੱਕ ਗਾਹਕ ਦੇ ਹੋਮਪੇਜ ’ਤੇ 0.8 ਦਾ CLS ਸੀ ਕਿਉਂਕਿ ਇੱਕ ਨਿਊਜ਼ਲੈਟਰ ਸਾਈਨਅਪ ਮੋਡਲ ਬਿਨਾਂ ਰਾਖਵੀਂ ਜਗ੍ਹਾ ਫੋਲਡ ਦੇ ਉੱਪਰ ਲਗਾਇਆ ਗਿਆ ਸੀ। ਸਿਰਫ਼ ਇੱਕ ਫਿਕਸਡ-ਉਚਾਈ ਵਾਲਾ ਪਲੇਸਹੋਲਡਰ div ਜੋੜਨ ਨਾਲ CLS ਘਟ ਕੇ 0.01 ਰਹਿ ਗਿਆ।
Core Web Vitals ਸੁਧਾਰ ਲਈ ਉੱਨਤ Server-Side ਅਨੁਕੂਲਨ
ਫਰੰਟ-ਐਂਡ ਸੁਧਾਰਾਂ ਤੋਂ ਅੱਗੇ, ਸਰਵਰ ਕੌਂਫਿਗਰੇਸ਼ਨ ਅਕਸਰ ਉਹ ਰੁਕਾਵਟ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਹਾਨੂੰ 95+ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਰੋਕਦੀ ਹੈ।
TTFB ਅਤੇ ਸਰਵਰ ਜਵਾਬ ਸਮਾਂ
ਹੌਲੀ ਟਾਈਮ ਟੂ ਫਰਸਟ ਬਾਈਟ (TTFB) ਹਰ ਹੋਰ ਮਾਪ ਨੂੰ ਪਿੱਛੇ ਰੱਖਦਾ ਹੈ। Lighthouse 95 ਲਈ, ਮੋਬਾਈਲ (ਲੈਬ) 'ਤੇ 600ms ਤੋਂ ਘੱਟ ਅਤੇ ਫੀਲਡ ਡਾਟਾ ਵਿੱਚ 800ms ਤੋਂ ਘੱਟ TTFB ਦਾ ਟੀਚਾ ਰੱਖੋ। ਮੈਂ ਬਹੁਤ ਸਾਰੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਚਿੱਤਰ ਅਤੇ ਸਕ੍ਰਿਪਟਾਂ ਅਨੁਕੂਲਿਤ ਕਰਦੇ ਦੇਖਿਆ ਹੈ ਜਦੋਂਕਿ ਉਨ੍ਹਾਂ ਦਾ ਸਰਵਰ ਸਿਰਫ਼ HTML ਬਣਾਉਣ ਵਿੱਚ 1.2s ਲੈ ਰਿਹਾ ਹੁੰਦਾ ਹੈ।
- ਐਜ ਕੈਚਿੰਗ ਵਾਲੇ CDN ਦੀ ਵਰਤੋਂ ਕਰੋ (ਜਿਵੇਂ, Cloudflare, Fastly) ਐਜ ਤੋਂ ਸਥਿਰ HTML ਪੰਨੇ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ।
- ਡਾਟਾਬੇਸ ਸਵਾਲ ਅਨੁਕੂਲ ਕਰੋ ਅਤੇ CMS-ਆਧਾਰਿਤ ਸਾਈਟਾਂ ਲਈ ਪੇਜ ਕੈਸ਼ ਪਲੱਗਇਨ ਵਰਤਣ 'ਤੇ ਵਿਚਾਰ ਕਰੋ।
- serverless ਜਾਂ edge functions ਵਿਚਾਰੋ ਗਤੀਸ਼ੀਲ ਸਮੱਗਰੀ ਲਈ ਜਿਸ ਲਈ ਪਹਿਲਾਂ ਪੂਰੀ ਸਰਵਰ-ਸਾਈਡ ਪ੍ਰੋਸੈਸਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਸੀ
ਪ੍ਰੀਕਨੈਕਟ ਅਤੇ DNS ਪ੍ਰੀਫੈਚ
Add <link rel="dns-prefetch" href="//fonts.googleapis.com"> and <link rel="preconnect" href="https://fonts.googleapis.com" crossorigin> ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਉਨ੍ਹਾਂ ਮੂਲ ਸਰੋਤਾਂ ਬਾਰੇ ਜਲਦੀ ਸੰਕੇਤ ਦੇਣ ਲਈ ਜਿਨ੍ਹਾਂ ਨਾਲ ਤੁਸੀਂ ਜੁੜੋਗੇ। ਇਹ ਤੀਜੀ-ਧਿਰ ਮੂਲ ਸਰੋਤਾਂ ਲਈ ਸ਼ੁਰੂਆਤੀ ਕਨੈਕਸ਼ਨ ਸਮੇਂ ਵਿੱਚੋਂ 400–600ms ਬਚਾ ਸਕਦਾ ਹੈ।
HTTP/2 and HTTP/3
ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡਾ ਸਰਵਰ HTTP/2 ਜਾਂ (ਤਰਜੀਹੀ ਤੌਰ 'ਤੇ) QUIC 'ਤੇ HTTP/3 ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਮਲਟੀਪਲੈਕਸਿੰਗ ਅਤੇ ਸਰਵਰ ਪੁਸ਼ ਲੇਟੈਂਸੀ ਘਟਾ ਸਕਦੇ ਹਨ, ਪਰ HTTP/3 ਉੱਚ ਪੈਕਟ ਨੁਕਸਾਨ ਵਾਲੇ ਮੋਬਾਈਲ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਖਾਸ ਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ।
ਅਸਲ ਦੁਨੀਆ ਦਾ ਕੇਸ ਸਟੱਡੀ: ਇੱਕ ਈ-ਕਾਮਰਸ Core Web Vitals ਫਿਕਸ
ਮੈਨੂੰ ਪੂਰੀ ਸ਼ਮੂਲੀਅਤ ਵਿੱਚ ਤੁਹਾਨੂੰ ਲਿਜਾਣ ਦਿਓ ਤਾਂ ਜੋ ਤੁਸੀਂ ਵਿਧੀ ਨੂੰ ਕਾਰਜ ਵਿੱਚ ਦੇਖ ਸਕੋ।
Client: 200,000 ਮਾਸਿਕ ਸੈਸ਼ਨਾਂ ਵਾਲੀ ਇੱਕ ਮਿਡ-ਮਾਰਕੀਟ ਫੈਸ਼ਨ ਈ-ਕਾਮਰਸ ਸਾਈਟ।
Baseline: Lighthouse ਪ੍ਰਦਰਸ਼ਨ ਸਕੋਰ 58, LCP 4.8s, CLS 0.28, INP 820ms।
Timeline: 3 two-week sprints.
ਸਪ੍ਰਿੰਟ 1 – ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਅਤੇ ਚਿੱਤਰ:
- ਚਿੱਤਰ ਅਨੁਕੂਲਨ ਵਾਲੇ CDN (Cloudinary) ’ਤੇ ਸਵਿੱਚ ਕੀਤਾ।
- ਫੋਲਡ ਤੋਂ ਹੇਠਾਂ ਸਾਰੇ ਚਿੱਤਰ ਮੂਲ ਲੇਜ਼ੀ ਲੋਡਿੰਗ ਨਾਲ ਲੇਜ਼ੀ-ਲੋਡ ਕੀਤੇ (
loading="lazy"). - ਨਤੀਜਾ: LCP ਘਟ ਕੇ 2.4s, ਪਰ Lighthouse ਸਕੋਰ ਸਿਰਫ਼ 72 ਤੱਕ ਪਹੁੰਚਿਆ।
ਸਪ੍ਰਿੰਟ 2 – JavaScript ਅਤੇ INP:
- React ਬੰਡਲ ਨੂੰ ਕੋਡ-ਸਪਲਿਟ ਕੀਤਾ। ਗੈਰ-ਅਹਿਮ ਕੰਪੋਨੈਂਟ ਡਾਇਨਾਮਿਕ ਇੰਪੋਰਟਾਂ ਵਿੱਚ ਭੇਜੇ।
- ਭਾਰੀ ਤੀਜੀ-ਧਿਰ ਸਮੀਖਿਆ ਵਿਜੇਟ ਨੂੰ ਹਲਕੇ ਕਸਟਮ ਕੰਪੋਨੈਂਟ ਨਾਲ ਬਦਲਿਆ।
- GTM ਨੂੰ ਇਸ ਤੋਂ ਬਾਅਦ ਲੋਡ ਹੋਣ ਲਈ ਭੇਜਿਆ
onloadviarequestIdleCallback. - ਨਤੀਜਾ: INP ਸੁਧਰ ਕੇ 210ms, Lighthouse ਸਕੋਰ 89 ਤੱਕ ਪਹੁੰਚਿਆ।
ਸਪ੍ਰਿੰਟ 3 – CLS ਅਤੇ ਅੰਤਿਮ ਨਿਖਾਰ:
- ਸਾਰੀਆਂ ਉਤਪਾਦ ਤਸਵੀਰਾਂ ਅਤੇ iframes ਵਿੱਚ ਸਪੱਸ਼ਟ ਚੌੜਾਈ/ਉਚਾਈ ਸ਼ਾਮਲ ਕੀਤੀ।
- Switched font to
font-display: optional. - ਸਟਿੱਕੀ ਹੈੱਡਰ ਵਿਗਿਆਪਨ ਲਈ ਰਾਖਵਾਂ ਪਲੇਸਹੋਲਡਰ ਸ਼ਾਮਲ ਕੀਤਾ।
- ਨਤੀਜਾ: CLS ਘਟ ਕੇ 0.02, Lighthouse ਸਕੋਰ 96, LCP 1.5s, INP 140ms ਤੱਕ ਪਹੁੰਚਿਆ।
Outcome: ਅਗਲੀ ਤਿਮਾਹੀ ਵਿੱਚ ਜੈਵਿਕ ਟ੍ਰੈਫਿਕ 35% ਵਧਿਆ। ਪਰਿਵਰਤਨ ਦਰ 12% ਵਧੀ ਕਿਉਂਕਿ ਮੋਬਾਈਲ ਤੇ ਪੇਜ ਤੇਜ਼ ਲੋਡ ਹੋਏ — ਬਾਊਂਸ ਦਰ 62% ਤੋਂ ਘਟ ਕੇ 51% ਹੋ ਗਈ।
This is the kind of Core Web Vitals fix ਜੋ ਅਸਲ ਨਿਵੇਸ਼ ਉੱਤੇ ਵਾਪਸੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ ਆਡਿਟ ਪਾਸ ਕਰਨ ਬਾਰੇ ਨਹੀਂ ਹੈ; ਇਹ ਤੁਹਾਡੀ ਸਾਈਟ ਨੂੰ ਉਪਭੋਗਤਾਵਾਂ ਅਤੇ ਕਾਰੋਬਾਰ ਲਈ ਮਜ਼ਬੂਤ ਬਣਾਉਣ ਬਾਰੇ ਹੈ।
Lighthouse 95 ਦੇਖਣ ਲਈ ਡਿਵੈਲਪਰ ਦਾ ਵਰਕਫਲੋ
ਕਿਸੇ ਵੀ ਪੇਜ ਲਈ ਇਹ ਪ੍ਰਕਿਰਿਆ ਅਪਣਾਓ:
- Baseline Audit: ਮੌਜੂਦਾ Lighthouse ਸਕੋਰ, ਫੀਲਡ ਡੇਟਾ ਅਤੇ ਵਿਅਕਤੀਗਤ CWV ਮਾਪਦੰਡ ਦਰਜ ਕਰੋ।
- Prioritize Issues: ਪ੍ਰਭਾਵ ਅਨੁਸਾਰ ਛਾਂਟੋ। ਪ੍ਰਦਰਸ਼ਨ ਸਕੋਰ ਵਿੱਚ LCP ਅਤੇ TBT (total blocking time) ਦਾ ਭਾਰ ਸਭ ਤੋਂ ਵੱਧ ਹੁੰਦਾ ਹੈ।
- ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਹੱਲ ਲਾਗੂ ਕਰੋ: ਹਰ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ Lighthouse ਦੁਬਾਰਾ ਚਲਾਓ। ਇਸ ਨਾਲ ਉਲਝਣ ਵਾਲੀ ਡਿਬੱਗਿੰਗ ਤੋਂ ਬਚਾਅ ਹੁੰਦਾ ਹੈ।
- WebPageTest ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਕਰੋ: ਇਸ ਉੱਤੇ 3G Slow ਟੈਸਟ ਚਲਾਓ WebPageTest ਫਿਲਮਸਟ੍ਰਿਪ ਦੇਖਣ ਅਤੇ ਅਸਲ-ਉਪਭੋਗਤਾ ਵਰਗੇ ਨਤੀਜਿਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ।
- ਰਿਗ੍ਰੈਸ਼ਨਾਂ ਲਈ ਨਿਗਰਾਨੀ ਕਰੋ: ਆਪਣੀ CI/CD ਪਾਈਪਲਾਈਨ ਵਿੱਚ Lighthouse CI ਸੈੱਟ ਕਰੋ ਤਾਂ ਜੋ ਕੋਈ ਨਵਾਂ ਕੋਡ ਸਕੋਰ 90 ਤੋਂ ਹੇਠਾਂ ਨਾ ਡੇਗੇ। ਮੈਂ GitHub Actions ਵਰਕਫਲੋ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦਾ ਹਾਂ ਜੋ ਹਰ PR ਉੱਤੇ Lighthouse ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਸਕੋਰ ਬਦਲਾਅ ਨਾਲ ਟਿੱਪਣੀ ਕਰਦਾ ਹੈ।
- ਆਪਣੇ ਚੋਟੀ ਦੇ 10 ਪੰਨਿਆਂ ਲਈ ਦੁਹਰਾਓ: ਸਿਰਫ਼ ਹੋਮਪੇਜ ਠੀਕ ਨਾ ਕਰੋ। ਉਤਪਾਦ, ਸ਼੍ਰੇਣੀ ਅਤੇ ਲੈਂਡਿੰਗ ਪੇਜ ਜਾਂਚੋ। Google ਸਿਰਫ਼ ਰੂਟ ਨਹੀਂ, ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਪੇਜ ਸਮੂਹਾਂ ਨੂੰ ਸਕੋਰ ਕਰਦਾ ਹੈ।
ਆਮ ਗਲਤੀਆਂ ਜੋ ਤੁਹਾਨੂੰ Lighthouse 95 ਤੋਂ ਦੂਰ ਰੱਖਦੀਆਂ ਹਨ
ਮੈਂ ਇੱਕੋ ਗਲਤੀਆਂ ਵਾਰ-ਵਾਰ ਦੇਖਦਾ ਹਾਂ:
- ਗਲਤ ਮੈਟ੍ਰਿਕ ਅਨੁਕੂਲ ਕਰਨਾ। ਜੇ ਤੁਹਾਡਾ TTFB 1.5s ਹੈ, ਤਾਂ ਕੋਈ ਤਸਵੀਰ ਸੰਕੁਚਨ LCP ਠੀਕ ਨਹੀਂ ਕਰੇਗਾ। ਪਹਿਲਾਂ ਸਰਵਰ ਠੀਕ ਕਰੋ।
- ਪਲੱਗਇਨ 'ਤੇ ਨਿਰਭਰ ਕਰਨਾ। ਹਾਂ, WP Rocket ਜਾਂ ਹੋਰ ਪਲੱਗਇਨ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਅਕਸਰ ਰੈਂਡਰ-ਬਲਾਕਿੰਗ CSS ਪੈਦਾ ਕਰਦੇ ਹਨ। ਕ੍ਰਿਟੀਕਲ CSS ਹੱਥੀਂ ਲਿਖਣਾ ਕਿਸੇ ਵੀ ਪਲੱਗਇਨ ਨੂੰ ਮਾਤ ਦਿੰਦਾ ਹੈ।
- ਅਸਲੀ ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ ’ਤੇ ਟੈਸਟ ਨਹੀਂ ਕੀਤਾ। Lighthouse ਮੋਬਾਈਲ ਸਿਮੂਲੇਸ਼ਨ ਠੀਕ ਹੈ, ਪਰ ਅਸਲ ਡਿਵਾਈਸ ਥਰਮਲ ਥ੍ਰਾਟਲਿੰਗ ਅਤੇ ਮੈਮਰੀ ਸੀਮਾਵਾਂ ਦਰਸਾਉਂਦੇ ਹਨ। ਮੈਂ ਹਮੇਸ਼ਾ ਅਸਲ Moto G power ਜਾਂ iPhone SE ਉੱਤੇ ਜਾਂਚ ਕਰਦਾ ਹਾਂ।
- ਤੀਜੀ-ਧਿਰ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ। Google Tag Manager, Facebook Pixel ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਸਭ ਤੋਂ ਵੱਡੇ ਰੁਕਾਵਟਾਂ ਵਿੱਚੋਂ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਹਮਲਾਵਰ ਢੰਗ ਨਾਲ ਮੁਲਤਵੀ ਕਰੋ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਸਵੈ-ਹੋਸਟ ਕਰਨ ਤੇ ਵਿਚਾਰ ਕਰੋ।
- Chasing 100. ਇੱਕ ਵਾਰ 95 ਤੇ ਪਹੁੰਚਣ ਤੇ, ਬਾਕੀ ਲਾਭ ਨਾਮਾਤਰ ਹਨ। ਸੂਖਮ-ਅਨੁਕੂਲਨਾਂ ਦੀ ਬਜਾਏ ਅਸਲ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੇ ਐਜ ਕੇਸਾਂ (ਜਿਵੇਂ, ਹੌਲੀ Wi-Fi, ਪੁਰਾਣੇ ਡਿਵਾਈਸ) ਤੇ ਮਿਹਨਤ ਕੇਂਦ੍ਰਿਤ ਕਰੋ।
ਤੁਹਾਨੂੰ DG10 Agency ਨਾਲ ਕੰਮ ਕਿਉਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ
We’ve executed Core Web Vitals fix 50 ਤੋਂ ਵੱਧ ਬ੍ਰਾਂਡਾਂ ਲਈ ਪ੍ਰੋਜੈਕਟ, ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਰਹੇ SaaS ਤੋਂ ਲੈ ਕੇ ਵੱਡੇ ਈ-ਕਾਮਰਸ ਤੱਕ। ਸਾਡੇ ਡਿਵੈਲਪਰ ਡੂੰਘੇ ਤਕਨੀਕੀ SEO ਗਿਆਨ ਨੂੰ ਫੁੱਲ-ਸਟੈਕ ਇੰਜੀਨੀਅਰਿੰਗ ਨਾਲ ਜੋੜਦੇ ਹਨ। ਨਤੀਜਾ ਇੱਕ ਅਜਿਹੀ ਸਾਈਟ ਹੈ ਜੋ ਨਾ ਸਿਰਫ਼ Core Web Vitals ਪਾਸ ਕਰਦੀ ਹੈ ਬਲਕਿ Lighthouse 95 ਦਾ ਅਨੁਭਵ ਵੀ ਦਿੰਦੀ ਹੈ।
ਅਸੀਂ ਹਰ ਸ਼ਮੂਲੀਅਤ ਦੀ ਸ਼ੁਰੂਆਤ ਇੱਕ ਵਿਆਪਕ ਪ੍ਰਦਰਸ਼ਨ ਆਡਿਟ ਨਾਲ ਕਰਦੇ ਹਾਂ, ਫੀਲਡ ਡਾਟਾ, ਲੈਬ ਡਾਟਾ ਅਤੇ ਵਾਟਰਫਾਲ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਮੈਪ ਕਰਦੇ ਹੋਏ। ਫਿਰ ਅਸੀਂ ਉਪਚਾਰ ਸਪ੍ਰਿੰਟਾਂ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹਾਂ ਜੋ ਤੁਹਾਡੇ ਵਿਕਾਸ ਚੱਕਰਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ। ਕੋਈ ਕਾਲਾ ਜਾਦੂ ਨਹੀਂ—ਸਿਰਫ਼ ਕੋਡ, ਸੰਰਚਨਾ ਅਤੇ ਨਿਰੰਤਰ ਮਾਪ।
ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਸਾਈਟ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਚੋਟੀ ਦੇ ਪ੍ਰਤੀਸ਼ਤ ਵਿੱਚ ਲੈ ਜਾਣ ਲਈ ਤਿਆਰ ਹੋ, let’s talk. ਅਸੀਂ ਤੁਹਾਨੂੰ ਆਪਣੇ ਪੋਰਟਫੋਲੀਓ ਦੇ ਅਸਲ ਅੰਕੜੇ ਦਿਖਾਵਾਂਗੇ ਤਾਂ ਜੋ ਤੁਹਾਨੂੰ ਪਤਾ ਹੋਵੇ ਕਿ ਕੀ ਉਮੀਦ ਕਰਨੀ ਹੈ।
ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ
ਕੀ ਚੰਗੇ SEO ਲਈ ਮੈਨੂੰ Lighthouse 100 ਦੀ ਲੋੜ ਹੈ?
ਨਹੀਂ। Lighthouse ਇੱਕ ਲੈਬ ਪ੍ਰੌਕਸੀ ਹੈ; ਹਰੇ ਫੀਲਡ Core Web Vitals ਨਾਲ ਸਥਿਰ 95+ ਰੈਂਕ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹੈ। 100 ਦੇ ਪਿੱਛੇ ਭੱਜਣਾ ਆਮ ਤੌਰ ’ਤੇ ਸਾਂਭ-ਸੰਭਾਲ ਦੀ ਕੀਮਤ ’ਤੇ ਅੰਕ ਖਰੀਦਦਾ ਹੈ — ਸਾਡਾ ਕਲਾਇੰਟ ਕੰਮ 95+ ਹਰੇ ’ਤੇ ਰੁਕਦਾ ਹੈ ਅਤੇ ਬਾਕੀ ਬਜਟ ਕੰਟੈਂਟ ’ਤੇ ਲਾਉਂਦਾ ਹੈ।
ਮੈਨੂੰ ਪਹਿਲਾਂ ਕਿਹੜਾ ਮੈਟ੍ਰਿਕ ਠੀਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: LCP, INP, ਜਾਂ CLS?
ਫੀਲਡ ਡਾਟਾ (CrUX) ਵਿੱਚ ਫੇਲ ਹੋ ਰਹੇ ਮੈਟ੍ਰਿਕ ਨੂੰ ਠੀਕ ਕਰੋ, ਲੈਬ ਰਨ ਵਾਲੇ ਨੂੰ ਨਹੀਂ। ਜ਼ਿਆਦਾਤਰ ਕੰਟੈਂਟ ਸਾਈਟਾਂ ਲਈ ਉਹ LCP ਹੈ—ਹੀਰੋ ਇਮੇਜ ਔਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਅਤੇ ਰੈਂਡਰ-ਬਲੌਕਿੰਗ ਸਕ੍ਰਿਪਟਾਂ। ਐਪ-ਵਰਗੀਆਂ ਸਾਈਟਾਂ ਲਈ ਉਹ INP ਹੈ—ਲੰਬੇ ਟਾਸਕ ਅਤੇ ਗੈਰ-ਅਨੁਕੂਲਿਤ ਈਵੈਂਟ ਹੈਂਡਲਰ। CLS ਆਮ ਤੌਰ ਤੇ ਸਭ ਤੋਂ ਸਸਤਾ ਹੈ: ਵਿਗਿਆਪਨਾਂ, ਐਂਬੈੱਡਾਂ ਅਤੇ ਤਸਵੀਰਾਂ ਲਈ ਜਗ੍ਹਾ ਰਾਖਵੀਂ ਰੱਖੋ।
ਕੀ WordPress ਵਾਸਤਵਿਕ ਤੌਰ 'ਤੇ Lighthouse 95 ਹਾਸਲ ਕਰ ਸਕਦਾ ਹੈ?
ਹਾਂ, ਅਨੁਸ਼ਾਸਨ ਨਾਲ: ਸਰਵਰ-ਪੱਧਰੀ ਕੈਸ਼ਿੰਗ, ਹਲਕਾ ਥੀਮ, ਸਪੱਸ਼ਟ ਮਾਪਾਂ ਨਾਲ CDN ਰਾਹੀਂ ਮੀਡੀਆ, ਅਤੇ ਹਰ ਤਿਮਾਹੀ ਪਲੱਗਇਨ ਆਡਿਟ। ਸਟੈਕ ਪੇਲੋਡ ਬਜਟ ਨਾਲੋਂ ਘੱਟ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ — ਸਾਡੀ WordPress ਤੋਂ Next.js ਮਾਈਗ੍ਰੇਸ਼ਨ ਗਾਈਡ ਦੱਸਦੀ ਹੈ ਕਿ ਸਟੈਕ ਬਦਲਣਾ ਕਦੋਂ ਅਨੁਕੂਲਨ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ।
Core Web Vitals ਫਿਕਸ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ?
ਆਮ ਮਾਰਕੀਟਿੰਗ ਸਾਈਟ ਲਈ ਕੇਂਦਰਿਤ ਉਪਚਾਰ ਸਪ੍ਰਿੰਟ ਦੋ ਤੋਂ ਚਾਰ ਹਫ਼ਤੇ ਚੱਲਦਾ ਹੈ: ਇੱਕ ਹਫ਼ਤਾ ਨਿਦਾਨ, ਇੱਕ ਤੋਂ ਦੋ ਸੁਧਾਰ, ਇੱਕ ਫੀਲਡ‑ਡਾਟਾ ਪ੍ਰਮਾਣਿਕਤਾ। ਪ੍ਰਤੀ ਪੰਨਾ‑ਕਿਸਮ ਟੈਂਪਲੇਟ ਵਾਲੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਕੈਟਾਲਾਗ ਵਿੱਚ ਛੇ ਤੋਂ ਦਸ ਹਫ਼ਤੇ ਲੱਗਦੇ ਹਨ।
ਕੀ ਫੀਲਡ ਡੇਟਾ ਅਤੇ ਲੈਬ ਸਕੋਰ ਕਦੇ ਅਸਹਿਮਤ ਹੁੰਦੇ ਹਨ?
ਲਗਾਤਾਰ — ਲੈਬ ਰਨ ਸਿਮੂਲੇਟਡ ਹੌਲੀ ਡਿਵਾਈਸ ਵਰਤਦੇ ਹਨ ਜਦੋਂ ਕਿ ਤੁਹਾਡੇ ਵਿਜ਼ਟਰ ਤੇਜ਼ ਫ਼ੋਨਾਂ ਜਾਂ ਭੈੜੇ ਹੋਟਲ wifi 'ਤੇ ਹੋ ਸਕਦੇ ਹਨ। 28-ਦਿਨਾ CrUX ਫੀਲਡ ਡਾਟੇ 'ਤੇ ਫੈਸਲੇ ਭੇਜੋ; ਡਿਪਲਾਇਮੈਂਟ ਤੋਂ ਪਹਿਲਾਂ ਵਿਅਕਤੀਗਤ ਫਿਕਸ ਪਰਖਣ ਲਈ ਹੀ Lighthouse ਲੈਬ ਰਨ ਵਰਤੋ।
DG10 'ਤੇ ਪੜ੍ਹਨਾ ਜਾਰੀ ਰੱਖੋ
- ਐਂਟਰਪ੍ਰਾਈਜ਼ ਲਈ Next.js ਬਨਾਮ WordPress
- ਵਰਡਪ੍ਰੈਸ ਤੋਂ Next.js ਮਾਈਗ੍ਰੇਸ਼ਨ ਗਾਈਡ
- ਟ੍ਰੈਫਿਕ ਵਧਾਉਣ ਲਈ ਉੱਨਤ SEO ਸੇਵਾਵਾਂ
ਪ੍ਰਦਰਸ਼ਨ ਇੱਕ ਅਨੁਸ਼ਾਸਨ ਹੈ, ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ। ਇਸਨੂੰ ਆਪਣਾ ਬਣਾਓ।