ಮೂಲ ವೆಬ್ ವೈಟಲ್ಸ್ ಪರಿಹಾರ: 95+ Lighthouse ಸ್ಕೋರ್‌ಗಳಿಗೆ ಡೆವಲಪರ್ ಮಾರ್ಗದರ್ಶಿ

ಮೂಲ ವೆಬ್ ವೈಟಲ್ಸ್ ಪರಿಹಾರ: 95+ Lighthouse ಸ್ಕೋರ್‌ಗಳಿಗೆ ಡೆವಲಪರ್ ಮಾರ್ಗದರ್ಶಿ

ನೀವು ಹುಡುಕುತ್ತಿದ್ದರೆ Core Web Vitals fix ನಿಮ್ಮ Lighthouse ಅಂಕಗಳನ್ನು 95 ದಾಟಿಸುವಂತಹದ್ದು, ನೀವು ಸರಿಯಾದ ಸ್ಥಳಕ್ಕೆ ಬಂದಿದ್ದೀರಿ. … ಸಾಧಿಸುವುದು Lighthouse 95 ಎಂಬುದು ಮಿಥ್ಯವಲ್ಲ—ಇದು DG10 Agency ನಲ್ಲಿ ಡಜನ್‌ಗಟ್ಟಲೆ ಎಂಟರ್‌ಪ್ರೈಸ್ ಯೋಜನೆಗಳಲ್ಲಿ ನಾನು ಪರಿಷ್ಕರಿಸಿದ ವ್ಯವಸ್ಥಿತ ಪ್ರಕ್ರಿಯೆ.

ವಿಧಾನ ಟಿಪ್ಪಣಿ: ಕೆಳಗಿನ ಪರಿಹಾರ ಹಂತಗಳನ್ನು ಏಪ್ರಿಲ್ ಮತ್ತು ಆಗಸ್ಟ್ 2026 ರ ನಡುವೆ DG10 ಕ್ಲೈಂಟ್ ಸೈಟ್‌ಗಳಲ್ಲಿ (WordPress, Next.js, Shopify) ಮೌಲ್ಯೀಕರಿಸಲಾಯಿತು, ಪ್ರತಿಯೊಂದನ್ನು ಫೀಲ್ಡ್ CrUX ಡೇಟಾ ಜೊತೆಗೆ ಲ್ಯಾಬ್ Lighthouse ರನ್‌ಗಳೊಂದಿಗೆ ಅಳೆಯಲಾಯಿತು. ಮಿತಿಗಳು ಮತ್ತು ಪರಿಕರ ಉಲ್ಲೇಖಗಳನ್ನು ಸೆಪ್ಟೆಂಬರ್ 2026 ರಲ್ಲಿ ಮರು-ಪರಿಶೀಲಿಸಲಾಯಿತು.

ವಾಸ್ತವ ಕ್ರೂರ: ಜೂನ್ 2026 ರ ಹೊತ್ತಿಗೆ, ಟಾಪ್ 1 ಮಿಲಿಯನ್ ವೆಬ್‌ಸೈಟ್‌ಗಳ 20% ಕ್ಕಿಂತ ಕಡಿಮೆ ಎಲ್ಲಾ ಪುಟ ಪ್ರಕಾರಗಳಲ್ಲಿ Google ನ Core Web Vitals ಮಿತಿಗಳನ್ನು ಪೂರೈಸುತ್ತವೆ. ಆದರೆ ನಾವು ಕೆಲಸ ಮಾಡಿದಾಗ — ನಿಜವಾದ ಪರಿಹಾರ, ಮೇಲ್ಮೈ-ಮಟ್ಟದ ಪ್ಯಾಚ್‌ಗಳಲ್ಲ — ಫಲಿತಾಂಶಗಳು ಸ್ವತಃ ಮಾತನಾಡುತ್ತವೆ. 15–40% ಟ್ರಾಫಿಕ್ ಲಾಭಗಳು ಸಾಮಾನ್ಯ, ಮತ್ತು ನಾವೆಲ್ಲರೂ ಭಯಪಡುವ SEO ಶ್ರೇಯಾಂಕ ಅಸ್ಥಿರತೆ? ಅದು ಸ್ಥಿರಗೊಳ್ಳುತ್ತದೆ.

ಈ ಮಾರ್ಗದರ್ಶಿ ನನ್ನ ಪ್ರಾಮಾಣಿಕ, ಯುದ್ಧ-ಪರೀಕ್ಷಿತ ತಂತ್ರಪುಸ್ತಕ. ನಾವು ಪ್ರತಿ ಮೆಟ್ರಿಕ್, ನಾನು ಬಳಸುವ ನಿಖರ ಸಾಧನಗಳು ಮತ್ತು ಸೂಜಿ ಚಲಿಸುವ ಕೋಡ್-ಮಟ್ಟದ ಬದಲಾವಣೆಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತೇವೆ. ನಿಜವಾದ ಮೊದಲು/ನಂತರ ಡೇಟಾ, ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು ಮತ್ತು ಯಾವುದೇ ಸೈಟ್ ಅನ್ನು ಕೆಂಪಿನಿಂದ ಹಸಿರಿಗೆ ತೆಗೆದುಕೊಳ್ಳಬಲ್ಲ ವರ್ಕ್‌ಫ್ಲೋ ಹಂಚಿಕೊಳ್ಳುತ್ತೇನೆ. ಇಲ್ಲಿನ ಪ್ರತಿ ಶಿಫಾರಸು ಪ್ರಾಯೋಗಿಕ ಅನುಭವದಿಂದ ಬಂದಿದೆ — ಸ್ಕೋರ್‌ಗಳು ಏರುವುದನ್ನು ಮತ್ತು ಟ್ರಾಫಿಕ್ ಅನುಸರಿಸುವುದನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ.

