ವೆಬ್ ಪರ್ಫಾರ್ಮೆನ್ಸ್ APIಗಳ ಆಳವಾದ ನೋಟ, ಸಾಂಪ್ರದಾಯಿಕ ಟೈಮಿಂಗ್ ಮಾಪನಗಳಿಂದ ಹಿಡಿದು ಕೋರ್ ವೆಬ್ ವೈಟಲ್ಸ್‌ನಂತಹ ಆಧುನಿಕ ಬಳಕೆದಾರ-ಕೇಂದ್ರಿತ ಮೆಟ್ರಿಕ್‌ಗಳವರೆಗೆ, ಮತ್ತು ಸಮಗ್ರ ಕಾರ್ಯಕ್ಷಮತೆಯ ದೃಷ್ಟಿಕೋನಕ್ಕಾಗಿ ಅವುಗಳನ್ನು ಹೇಗೆ ಸಂಪರ್ಕಿಸುವುದು.
ಕೇವಲ ಸಮಯದಾಚೆ: ವೆಬ್ ಪರ್ಫಾರ್ಮೆನ್ಸ್ APIಗಳನ್ನು ನೈಜ ಬಳಕೆದಾರರ ಅನುಭವಕ್ಕೆ ಜೋಡಿಸುವುದು
ಡಿಜಿಟಲ್ ಆರ್ಥಿಕತೆಯಲ್ಲಿ, ವೇಗ ಕೇವಲ ಒಂದು ವೈಶಿಷ್ಟ್ಯವಲ್ಲ; ಇದು ಬಳಕೆದಾರರ ಅನುಭವದ ಅಡಿಪಾಯವಾಗಿದೆ. ನಿಧಾನವಾದ ವೆಬ್‌ಸೈಟ್ ನಿರಾಶೆಗೊಂಡ ಬಳಕೆದಾರರಿಗೆ, ಹೆಚ್ಚಿನ ಬೌನ್ಸ್ ದರಗಳಿಗೆ ಮತ್ತು ಆದಾಯದ ಮೇಲೆ ನೇರ ಪರಿಣಾಮಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು. ವರ್ಷಗಳಿಂದ, ಡೆವಲಪರ್‌ಗಳು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅಳೆಯಲು window.onload ನಂತಹ ಟೈಮಿಂಗ್ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಿದ್ದಾರೆ. ಆದರೆ ವೇಗದ ಲೋಡ್ ಸಮಯವು ನಿಜವಾಗಿಯೂ ಸಂತೋಷದಾಯಕ ಬಳಕೆದಾರರಿಗೆ ಸಮಾನವೇ? ಉತ್ತರವು ಸಾಮಾನ್ಯವಾಗಿ ಇಲ್ಲ.
ಒಂದು ಪುಟವು ತನ್ನ ಎಲ್ಲಾ ತಾಂತ್ರಿಕ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಒಂದು ಸೆಕೆಂಡಿಗಿಂತ ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಲೋಡ್ ಮಾಡುವುದನ್ನು ಮುಗಿಸಬಹುದು, ಆದರೂ ಅದರೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ನಿಜವಾದ ವ್ಯಕ್ತಿಗೆ ಅದು ನಿಧಾನ ಮತ್ತು ನಿಷ್ಪ್ರಯೋಜಕವೆಂದು ಅನಿಸಬಹುದು. ಈ ಅಂತರವು ವೆಬ್ ಡೆವಲಪ್ಮೆಂಟ್‌ನಲ್ಲಿ ಒಂದು ನಿರ್ಣಾಯಕ ವಿಕಾಸವನ್ನು ಎತ್ತಿ ತೋರಿಸುತ್ತದೆ: ತಾಂತ್ರಿಕ ಸಮಯವನ್ನು ಅಳೆಯುವುದರಿಂದ ಮಾನವ ಅನುಭವವನ್ನು ಅಳೆಯುವತ್ತ ಸಾಗುವುದು. ಆಧುನಿಕ ವೆಬ್ ಕಾರ್ಯಕ್ಷಮತೆಯು ಎರಡು ದೃಷ್ಟಿಕೋನಗಳ ಕಥೆಯಾಗಿದೆ: ವೆಬ್ ಪರ್ಫಾರ್ಮೆನ್ಸ್ APIಗಳಿಂದ ಒದಗಿಸಲಾದ ಸೂಕ್ಷ್ಮ, ಕೆಳಮಟ್ಟದ ಡೇಟಾ ಮತ್ತು ಗೂಗಲ್‌ನ ಕೋರ್ ವೆಬ್ ವೈಟಲ್ಸ್‌ನಂತಹ ಉನ್ನತ ಮಟ್ಟದ, ಬಳಕೆದಾರ-ಕೇಂದ್ರಿತ ಮೆಟ್ರಿಕ್‌ಗಳು.
ಈ ಸಮಗ್ರ ಮಾರ್ಗದರ್ಶಿ ಆ ಅಂತರವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ನಮ್ಮ ರೋಗನಿರ್ಣಯದ ಸಾಧನಗಳಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ವೆಬ್ ಪರ್ಫಾರ್ಮೆನ್ಸ್ APIಗಳ ಶಕ್ತಿಯುತ ಸೂಟ್ ಅನ್ನು ನಾವು ಅನ್ವೇಷಿಸುತ್ತೇವೆ. ನಂತರ, ಕಾರ್ಯಕ್ಷಮತೆ *ಹೇಗೆ* ಅನಿಸುತ್ತದೆ ಎಂದು ನಮಗೆ ತಿಳಿಸುವ ಆಧುನಿಕ ಬಳಕೆದಾರರ ಅನುಭವದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ಎಲ್ಲಕ್ಕಿಂತ ಮುಖ್ಯವಾಗಿ, ನಿಮ್ಮ ಜಾಗತಿಕ ಪ್ರೇಕ್ಷಕರಿಗೆ ಕಳಪೆ ಬಳಕೆದಾರರ ಅನುಭವದ ಮೂಲ ಕಾರಣಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಮತ್ತು ಸರಿಪಡಿಸಲು ಕೆಳಮಟ್ಟದ ಟೈಮಿಂಗ್ ಡೇಟಾವನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಎಂಬುದನ್ನು ತೋರಿಸುವ ಮೂಲಕ ನಾವು ಎಲ್ಲವನ್ನೂ ಜೋಡಿಸುತ್ತೇವೆ.
ಅಡಿಪಾಯ: ವೆಬ್ ಪರ್ಫಾರ್ಮೆನ್ಸ್ APIಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು
ವೆಬ್ ಪರ್ಫಾರ್ಮೆನ್ಸ್ APIಗಳು ಪ್ರಮಾಣಿತ ಬ್ರೌಸರ್ ಇಂಟರ್ಫೇಸ್‌ಗಳ ಒಂದು ಗುಂಪಾಗಿದ್ದು, ವೆಬ್ ಪುಟದ ನ್ಯಾವಿಗೇಷನ್ ಮತ್ತು ರೆಂಡರಿಂಗ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಅತ್ಯಂತ ವಿವರವಾದ ಮತ್ತು ನಿಖರವಾದ ಟೈಮಿಂಗ್ ಡೇಟಾಗೆ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನೀಡುತ್ತದೆ. ಅವು ಕಾರ್ಯಕ್ಷಮತೆಯ ಮಾಪನದ ಮೂಲಾಧಾರವಾಗಿದ್ದು, ಸರಳವಾದ ಸ್ಟಾಪ್‌ವಾಚ್‌ಗಳನ್ನು ಮೀರಿ ನೆಟ್‌ವರ್ಕ್ ವಿನಂತಿಗಳು, ಪಾರ್ಸಿಂಗ್ ಮತ್ತು ರೆಂಡರಿಂಗ್‌ನ ಸಂಕೀರ್ಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತವೆ.
ನ್ಯಾವಿಗೇಷನ್ ಟೈಮಿಂಗ್ API: ಪುಟದ ಪ್ರಯಾಣ
ನ್ಯಾವಿಗೇಷನ್ ಟೈಮಿಂಗ್ API ಮುಖ್ಯ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಲೋಡ್ ಮಾಡಲು ತೆಗೆದುಕೊಳ್ಳುವ ಸಮಯದ ವಿವರವಾದ ವಿಭಜನೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಬಳಕೆದಾರರು ನ್ಯಾವಿಗೇಷನ್ ಪ್ರಾರಂಭಿಸಿದ ಕ್ಷಣದಿಂದ (ಲಿಂಕ್ ಕ್ಲಿಕ್ ಮಾಡುವಂತಹ) ಪುಟವು ಸಂಪೂರ್ಣವಾಗಿ ಲೋಡ್ ಆಗುವ ಕ್ಷಣದವರೆಗಿನ ಮೈಲಿಗಲ್ಲುಗಳನ್ನು ಇದು ಸೆರೆಹಿಡಿಯುತ್ತದೆ. ಪುಟ ಲೋಡ್ ಪ್ರಕ್ರಿಯೆಯ ಬಗ್ಗೆ ಇದು ನಮ್ಮ ಮೊದಲ ಮತ್ತು ಅತ್ಯಂತ ಮೂಲಭೂತ ದೃಷ್ಟಿಕೋನವಾಗಿದೆ.
ನೀವು ಸರಳ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಕರೆಯೊಂದಿಗೆ ಈ ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸಬಹುದು:
const navigationEntry = performance.getEntriesByType('navigation')[0];
console.log(navigationEntry.toJSON());
ಇದು ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳಿಂದ ತುಂಬಿದ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಕೆಲವು ಪ್ರಮುಖ ಪ್ರಾಪರ್ಟಿಗಳು ಇಲ್ಲಿವೆ:
- fetchStart: ಬ್ರೌಸರ್ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಪಡೆಯಲು ಪ್ರಾರಂಭಿಸಿದಾಗ.
- responseStart: ಬ್ರೌಸರ್ ಸರ್ವರ್‌ನಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯ ಮೊದಲ ಬೈಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ.
fetchStartಮತ್ತುresponseStartನಡುವಿನ ಸಮಯವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಟೈಮ್ ಟು ಫಸ್ಟ್ ಬೈಟ್ (TTFB) ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. - domContentLoadedEventEnd: ಆರಂಭಿಕ HTML ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಪಾರ್ಸ್ ಮಾಡಿದಾಗ, ಸ್ಟೈಲ್‌ಶೀಟ್‌ಗಳು, ಚಿತ್ರಗಳು ಮತ್ತು ಸಬ್‌ಫ್ರೇಮ್‌ಗಳು ಲೋಡ್ ಆಗುವುದನ್ನು ಕಾಯದೆ.
- loadEventEnd: ಪುಟದ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳು (ಚಿತ್ರಗಳು, CSS, ಇತ್ಯಾದಿ ಸೇರಿದಂತೆ) ಸಂಪೂರ್ಣವಾಗಿ ಲೋಡ್ ಆದಾಗ.
ಬಹಳ ಕಾಲ, loadEventEnd ಚಿನ್ನದ ಗುಣಮಟ್ಟವಾಗಿತ್ತು. ಆದಾಗ್ಯೂ, ಅದರ ಮಿತಿಯು ತೀವ್ರವಾಗಿದೆ: ಬಳಕೆದಾರರು ಅರ್ಥಪೂರ್ಣ ವಿಷಯವನ್ನು *ನೋಡಿದಾಗ* ಅಥವಾ ಪುಟದೊಂದಿಗೆ *ಸಂವಹನ* ನಡೆಸಲು ಸಾಧ್ಯವಾದಾಗ ಎಂಬುದರ ಬಗ್ಗೆ ಇದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಇದು ತಾಂತ್ರಿಕ ಮೈಲಿಗಲ್ಲು, ಮಾನವನದ್ದಲ್ಲ.
ರಿಸೋರ್ಸ್ ಟೈಮಿಂಗ್ API: ಘಟಕಗಳನ್ನು ವಿಭಜಿಸುವುದು
ವೆಬ್ ಪುಟವು ಅಪರೂಪವಾಗಿ ಒಂದೇ ಫೈಲ್ ಆಗಿರುತ್ತದೆ. ಇದು HTML, CSS, ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್, ಚಿತ್ರಗಳು, ಫಾಂಟ್‌ಗಳು ಮತ್ತು API ಕರೆಗಳ ಒಂದು ಸಂಯೋಜನೆಯಾಗಿದೆ. ರಿಸೋರ್ಸ್ ಟೈಮಿಂಗ್ API ನಿಮಗೆ ಈ ಪ್ರತಿಯೊಂದು ಪ್ರತ್ಯೇಕ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ನೆಟ್‌ವರ್ಕ್ ಟೈಮಿಂಗ್ ಅನ್ನು ಪರಿಶೀಲಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.
ಅಡಚಣೆಗಳನ್ನು ಗುರುತಿಸಲು ಇದು ನಂಬಲಾಗದಷ್ಟು ಶಕ್ತಿಯುತವಾಗಿದೆ. ಇನ್ನೊಂದು ಖಂಡದಲ್ಲಿರುವ ಕಂಟೆಂಟ್ ಡೆಲಿವರಿ ನೆಟ್‌ವರ್ಕ್ (CDN) ನಿಂದ ಬಂದ ದೊಡ್ಡ, ಆಪ್ಟಿಮೈಸ್ ಮಾಡದ ಹೀರೋ ಚಿತ್ರವು ಆರಂಭಿಕ ರೆಂಡರ್ ಅನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತಿದೆಯೇ? ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಅನಾಲಿಟಿಕ್ಸ್ ಸ್ಕ್ರಿಪ್ಟ್ ಮುಖ್ಯ ಥ್ರೆಡ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತಿದೆಯೇ? ಈ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಲು ರಿಸೋರ್ಸ್ ಟೈಮಿಂಗ್ ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ನೀವು ಈ ರೀತಿ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳ ಪಟ್ಟಿಯನ್ನು ಪಡೆಯಬಹುದು:
const resourceEntries = performance.getEntriesByType('resource');
resourceEntries.forEach(resource => {
if (resource.duration > 200) { // Find resources that took longer than 200ms
console.log(`Slow resource: ${resource.name}, Duration: ${resource.duration}ms`);
}
});
ಪ್ರಮುಖ ಪ್ರಾಪರ್ಟಿಗಳಲ್ಲಿ name (ಸಂಪನ್ಮೂಲದ URL), initiatorType (ಸಂಪನ್ಮೂಲವನ್ನು ಲೋಡ್ ಮಾಡಲು ಕಾರಣವಾದುದು, ಉದಾಹರಣೆಗೆ, 'img', 'script'), ಮತ್ತು duration (ಅದನ್ನು ಪಡೆಯಲು ತೆಗೆದುಕೊಂಡ ಒಟ್ಟು ಸಮಯ) ಸೇರಿವೆ.
ಯೂಸರ್ ಟೈಮಿಂಗ್ API: ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಲಾಜಿಕ್ ಅನ್ನು ಅಳೆಯುವುದು
ಕೆಲವೊಮ್ಮೆ, ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಡಚಣೆ ಆಸ್ತಿಗಳನ್ನು ಲೋಡ್ ಮಾಡುವುದರಲ್ಲಿರುವುದಿಲ್ಲ, ಬದಲಿಗೆ ಕ್ಲೈಂಟ್-ಸೈಡ್ ಕೋಡ್‌ನಲ್ಲಿಯೇ ಇರುತ್ತದೆ. API ನಿಂದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ ನಿಮ್ಮ ಸಿಂಗಲ್-ಪೇಜ್ ಅಪ್ಲಿಕೇಶನ್ (SPA) ಒಂದು ಸಂಕೀರ್ಣ ಘಟಕವನ್ನು ರೆಂಡರ್ ಮಾಡಲು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ? ಯೂಸರ್ ಟೈಮಿಂಗ್ API ನಿಮಗೆ ಕಸ್ಟಮ್, ಅಪ್ಲಿಕೇಶನ್-ನಿರ್ದಿಷ್ಟ ಮಾಪನಗಳನ್ನು ರಚಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.
ಇದು ಎರಡು ಮುಖ್ಯ ವಿಧಾನಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ:
- performance.mark(name): ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಬಫರ್‌ನಲ್ಲಿ ಹೆಸರಿನ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ.
- performance.measure(name, startMark, endMark): ಎರಡು ಮಾರ್ಕ್‌ಗಳ ನಡುವಿನ ಅವಧಿಯನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ ಮತ್ತು ಹೆಸರಿನ ಮಾಪನವನ್ನು ರಚಿಸುತ್ತದೆ.
ಉದಾಹರಣೆ: ಉತ್ಪನ್ನ ಪಟ್ಟಿ ಘಟಕದ ರೆಂಡರ್ ಸಮಯವನ್ನು ಅಳೆಯುವುದು.
// When you start fetching data
performance.mark('product-list-fetch-start');
fetch('/api/products')
.then(response => response.json())
.then(data => {
// After fetching, before rendering
performance.mark('product-list-render-start');
renderProductList(data);
// Immediately after rendering is complete
performance.mark('product-list-render-end');
// Create a measure
performance.measure(
'Product List Render Time',
'product-list-render-start',
'product-list-render-end'
);
});
ಇದು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಯಾವ ಭಾಗಗಳು ಬಳಕೆದಾರರ ವರ್ಕ್‌ಫ್ಲೋಗೆ ಅತ್ಯಂತ ನಿರ್ಣಾಯಕವಾಗಿವೆ ಎಂಬುದನ್ನು ಅಳೆಯಲು ನಿಖರವಾದ ನಿಯಂತ್ರಣವನ್ನು ನೀಡುತ್ತದೆ.
ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಅಬ್ಸರ್ವರ್: ಆಧುನಿಕ, ದಕ್ಷ ವಿಧಾನ
ನಿರಂತರವಾಗಿ `performance.getEntriesByType()` ಅನ್ನು ಪೋಲ್ ಮಾಡುವುದು ಅಸಮರ್ಥವಾಗಿದೆ. `PerformanceObserver` API ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಎಂಟ್ರಿಗಳನ್ನು ಕೇಳಲು ಉತ್ತಮ ಮಾರ್ಗವನ್ನು ಒದಗಿಸುತ್ತದೆ. ನೀವು ನಿರ್ದಿಷ್ಟ ಎಂಟ್ರಿ ಪ್ರಕಾರಗಳಿಗೆ ಚಂದಾದಾರರಾಗುತ್ತೀರಿ, ಮತ್ತು ಅವುಗಳು ರೆಕಾರ್ಡ್ ಆದಂತೆ ಬ್ರೌಸರ್ ನಿಮ್ಮ ಕಾಲ್‌ಬ್ಯಾಕ್ ಫಂಕ್ಷನ್‌ಗೆ ಅಸಮಕಾಲಿಕವಾಗಿ ಸೂಚಿಸುತ್ತದೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಹೆಚ್ಚುವರಿ ಹೊರೆ ಸೇರಿಸದೆ ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಇದು ಶಿಫಾರಸು ಮಾಡಲಾದ ಮಾರ್ಗವಾಗಿದೆ.
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.log(`Entry Type: ${entry.entryType}, Name: ${entry.name}`);
}
});
observer.observe({ entryTypes: ['resource', 'navigation', 'mark', 'measure'] });
ಈ ಅಬ್ಸರ್ವರ್ ಕೇವಲ ಮೇಲಿನ ಸಾಂಪ್ರದಾಯಿಕ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ನಾವು ಮುಂದೆ ಚರ್ಚಿಸಲಿರುವ ಆಧುನಿಕ, ಬಳಕೆದಾರ-ಕೇಂದ್ರಿತ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಪ್ರಮುಖವಾಗಿದೆ.
ಬಳಕೆದಾರ-ಕೇಂದ್ರಿತತೆಗೆ ಬದಲಾವಣೆ: ಕೋರ್ ವೆಬ್ ವೈಟಲ್ಸ್
ಒಂದು ಪುಟವು 2 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಲೋಡ್ ಆಗಿದೆ ಎಂದು ತಿಳಿಯುವುದು ಉಪಯುಕ್ತ, ಆದರೆ ಇದು ನಿರ್ಣಾಯಕ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುವುದಿಲ್ಲ: ಆ 2 ಸೆಕೆಂಡುಗಳ ಕಾಲ ಬಳಕೆದಾರರು ಖಾಲಿ ಪರದೆಯನ್ನು ನೋಡುತ್ತಿದ್ದರೇ? ಅವರು ಪುಟದೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಬಹುದೇ, ಅಥವಾ ಅದು ಫ್ರೀಜ್ ಆಗಿತ್ತೇ? ಅವರು ಓದಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದಾಗ ವಿಷಯವು ಅನಿರೀಕ್ಷಿತವಾಗಿ ಅತ್ತಿತ್ತ ಜಿಗಿದಿದೆಯೇ?
ಇದನ್ನು ಪರಿಹರಿಸಲು, ಗೂಗಲ್ ಕೋರ್ ವೆಬ್ ವೈಟಲ್ಸ್ (CWV) ಅನ್ನು ಪರಿಚಯಿಸಿತು, ಇದು ಪುಟದ ನೈಜ-ಪ್ರಪಂಚದ ಬಳಕೆದಾರರ ಅನುಭವವನ್ನು ಮೂರು ಪ್ರಮುಖ ಆಯಾಮಗಳಲ್ಲಿ ಅಳೆಯಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಮೆಟ್ರಿಕ್‌ಗಳ ಗುಂಪಾಗಿದೆ: ಲೋಡಿಂಗ್, ಇಂಟರಾಕ್ಟಿವಿಟಿ, ಮತ್ತು ದೃಶ್ಯ ಸ್ಥಿರತೆ.
ಲಾರ್ಜೆಸ್ಟ್ ಕಂಟೆಂಟ್ಫುಲ್ ಪೇಂಟ್ (LCP): ಗ್ರಹಿಸಿದ ಲೋಡಿಂಗ್ ಅನ್ನು ಅಳೆಯುವುದು
LCP ವ್ಯೂಪೋರ್ಟ್‌ನಲ್ಲಿ ಗೋಚರಿಸುವ ಅತಿದೊಡ್ಡ ಚಿತ್ರ ಅಥವಾ ಪಠ್ಯ ಬ್ಲಾಕ್‌ನ ರೆಂಡರ್ ಸಮಯವನ್ನು ಅಳೆಯುತ್ತದೆ. ಪುಟದ ಮುಖ್ಯ ವಿಷಯವು ಲೋಡ್ ಆಗಿದೆ ಎಂದು ಬಳಕೆದಾರರು ಭಾವಿಸಿದಾಗ ಇದು ಅತ್ಯುತ್ತಮ ಪ್ರಾಕ್ಸಿಯಾಗಿದೆ. ಇದು ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಗೆ ನೇರವಾಗಿ ಉತ್ತರಿಸುತ್ತದೆ: "ಈ ಪುಟವು ಈಗ ಉಪಯುಕ್ತವಾಗಿದೆಯೇ?"
- ಉತ್ತಮ: 2.5 ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಕಡಿಮೆ
- ಸುಧಾರಣೆ ಅಗತ್ಯವಿದೆ: 2.5s ಮತ್ತು 4.0s ನಡುವೆ
- ಕಳಪೆ: 4.0 ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಹೆಚ್ಚು
`loadEventEnd` ಗಿಂತ ಭಿನ್ನವಾಗಿ, LCP ಬಳಕೆದಾರರು ಮೊದಲು ನೋಡುವುದರ ಮೇಲೆ ಗಮನಹರಿಸುತ್ತದೆ, ಇದು ಗ್ರಹಿಸಿದ ಲೋಡ್ ವೇಗದ ಹೆಚ್ಚು ನಿಖರವಾದ ಪ್ರತಿಬಿಂಬವಾಗಿದೆ.
ಇಂಟರಾಕ್ಷನ್ ಟು ನೆಕ್ಸ್ಟ್ ಪೇಂಟ್ (INP): ಪ್ರತಿಕ್ರಿಯಾತ್ಮಕತೆಯನ್ನು ಅಳೆಯುವುದು
INP ಯು ಫಸ್ಟ್ ಇನ್‌ಪುಟ್ ಡಿಲೇ (FID) ಯ ಉತ್ತರಾಧಿಕಾರಿಯಾಗಿದೆ ಮತ್ತು ಮಾರ್ಚ್ 2024 ರಲ್ಲಿ ಅಧಿಕೃತ ಕೋರ್ ವೆಬ್ ವೈಟಲ್ ಆಯಿತು. FID ಕೇವಲ *ಮೊದಲ* ಸಂವಹನದ ವಿಳಂಬವನ್ನು ಅಳೆಯುತ್ತಿದ್ದರೆ, INP ಪುಟದ ಜೀವನಚಕ್ರದುದ್ದಕ್ಕೂ *ಎಲ್ಲಾ* ಬಳಕೆದಾರರ ಸಂವಹನಗಳ (ಕ್ಲಿಕ್‌ಗಳು, ಟ್ಯಾಪ್‌ಗಳು, ಕೀ ಪ್ರೆಸ್‌ಗಳು) ಲೇಟೆನ್ಸಿಯನ್ನು ಅಳೆಯುತ್ತದೆ. ಇದು ಅತಿ ಉದ್ದದ ಸಂವಹನವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಬಳಕೆದಾರರು ಅನುಭವಿಸುವ ಕೆಟ್ಟ ಪ್ರತಿಕ್ರಿಯಾತ್ಮಕತೆಯನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಗುರುತಿಸುತ್ತದೆ.
ಬಳಕೆದಾರರ ಇನ್‌ಪುಟ್‌ನಿಂದ ಮುಂದಿನ ಫ್ರೇಮ್ ಪೇಂಟ್ ಆಗುವವರೆಗಿನ ಸಂಪೂರ್ಣ ಸಮಯವನ್ನು INP ಅಳೆಯುತ್ತದೆ, ಇದು ದೃಶ್ಯ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ. ಇದು ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: "ನಾನು ಈ ಬಟನ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ, ಪುಟವು ತ್ವರಿತವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆಯೇ?"
- ಉತ್ತಮ: 200 ಮಿಲಿಸೆಕೆಂಡುಗಳಿಗಿಂತ ಕಡಿಮೆ
- ಸುಧಾರಣೆ ಅಗತ್ಯವಿದೆ: 200ms ಮತ್ತು 500ms ನಡುವೆ
- ಕಳಪೆ: 500ms ಗಿಂತ ಹೆಚ್ಚು
ಹೆಚ್ಚಿನ INP ಸಾಮಾನ್ಯವಾಗಿ ಕಾರ್ಯನಿರತ ಮುಖ್ಯ ಥ್ರೆಡ್‌ನಿಂದ ಉಂಟಾಗುತ್ತದೆ, ಅಲ್ಲಿ ದೀರ್ಘಕಾಲದ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಕಾರ್ಯಗಳು ಬ್ರೌಸರ್ ಬಳಕೆದಾರರ ಇನ್‌ಪುಟ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ತಡೆಯುತ್ತವೆ.
ಕ್ಯುಮುಲೇಟಿವ್ ಲೇಔಟ್ ಶಿಫ್ಟ್ (CLS): ದೃಶ್ಯ ಸ್ಥಿರತೆಯನ್ನು ಅಳೆಯುವುದು
CLS ಪುಟದ ದೃಶ್ಯ ಸ್ಥಿರತೆಯನ್ನು ಅಳೆಯುತ್ತದೆ. ಲೋಡಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಪರದೆಯ ಮೇಲೆ ವಿಷಯವು ಎಷ್ಟು ಅನಿರೀಕ್ಷಿತವಾಗಿ ಚಲಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಇದು ಅಳೆಯುತ್ತದೆ. ಹೆಚ್ಚಿನ CLS ಸ್ಕೋರ್ ಬಳಕೆದಾರರ ಹತಾಶೆಗೆ ಸಾಮಾನ್ಯ ಕಾರಣವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ ನೀವು ಬಟನ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ಆದರೆ ಅದರ ಮೇಲೆ ಜಾಹೀರಾತು ಲೋಡ್ ಆಗಿ ಬಟನ್ ಅನ್ನು ಕೆಳಗೆ ತಳ್ಳಿ, ನೀವು ಜಾಹೀರಾತನ್ನು ಕ್ಲಿಕ್ ಮಾಡುವಂತೆ ಮಾಡುತ್ತದೆ.
CLS ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: "ಅಂಶಗಳು ಎಲ್ಲೆಡೆ ಜಿಗಿಯದೆ ನಾನು ಈ ಪುಟವನ್ನು ಬಳಸಬಹುದೇ?"
- ಉತ್ತಮ: 0.1 ಕ್ಕಿಂತ ಕಡಿಮೆ
- ಸುಧಾರಣೆ ಅಗತ್ಯವಿದೆ: 0.1 ಮತ್ತು 0.25 ನಡುವೆ
- ಕಳಪೆ: 0.25 ಕ್ಕಿಂತ ಹೆಚ್ಚು
ಹೆಚ್ಚಿನ CLS ನ ಸಾಮಾನ್ಯ ಕಾರಣಗಳಲ್ಲಿ ಆಯಾಮಗಳಿಲ್ಲದ ಚಿತ್ರಗಳು ಅಥವಾ ಐಫ್ರೇಮ್‌ಗಳು, ತಡವಾಗಿ ಲೋಡ್ ಆಗುವ ವೆಬ್ ಫಾಂಟ್‌ಗಳು, ಅಥವಾ ವಿಷಯವನ್ನು ಅದಕ್ಕೆ ಜಾಗವನ್ನು ಮೀಸಲಿಡದೆ ಪುಟಕ್ಕೆ ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಸೇರಿಸುವುದು ಸೇರಿವೆ.
ಅಂತರವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು: ಕಳಪೆ ಬಳಕೆದಾರರ ಅನುಭವವನ್ನು ಪತ್ತೆಹಚ್ಚಲು APIಗಳನ್ನು ಬಳಸುವುದು
ಇಲ್ಲಿ ಎಲ್ಲವೂ ಒಟ್ಟಿಗೆ ಸೇರುತ್ತವೆ. ಕೋರ್ ವೆಬ್ ವೈಟಲ್ಸ್ ಬಳಕೆದಾರರು *ಏನನ್ನು* ಅನುಭವಿಸಿದರು ಎಂದು ಹೇಳುತ್ತದೆ (ಉದಾ., ನಿಧಾನವಾದ LCP). ವೆಬ್ ಪರ್ಫಾರ್ಮೆನ್ಸ್ APIಗಳು ಅದು *ಏಕೆ* ಸಂಭವಿಸಿತು ಎಂದು ಹೇಳುತ್ತವೆ. ಅವುಗಳನ್ನು ಸಂಯೋಜಿಸುವ ಮೂಲಕ, ನಾವು ಕೇವಲ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಗಮನಿಸುವುದರಿಂದ ಅದನ್ನು ಸಕ್ರಿಯವಾಗಿ ಪತ್ತೆಹಚ್ಚುವ ಮತ್ತು ಸರಿಪಡಿಸುವತ್ತ ಪರಿವರ್ತನೆಗೊಳ್ಳುತ್ತೇವೆ.
ನಿಧಾನವಾದ LCP ಅನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು
ನಿಮ್ಮ ರಿಯಲ್ ಯೂಸರ್ ಮಾನಿಟರಿಂಗ್ (RUM) ಸಾಧನವು ನಿರ್ದಿಷ್ಟ ಪ್ರದೇಶದ ಬಳಕೆದಾರರಿಗೆ 4.5 ಸೆಕೆಂಡುಗಳ ಕಳಪೆ LCP ಅನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ನೀವು ಅದನ್ನು ಹೇಗೆ ಸರಿಪಡಿಸುತ್ತೀರಿ? ನೀವು LCP ಸಮಯವನ್ನು ಅದರ ಘಟಕ ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸಬೇಕಾಗುತ್ತದೆ.
- ಟೈಮ್ ಟು ಫಸ್ಟ್ ಬೈಟ್ (TTFB): ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯಿಸಲು ನಿಧಾನವಾಗಿದೆಯೇ? ನ್ಯಾವಿಗೇಷನ್ ಟೈಮಿಂಗ್ API ಬಳಸಿ. `responseStart - requestStart` ಅವಧಿಯು ನಿಮಗೆ ನಿಖರವಾದ TTFB ನೀಡುತ್ತದೆ. ಇದು ಹೆಚ್ಚಾಗಿದ್ದರೆ, ಸಮಸ್ಯೆ ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್, ಸರ್ವರ್ ಕಾನ್ಫಿಗರೇಶನ್, ಅಥವಾ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿದೆ, ಫ್ರಂಟ್‌ಎಂಡ್‌ನಲ್ಲಲ್ಲ.
- ಸಂಪನ್ಮೂಲ ಲೋಡ್ ವಿಳಂಬ ಮತ್ತು ಸಮಯ: LCP ಅಂಶವೇ ಲೋಡ್ ಆಗಲು ನಿಧಾನವಾಗಿದೆಯೇ? ಮೊದಲು, LCP ಅಂಶವನ್ನು ಗುರುತಿಸಿ (ಉದಾ., ಹೀರೋ ಇಮೇಜ್). ಅಂಶವನ್ನು ಪಡೆಯಲು ನೀವು 'largest-contentful-paint' ಗಾಗಿ `PerformanceObserver` ಅನ್ನು ಬಳಸಬಹುದು. ನಂತರ, ಆ ಅಂಶದ URL ಗಾಗಿ ಎಂಟ್ರಿಯನ್ನು ಹುಡುಕಲು ರಿಸೋರ್ಸ್ ಟೈಮಿಂಗ್ API ಬಳಸಿ. ಅದರ ಟೈಮ್‌ಲೈನ್ ಅನ್ನು ವಿಶ್ಲೇಷಿಸಿ: ದೀರ್ಘ `connectStart` ನಿಂದ `connectEnd` ಇತ್ತೇ (ನಿಧಾನ ನೆಟ್‌ವರ್ಕ್)? `responseStart` ನಿಂದ `responseEnd` ದೀರ್ಘವಾಗಿತ್ತೇ (ದೊಡ್ಡ ಫೈಲ್ ಗಾತ್ರ)? CSS ಅಥವಾ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ನಂತಹ ಇತರ ರೆಂಡರ್-ಬ್ಲಾಕಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳಿಂದ ನಿರ್ಬಂಧಿಸಲ್ಪಟ್ಟಿದ್ದರಿಂದ ಅದರ `fetchStart` ವಿಳಂಬವಾಯಿತೇ?
- ಎಲಿಮೆಂಟ್ ರೆಂಡರ್ ಡಿಲೇ: ಸಂಪನ್ಮೂಲ ಲೋಡ್ ಆಗುವುದನ್ನು ಮುಗಿಸಿದ ನಂತರ ಅದು ನಿಜವಾಗಿ ಪರದೆಯ ಮೇಲೆ ಪೇಂಟ್ ಆಗುವವರೆಗಿನ ಸಮಯ ಇದು. ಮುಖ್ಯ ಥ್ರೆಡ್ ದೊಡ್ಡ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಬಂಡಲ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಂತಹ ಇತರ ಕಾರ್ಯಗಳಲ್ಲಿ ನಿರತವಾಗಿರುವುದರಿಂದ ಇದು ಸಂಭವಿಸಬಹುದು.
ನ್ಯಾವಿಗೇಷನ್ ಮತ್ತು ರಿಸೋರ್ಸ್ ಟೈಮಿಂಗ್ ಅನ್ನು ಬಳಸುವ ಮೂಲಕ, ನಿಧಾನವಾದ LCP ನಿಧಾನವಾದ ಸರ್ವರ್, ರೆಂಡರ್-ಬ್ಲಾಕಿಂಗ್ ಸ್ಕ್ರಿಪ್ಟ್, ಅಥವಾ ಬೃಹತ್, ಆಪ್ಟಿಮೈಸ್ ಮಾಡದ ಚಿತ್ರದಿಂದ ಉಂಟಾಗಿದೆಯೇ ಎಂದು ನೀವು ನಿಖರವಾಗಿ ಗುರುತಿಸಬಹುದು.
ಕಳಪೆ INP ಅನ್ನು ತನಿಖೆ ಮಾಡುವುದು
ನಿಮ್ಮ ಬಳಕೆದಾರರು "ಕಾರ್ಟ್‌ಗೆ ಸೇರಿಸಿ" ಬಟನ್ ಕ್ಲಿಕ್ ಮಾಡುವುದು ನಿಧಾನವಾಗಿ ಅನಿಸುತ್ತದೆ ಎಂದು ದೂರುತ್ತಿದ್ದಾರೆ. ನಿಮ್ಮ INP ಮೆಟ್ರಿಕ್ "ಕಳಪೆ" ಶ್ರೇಣಿಯಲ್ಲಿದೆ. ಇದು ಬಹುತೇಕ ಯಾವಾಗಲೂ ಮುಖ್ಯ ಥ್ರೆಡ್ ಸಮಸ್ಯೆಯಾಗಿದೆ.
- ದೀರ್ಘ ಕಾರ್ಯಗಳನ್ನು ಗುರುತಿಸಿ: ಲಾಂಗ್ ಟಾಸ್ಕ್ಸ್ API ಇಲ್ಲಿ ನಿಮ್ಮ ಪ್ರಾಥಮಿಕ ಸಾಧನವಾಗಿದೆ. ಇದು ಮುಖ್ಯ ಥ್ರೆಡ್‌ನಲ್ಲಿ 50ms ಗಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವ ಯಾವುದೇ ಕಾರ್ಯವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಇದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯವು ಬಳಕೆದಾರರಿಗೆ ಗಮನಾರ್ಹ ವಿಳಂಬದ ಅಪಾಯವನ್ನುಂಟುಮಾಡುತ್ತದೆ. 'longtask' ಎಂಟ್ರಿಗಳನ್ನು ಕೇಳಲು `PerformanceObserver` ಅನ್ನು ಹೊಂದಿಸಿ.
- ಬಳಕೆದಾರರ ಕ್ರಿಯೆಗಳೊಂದಿಗೆ ಪರಸ್ಪರ ಸಂಬಂಧಿಸಿ: ಬಳಕೆದಾರರು ಸಂವಹನ ನಡೆಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವಾಗ ದೀರ್ಘ ಕಾರ್ಯ ಸಂಭವಿಸಿದರೆ ಮಾತ್ರ ಅದು ಸಮಸ್ಯೆಯಾಗಿದೆ. ನೀವು INP ಈವೆಂಟ್‌ನ `startTime` ಅನ್ನು ('event' ಪ್ರಕಾರದ ಮೇಲೆ `PerformanceObserver` ಮೂಲಕ ಗಮನಿಸಲಾಗಿದೆ) ಅದೇ ಸಮಯದಲ್ಲಿ ಸಂಭವಿಸಿದ ಯಾವುದೇ ದೀರ್ಘ ಕಾರ್ಯಗಳ ಸಮಯದೊಂದಿಗೆ ಪರಸ್ಪರ ಸಂಬಂಧಿಸಬಹುದು. ಇದು ಬಳಕೆದಾರರ ಸಂವಹನವನ್ನು ಯಾವ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಫಂಕ್ಷನ್ ನಿರ್ಬಂಧಿಸಿದೆ ಎಂದು ನಿಮಗೆ ನಿಖರವಾಗಿ ಹೇಳುತ್ತದೆ.
- ನಿರ್ದಿಷ್ಟ ಹ್ಯಾಂಡ್ಲರ್‌ಗಳನ್ನು ಅಳೆಯಿರಿ: ಇನ್ನೂ ಹೆಚ್ಚು ಸೂಕ್ಷ್ಮವಾಗಿರಲು ಯೂಸರ್ ಟೈಮಿಂಗ್ API ಬಳಸಿ. ನಿಮ್ಮ ನಿರ್ಣಾಯಕ ಈವೆಂಟ್ ಹ್ಯಾಂಡ್ಲರ್‌ಗಳನ್ನು (ಉದಾಹರಣೆಗೆ "ಕಾರ್ಟ್‌ಗೆ ಸೇರಿಸಿ" ಗಾಗಿ 'click' ಹ್ಯಾಂಡ್ಲರ್) `performance.mark()` ಮತ್ತು `performance.measure()` ನೊಂದಿಗೆ ಸುತ್ತುವರಿಯಿರಿ. ಇದು ನಿಮ್ಮ ಸ್ವಂತ ಕೋಡ್ ಕಾರ್ಯಗತಗೊಳ್ಳಲು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತಿದೆ ಮತ್ತು ಅದು ದೀರ್ಘ ಕಾರ್ಯದ ಮೂಲವೇ ಎಂದು ನಿಖರವಾಗಿ ಹೇಳುತ್ತದೆ.
ಹೆಚ್ಚಿನ CLS ಅನ್ನು ನಿಭಾಯಿಸುವುದು
ಬಳಕೆದಾರರು ತಮ್ಮ ಮೊಬೈಲ್ ಸಾಧನಗಳಲ್ಲಿ ಲೇಖನವನ್ನು ಓದುತ್ತಿರುವಾಗ ಪಠ್ಯವು ಅತ್ತಿತ್ತ ಜಿಗಿಯುತ್ತದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತಾರೆ. ನಿಮ್ಮ CLS ಸ್ಕೋರ್ 0.3 ಆಗಿದೆ.
- ಲೇಔಟ್ ಶಿಫ್ಟ್‌ಗಳನ್ನು ಗಮನಿಸಿ: 'layout-shift' ಎಂಟ್ರಿಗಳನ್ನು ಕೇಳಲು `PerformanceObserver` ಬಳಸಿ. ಪ್ರತಿಯೊಂದು ಎಂಟ್ರಿಯು `value` (CLS ಸ್ಕೋರ್‌ಗೆ ಅದರ ಕೊಡುಗೆ) ಮತ್ತು ಚಲಿಸಿದ DOM ಅಂಶಗಳ ಪಟ್ಟಿಯಾದ `sources` ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಇದು *ಏನು* ಚಲಿಸಿತು ಎಂದು ನಿಮಗೆ ಹೇಳುತ್ತದೆ.
- ಅಪರಾಧಿ ಸಂಪನ್ಮೂಲವನ್ನು ಹುಡುಕಿ: ಮುಂದಿನ ಪ್ರಶ್ನೆ *ಏಕೆ* ಅದು ಚಲಿಸಿತು. ಸಾಮಾನ್ಯ ಕಾರಣವೆಂದರೆ ಸಂಪನ್ಮೂಲವು ತಡವಾಗಿ ಲೋಡ್ ಆಗಿ ಇತರ ವಿಷಯವನ್ನು ಕೆಳಗೆ ತಳ್ಳುವುದು. ನೀವು `layout-shift` ಎಂಟ್ರಿಯ `startTime` ಅನ್ನು ರಿಸೋರ್ಸ್ ಟೈಮಿಂಗ್ API ಯಿಂದ ಎಂಟ್ರಿಗಳ `responseEnd` ಸಮಯದೊಂದಿಗೆ ಪರಸ್ಪರ ಸಂಬಂಧಿಸಬಹುದು. ಜಾಹೀರಾತು ಸ್ಕ್ರಿಪ್ಟ್ ಅಥವಾ ದೊಡ್ಡ ಚಿತ್ರವು ಲೋಡ್ ಆಗುವುದನ್ನು ಮುಗಿಸಿದ ತಕ್ಷಣ ಲೇಔಟ್ ಶಿಫ್ಟ್ ಸಂಭವಿಸಿದರೆ, ನೀವು ನಿಮ್ಮ ಅಪರಾಧಿಯನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ.
- ಸಕ್ರಿಯ ಪರಿಹಾರಗಳು: ಪರಿಹಾರವು ಸಾಮಾನ್ಯವಾಗಿ ಚಿತ್ರಗಳು ಮತ್ತು ಜಾಹೀರಾತುಗಳಿಗೆ ಆಯಾಮಗಳನ್ನು ಒದಗಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ (`
`) ಅಥವಾ ಕ್ರಿಯಾತ್ಮಕ ವಿಷಯವು ಲೋಡ್ ಆಗುವ ಮೊದಲು ಪುಟದಲ್ಲಿ ಜಾಗವನ್ನು ಮೀಸಲಿಡುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಯಾವ ಸಂಪನ್ಮೂಲಗಳ ಬಗ್ಗೆ ನೀವು ಪೂರ್ವಭಾವಿಯಾಗಿರಬೇಕು ಎಂಬುದನ್ನು ಗುರುತಿಸಲು ರಿಸೋರ್ಸ್ ಟೈಮಿಂಗ್ ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಪ್ರಾಯೋಗಿಕ ಅನುಷ್ಠಾನ: ಜಾಗತಿಕ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸುವುದು
ಈ APIಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಒಂದು ವಿಷಯ; ನಿಮ್ಮ ಜಾಗತಿಕ ಬಳಕೆದಾರರ ಅನುಭವವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಅವುಗಳನ್ನು ನಿಯೋಜಿಸುವುದು ಮುಂದಿನ ಹಂತವಾಗಿದೆ. ಇದು ರಿಯಲ್ ಯೂಸರ್ ಮಾನಿಟರಿಂಗ್ (RUM) ನ ಕ್ಷೇತ್ರವಾಗಿದೆ.
`PerformanceObserver` ನೊಂದಿಗೆ ಎಲ್ಲವನ್ನೂ ಒಟ್ಟಿಗೆ ಸೇರಿಸುವುದು
ಈ ಎಲ್ಲಾ ನಿರ್ಣಾಯಕ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ನೀವು ಒಂದೇ, ಶಕ್ತಿಯುತ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ರಚಿಸಬಹುದು. ಗುರಿಯು ನೀವು ಅಳೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರದೆ ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಅವುಗಳ ಸಂದರ್ಭವನ್ನು ಸಂಗ್ರಹಿಸುವುದಾಗಿದೆ.
ದೃಢವಾದ ಅಬ್ಸರ್ವರ್ ಸೆಟಪ್‌ನ ಪರಿಕಲ್ಪನಾ ತುಣುಕು ಇಲ್ಲಿದೆ:
const collectedMetrics = {};
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.entryType === 'largest-contentful-paint') {
collectedMetrics.lcp = entry.startTime;
} else if (entry.entryType === 'layout-shift') {
collectedMetrics.cls = (collectedMetrics.cls || 0) + entry.value;
} else if (entry.entryType === 'event') {
// This is a simplified view of INP calculation
const duration = entry.duration;
if (duration > (collectedMetrics.inp || 0)) {
collectedMetrics.inp = duration;
}
}
// ... and so on for other entry types like 'longtask'
}
});
observer.observe({ entryTypes: ['largest-contentful-paint', 'layout-shift', 'event', 'longtask'] });
ಡೇಟಾವನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಕಳುಹಿಸುವುದು
ನೀವು ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿದ ನಂತರ, ಸಂಗ್ರಹಣೆ ಮತ್ತು ವಿಶ್ಲೇಷಣೆಗಾಗಿ ಅದನ್ನು ಅನಾಲಿಟಿಕ್ಸ್ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಕಳುಹಿಸಬೇಕಾಗುತ್ತದೆ. ಪುಟ ಅನ್‌ಲೋಡ್‌ಗಳನ್ನು ವಿಳಂಬಿಸದೆ ಅಥವಾ ತಮ್ಮ ಟ್ಯಾಬ್‌ಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಮುಚ್ಚುವ ಬಳಕೆದಾರರಿಂದ ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳದೆ ಇದನ್ನು ಮಾಡುವುದು ನಿರ್ಣಾಯಕವಾಗಿದೆ.
`navigator.sendBeacon()` API ಇದಕ್ಕಾಗಿ ಪರಿಪೂರ್ಣವಾಗಿದೆ. ಪುಟವು ಅನ್‌ಲೋಡ್ ಆಗುತ್ತಿದ್ದರೂ ಸಹ, ಸರ್ವರ್‌ಗೆ ಸಣ್ಣ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಲು ಇದು ವಿಶ್ವಾಸಾರ್ಹ, ಅಸಮಕಾಲಿಕ ಮಾರ್ಗವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಇದು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನಿರೀಕ್ಷಿಸುವುದಿಲ್ಲ, ಇದು ಹಗುರ ಮತ್ತು ನಿರ್ಬಂಧಿಸದಂತೆ ಮಾಡುತ್ತದೆ.
window.addEventListener('visibilitychange', () => {
if (document.visibilityState === 'hidden') {
const payload = JSON.stringify(collectedMetrics);
navigator.sendBeacon('/api/performance-analytics', payload);
}
});
ಜಾಗತಿಕ ದೃಷ್ಟಿಕೋನದ ಮಹತ್ವ
ಲೈಟ್‌ಹೌಸ್‌ನಂತಹ ಲ್ಯಾಬ್ ಪರೀಕ್ಷಾ ಸಾಧನಗಳು ಅಮೂಲ್ಯವಾಗಿವೆ, ಆದರೆ ಅವು ನಿಯಂತ್ರಿತ ಪರಿಸರದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಈ APIಗಳಿಂದ ಸಂಗ್ರಹಿಸಲಾದ RUM ಡೇಟಾವು ವಿವಿಧ ದೇಶಗಳು, ನೆಟ್‌ವರ್ಕ್ ಪರಿಸ್ಥಿತಿಗಳು ಮತ್ತು ಸಾಧನಗಳಲ್ಲಿ ನಿಮ್ಮ ಬಳಕೆದಾರರು ಅನುಭವಿಸುವ ವಾಸ್ತವ ಸತ್ಯವನ್ನು ನಿಮಗೆ ಹೇಳುತ್ತದೆ.
ನಿಮ್ಮ ಡೇಟಾವನ್ನು ವಿಶ್ಲೇಷಿಸುವಾಗ, ಯಾವಾಗಲೂ ಅದನ್ನು ವಿಭಾಗಿಸಿ. ನೀವು ಹೀಗೆ ಕಂಡುಹಿಡಿಯಬಹುದು:
- ನಿಮ್ಮ LCP ಉತ್ತರ ಅಮೆರಿಕಾದಲ್ಲಿನ ಬಳಕೆದಾರರಿಗೆ ಅತ್ಯುತ್ತಮವಾಗಿದೆ ಆದರೆ ಆಸ್ಟ್ರೇಲಿಯಾದಲ್ಲಿನ ಬಳಕೆದಾರರಿಗೆ ಕಳಪೆಯಾಗಿದೆ ಏಕೆಂದರೆ ನಿಮ್ಮ ಪ್ರಾಥಮಿಕ ಇಮೇಜ್ ಸರ್ವರ್ US ಮೂಲದ್ದಾಗಿದೆ.
- ನಿಮ್ಮ INP ಮಧ್ಯಮ-ಶ್ರೇಣಿಯ ಆಂಡ್ರಾಯ್ಡ್ ಸಾಧನಗಳಲ್ಲಿ ಹೆಚ್ಚಾಗಿದೆ, ಇದು ಉದಯೋನ್ಮುಖ ಮಾರುಕಟ್ಟೆಗಳಲ್ಲಿ ಜನಪ್ರಿಯವಾಗಿದೆ, ಏಕೆಂದರೆ ನಿಮ್ಮ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಅವುಗಳಿಗೆ ತುಂಬಾ CPU-ತೀವ್ರವಾಗಿದೆ.
- ನಿಮ್ಮ CLS ಕೇವಲ ನಿರ್ದಿಷ್ಟ ಪರದೆಯ ಗಾತ್ರಗಳಲ್ಲಿ ಮಾತ್ರ ಸಮಸ್ಯೆಯಾಗಿದೆ, ಅಲ್ಲಿ CSS ಮೀಡಿಯಾ ಪ್ರಶ್ನೆಯು ಜಾಹೀರಾತನ್ನು ತಪ್ಪಾಗಿ ಮರುಗಾತ್ರಗೊಳಿಸಲು ಕಾರಣವಾಗುತ್ತದೆ.
ಈ ಮಟ್ಟದ ವಿಭಾಗಿಸಿದ ಒಳನೋಟವು ನಿಮ್ಮ ನೈಜ ಬಳಕೆದಾರರ ಮೇಲೆ, ಅವರು ಎಲ್ಲೇ ಇರಲಿ, ಅತ್ಯಂತ ಮಹತ್ವದ ಪರಿಣಾಮವನ್ನು ಬೀರುವ ಆಪ್ಟಿಮೈಸೇಷನ್‌ಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ತೀರ್ಮಾನ: ಮಾಪನದಿಂದ ಪಾಂಡಿತ್ಯದವರೆಗೆ
ವೆಬ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಪ್ರಪಂಚವು ಪ್ರಬುದ್ಧವಾಗಿದೆ. ನಾವು ಸರಳ ತಾಂತ್ರಿಕ ಸಮಯಗಳಿಂದ ಬಳಕೆದಾರರ ಗ್ರಹಿಸಿದ ಅನುಭವದ ಅತ್ಯಾಧುನಿಕ ತಿಳುವಳಿಕೆಗೆ ಸಾಗಿದ್ದೇವೆ. ಈ ಪ್ರಯಾಣವು ಮೂರು ಪ್ರಮುಖ ಹಂತಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:
- ಅನುಭವವನ್ನು ಅಳೆಯಿರಿ: ಕೋರ್ ವೆಬ್ ವೈಟಲ್ಸ್ (LCP, INP, CLS) ಅನ್ನು ಸಂಗ್ರಹಿಸಲು `PerformanceObserver` ಬಳಸಿ. ಇದು *ಏನು* ನಡೆಯುತ್ತಿದೆ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ *ಹೇಗೆ ಅನಿಸುತ್ತದೆ* ಎಂದು ಹೇಳುತ್ತದೆ.
- ಕಾರಣವನ್ನು ಪತ್ತೆಹಚ್ಚಿ: ಆಳವಾಗಿ ಅಗೆಯಲು ಮೂಲಭೂತ ಟೈಮಿಂಗ್ APIಗಳನ್ನು (ನ್ಯಾವಿಗೇಷನ್, ರಿಸೋರ್ಸ್, ಯೂಸರ್, ಲಾಂಗ್ ಟಾಸ್ಕ್ಸ್) ಬಳಸಿ. ಇದು ಅನುಭವವು *ಏಕೆ* ಕಳಪೆಯಾಗಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ.
- ನಿಖರತೆಯೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಿ: ನಿರ್ದಿಷ್ಟ ಬಳಕೆದಾರ ವಿಭಾಗಗಳಿಗೆ ಸಮಸ್ಯೆಯ ಮೂಲ ಕಾರಣವನ್ನು ಪರಿಹರಿಸುವ ತಿಳುವಳಿಕೆಯುಳ್ಳ, ಉದ್ದೇಶಿತ ಆಪ್ಟಿಮೈಸೇಷನ್‌ಗಳನ್ನು ಮಾಡಲು ಸಂಯೋಜಿತ ಡೇಟಾವನ್ನು ಬಳಸಿ.
ಉನ್ನತ ಮಟ್ಟದ ಬಳಕೆದಾರರ ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಕೆಳಮಟ್ಟದ ರೋಗನಿರ್ಣಯದ APIಗಳು ಎರಡನ್ನೂ ಕರಗತ ಮಾಡಿಕೊಳ್ಳುವ ಮೂಲಕ, ನೀವು ಸಮಗ್ರ ಕಾರ್ಯಕ್ಷಮತೆಯ ತಂತ್ರವನ್ನು ನಿರ್ಮಿಸಬಹುದು. ನೀವು ಊಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ತಾಂತ್ರಿಕವಾಗಿ ವೇಗವಾಗಿರುವುದಲ್ಲದೆ, ಪ್ರಪಂಚದಾದ್ಯಂತ ಪ್ರತಿಯೊಂದು ಸಾಧನದಲ್ಲಿ, ಪ್ರತಿಯೊಬ್ಬ ಬಳಕೆದಾರರಿಗೆ ವೇಗ, ಸ್ಪಂದನಶೀಲ ಮತ್ತು ಸಂತೋಷಕರವೆಂದು ಅನಿಸುವ ವೆಬ್ ಅನುಭವವನ್ನು ರೂಪಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ.