కేవలం గడియారం దాటి: వెబ్ పర్ఫార్మెన్స్ 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) { // 200ms కంటే ఎక్కువ సమయం తీసుకున్న వనరులను కనుగొనండి console.log(`నెమ్మది వనరు: ${resource.name}, వ్యవధి: ${resource.duration}ms`); } });

కీలకమైన ప్రాపర్టీలలో name (వనరు యొక్క URL), initiatorType (వనరు లోడ్ కావడానికి కారణం, ఉదా., 'img', 'script'), మరియు duration (దాన్ని ఫెచ్ చేయడానికి పట్టిన మొత్తం సమయం) ఉన్నాయి.

యూజర్ టైమింగ్ API: మీ అప్లికేషన్ యొక్క లాజిక్‌ను కొలవడం

కొన్నిసార్లు, పనితీరు అడ్డంకి ఆస్తులను లోడ్ చేయడంలో కాకుండా క్లయింట్-సైడ్ కోడ్‌లోనే ఉంటుంది. API నుండి డేటా స్వీకరించబడిన తర్వాత మీ సింగిల్-పేజ్ అప్లికేషన్ (SPA) ఒక సంక్లిష్ట భాగాన్ని రెండర్ చేయడానికి ఎంత సమయం పడుతుంది? యూజర్ టైమింగ్ API మిమ్మల్ని కస్టమ్, అప్లికేషన్-నిర్దిష్ట కొలతలను సృష్టించడానికి అనుమతిస్తుంది.

ఇది రెండు ప్రధాన పద్ధతులతో పనిచేస్తుంది:

• performance.mark(name): పెర్ఫార్మెన్స్ బఫర్‌లో పేరున్న టైమ్‌స్టాంప్‌ను సృష్టిస్తుంది.
• performance.measure(name, startMark, endMark): రెండు మార్కుల మధ్య వ్యవధిని లెక్కిస్తుంది మరియు పేరున్న కొలతను సృష్టిస్తుంది.

ఉదాహరణ: ఒక ఉత్పత్తి జాబితా కాంపోనెంట్ యొక్క రెండర్ సమయాన్ని కొలవడం.

// మీరు డేటాను ఫెచ్ చేయడం ప్రారంభించినప్పుడు performance.mark('product-list-fetch-start'); fetch('/api/products') .then(response => response.json()) .then(data => { // ఫెచింగ్ తర్వాత, రెండరింగ్ ముందు performance.mark('product-list-render-start'); renderProductList(data); // రెండరింగ్ పూర్తయిన వెంటనే performance.mark('product-list-render-end'); // ఒక కొలతను సృష్టించండి performance.measure( 'Product List Render Time', 'product-list-render-start', 'product-list-render-end' ); });

వినియోగదారు యొక్క వర్క్‌ఫ్లోకు అత్యంత క్లిష్టమైన మీ అప్లికేషన్ భాగాలను కొలవడానికి ఇది మీకు ఖచ్చితమైన నియంత్రణను ఇస్తుంది.

PerformanceObserver: ఆధునిక, సమర్థవంతమైన విధానం

`performance.getEntriesByType()`ని నిరంతరం పోల్ చేయడం అసమర్థమైనది. `PerformanceObserver` API పెర్ఫార్మెన్స్ ఎంట్రీలను వినడానికి చాలా మంచి మార్గాన్ని అందిస్తుంది. మీరు నిర్దిష్ట ఎంట్రీ రకాలకు సబ్‌స్క్రైబ్ చేస్తారు మరియు బ్రౌజర్ వాటిని రికార్డ్ చేసినప్పుడు మీ కాల్‌బ్యాక్ ఫంక్షన్‌కు అసమకాలికంగా తెలియజేస్తుంది. మీ అప్లికేషన్‌కు ఓవర్‌హెడ్ జోడించకుండా పెర్ఫార్మెన్స్ డేటాను సేకరించడానికి ఇది సిఫార్సు చేయబడిన మార్గం.

const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { console.log(`ఎంట్రీ రకం: ${entry.entryType}, పేరు: ${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 సమయాన్ని దాని భాగస్వామ్య భాగాలుగా విభజించాలి.

1. టైమ్ టు ఫస్ట్ బైట్ (TTFB): సర్వర్ ప్రతిస్పందించడానికి నెమ్మదిగా ఉందా? నావిగేషన్ టైమింగ్ APIని ఉపయోగించండి. `responseStart - requestStart` వ్యవధి మీకు ఖచ్చితమైన TTFBని ఇస్తుంది. ఇది ఎక్కువగా ఉంటే, సమస్య మీ బ్యాకెండ్, సర్వర్ కాన్ఫిగరేషన్ లేదా డేటాబేస్‌లో ఉంది, ఫ్రంటెండ్‌లో కాదు.
2. వనరు లోడ్ ఆలస్యం & సమయం: LCP ఎలిమెంట్ స్వయంగా లోడ్ అవ్వడానికి నెమ్మదిగా ఉందా? మొదట, LCP ఎలిమెంట్‌ను గుర్తించండి (ఉదా., ఒక హీరో ఇమేజ్). మీరు ఎలిమెంట్‌ను పొందడానికి `'largest-contentful-paint'` కోసం ఒక `PerformanceObserver`ను ఉపయోగించవచ్చు. ఆ తర్వాత, ఆ ఎలిమెంట్ URL కోసం ఎంట్రీని కనుగొనడానికి రిసోర్స్ టైమింగ్ APIని ఉపయోగించండి. దాని టైమ్‌లైన్‌ను విశ్లేషించండి: సుదీర్ఘ `connectStart` నుండి `connectEnd` (నెమ్మది నెట్‌వర్క్) ఉందా? `responseStart` నుండి `responseEnd` సుదీర్ఘంగా ఉందా (ఒక పెద్ద ఫైల్ సైజ్)? దాని `fetchStart` ఆలస్యం అయ్యిందా ఎందుకంటే అది CSS లేదా జావాస్క్రిప్ట్ వంటి ఇతర రెండర్-బ్లాకింగ్ వనరులచే బ్లాక్ చేయబడిందా?
3. ఎలిమెంట్ రెండర్ ఆలస్యం: ఇది వనరు లోడ్ అవ్వడం పూర్తయిన తర్వాత స్క్రీన్‌పై వాస్తవంగా పెయింట్ అయ్యే వరకు పట్టే సమయం. ఇది మెయిన్ థ్రెడ్ ఇతర పనులతో బిజీగా ఉండటం వల్ల కావచ్చు, ఉదాహరణకు ఒక పెద్ద జావాస్క్రిప్ట్ బండిల్‌ను ఎగ్జిక్యూట్ చేయడం.

నావిగేషన్ మరియు రిసోర్స్ టైమింగ్‌ను ఉపయోగించడం ద్వారా, నెమ్మదిగా ఉన్న LCPకి కారణం నెమ్మదిగా ఉన్న సర్వర్, రెండర్-బ్లాకింగ్ స్క్రిప్ట్ లేదా ఒక భారీ, ఆప్టిమైజ్ చేయని ఇమేజ్ అని మీరు ఖచ్చితంగా గుర్తించవచ్చు.

పేలవమైన INPని పరిశోధించడం

మీ వినియోగదారులు "Add to Cart" బటన్‌ను క్లిక్ చేయడం లాగీగా అనిపిస్తుందని ఫిర్యాదు చేస్తున్నారు. మీ INP మెట్రిక్ "పేలవమైనది" పరిధిలో ఉంది. ఇది దాదాపు ఎల్లప్పుడూ మెయిన్ థ్రెడ్ సమస్య.

1. లాంగ్ టాస్క్‌లను గుర్తించండి: లాంగ్ టాస్క్స్ API మీ ప్రాథమిక సాధనం. ఇది మెయిన్ థ్రెడ్‌లో 50ms కంటే ఎక్కువ సమయం తీసుకునే ఏ టాస్క్‌ను అయినా నివేదిస్తుంది, ఎందుకంటే అంతకంటే ఎక్కువ సమయం వినియోగదారుకు గుర్తించదగిన ఆలస్యం కలిగించే ప్రమాదం ఉంది. `'longtask'` ఎంట్రీల కోసం వినడానికి ఒక `PerformanceObserver`ను సెటప్ చేయండి.
2. వినియోగదారు చర్యలతో సహసంబంధం: ఒక లాంగ్ టాస్క్ వినియోగదారు ఇంటరాక్ట్ అవ్వడానికి ప్రయత్నిస్తున్నప్పుడు సంభవిస్తేనే సమస్య. మీరు ఒక INP ఈవెంట్ యొక్క `startTime`ని ( `'event'` రకంపై `PerformanceObserver` ద్వారా గమనించబడింది) అదే సమయంలో సంభవించిన ఏవైనా లాంగ్ టాస్క్‌ల సమయాలతో సహసంబంధం చేయవచ్చు. ఇది మీ వినియోగదారు ఇంటరాక్షన్‌ను ఏ జావాస్క్రిప్ట్ ఫంక్షన్ బ్లాక్ చేసిందో ఖచ్చితంగా చెబుతుంది.
3. నిర్దిష్ట హ్యాండ్లర్లను కొలవండి: మరింత సూక్ష్మంగా ఉండటానికి యూజర్ టైమింగ్ APIని ఉపయోగించండి. మీ క్లిష్టమైన ఈవెంట్ హ్యాండ్లర్లను (ఉదా., "Add to Cart" కోసం 'click' హ్యాండ్లర్) `performance.mark()` మరియు `performance.measure()`తో చుట్టండి. ఇది మీ స్వంత కోడ్ అమలు చేయడానికి ఎంత సమయం తీసుకుంటుందో మరియు అది లాంగ్ టాస్క్‌కు మూలమా కాదా అని ఖచ్చితంగా చెబుతుంది.

అధిక CLSని ఎదుర్కోవడం

వినియోగదారులు వారి మొబైల్ పరికరాలలో ఒక కథనాన్ని చదువుతున్నప్పుడు టెక్స్ట్ అటూ ఇటూ దూకుతుందని నివేదిస్తున్నారు. మీ CLS స్కోర్ 0.3.

1. లేఅవుట్ షిఫ్ట్‌లను గమనించండి: `'layout-shift'` ఎంట్రీల కోసం వినడానికి ఒక `PerformanceObserver`ను ఉపయోగించండి. ప్రతి ఎంట్రీకి ఒక `value` (CLS స్కోర్‌కు దాని సహకారం) మరియు `sources` యొక్క జాబితా ఉంటుంది, ఇవి కదిలిన DOM ఎలిమెంట్లు. ఇది *ఏమి* కదిలిందో మీకు చెబుతుంది.
2. అపరాధి వనరును కనుగొనండి: తదుపరి ప్రశ్న *ఎందుకు* కదిలింది. ఒక సాధారణ కారణం ఒక వనరు ఆలస్యంగా లోడ్ అవ్వడం మరియు ఇతర కంటెంట్‌ను క్రిందికి నెట్టడం. మీరు ఒక `layout-shift` ఎంట్రీ యొక్క `startTime`ని రిసోర్స్ టైమింగ్ API నుండి ఎంట్రీల `responseEnd` సమయంతో సహసంబంధం చేయవచ్చు. ఒక యాడ్ స్క్రిప్ట్ లేదా ఒక పెద్ద ఇమేజ్ లోడ్ అవ్వడం పూర్తయిన వెంటనే ఒక లేఅవుట్ షిఫ్ట్ జరిగితే, మీరు మీ అపరాధిని కనుగొన్నట్లే.
3. ముందస్తు పరిష్కారాలు: పరిష్కారం తరచుగా చిత్రాలు మరియు ప్రకటనల కోసం కొలతలు (``) అందించడం లేదా డైనమిక్ కంటెంట్ లోడ్ అవ్వడానికి ముందు పేజీలో స్థలాన్ని రిజర్వ్ చేయడం వంటివి కలిగి ఉంటుంది. మీరు ఏ వనరుల గురించి చురుకుగా ఉండాలో గుర్తించడానికి రిసోర్స్ టైమింగ్ మీకు సహాయపడుతుంది.

ప్రాక్టికల్ ఇంప్లిమెంటేషన్: గ్లోబల్ మానిటరింగ్ సిస్టమ్‌ను నిర్మించడం

ఈ 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') { // ఇది INP లెక్కింపు యొక్క సరళీకృత వీక్షణ const duration = entry.duration; if (duration > (collectedMetrics.inp || 0)) { collectedMetrics.inp = duration; } } // ... మరియు '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); } });

గ్లోబల్ వ్యూ యొక్క ప్రాముఖ్యత

Lighthouse వంటి ల్యాబ్ టెస్టింగ్ సాధనాలు అమూల్యమైనవి, కానీ అవి నియంత్రిత వాతావరణంలో నడుస్తాయి. ఈ APIల నుండి సేకరించిన RUM డేటా వివిధ దేశాలు, నెట్‌వర్క్ పరిస్థితులు మరియు పరికరాలలో మీ వినియోగదారులు అనుభవించే వాస్తవాన్ని మీకు చెబుతుంది.

మీ డేటాను విశ్లేషించేటప్పుడు, దానిని ఎల్లప్పుడూ విభజించండి. మీరు కనుగొనవచ్చు:

• ఉత్తర అమెరికాలోని వినియోగదారులకు మీ LCP అద్భుతంగా ఉంది, కానీ ఆస్ట్రేలియాలోని వినియోగదారులకు పేలవంగా ఉంది ఎందుకంటే మీ ప్రాథమిక ఇమేజ్ సర్వర్ USలో ఉంది.
• మీ JavaScript వారి కోసం చాలా CPU-ఇంటెన్సివ్ అయినందున, అభివృద్ధి చెందుతున్న మార్కెట్లలో ప్రసిద్ధి చెందిన మధ్య-శ్రేణి ఆండ్రాయిడ్ పరికరాలలో మీ INP ఎక్కువగా ఉంది.
• మీ CLS కేవలం నిర్దిష్ట స్క్రీన్ పరిమాణాలలో మాత్రమే సమస్య, ఇక్కడ ఒక CSS మీడియా క్వెరీ ఒక ప్రకటనను సరిగ్గా పునఃపరిమాణం చేయడానికి కారణమవుతుంది.

ఈ స్థాయి విభజించబడిన అంతర్దృష్టి మీ వాస్తవ వినియోగదారు బేస్‌పై అత్యంత ముఖ్యమైన ప్రభావాన్ని చూపే ఆప్టిమైజేషన్‌లకు ప్రాధాన్యత ఇవ్వడానికి మిమ్మల్ని అనుమతిస్తుంది, వారు ఎక్కడ ఉన్నా.

ముగింపు: కొలత నుండి నైపుణ్యం వరకు

వెబ్ పనితీరు ప్రపంచం పరిపక్వం చెందింది. మనం సాధారణ సాంకేతిక సమయాల నుండి వినియోగదారు గ్రహించిన అనుభవం యొక్క అధునాతన అవగాహనకు మారాము. ఈ ప్రయాణంలో మూడు కీలక దశలు ఉన్నాయి:

1. అనుభవాన్ని కొలవండి: కోర్ వెబ్ వైటల్స్ (LCP, INP, CLS) సేకరించడానికి `PerformanceObserver`ను ఉపయోగించండి. ఇది *ఏమి* జరుగుతోందో మరియు వినియోగదారుకు *ఎలా అనిపిస్తుందో* చెబుతుంది.
2. కారణాన్ని నిర్ధారించండి: లోతుగా తవ్వడానికి పునాది టైమింగ్ APIలను (నావిగేషన్, రిసోర్స్, యూజర్, లాంగ్ టాస్క్స్) ఉపయోగించండి. ఇది అనుభవం *ఎందుకు* పేలవంగా ఉందో చెబుతుంది.
3. ఖచ్చితత్వంతో చర్య తీసుకోండి: నిర్దిష్ట వినియోగదారు విభాగాల కోసం సమస్య యొక్క మూల కారణాన్ని పరిష్కరించే సమాచారంతో కూడిన, లక్ష్య ఆప్టిమైజేషన్‌లను చేయడానికి మిళిత డేటాను ఉపయోగించండి.

అధిక-స్థాయి వినియోగదారు మెట్రిక్‌లు మరియు తక్కువ-స్థాయి డయాగ్నస్టిక్ APIలు రెండింటిలోనూ నైపుణ్యం సాధించడం ద్వారా, మీరు ఒక సమగ్ర పనితీరు వ్యూహాన్ని నిర్మించవచ్చు. మీరు ఊహించడం మానేసి, సాంకేతికంగా వేగంగా ఉండటమే కాకుండా, ప్రపంచంలోని ప్రతిచోటా, ప్రతి పరికరంలో, ప్రతి వినియోగదారుకు వేగంగా, ప్రతిస్పందనగా మరియు ఆనందంగా అనిపించే వెబ్ అనుభవాన్ని ఇంజనీరింగ్ చేయడం ప్రారంభిస్తారు.