Core Web Vitals ಪರಿಹಾರ ನಿಮ್ಮ ಲಾಭದ ಮೇಲೆ ನೇರವಾಗಿ ಏಕೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ

ವ್ಯವಹಾರ ಪ್ರಕರಣವನ್ನು ಬದಿಗಿಡೋಣ. Google ಅವರ ಶ್ರೇಯಾಂಕ ವ್ಯವಸ್ಥೆ—ವರ್ಷಗಳ ಹಿಂದೆ ಘೋಷಿತ—ಇನ್ನೂ CWV ಅನ್ನು ಶ್ರೇಯಾಂಕ ಸಂಕೇತವಾಗಿ ಬಳಸುತ್ತದೆ. ಆದರೆ ಕ್ಲೈಂಟ್‌ಗಳಲ್ಲಿ ನಾನು ನೋಡಿದ ಡೇಟಾ ಹೆಚ್ಚು ಸೂಕ್ಷ್ಮವಾದದ್ದನ್ನು ತೋರಿಸುತ್ತದೆ.

ನೈಜ ಟ್ರಾಫಿಕ್ ಬೆಳವಣಿಗೆ ಪುರಾಣವಲ್ಲ

92 Lighthouse ಕಾರ್ಯಕ್ಷಮತಾ ಅಂಕದಲ್ಲಿ ಸಿಲುಕಿದ್ದ SaaS ಕಂಪನಿಯೊಂದನ್ನು ನಾನು ಇತ್ತೀಚೆಗೆ ಲೆಕ್ಕಪರಿಶೋಧಿಸಿದೆ. ಅವರ largest contentful paint (LCP), cumulative layout shift (CLS) ಮತ್ತು ಇಂಟರಾಕ್ಷನ್ ಟು ನೆಕ್ಸ್ಟ್ ಪೇಂಟ್ (INP) ಮೇಲೆ ಕೇಂದ್ರಿತ ಎರಡು ವಾರಗಳ ಪರಿಹಾರ ಸ್ಪ್ರಿಂಟ್ ನಂತರ, ಅವರು 97 ತಲುಪಿದರು. ಮುಂದಿನ 90 ದಿನಗಳಲ್ಲಿ ಆರ್ಗ್ಯಾನಿಕ್ ಟ್ರಾಫಿಕ್ 22% ಏರಿತು.

ಅಂತಹ ಸಂಖ್ಯೆಗಳು ಅಪವಾದಗಳಲ್ಲ. 2025 ರ ಪ್ರಕರಣ ಅಧ್ಯಯನದ ಪ್ರಕಾರ web.dev , CWV ಅನ್ನು "ಸುಧಾರಣೆ ಅಗತ್ಯ" ದಿಂದ "ಉತ್ತಮ" ಗೆ ಸುಧಾರಿಸುವ ಸೈಟ್‌ಗಳು ಸಾವಯವ ಟ್ರಾಫಿಕ್‌ನಲ್ಲಿ 10–25% ಹೆಚ್ಚಳವನ್ನು ಕಾಣುತ್ತವೆ. ಅದು ನಿಜವಾದ Google ಮೊದಲ-ಪುಟ ಸ್ಥಾನ ಚಲನೆ. ನಮ್ಮ ಕ್ಲೈಂಟ್ ನೆಲೆಯಾದ್ಯಂತ ನಾನು ನೋಡಿದ ಮತ್ತೊಂದು ವಿಶ್ಲೇಷಣೆಯು ಮೂರೂ CWV ಮಿತಿಗಳನ್ನು ದಾಟುವುದು ಬ್ರಾಂಡ್-ಅಲ್ಲದ ಹುಡುಕಾಟ ಕ್ಲಿಕ್‌ಗಳಲ್ಲಿ ಸರಾಸರಿ 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

ಒಟ್ಟಾರೆ Lighthouse ಕಾರ್ಯಕ್ಷಮತೆ ಸ್ಕೋರ್‌ನಲ್ಲಿ LCP 25% ಪಾಲು ಹೊಂದಿದೆ. 95+ ಸ್ಕೋರ್ ಪಡೆಯಲು, ಲ್ಯಾಬ್ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ನಿಮ್ಮ LCP 1.8s ಒಳಗೆ ಮತ್ತು 75ನೇ ಶೇಕಡಾವಾರು ಫೀಲ್ಡ್ ಡೇಟಾದಲ್ಲಿ 2.0s ಒಳಗೆ ಇರಬೇಕು. ನನ್ನ ಅನುಭವದಲ್ಲಿ, 95+ ತಲುಪುವ ಹೆಚ್ಚಿನ ಸೈಟ್‌ಗಳು ಲ್ಯಾಬ್‌ನಲ್ಲಿ ಸುಮಾರು 1.2–1.5s LCP ಹೊಂದಿರುತ್ತವೆ.

ಇಂಟರಾಕ್ಷನ್ ಟು ನೆಕ್ಸ್ಟ್ ಪೇಂಟ್ (INP)

• Good: ≤ 200ms
• Needs Improvement: 200ms–500ms
• Poor: > 500ms

