ನಿಮ್ಮ ವೆಬ್‌ಸೈಟ್ ಅನ್ನು ವೇಗವಾಗಿಸುವುದು ಹೇಗೆ: ಪ್ರಾಯೋಗಿಕ ಪರಿಶೀಲನಾಪಟ್ಟಿ
ವೆಬ್‌ಸೈಟ್ ವೇಗವಾಗಿಸಲು, ಮೊದಲು PageSpeed Insights ನಿಂದ ಅಳೆಯಿರಿ, ನಂತರ ಅದು ತೋರಿಸುವ ದೊಡ್ಡ ಕಾರಣವನ್ನು ಸರಿಪಡಿಸಿ — ಸಾಮಾನ್ಯವಾಗಿ ಬಹಳ ದೊಡ್ಡ ಚಿತ್ರಗಳು, ತುಂಬಾ JavaScript, ಭಾರೀ ಫಾಂಟ್‌ಗಳು ಅಥವಾ ಮೂರನೇ ವ್ಯಕ್ತಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು. Google ನ Core Web Vitals “ಉತ್ತಮ” ಗುರಿಗಳನ್ನು ಗುರಿಯಾಗಿಸಿ: ಮುಖ್ಯ ವಿಷಯ 2.5 ಸೆಕೆಂಡ್‌ಗಳೊಳಗೆ ಗೋಚರ, ಟ್ಯಾಪ್‌ಗಳಿಗೆ 200 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳೊಳಗೆ ಪ್ರತಿಕ್ರಿಯೆ, ಮತ್ತು ಬಹುತೇಕ ಲೇಔಟ್ ಜಿಗಿತವಿಲ್ಲ. ಹೆಚ್ಚಿನ ಸೈಟ್‌ಗಳು ಮರುಬರೆಯದೆ ಕೆಲವು ಬದಲಾವಣೆಗಳಿಂದಲೇ ಅಲ್ಲಿಗೆ ತಲುಪುತ್ತವೆ.
ಯಾವುದನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಅಳೆಯಿರಿ
ಊಹಿಸುವುದು ಸಮಯ ವ್ಯರ್ಥ. ಎರಡು ಉಚಿತ ಉಪಕರಣಗಳು ಬಹುತೇಕ ಎಲ್ಲರಿಗೂ ಸಾಕು:
- PageSpeed Insights (pagespeed.web.dev) — ಜೀವಂತ URL ಅಂಟಿಸಿ. ಸಾಕಷ್ಟು ಟ್ರಾಫಿಕ್ ಇದ್ದರೆ ನಿಜವಾದ Chrome ಬಳಕೆದಾರರಿಂದ ಫೀಲ್ಡ್ ಡೇಟಾ ಮತ್ತು ಸಿಮ್ಯುಲೇಟೆಡ್ ಲೋಡ್‌ನಿಂದ ಲ್ಯಾಬ್ ಡೇಟಾ, ಜೊತೆಗೆ ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆಗಳ ಪಟ್ಟಿ ತೋರಿಸುತ್ತದೆ.
- Lighthouse Chrome DevTools ನಲ್ಲಿ — ಅದೇ ಲ್ಯಾಬ್ ಪರೀಕ್ಷೆ, ತೆರೆಯಬಹುದಾದ ಯಾವುದೇ ಪುಟದಲ್ಲಿ, preview ಸೇರಿದಂತೆ. ಮೊಬೈಲ್ ಮೋಡ್‌ನಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ; ನಿಧಾನ ನೆಟ್‌ವರ್ಕ್‌ನ ಫೋನ್‌ಗಳಲ್ಲಿ ಸಮಸ್ಯೆಗಳು ಗೋಚರಿಸುತ್ತವೆ.
ನಿಮಗೆ ಮುಖ್ಯವಾದ ಸಂಖ್ಯೆಗಳು Google ನ Core Web Vitals. ಸೆಪ್ಟೆಂಬರ್ 2026 ರ ವೇಳೆಗೆ, web.dev ನಲ್ಲಿರುವ Google ದಾಖಲೆ ಪುಟ ಲೋಡ್‌ಗಳ 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 ಬಳಸಿ | ಅತಿಯಾಗಿ ಸಂಕುಚಿಸಿದರೆ ಸ್ವಲ್ಪ ಗುಣಮಟ್ಟ ನಷ್ಟ |
| ತಪ್ಪು ಕ್ರಮದಲ್ಲಿ ಲೋಡ್ ಆಗುವ ಚಿತ್ರಗಳು | ಪಟ್ಟು ಕೆಳಗಿನ ಚಿತ್ರಗಳನ್ನು lazy-load ಮಾಡಿ; ಹೀರೋ ಚಿತ್ರಕ್ಕೆ ಹೆಚ್ಚಿನ ಆದ್ಯತೆ | ಹೀರೋ lazy ಆಗದಿದ್ದರೆ ಏನೂ ಇಲ್ಲ |
| ತುಂಬಾ JavaScript | ಪ್ರತಿ ಪುಟಕ್ಕೆ ಕೋಡ್ ವಿಭಜಿಸಿ, ಬಳಸದ ಲೈಬ್ರರಿಗಳನ್ನು ತೆಗೆಯಿರಿ | ಕೆಲವು ಮರುರಚನೆ |
| ಕ್ಲೈಂಟ್-ಮಾತ್ರ ರೆಂಡರಿಂಗ್ | ಸಾರ್ವಜನಿಕ ಪುಟಗಳನ್ನು ಪ್ರಿರೆಂಡರ್ ಅಥವಾ ಸರ್ವರ್-ರೆಂಡರ್ ಮಾಡಿ | ಹೆಚ್ಚು ಬಿಲ್ಡ್ ಅಥವಾ ಸರ್ವರ್ ಸೆಟಪ್ |
| ವೆಬ್ ಫಾಂಟ್‌ಗಳು | ಕಡಿಮೆ ಕುಟುಂಬಗಳು ಮತ್ತು ತೂಕಗಳು, ಮುಖ್ಯದನ್ನು ಪ್ರಿಲೋಡ್ ಮಾಡಿ, font-display: swap | ಟೈಪೋಗ್ರಫಿ ವೈವಿಧ್ಯ ಕಡಿಮೆ |
| ಮೂರನೇ ವ್ಯಕ್ತಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು | ಬಳಸದವುಗಳನ್ನು ತೆಗೆಯಿರಿ, ಉಳಿದವನ್ನು ಪುಟದ ನಂತರ ಲೋಡ್ ಮಾಡಿ | ಒಂದು ವಿಜೆಟ್ ಅಥವಾ ಟ್ರ್ಯಾಕರ್ ಕಳೆದುಕೊಳ್ಳುವುದು |
| ನಿಧಾನ ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯೆ | ಕ್ಯಾಶಿಂಗ್, CDN, ವಿಷಯ ಪುಟಗಳಿಗೆ ಸ್ಟ್ಯಾಟಿಕ್ ಹೋಸ್ಟಿಂಗ್ | ಕ್ಯಾಶ್ ಅಮಾನ್ಯೀಕರಣದ ಬಗ್ಗೆ ಯೋಚಿಸಬೇಕು |
ಚಿತ್ರಗಳು
ಚಿತ್ರಗಳು ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆ ಮತ್ತು ಸರಿಪಡಿಸಲು ಸುಲಭ. 800 ಪಿಕ್ಸೆಲ್ ಅಗಲದಲ್ಲಿ ತೋರಿಸುವ 4,000 ಪಿಕ್ಸೆಲ್ ಫೋಟೋ ಪ್ರತಿ ಸಂದರ್ಶಕರು ನೋಡುವುದಕ್ಕಿಂತ ಐದು ಪಟ್ಟು ಹೆಚ್ಚು ಡೌನ್‌ಲೋಡ್ ಮಾಡುವಂತೆ ಮಾಡುತ್ತದೆ.
- ಫೋನ್ ಮತ್ತು ಡೆಸ್ಕ್‌ಟಾಪ್‌ಗಾಗಿ ಸ್ಪಂದನಶೀಲ
srcsetಗಾತ್ರಗಳೊಂದಿಗೆ ಪ್ರದರ್ಶಿತ ಗಾತ್ರದಲ್ಲಿ ಚಿತ್ರಗಳನ್ನು ನೀಡಿ. - ಆಧುನಿಕ ಸ್ವರೂಪಗಳು (WebP ಅಥವಾ AVIF) ಮತ್ತು ಸೂಕ್ತ ಸಂಕುಚನ ಬಳಸಿ.
- ಪ್ರತಿ ಚಿತ್ರಕ್ಕೆ
widthಮತ್ತುheightಹೊಂದಿಸಿ, ಬ್ರೌಸರ್ ಸ್ಥಳ ಕಾಯ್ದಿರಿಸುವಂತೆ. ಇದೊಂದೇ ಹೆಚ್ಚಿನ ಲೇಔಟ್ ಜಿಗಿತವನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ. - ಪಟ್ಟಿಗಿಂತ ಕೆಳಗಿನ ಚಿತ್ರಗಳನ್ನು
loading="lazy"ನಿಂದ lazy-load ಮಾಡಿ. - ಪುಟದ ಮೇಲ್ಭಾಗದ ಮುಖ್ಯ ಚಿತ್ರವನ್ನು ಎಂದಿಗೂ lazy-load ಮಾಡಬೇಡಿ. Google ನ LCP ಮಾರ್ಗದರ್ಶನ ಇದರ ಬಗ್ಗೆ ನೇರವಾಗಿದೆ: LCP ಚಿತ್ರವನ್ನು lazy-load ಮಾಡಿದರೆ ಅದು ಯಾವಾಗಲೂ ವಿಳಂಬವಾಗುತ್ತದೆ. ಬದಲಾಗಿ
fetchpriority="high"ನೀಡಿ.
JavaScript
ಅನೇಕ AI-ನಿರ್ಮಿತ ಸೈಟ್‌ಗಳು ಸಿಂಗಲ್-ಪೇಜ್ ಆ್ಯಪ್‌ಗಳು (SPA): ಬ್ರೌಸರ್ JavaScript ಬಂಡಲ್ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ ನಂತರ ಪುಟ ಚಿತ್ರಿಸುತ್ತದೆ. ಬಂಡಲ್ ದೊಡ್ಡದಾದಷ್ಟು ಖಾಲಿ ಪರದೆ ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯುತ್ತದೆ. ಪ್ರಯತ್ನದ ಕ್ರಮದಲ್ಲಿ ಸರಿಪಡಿಸುವಿಕೆಗಳು:
- ಬಳಸದ್ದನ್ನು ತೆಗೆಯಿರಿ. ಅವಲಂಬನೆಗಳ ಪಟ್ಟಿ ಕೇಳಿ, ಒಮ್ಮೆ ಸೇರಿಸಿ ಮರೆತ ಲೈಬ್ರರಿಗಳನ್ನು ಕತ್ತರಿಸಿ — ಒಂದು ದಿನಾಂಕಕ್ಕೆ ದಿನಾಂಕ ಲೈಬ್ರರಿ, ಐದು ಐಕಾನ್‌ಗಳಿಗೆ ಪೂರ್ಣ ಐಕಾನ್ ಪ್ಯಾಕ್.
- ಮಾರ್ಗದ ಪ್ರಕಾರ ವಿಭಜಿಸಿ. ಅಡ್ಮಿನ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಕೋಡ್ ಯಾರಾದರೂ ಅದನ್ನು ತೆರೆದಾಗ ಮಾತ್ರ ಲೋಡ್ ಮಾಡಿ, ಮುಖಪುಟದಲ್ಲಿ ಅಲ್ಲ.
- ಸಾರ್ವಜನಿಕ ಪುಟಗಳನ್ನು ಪ್ರಿರೆಂಡರ್ ಮಾಡಿ. ನಿಜವಾದ HTML ಆಗಿ ಬರುವ ಮಾರುಕಟ್ಟೆ ಪುಟ ಯಾವುದೇ JavaScript ಚಲಿಸುವ ಮೊದಲೇ ಕಾಣಿಸುತ್ತದೆ. ಇದು ಸರ್ಚ್ ಎಂಜಿನ್‌ಗಳಿಗೂ ಸಹಾಯ ಮಾಡುತ್ತದೆ; ನೋಡಿ AI-ನಿರ್ಮಿತ ವೆಬ್‌ಸೈಟ್‌ಗಳಿಗೆ SEO.
ನಿಧಾನ INP ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ದೀರ್ಘ ಕಾರ್ಯ ಪುಟವನ್ನು ತಡೆಯುವುದರಿಂದ ಬರುತ್ತದೆ — ಪ್ರತಿ ಕೀಸ್ಟ್ರೋಕ್‌ಗೆ ದೊಡ್ಡ ಪಟ್ಟಿಯನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುವುದು, ಅಥವಾ ಒಂದು ಸೆಲ್ ಬದಲಾದಾಗ ಸಂಪೂರ್ಣ ಟೇಬಲ್ ಮರುರೆಂಡರ್ ಮಾಡುವುದು. Chrome DevTools ನ Performance ಫಲಕ ಯಾವುದು ಎಂದು ತೋರಿಸುತ್ತದೆ.
ಫಾಂಟ್‌ಗಳು
ಪ್ರತಿ ಫಾಂಟ್ ಕುಟುಂಬ ಮತ್ತು ತೂಕ ಇನ್ನೊಂದು ಫೈಲ್. ಎರಡು ಕುಟುಂಬಗಳು ಮತ್ತು ಮೂರು ಅಥವಾ ನಾಲ್ಕು ತೂಕಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಸಾಕು. ಪಟ್ಟಿಯ ಮೇಲಿನ ಭಾಗದಲ್ಲಿ ಬಳಸುವ ಫಾಂಟ್ ಅನ್ನು ಪ್ರಿಲೋಡ್ ಮಾಡಿ, ಪಠ್ಯ ತಕ್ಷಣ ಕಾಣಲು font-display: swap ಬಳಸಿ, ಮತ್ತು ಬಾಹ್ಯ ಫಾಂಟ್ ಸೇವೆ ನಿಧಾನವಾಗಿದ್ದರೆ ನಿಮ್ಮದೇ ಸರ್ವರ್‌ನಲ್ಲಿ ಫಾಂಟ್‌ಗಳನ್ನು ಇಡಿ.
ಮೂರನೇ ವ್ಯಕ್ತಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು
ಚಾಟ್ ವಿಜೆಟ್‌ಗಳು, ಅನಾಲಿಟಿಕ್ಸ್, ಹೀಟ್‌ಮ್ಯಾಪ್‌ಗಳು, ಜಾಹೀರಾತು ಪಿಕ್ಸೆಲ್‌ಗಳು, ಎಂಬೆಡ್ ಮಾಡಿದ ವೀಡಿಯೊಗಳು ಮತ್ತು ಸಾಮಾಜಿಕ ಫೀಡ್‌ಗಳು ಎಲ್ಲವೂ ಬೇರೆ ಸರ್ವರ್‌ಗಳಿಂದ ಕೋಡ್ ಲೋಡ್ ಮಾಡುತ್ತವೆ. ಪ್ರತಿಯೊಂದೂ ಚಿಕ್ಕದಾಗಿ ಕಾಣುತ್ತದೆ; ಒಟ್ಟಿಗೆ ಅವು ಆಗಾಗ್ಗೆ ಪುಟದ ನಿಧಾನ ಭಾಗ. ನೀವು ನಿಜವಾಗಿ ನೋಡುವವುಗಳನ್ನು ಇಡಿ. ಉಳಿದವನ್ನು ಪುಟ ಸಂವಾದಾತ್ಮಕವಾದ ನಂತರ ಲೋಡ್ ಮಾಡಿ, ಮತ್ತು ಭಾರೀ ಎಂಬೆಡ್‌ಗಳನ್ನು (YouTube ಪ್ಲೇಯರ್, ನಕ್ಷೆ) ಕ್ಲಿಕ್‌ನಲ್ಲಿ ನಿಜವಾದದ್ದನ್ನು ಲೋಡ್ ಮಾಡುವ ಹಗುರ ಪೂರ್ವವೀಕ್ಷಣೆಯೊಂದಿಗೆ ಬದಲಿಸಿ.
ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯೆ
Time to first byte (TTFB) — ಸರ್ವರ್ ಉತ್ತರಿಸಲು ಆರಂಭಿಸಲು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ — ಇತರ ಎಲ್ಲ ಮೆಟ್ರಿಕ್‌ಗಳ ಕೆಳಗೆ ಇರುತ್ತದೆ. CDN (ನಿಮ್ಮ ಸಂದರ್ಶಕರ ಹತ್ತಿರ ಸರ್ವರ್‌ಗಳ ಜಾಲ; ನೋಡಿ CDN ಎಂದರೇನು) ಮೂಲಕ ಸೇವೆಯಾಗುವ ಸ್ಟ್ಯಾಟಿಕ್ ಪುಟಗಳು ಬಹುತೇಕ ಎಲ್ಲೆಡೆ ವೇಗವಾಗಿರುತ್ತವೆ. ಪ್ರತಿ ವಿನಂತಿಯಲ್ಲಿ ಸರ್ವರ್ ನಿರ್ಮಿಸುವ ಪುಟಗಳು ಆ ಸರ್ವರ್ ಮತ್ತು ಅದರ ಡೇಟಾಬೇಸ್ ಮೇಲೆ ಅವಲಂಬಿತ. ಪುನರಾವರ್ತಿತ ಕೆಲಸವನ್ನು ಕ್ಯಾಶ್ ಮಾಡುವುದು ಮತ್ತು ನಿಧಾನ ಪ್ರಶ್ನೆಗಳಿಗೆ ಡೇಟಾಬೇಸ್ ಇಂಡೆಕ್ಸ್‌ಗಳು ಸಾಮಾನ್ಯ ಸರಿಪಡಿಸುವಿಕೆಗಳು.
ಕೆಲಸ ಮಾಡುವ ಪ್ರಾಂಪ್ಟ್‌ಗಳು
ನಿರ್ದಿಷ್ಟವಾಗಿರಿ: ಪುಟ, ಮೆಟ್ರಿಕ್ ಮತ್ತು ನಿರ್ಬಂಧವನ್ನು ಹೆಸರಿಸಿ. ನಿಮ್ಮಲ್ಲಿ PageSpeed Insights ಫಲಿತಾಂಶಗಳಿದ್ದರೆ ಅವನ್ನು ಅಂಟಿಸಿ.
PageSpeed Insights ಮುಖಪುಟಕ್ಕೆ ಮೊಬೈಲ್‌ನಲ್ಲಿ 4.8 ಸೆಕೆಂಡ್ LCP ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು LCP ಅಂಶ ಹೀರೋ ಚಿತ್ರ. ಹೀರೋ ಚಿತ್ರವನ್ನು ಗಾತ್ರ ಬದಲಿಸಿ WebP ಗೆ ಪರಿವರ್ತಿಸಿ, ಸ್ಪಂದನಶೀಲ ಗಾತ್ರಗಳನ್ನು ನೀಡಿ, width ಮತ್ತು height ಹೊಂದಿಸಿ,
fetchpriority="high"ನೀಡಿ ಮತ್ತು lazy-load ಆಗದಂತೆ ಖಚಿತಪಡಿಸಿ. ಪಟ್ಟಿಯ ಕೆಳಗಿನ ಪ್ರತಿ ಚಿತ್ರವನ್ನು lazy-load ಮಾಡಿ. ವಿನ್ಯಾಸ ಬದಲಿಸಬೇಡಿ.
ಈ ಆ್ಯಪ್‌ನ ಅವಲಂಬನೆಗಳನ್ನು ಆಡಿಟ್ ಮಾಡಿ. ಪ್ರತಿ ಪ್ಯಾಕೇಜ್, ಅದನ್ನು ಯಾರು ಬಳಸುತ್ತಾರೆ ಮತ್ತು ಬಂಡಲ್‌ಗೆ ಅಂದಾಜು ಎಷ್ಟು ಸೇರಿಸುತ್ತದೆ ಎಂದು ಪಟ್ಟಿ ಮಾಡಿ. ಬಳಸದವುಗಳನ್ನು ತೆಗೆಯಿರಿ ಮತ್ತು /admin ಮತ್ತು /settings ಮಾರ್ಗಗಳನ್ನು ಭೇಟಿ ನೀಡಿದಾಗ ಮಾತ್ರ ಲೋಡ್ ಆಗುವ ಪ್ರತ್ಯೇಕ ತುಣುಕುಗಳಾಗಿ ವಿಭಜಿಸಿ.
/products ಪುಟದ ಹುಡುಕಾಟ ಪೆಟ್ಟಿಗೆ ನಿಧಾನವೆನಿಸುತ್ತದೆ. ಫಿಲ್ಟರ್ ಅನ್ನು ಡಿಬೌನ್ಸ್ ಮಾಡಿ, ಪ್ರತಿ ಕೀಸ್ಟ್ರೋಕ್‌ನಲ್ಲಿ ಇಡೀ ಪಟ್ಟಿಯನ್ನು ಮರುರೆಂಡರ್ ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸಿ, ಮತ್ತು ಪಟ್ಟಿ 200 ಕ್ಕಿಂತ ಹೆಚ್ಚು ಐಟಂಗಳಿದ್ದರೆ ಪುಟ ಮಾಡಿ ಅಥವಾ ವರ್ಚುವಲೈಸ್ ಮಾಡಿ.
ಹಂತ ಹಂತವಾಗಿ
- ಲೈವ್ ಪುಟವನ್ನು ಪರೀಕ್ಷಿಸಿ ಮೊಬೈಲ್‌ನಲ್ಲಿ PageSpeed Insights ನಲ್ಲಿ. LCP, INP ಮತ್ತು CLS ಮತ್ತು ಪಟ್ಟಿ ಮಾಡಿದ ಮೊದಲ ಮೂರು ಸಮಸ್ಯೆಗಳನ್ನು ಗಮನಿಸಿ.
- ಮೊದಲು ಚಿತ್ರಗಳನ್ನು ಸರಿಪಡಿಸಿ: ಗಾತ್ರ, ಸ್ವರೂಪ, ಆಯಾಮಗಳು, ಪಟ್ಟಿಯ ಕೆಳಗೆ lazy-loading, ಹೀರೋಗೆ ಆದ್ಯತೆ.
- ಬಳಸದ ಮೂರನೇ ವ್ಯಕ್ತಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಕತ್ತರಿಸಿ, ಉಳಿದವನ್ನು ತಡವಾಗಿಸಿ.
- ಫಾಂಟ್‌ಗಳನ್ನು ವಿನ್ಯಾಸಕ್ಕೆ ಬೇಕಾದಷ್ಟಕ್ಕೆ ಕುಗ್ಗಿಸಿ.
- JavaScript ಚಿಕ್ಕದಾಗಿಸಿ: ಬಳಸದ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ತೆಗೆಯಿರಿ, ಪ್ರತಿ ಮಾರ್ಗಕ್ಕೆ ವಿಭಜಿಸಿ.
- ಸಾರ್ವಜನಿಕ ಪುಟಗಳನ್ನು ಪ್ರಿರೆಂಡರ್ ಮಾಡಿ ಅವು ಇನ್ನೂ ಕ್ಲೈಂಟ್-ರೆಂಡರ್ ಆಗಿದ್ದು LCP ಇನ್ನೂ ನಿಧಾನವಾಗಿದ್ದರೆ.
- ಸರ್ವರ್ ಪರಿಶೀಲಿಸಿ: ಕ್ಯಾಶಿಂಗ್, ಡೇಟಾಬೇಸ್ ಇಂಡೆಕ್ಸ್‌ಗಳು, ಅಪರೂಪವಾಗಿ ಬದಲಾಗುವ ವಿಷಯಕ್ಕೆ ಸ್ಟ್ಯಾಟಿಕ್ ಹೋಸ್ಟಿಂಗ್.
- ಮರುಪ್ರಕಟಿಸಿ ಮತ್ತು ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ. PageSpeed Insights ನ ಫೀಲ್ಡ್ ಡೇಟಾ ನಿಜವಾದ ಭೇಟಿಗಳು ಬಂದಂತೆ ಮುಂದಿನ ವಾರಗಳಲ್ಲಿ ನವೀಕರಣಗೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಆರಂಭಿಕ ಫಲಿತಾಂಶಗಳನ್ನು ಲ್ಯಾಬ್ ಡೇಟಾದಿಂದ ನಿರ್ಣಯಿಸಿ.
ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು
- ವೇಗದ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ಮಾತ್ರ ಪರೀಕ್ಷಿಸುವುದು. ನಿಮ್ಮ ಸಂದರ್ಶಕರು ಮಧ್ಯಮ ಶ್ರೇಣಿಯ ಫೋನ್‌ಗಳು ಮತ್ತು ಅಸ್ಥಿರ ಮೊಬೈಲ್ ಡೇಟಾದಲ್ಲಿದ್ದಾರೆ. ಮೊಬೈಲ್ ಮೋಡ್‌ನಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ.
- ಪರಿಪೂರ್ಣ 100 ಬೆನ್ನು ಹತ್ತುವುದು. ಲ್ಯಾಬ್ ಸ್ಕೋರ್ ಒಂದು ಮಾರ್ಗದರ್ಶಿ. Core Web Vitals ಉತ್ತಮ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಬಂದ ನಂತರ, ವಿಷಯ ಮತ್ತು ಬಳಕೆ ಸುಲಭತೆ ಕೊನೆಯ ಕೆಲವು ಅಂಕಗಳಿಗಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯ.
- ಎಲ್ಲವನ್ನೂ lazy-load ಮಾಡುವುದು, ಹೀರೋ ಚಿತ್ರ ಸೇರಿದಂತೆ. ಅದು LCP ಅನ್ನು ಇನ್ನಷ್ಟು ಹದಗೆಡಿಸುತ್ತದೆ.
- ಮೇಲೆ ವೇಗ ಪ್ಲಗಿನ್ ಅಥವಾ ಲೈಬ್ರರಿ ಸೇರಿಸುವುದು. ತೂಕ ತೆಗೆಯುವುದು ಅದನ್ನು ನಿರ್ವಹಿಸಲು ಕೋಡ್ ಸೇರಿಸುವುದಕ್ಕಿಂತ ಬಹುತೇಕ ಯಾವಾಗಲೂ ಉತ್ತಮ.
- ಪ್ರಿವ್ಯೂ ಅನ್ನು ಉತ್ತಮಗೊಳಿಸುವುದು, ಲೈವ್ ಸೈಟ್ ಅಲ್ಲ. ಅಭಿವೃದ್ಧಿ ಪ್ರಿವ್ಯೂಗಳು ಆಪ್ಟಿಮೈಸ್ ಆಗದ ಬಿಲ್ಡ್‌ಗಳನ್ನು ನಡೆಸುತ್ತವೆ. ಪ್ರಕಟವಾದ URL ಅನ್ನು ಅಳೆಯಿರಿ.
- ವೇಗವನ್ನು ಒಮ್ಮೆ ಸರಿಪಡಿಸುವುದು. ಪ್ರತಿ ಹೊಸ ವಿಜೆಟ್, ಚಿತ್ರ ಮತ್ತು ವೈಶಿಷ್ಟ್ಯ ತೂಕ ಸೇರಿಸುತ್ತದೆ. ದೊಡ್ಡ ಬದಲಾವಣೆಗಳ ನಂತರ ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ.
ವೇಗ ಪರಿಶೀಲನಾಪಟ್ಟಿ
- ಮೊಬೈಲ್‌ನಲ್ಲಿ LCP ≤ 2.5 ಸೆ, INP ≤ 200 ms, CLS ≤ 0.1
- ಚಿತ್ರಗಳು ಗಾತ್ರ ಬದಲಿಸಿ, ಸಂಕುಚಿಸಿ, ಆಧುನಿಕ ಸ್ವರೂಪದಲ್ಲಿ, width ಮತ್ತು height ಸಹಿತ
- ಹೀರೋ ಚಿತ್ರ lazy ಅಲ್ಲ; ಪಟ್ಟಿಯ ಕೆಳಗಿನ ಚಿತ್ರಗಳು lazy
- ಬಳಸದ JavaScript ಲೈಬ್ರರಿಗಳಿಲ್ಲ; ಭಾರೀ ಮಾರ್ಗಗಳು ವಿಭಜಿತ
- ಎರಡು ಫಾಂಟ್ ಕುಟುಂಬಗಳು ಅಥವಾ ಕಡಿಮೆ; ಮುಖ್ಯ ಫಾಂಟ್ ಪ್ರಿಲೋಡ್
- ನೀವು ನಿಜವಾಗಿ ಬಳಸುವ ಮೂರನೇ ವ್ಯಕ್ತಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಮಾತ್ರ, ತಡವಾಗಿ ಲೋಡ್
- ಸಾರ್ವಜನಿಕ ಪುಟಗಳು ಸಾಧ್ಯವಿರುವಲ್ಲಿ ಪ್ರಿರೆಂಡರ್ ಅಥವಾ ಸ್ಟ್ಯಾಟಿಕ್
- ಪ್ರಕಟಿಸಿದ ನಂತರ ಲೈವ್ URL ನಲ್ಲಿ ಮರುಪರೀಕ್ಷಿಸಲಾಗಿದೆ
ವೇಗ ಮತ್ತು ಮೊಬೈಲ್ ಲೇಔಟ್ ಒಟ್ಟಿಗೆ ಹೋಗುತ್ತವೆ; ನೋಡಿ ವೆಬ್‌ಸೈಟ್ ಮೊಬೈಲ್ ಸ್ಪಂದನಶೀಲವಾಗಿಸುವುದು ಹೇಗೆ. ಪೂರ್ಣ ಪ್ರಾರಂಭ-ಪೂರ್ವ ಪಾಸ್‌ಗೆ, AI ಪ್ರೋಟೋಟೈಪ್ ಅನ್ನು ಉತ್ಪಾದನೆಗೆ ತರುವುದು ಹೇಗೆ ಉಳಿದದ್ದನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ.
Mythex ನಲ್ಲಿ ವೇಗ
Mythex ನಲ್ಲಿ ಈ ಬದಲಾವಣೆಗಳನ್ನು ನೀವು ಚಾಟ್‌ನಲ್ಲಿ ಕೇಳಿ ಮಾಡುತ್ತೀರಿ, ಅಥವಾ Pro ನಲ್ಲಿ ಕೋಡ್ ಎಡಿಟರ್‌ನಲ್ಲಿ. Preview ಅಭಿವೃದ್ಧಿ ಸರ್ವರ್ ನಡೆಸುವುದರಿಂದ, ಪ್ರಕಟವಾದ URL ಅನ್ನು ಪರಿಶೀಲಿಸಿ, Preview ಅನ್ನು ಅಲ್ಲ. ಸ್ಟ್ಯಾಟಿಕ್ ಫ್ರಂಟ್ ಎಂಡ್‌ಗಳು ಪ್ರಕಟಿಸಿದಾಗ ಸ್ಟ್ಯಾಟಿಕ್ ಸೈಟ್‌ಗಳಾಗಿ ನಿಯೋಜನೆಯಾಗುತ್ತವೆ (ಸ್ಟ್ಯಾಟಿಕ್ ವೆಬ್‌ಸೈಟ್‌ಗಳು), ಇದು ವಿಷಯ ಪುಟಗಳಿಗೆ ಸೂಕ್ತ. ಸರ್ವರ್ ಹೊಂದಿರುವ ಆ್ಯಪ್‌ಗಳು ಶೂನ್ಯಕ್ಕೆ ಇಳಿಯುತ್ತವೆ: ನಿಷ್ಕ್ರಿಯವಾಗಿದ್ದಾಗ ನಿದ್ರಿಸಿ ಮುಂದಿನ ಭೇಟಿಯಲ್ಲಿ ಎಚ್ಚರಗೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಶಾಂತ ಅವಧಿಯ ನಂತರದ ಮೊದಲ ವಿನಂತಿ ನಿಧಾನವಾಗಿರುತ್ತದೆ, ಮತ್ತು ಲಗತ್ತಿಸಿದ ಡೇಟಾಬೇಸ್ 5 ನಿಷ್ಕ್ರಿಯ ನಿಮಿಷಗಳ ನಂತರ ನಿದ್ರಿಸುತ್ತದೆ (ಹೋಸ್ಟಿಂಗ್ ಮಿತಿಗಳು). ಸಾರ್ವಜನಿಕ ಪುಟ ಮೊದಲ ಭೇಟಿಯಲ್ಲಿ ಮಾತ್ರ ನಿಧಾನವಾದರೆ, ಇದೇ ಸಾಧ್ಯತೆ ಕಾರಣ. ಮಾರ್ಕೆಟಿಂಗ್ ಪುಟಗಳನ್ನು ಸ್ಟ್ಯಾಟಿಕ್ ಆಗಿಡುವುದು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಬದಲಾವಣೆಗಳ ನಂತರ, ಮತ್ತೆ ಪ್ರಕಟಿಸಿ ಮತ್ತು ಹಾರ್ಡ್-ರಿಫ್ರೆಶ್ ಮಾಡಿ.
ಪ್ರಶ್ನೆಗಳು
ಉತ್ತಮ ಪುಟ ಲೋಡ್ ಸಮಯ ಎಷ್ಟು?
Google ನ Core Web Vitals ಸ್ಪಷ್ಟ ಗುರಿಗಳನ್ನು ನೀಡುತ್ತವೆ: ಮುಖ್ಯ ವಿಷಯ 2.5 ಸೆಕೆಂಡ್‌ಗಳಲ್ಲಿ ಕಾಣಿಸಬೇಕು (LCP), ಪುಟವು ಇನ್‌ಪುಟ್‌ಗೆ 200 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕು (INP), ಮತ್ತು ಲೇಔಟ್ ಬದಲಾವಣೆ 0.1 ಅಥವಾ ಕಡಿಮೆ ಇರಬೇಕು (CLS) — ನಿಜವಾದ ಭೇಟಿಗಳ 75ನೇ ಪರ್ಸೆಂಟೈಲ್‌ನಲ್ಲಿ ಅಳೆಯಲಾಗಿದೆ.
ವೆಬ್‌ಸೈಟ್ ವೇಗ SEO ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆಯೇ?
ಸ್ವಲ್ಪ ಹೌದು. Google ಕೋರ್ ವೆಬ್ ವೈಟಲ್ಸ್ ಸೇರಿದಂತೆ ಪುಟ ಅನುಭವ ಸಂಕೇತಗಳನ್ನು ಬಳಸುತ್ತದೆ, ಆದರೆ ಸಂಬಂಧಿತ ವಿಷಯ ಹೆಚ್ಚು ಮುಖ್ಯ. ವೇಗ ಸಂದರ್ಶಕರ ಮೇಲೆ ಹೆಚ್ಚು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ, ಏಕೆಂದರೆ ನಿಧಾನ ಪುಟಗಳನ್ನು ಅವರು ಓದುವ ಮೊದಲೇ ಬಿಟ್ಟುಹೋಗುತ್ತಾರೆ.
ನನ್ನ PageSpeed Insights ಸ್ಕೋರ್ ಪ್ರತಿ ಬಾರಿ ಏಕೆ ಬೇರೆಯಾಗಿರುತ್ತದೆ?
ಲ್ಯಾಬ್ ಸ್ಕೋರ್ ಒಂದೇ ಸಿಮ್ಯುಲೇಟೆಡ್ ಲೋಡ್‌ನಿಂದ ಬರುತ್ತದೆ, ಆದ್ದರಿಂದ ನೆಟ್‌ವರ್ಕ್ ಮತ್ತು ಸರ್ವರ್ ಸಮಯ ಪ್ರತಿ ಓಟದಲ್ಲಿ ಬದಲಾಗುತ್ತದೆ. ಹಲವು ಬಾರಿ ಓಡಿಸಿ ಪ್ರವೃತ್ತಿ ನೋಡಿ, ಮತ್ತು ನಿಜವಾದ Chrome ಬಳಕೆದಾರರಿಂದ ಬರುವ ಫೀಲ್ಡ್ ಡೇಟಾ ವಿಭಾಗಕ್ಕೆ ಹೆಚ್ಚು ತೂಕ ನೀಡಿ.
ಹೆಚ್ಚಿನ ವೆಬ್‌ಸೈಟ್‌ಗಳನ್ನು ಯಾವುದು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ?
ಸಾಮಾನ್ಯವಾಗಿ ಬಹಳ ದೊಡ್ಡ ಚಿತ್ರಗಳು, ತುಂಬಾ JavaScript, ವೆಬ್ ಫಾಂಟ್‌ಗಳು ಮತ್ತು ಚಾಟ್ ವಿಜೆಟ್‌ಗಳು, ಜಾಹೀರಾತು ಪಿಕ್ಸೆಲ್‌ಗಳು ಮತ್ತು ಎಂಬೆಡ್‌ಗಳಂತಹ ಮೂರನೇ ವ್ಯಕ್ತಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು. ನಿಧಾನ ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯೆ ಅಥವಾ ತಣ್ಣಗೆ ಆರಂಭವಾಗುವ ಬ್ಯಾಕ್‌ಎಂಡ್ ಇವೆಲ್ಲದಕ್ಕೂ ಸೇರುತ್ತದೆ.