INP ಮಾರ್ಚ್ 2024 ರಲ್ಲಿ FID ಅನ್ನು ಬದಲಾಯಿಸಿತು. ಇದು ಪುಟದ ಒಟ್ಟಾರೆ ಪ್ರತಿಕ್ರಿಯಾಶೀಲತೆಯನ್ನು ಅಳೆಯುತ್ತದೆ. 95+ ಅಂಕಕ್ಕೆ, ಭಾರೀ ಥ್ರಾಟ್ಲಿಂಗ್ ಅಡಿಯಲ್ಲಿ ಗರಿಷ್ಠ INP 150ms ಗುರಿಯಿಡಿ. ಇದರರ್ಥ ನಿಮ್ಮ 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

ಕೋಷ್ಟಕ: ಕೋರ್ ವೆಬ್ ವೈಟಲ್ಸ್ ಮಿತಿಗಳು ಮತ್ತು Lighthouse ಸ್ಕೋರಿಂಗ್ ತೂಕಗಳು.

ರೋಗನಿರ್ಣಯ: ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ Core Web Vitals ಪರಿಹಾರವನ್ನು ಹುಡುಕುವುದು

ಕೋಡ್‌ನ ಒಂದೇ ಸಾಲನ್ನು ಬದಲಾಯಿಸುವ ಮೊದಲು, ಉತ್ತಮ ಗುಣಮಟ್ಟದ ರೋಗನಿರ್ಣಯ ಅಗತ್ಯ. ತಪ್ಪು ಸಮಸ್ಯೆಯ ಹಿಂದೆ ವಾರಗಟ್ಟಲೆ ವ್ಯರ್ಥ ಮಾಡಿದ ತಂಡಗಳನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ.

ಹಂತ 1: ಥ್ರಾಟ್ಲಿಂಗ್ ಜೊತೆ Incognito ನಲ್ಲಿ Lighthouse ಬಳಸಿ

"Mobile 3G Slow" ಪ್ರಿಸೆಟ್‌ನೊಂದಿಗೆ Chrome DevTools ನಿಂದ Lighthouse ಚಲಾಯಿಸಿ ಅಥವಾ ಮಧ್ಯಮ-ಶ್ರೇಣಿಯ ಸಾಧನವನ್ನು ಅನುಕರಿಸಿ. Opportunities and Diagnostics ವಿಭಾಗಗಳು—ಏನನ್ನು ಸರಿಪಡಿಸಬೇಕೆಂದು ಅವು ನಿಮಗೆ ನಿಖರವಾಗಿ ತಿಳಿಸುತ್ತವೆ. “Reduce initial server response time” ಮತ್ತು “Eliminate render-blocking resources” ಗೆ ವಿಶೇಷ ಗಮನ ಕೊಡಿ, ಏಕೆಂದರೆ ಇವು ಹೆಚ್ಚಾಗಿ ಅತ್ಯಧಿಕ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ.

ಹಂತ 2: ಫೀಲ್ಡ್ ಡೇಟಾಕ್ಕಾಗಿ CrUX API

Use the Chrome ಬಳಕೆದಾರ ಅನುಭವ ವರದಿ ನಿಮ್ಮ ಮೂಲದ ನೈಜ-ಬಳಕೆದಾರ ಡೇಟಾವನ್ನು ಎಳೆಯಲು API. ಫೀಲ್ಡ್ ಡೇಟಾವು LCP > 3s ತೋರಿಸಿದರೆ ಆದರೆ ಲ್ಯಾಬ್ ಡೇಟಾ 1s ತೋರಿಸಿದರೆ, DevTools ಸಂಪೂರ್ಣವಾಗಿ ಅನುಕರಿಸಲು ಸಾಧ್ಯವಾಗದ ಸರ್ವರ್-ಸೈಡ್ ಸಮಸ್ಯೆ (ನಿಧಾನ TTFB) ನಿಮ್ಮಲ್ಲಿದೆ. ಆ ಸಂದರ್ಭದಲ್ಲಿ, ಫ್ರಂಟ್-ಎಂಡ್ ಸಂಪನ್ಮೂಲಗಳ ಬದಲು ಹೋಸ್ಟಿಂಗ್, CDN ಮತ್ತು ಸರ್ವರ್ ಸಂರಚನೆಯತ್ತ ಗಮನ ಹರಿಸಬೇಕು.

ಹಂತ 3: ನೈಜ ಬಳಕೆದಾರ ಮೇಲ್ವಿಚಾರಣೆ (RUM)

ಹೆಚ್ಚು-ಟ್ರಾಫಿಕ್ ಸೈಟ್‌ಗಳಿಗೆ, ಹಗುರವಾದ RUM ಪರಿಹಾರವನ್ನು ( ... ನಂತಹ) ನಿಯೋಜಿಸಿ WebPageTest’s RUM or custom PerformanceObserver ಕರೆಗಳು). ಇದು ವೈಯಕ್ತಿಕ ಅಸಹಜತೆಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ — ಕೆಲವು ಸಾಧನ ಪ್ರಕಾರಗಳು ಅಥವಾ ಭೌಗೋಳಿಕ ಪ್ರದೇಶಗಳಿಗೆ ಮಾತ್ರ ನಿಧಾನವಾಗಿರುವ ಪುಟಗಳಂತೆ. RUM ಸೆಟಪ್ ನಿಮ್ಮ ಮೊಬೈಲ್ LCP ಉತ್ತಮವಾಗಿದೆ ಆದರೆ ಸೋಮಾರಿ-ಲೋಡಿಂಗ್ ಜಾಹೀರಾತುಗಳಿಂದ ಡೆಸ್ಕ್‌ಟಾಪ್ CLS ಏರುತ್ತದೆ ಎಂದು ಬಹಿರಂಗಪಡಿಸಬಹುದು. ಕ್ಷೇತ್ರ ಡೇಟಾ ಇಲ್ಲದೆ, ನೀವು ಕುರುಡಾಗಿ ಹಾರುತ್ತಿದ್ದೀರಿ.

ಹಂತ 4: WebPageTest ಫಿಲ್ಮ್‌ಸ್ಟ್ರಿಪ್

ನಾನು ಯಾವಾಗಲೂ Lighthouse ಅನ್ನು ಇದರೊಂದಿಗೆ ಪೂರಕಗೊಳಿಸುತ್ತೇನೆ WebPageTest. ಅದನ್ನು “Mobile Slow 3G” ಗೆ ಹೊಂದಿಸಿ ಮತ್ತು ಫಿಲ್ಮ್‌ಸ್ಟ್ರಿಪ್ ನೋಡಿ. ಪ್ರತಿ ಅಂಶವು ನಿಖರವಾಗಿ ಯಾವಾಗ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ವ್ಯರ್ಥ ವಿನಂತಿಗಳಿವೆಯೇ ಎಂದು ಅದು ನಿಮಗೆ ತೋರಿಸುತ್ತದೆ. ನನ್ನ ಹೀರೋ ಚಿತ್ರಕ್ಕಿಂತ ಮೊದಲು ಡೌನ್‌ಲೋಡ್ ಆರಂಭಿಸುವ ಥರ್ಡ್-ಪಾರ್ಟಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ನಾನು ಹಿಡಿದಿದ್ದೇನೆ—ತ್ವರಿತ ಗೆಲುವು ನೀಡುವ ಸಂಶೋಧನೆಗಳು ಅಂತಹವು.

95+ Lighthouse ಗಾಗಿ ಕಾರ್ಯಸಾಧ್ಯ ಕೋರ್ ವೆಬ್ ವೈಟಲ್ಸ್ ಪರಿಹಾರ ತಂತ್ರಗಳು

ಪ್ರತಿಯೊಂದು ಮೆಟ್ರಿಕ್ ಅನ್ನು ಕಾಂಕ್ರೀಟ್ ಕೋಡ್ ಮಟ್ಟದ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ವಿವರಿಸುತ್ತೇನೆ.

LCP: ದೊಡ್ಡ ಹೊರೆ ಹೊರುವವನು

LCP ಸಾಮಾನ್ಯವಾಗಿ ಚಿತ್ರ, ವೀಡಿಯೊ ಪೋಸ್ಟರ್ ಅಥವಾ ದೊಡ್ಡ ಪಠ್ಯ ಬ್ಲಾಕ್. 95 ದಾಟಲು ನಿಮಗೆ 1.8s ಒಳಗಿನ LCP ಬೇಕು.

• ನಿರ್ಣಾಯಕ ಆಸ್ತಿಗಳನ್ನು ಮೊದಲೇ ಲೋಡ್ ಮಾಡಿ: Use <link rel="preload" as="image" href="hero.webp"> ಹೀರೋ ಚಿತ್ರಗಳಿಗಾಗಿ. ಪಠ್ಯ-ಆಧಾರಿತ LCP ಗಾಗಿ, ನಿಮ್ಮ ಫಾಂಟ್ ಅನ್ನು ಸಹ ಪೂರ್ವಲೋಡ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
• Optimize images: WebP ಗೆ ಪರಿವರ್ತಿಸಿ, ರೆಸ್ಪಾನ್ಸಿವ್ ಗಾತ್ರಗಳನ್ನು ಬಳಸಿ (srcset ), ಮತ್ತು AVIF ನಂತಹ ಮುಂದಿನ-ಪೀಳಿಗೆಯ ಸ್ವರೂಪಗಳನ್ನು ನೀಡಿ. WebP ಗೆ ಹೋಲಿಸಿದರೆ ಗಮನಾರ್ಹ ಗುಣಮಟ್ಟ ನಷ್ಟವಿಲ್ಲದೆ AVIF ಚಿತ್ರದ ಭಾರವನ್ನು 30% ಕಡಿಮೆ ಮಾಡುವುದನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ.
• ಸರ್ವರ್-ಸೈಡ್ ರೆಂಡರಿಂಗ್: ನೀವು ಇದರಂತಹ ಫ್ರೇಮ್‌ವರ್ಕ್ ಬಳಸುತ್ತಿದ್ದರೆ Next.js or React , LCP ವಿಷಯವು JavaScript ಮೂಲಕ ಲೋಡ್ ಆಗದೆ ಆರಂಭಿಕ HTML ನಲ್ಲಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. 1.8s ಕ್ಕಿಂತ ಕಡಿಮೆ LCP ಗೆ ಸ್ಥಿರ ಉತ್ಪಾದನೆ ಅಥವಾ ಸರ್ವರ್-ಬದಿಯ ರೆಂಡರಿಂಗ್ ಅನಿವಾರ್ಯ.
• ರೆಂಡರ್-ತಡೆಯುವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ತೆಗೆದುಹಾಕಿ: ನಿರ್ಣಾಯಕವಲ್ಲದ CSS ಮತ್ತು JavaScript ಅನ್ನು ಮುಂದೂಡಿ. ಬಳಸಿ rel="preload" for fonts and media="print" ಫಾಲ್‌ಬ್ಯಾಕ್ ಶೈಲಿಗಳಿಗಾಗಿ. ನಾವು ಹೆಚ್ಚಾಗಿ ಮಡಿಕೆ-ಮೇಲಿನ ವಿಷಯಕ್ಕಾಗಿ ನಿರ್ಣಾಯಕ CSS ಅನ್ನು ಇನ್‌ಲೈನ್ ಮಾಡುತ್ತೇವೆ.
• ನೈಜ ಬಳಕೆದಾರ ಎಡ್ಜ್ ಕ್ಯಾಶಿಂಗ್ ಇರುವ CDN ಬಳಸಿ Services like Cloudflare ಅಥವಾ Amazon CloudFront ಬಳಕೆದಾರರಿಗೆ ಹತ್ತಿರವಿರುವ ಕ್ಯಾಶ್ ಸ್ಥಳಗಳಿಂದ ಸ್ಟ್ಯಾಟಿಕ್ ಅಸೆಟ್‌ಗಳು ಮತ್ತು API ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಸಹ ಸರ್ವ್ ಮಾಡಬಹುದು, TTFB ಮತ್ತು LCPಯನ್ನು ನಾಟಕೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

Case: ಇದನ್ನು ಬಳಸಿಕೊಂಡು ನಾನು ಇ-ಕಾಮರ್ಸ್ ಸೈಟ್‌ಗೆ ಸಹಾಯ ಮಾಡಿದೆ Shopify ಕಸ್ಟಮ್ ನಿರ್ಣಾಯಕ CSS ಪೈಪ್‌ಲೈನ್ ಜಾರಿಗೆ ತಂದು ಕೆಳ-ಮಡಿಕೆ ಚಿತ್ರಗಳನ್ನು ಸೋಮಾರಿ-ಲೋಡ್ ಮಾಡುವ ಮೂಲಕ LCP ಅನ್ನು 4.1s ನಿಂದ 1.6s ಗೆ ಇಳಿಸಿ. ತಂತ್ರವೆಂದರೆ 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 ಮತ್ತು ಇತರ ವಿಶ್ಲೇಷಣಾ ಪರಿಕರಗಳು ಹೆಚ್ಚಾಗಿ ಮೊದಲು ಚಾಲನೆಯಾಗಿ ಬಳಕೆದಾರರ ಇನ್‌ಪುಟ್ ಅನ್ನು ತಡೆಯುತ್ತವೆ. ಅವುಗಳನ್ನು ತೆಗೆದುಹಾಕಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಅವುಗಳನ್ನು ಇದರ ನಂತರ ಲೋಡ್ ಮಾಡಿ onload or use async ಎಚ್ಚರಿಕೆಯ ಕಾರ್ಯ ನಿಗದಿಯೊಂದಿಗೆ.

Real data: ನಾನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ಹಣಕಾಸು ಸೈಟ್ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಚಾರ್ಟ್ ಲೈಬ್ರರಿಯಿಂದಾಗಿ 540ms INP ಹೊಂದಿತ್ತು. Canvas ನೊಂದಿಗೆ ನಿರ್ಮಿಸಿದ ಹಗುರವಾದ ಚಾರ್ಟ್‌ಗೆ ಬದಲಾಯಿಸಿದ ನಂತರ, INP 130ms ಗೆ ಇಳಿಯಿತು. ಲೈಬ್ರರಿಯು ಪ್ರತಿ ಡೇಟಾ ಪಾಯಿಂಟ್ ಹೋವರ್‌ನಲ್ಲಿ ಸಂಪೂರ್ಣ ಚಾರ್ಟ್ ಅನ್ನು ಮರು-ರೆಂಡರ್ ಮಾಡುತ್ತಿತ್ತು; ಜೊತೆಗೆ ಥ್ರಾಟ್ಲಿಂಗ್ ಮಾಡುವ ಮೂಲಕ requestAnimationFrame ಮತ್ತು ಸರಳ ರೆಂಡರಿಂಗ್ ವಿಧಾನವನ್ನು ಬಳಸಿ, ನಾವು ಜಾಂಕ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿದೆವು.

CLS: ಸುಲಭ ಸಾಧನೆ

CLS ಬಹುತೇಕ ಯಾವಾಗಲೂ ಆಯಾಮಗಳಿಲ್ಲದೆ ಡೈನಾಮಿಕ್ ವಿಷಯ ಲೋಡ್ ಆಗುವುದರಿಂದ ಉಂಟಾಗುತ್ತದೆ.

• Always set width and height ಚಿತ್ರಗಳು ಮತ್ತು iframeಗಳ ಮೇಲೆ. Use CSS aspect-ratio ಪ್ರತಿಕ್ರಿಯಾಶೀಲ ಚಿತ್ರಗಳಿಗೆ ಫಾಲ್‌ಬ್ಯಾಕ್ ಆಗಿ.
• ಜಾಹೀರಾತುಗಳು ಮತ್ತು ಎಂಬೆಡ್‌ಗಳಿಗಾಗಿ ಸ್ಥಳ ಕಾಯ್ದಿರಿಸಿ. Use CSS aspect-ratio ಅಥವಾ ಸ್ಥಿರ ಕಂಟೈನರ್‌ಗಳು. ಡೈನಾಮಿಕ್ ಜಾಹೀರಾತು ಗಾತ್ರಗಳಿಗೆ, ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಜಾಹೀರಾತು ಸ್ವರೂಪಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವ ಕಸ್ಟಮ್ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ಅಂಶವನ್ನು ಬಳಸಿ.
• ಮೊದಲ ಪೇಂಟ್ ನಂತರ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವಿಷಯದ ಮೇಲೆ ವಿಷಯವನ್ನು ಸೇರಿಸುವುದನ್ನು ತಪ್ಪಿಸಿ. ಇದು ನಿಜವಾಗಿಯೂ ಸುವರ್ಣ ನಿಯಮ. ಫೋಲ್ಡ್ ಮೇಲೆ DOM ಅನ್ನು ಮಾರ್ಪಡಿಸುವ ಯಾವುದೇ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಆರಂಭಿಕ ಲೇಔಟ್ ಸ್ಥಿರವಾಗುವವರೆಗೆ ಮುಂದೂಡಬೇಕು.
• Use font-display: optional or swap ಅಗೋಚರ ಪಠ್ಯವು ಲೇಔಟ್ ಬದಲಾವಣೆಗಳನ್ನು ಉಂಟುಮಾಡುವುದನ್ನು ತಡೆಯಲು. ಕಸ್ಟಮ್ ಫಾಂಟ್ ನಿಧಾನವಾಗಿ ಲೋಡ್ ಆದಾಗ, ಬ್ರೌಸರ್ ಫಾಲ್‌ಬ್ಯಾಕ್ ಫಾಂಟ್‌ಗೆ ಡೀಫಾಲ್ಟ್ ಆಗಿ ನಂತರ ಬದಲಾಯಿಸಬಹುದು, ಇದರಿಂದ ಬದಲಾವಣೆ ಉಂಟಾಗುತ್ತದೆ. font-display: optional ಸ್ವಾಪ್ ಅನ್ನು ತಡೆಯುತ್ತದೆ ಮತ್ತು ಕಸ್ಟಮ್ ಫಾಂಟ್ ಸಮಯಕ್ಕೆ ಬರದಿದ್ದರೆ ಫಾಲ್‌ಬ್ಯಾಕ್ ಫಾಂಟ್ ಅನ್ನು ಬಳಸುತ್ತದೆ.

ಒಂದೇ ಸ್ಪ್ರಿಂಟ್‌ನಲ್ಲಿ CLS 0.25+ ರಿಂದ 0.03 ಕ್ಕೆ ಸುಧಾರಿಸುವುದನ್ನು ನಾನು ನಿರಂತರವಾಗಿ ನೋಡಿದ್ದೇನೆ. ಇದು ಅತ್ಯಂತ ವೇಗದ Core Web Vitals fix ನೀವು ಅನ್ವಯಿಸಬಹುದು. ಒಬ್ಬ ಕ್ಲೈಂಟ್ ತಮ್ಮ ಮುಖಪುಟದಲ್ಲಿ 0.8 CLS ಹೊಂದಿದ್ದರು ಏಕೆಂದರೆ ಸುದ್ದಿಪತ್ರ ಸೈನ್‌ಅಪ್ ಮೋಡಲ್ ಅನ್ನು ಕಾಯ್ದಿರಿಸಿದ ಜಾಗವಿಲ್ಲದೆ ಫೋಲ್ಡ್ ಮೇಲೆ ಚುಚ್ಚಲಾಗಿತ್ತು. ಸರಳವಾಗಿ ಸ್ಥಿರ-ಎತ್ತರದ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ div ಸೇರಿಸುವ ಮೂಲಕ, CLS 0.01 ಕ್ಕೆ ಇಳಿಯಿತು.

ಕೋರ್ ವೆಬ್ ವೈಟಲ್ಸ್ ಪರಿಹಾರಕ್ಕಾಗಿ ಸುಧಾರಿತ ಸರ್ವರ್-ಸೈಡ್ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳು

ಫ್ರಂಟ್-ಎಂಡ್ ಮಾರ್ಪಾಡುಗಳನ್ನು ಮೀರಿ, 95+ ತಲುಪದಂತೆ ತಡೆಯುವ ಅಡಚಣೆ ಸರ್ವರ್ ಸಂರಚನೆಯೇ ಆಗಿರುತ್ತದೆ.

TTFB ಮತ್ತು ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ

ನಿಧಾನ ಮೊದಲ ಬೈಟ್‌ಗೆ ಸಮಯ (TTFB) ಪ್ರತಿಯೊಂದು ಇತರ ಮೆಟ್ರಿಕ್ ಅನ್ನು ಹಿಂದಿಡುತ್ತದೆ. Lighthouse 95ಗಾಗಿ, ಮೊಬೈಲ್‌ನಲ್ಲಿ (ಲ್ಯಾಬ್) 600ms ಕ್ಕಿಂತ ಕಡಿಮೆ ಮತ್ತು ಕ್ಷೇತ್ರ ಡೇಟಾದಲ್ಲಿ 800ms ಕ್ಕಿಂತ ಕಡಿಮೆ TTFB ಗುರಿಯಿಡಿ. HTML ಉತ್ಪಾದಿಸಲು ಅವರ ಸರ್ವರ್ 1.2s ತೆಗೆದುಕೊಳ್ಳುತ್ತಿರುವಾಗ ಚಿತ್ರಗಳು ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡುವ ಡೆವಲಪರ್‌ಗಳನ್ನು ನಾನು ಬಹಳಷ್ಟು ನೋಡಿದ್ದೇನೆ.

• ಎಡ್ಜ್ ಕ್ಯಾಶಿಂಗ್ ಇರುವ CDN ಬಳಸಿ (ಅಂಚಿನಿಂದ ಸ್ಥಿರ HTML ಪುಟಗಳನ್ನು ಒದಗಿಸಲು Cloudflare, Fastly ನಂತಹ) .
• ಡೇಟಾಬೇಸ್ ಪ್ರಶ್ನೆಗಳನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿ ಮತ್ತು CMS-ಆಧಾರಿತ ಸೈಟ್‌ಗಳಿಗೆ ಪುಟ ಕ್ಯಾಶ್ ಪ್ಲಗಿನ್ ಬಳಸುವುದನ್ನು ಪರಿಗಣಿಸಿ.
• ಸರ್ವರ್‌ಲೆಸ್ ಅಥವಾ ಎಡ್ಜ್ ಫಂಕ್ಷನ್‌ಗಳನ್ನು ಪರಿಗಣಿಸಿ ಪೂರ್ಣ ಸರ್ವರ್-ಬದಿ ಸಂಸ್ಕರಣೆಯ ಅಗತ್ಯವಿದ್ದ ಡೈನಾಮಿಕ್ ವಿಷಯಕ್ಕಾಗಿ.

ಪ್ರಿಕನೆಕ್ಟ್ ಮತ್ತು DNS ಪ್ರಿಫೆಚ್

Add <link rel="dns-prefetch" href="//fonts.googleapis.com"> and <link rel="preconnect" href="https://fonts.googleapis.com" crossorigin> ನೀವು ಸಂಪರ್ಕಿಸಲಿರುವ ಮೂಲಗಳ (origins) ಬಗ್ಗೆ ಬ್ರೌಸರ್‌ಗೆ ಮುಂಚಿತ ಸುಳಿವು ನೀಡಲು. ಇದು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಮೂಲಗಳಿಗೆ ಆರಂಭಿಕ ಸಂಪರ್ಕ ಸಮಯವನ್ನು 400–600ms ರಷ್ಟು ಕಡಿಮೆ ಮಾಡಬಹುದು.

HTTP/2 and HTTP/3

ನಿಮ್ಮ ಸರ್ವರ್ QUIC ಮೇಲೆ HTTP/2 ಅಥವಾ (ಆದ್ಯತೆಯಾಗಿ) HTTP/3 ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಮಲ್ಟಿಪ್ಲೆಕ್ಸಿಂಗ್ ಮತ್ತು ಸರ್ವರ್ ಪುಶ್ ವಿಳಂಬ ಕಡಿಮೆ ಮಾಡಬಹುದು, ಆದರೆ ಹೆಚ್ಚು ಪ್ಯಾಕೆಟ್ ನಷ್ಟವಿರುವ ಮೊಬೈಲ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ HTTP/3 ವಿಶೇಷವಾಗಿ ಪರಿಣಾಮಕಾರಿ.

ನೈಜ-ಪ್ರಪಂಚದ ಕೇಸ್ ಸ್ಟಡಿ: ಇ-ಕಾಮರ್ಸ್ ಕೋರ್ ವೆಬ್ ವೈಟಲ್ಸ್ ಪರಿಹಾರ

ವಿಧಾನವನ್ನು ಕಾರ್ಯರೂಪದಲ್ಲಿ ನೋಡಲು ಪೂರ್ಣ ತೊಡಗಿಸಿಕೊಳ್ಳುವಿಕೆಯ ಮೂಲಕ ನಿಮ್ಮನ್ನು ಕರೆದೊಯ್ಯುತ್ತೇನೆ.

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 ಅನ್ನು ಇದರ ನಂತರ ಲೋಡ್ ಆಗುವಂತೆ ಸರಿಸಲಾಗಿದೆ onload via requestIdleCallback.
• ಫಲಿತಾಂಶ: INP 210ms ಗೆ ಸುಧಾರಿಸಿತು, Lighthouse ಸ್ಕೋರ್ 89 ತಲುಪಿತು.

ಸ್ಪ್ರಿಂಟ್ 3 – CLS ಮತ್ತು ಅಂತಿಮ ಮೆರುಗು:

• ಎಲ್ಲಾ ಉತ್ಪನ್ನ ಚಿತ್ರಗಳು ಮತ್ತು iframe ಗಳಿಗೆ ಸ್ಪಷ್ಟ ಅಗಲ/ಎತ್ತರ ಸೇರಿಸಲಾಗಿದೆ.
• 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 ಸಾಧಿಸಲು ಡೆವಲಪರ್ ಕಾರ್ಯವಿಧಾನ

ಯಾವುದೇ ಪುಟಕ್ಕೂ ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅನುಸರಿಸಿ:

1. Baseline Audit: ಪ್ರಸ್ತುತ Lighthouse ಸ್ಕೋರ್, ಫೀಲ್ಡ್ ದತ್ತಾಂಶ ಮತ್ತು ವೈಯಕ್ತಿಕ CWV ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ದಾಖಲಿಸಿ.
2. Prioritize Issues: ಪರಿಣಾಮದ ಪ್ರಕಾರ ವಿಂಗಡಿಸಿ. ಕಾರ್ಯಕ್ಷಮತೆ ಸ್ಕೋರ್‌ನಲ್ಲಿ LCP ಮತ್ತು TBT (ಒಟ್ಟು ನಿರ್ಬಂಧಿಸುವ ಸಮಯ) ಅತಿ ಹೆಚ್ಚು ತೂಕ ಹೊಂದಿವೆ.
3. ಒಂದೊಂದೇ ಪರಿಹಾರವನ್ನು ಅನ್ವಯಿಸಿ: ಪ್ರತಿ ಬದಲಾವಣೆಯ ನಂತರ Lighthouse ಅನ್ನು ಮರು-ಚಲಾಯಿಸಿ. ಇದು ಗೋಜಲು ಡಿಬಗ್ಗಿಂಗ್ ಅನ್ನು ತಡೆಯುತ್ತದೆ.
4. WebPageTest ನೊಂದಿಗೆ ಮೌಲ್ಯೀಕರಿಸಿ: ಇದರ ಮೇಲೆ 3G ನಿಧಾನ ಪರೀಕ್ಷೆಯನ್ನು ಚಲಾಯಿಸಿ WebPageTest ಫಿಲ್ಮ್‌ಸ್ಟ್ರಿಪ್ ನೋಡಿ ನೈಜ-ಬಳಕೆದಾರರಂತಹ ಫಲಿತಾಂಶಗಳನ್ನು ಖಚಿತಪಡಿಸಲು.
5. ರಿಗ್ರೆಶನ್‌ಗಳಿಗಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ: ನಿಮ್ಮ CI/CD ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ Lighthouse CI ಅನ್ನು ಹೊಂದಿಸಿ, ಇದರಿಂದ ಯಾವುದೇ ಹೊಸ ಕೋಡ್ ಸ್ಕೋರ್ ಅನ್ನು 90 ಕ್ಕಿಂತ ಕಡಿಮೆ ಮಾಡುವುದಿಲ್ಲ. ಪ್ರತಿ PR ಗೆ Lighthouse ಚಲಾಯಿಸಿ ಸ್ಕೋರ್ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ಕಾಮೆಂಟ್ ಮಾಡುವ GitHub Actions ಕೆಲಸದ ಹರಿವನ್ನು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇನೆ.
6. ನಿಮ್ಮ ಟಾಪ್ 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-to-Next.js ವಲಸೆ ಮಾರ್ಗದರ್ಶಿ ಒಳಗೊಂಡಿದೆ.

Core Web Vitals ಪರಿಹಾರಕ್ಕೆ ಎಷ್ಟು ಸಮಯ ಬೇಕು?

ವಿಶಿಷ್ಟ ಮಾರ್ಕೆಟಿಂಗ್ ಸೈಟ್‌ಗಾಗಿ ಕೇಂದ್ರೀಕೃತ ಪರಿಹಾರ ಸ್ಪ್ರಿಂಟ್ ಎರಡರಿಂದ ನಾಲ್ಕು ವಾರಗಳು: ಒಂದು ವಾರ ರೋಗನಿರ್ಣಯ, ಒಂದರಿಂದ ಎರಡು ಪರಿಹಾರಗಳು, ಒಂದು ಕ್ಷೇತ್ರ-ಡೇಟಾ ಮೌಲ್ಯೀಕರಣ. ಪ್ರತಿ ಪುಟ-ಪ್ರಕಾರಕ್ಕೆ ಟೆಂಪ್ಲೇಟ್‌ಗಳಿರುವ ಎಂಟರ್‌ಪ್ರೈಸ್ ಕ್ಯಾಟಲಾಗ್‌ಗಳಿಗೆ ಆರರಿಂದ ಹತ್ತು ವಾರಗಳು.

ಕ್ಷೇತ್ರ ದತ್ತಾಂಶ ಮತ್ತು ಲ್ಯಾಬ್ ಅಂಕಗಳು ಎಂದಾದರೂ ಭಿನ್ನಾಭಿಪ್ರಾಯ ಹೊಂದಿವೆಯೇ?

ನಿರಂತರವಾಗಿ — ಲ್ಯಾಬ್ ರನ್‌ಗಳು ಅನುಕರಿಸಿದ ನಿಧಾನ ಸಾಧನವನ್ನು ಬಳಸುತ್ತವೆ, ಆದರೆ ನಿಮ್ಮ ಸಂದರ್ಶಕರು ವೇಗದ ಫೋನ್‌ಗಳಲ್ಲಿ ಅಥವಾ ಭಯಾನಕ ಹೋಟೆಲ್ ವೈಫೈನಲ್ಲಿರಬಹುದು. 28-ದಿನಗಳ CrUX ಫೀಲ್ಡ್ ಡೇಟಾದ ಮೇಲೆ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ; ನಿಯೋಜನೆಗೆ ಮೊದಲು ವೈಯಕ್ತಿಕ ಪರಿಹಾರಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಮಾತ್ರ Lighthouse ಲ್ಯಾಬ್ ರನ್‌ಗಳನ್ನು ಬಳಸಿ.

DG10 ನಲ್ಲಿ ಓದುವುದನ್ನು ಮುಂದುವರಿಸಿ

• Next.js vs WordPress for Enterprise
• WordPress ನಿಂದ Next.js ಗೆ ವಲಸೆ ಮಾರ್ಗದರ್ಶಿ
• ಟ್ರಾಫಿಕ್ ಹೆಚ್ಚಿಸಲು ಸುಧಾರಿತ SEO ಸೇವೆಗಳು

ಕಾರ್ಯಕ್ಷಮತೆ ಶಿಸ್ತು, ಯೋಜನೆಯಲ್ಲ. ಅದನ್ನು ನಿಮ್ಮದಾಗಿಸಿಕೊಳ್ಳಿ.