క్యారెఔసెల్ లోడింగ్‌లో ఫ్రంట్-ఎండ్ మెమరీ వినియోగాన్ని 30 రెట్లు మెరుగుపరచడం

2020 రెండవ త్రైమాసికంలో, మేము ఎక్స్‌పీరియన్స్ పేజీని టెక్ రీఫ్యాక్టర్ చేశాము, దానిని React లోకి తిరిగి వ్రాసి, REST APIని ఉపయోగించాము. కానీ అమలు చేసే సమయంలో, మాకు ఒక ఆసక్తికరమైన సమస్య ఎదురైంది.

ఎక్స్‌పీరియన్స్ పేజీలో సుమారు 20 క్యారస్‌ెల్‌లు ఉన్నాయి, ప్రతిదానిలో కనీసం 60 టైల్స్ ఉంటాయి. కాబట్టి ఆ పేజీ 1,200 కంటే ఎక్కువ ఎక్స్‌పీరియన్స్‌లను రెండర్ చేస్తుంది, వాటి టైటిల్, యూజర్ రేటింగ్, ఏకకాల వినియోగదారులు మరియు థంబ్‌నెయిల్ వంటి సంబంధిత సమాచారంతో సహా. ప్రతి క్యారస్‌ెల్‌లో, కుడి వైపు స్క్రోల్ క్లిక్ చేయడం ద్వారా, మరిన్ని ఎక్స్‌పీరియన్స్‌లు ఉంటే, తదుపరి బ్యాచ్‌ను లోడ్ చేయడానికి ఒక అభ్యర్థన పంపబడుతుంది. ఆ తర్వాత, అభ్యర్థన ఫలితంగా వచ్చిన కొత్త డేటా క్యారస్‌ల్‌కు జోడించబడుతుంది, అంటే DOMలో మరిన్ని నోడ్‌లు జోడించబడతాయి మరియు బ్రౌజర్‌లో మరిన్ని థంబ్‌నెయిల్స్ రెండర్ అవుతాయి. వినియోగదారులు మరింత డేటాను అభ్యర్థించడానికి స్క్రోల్ చేస్తున్నప్పుడు బ్రౌజర్‌లోని మెమరీ వినియోగం పెరుగుతుంది, మరియు ఆ తర్వాత UX నెమ్మదిగా మారి, లాగ్ అవ్వడం ప్రారంభమవుతుంది.

మెమరీ ప్రొఫైల్

ఈ సమస్యను ప్రొఫైల్ చేయడానికి మనం Chrome డెవలపర్ టూల్స్‌ను ఉపయోగించవచ్చు. మొదటి స్నాప్‌షాట్ పేజీ మొదట లోడ్ అయినప్పుడు తీసుకోబడుతుంది, మరియు రెండవది ఒక క్యారస్‌ల్‌లో నెక్స్ట్ స్క్రోల్‌ను వినియోగదారు 12 సార్లు క్లిక్ చేసిన తర్వాత తీసుకోబడుతుంది. 100+ స్ట్రింగ్ నోడ్‌లు మరియు పెరిగిన థంబ్‌నెయిల్ రెండరింగ్ నుండి మెమరీ వినియోగంలో దాదాపు 9.7MB పెరుగుదలను మనం చూస్తాము.

పరిష్కారం

కారోసెల్ స్క్రోల్ చేసినప్పుడు, వినియోగదారులు కారోసెల్ విండో నుండి మాత్రమే అంశాలను చూస్తారు. ఉదాహరణకు, 1920×1080 రిజల్యూషన్ ఉన్న ల్యాప్‌టాప్‌లో, ఫుల్ స్క్రీన్ బ్రౌజర్‌లో, ప్రతిసారీ ~9 అంశాలు మాత్రమే కనిపిస్తాయి. అందువల్ల, కనిపించని అన్ని నోడ్‌లు మరియు థంబ్‌నెయిల్స్‌ను కలిపి రెండర్ చేయడం లేదా అభ్యర్థన నుండి తిరిగి వచ్చిన ఎక్కువ డేటాను DOM లోకి తీసుకువెళ్లడం అనవసరం.

కాబట్టి, ఇక్కడ ఒక ఆలోచన ఉంది: మనం మొదటిసారి API అభ్యర్థన నుండి ముడి డేటాను పొందిన తర్వాత, DOM లోకి రెండరింగ్ చేయడానికి అదే పొడవు గల అరేని నిర్మిస్తాము. రెండరింగ్ అరే లోపల, డిస్‌ప్లేను నింపడానికి మరియు తదుపరికి స్క్రోల్ చేయడానికి సరిపడా డేటాను మాత్రమే నింపగలము. అరేలోని మిగిలిన భాగం, డిస్‌ప్లే విండో దాని దగ్గరకు స్క్రోల్ అయినప్పుడు మాత్రమే నింపబడుతుంది. రెండరింగ్ డేటా పరిధిని రికార్డ్ చేయడానికి రెండు ఇండెక్స్‌లను ఇద్దాం: renderingStartIndex మరియు renderingEndIndex. జాబితాలో ఏ ప్రారంభ స్థానం కనిపిస్తుందో చెప్పడానికి మనం ఒక కర్సర్‌ను ఏర్పాటు చేస్తాము. స్క్రోల్ చేస్తున్నప్పుడు, మనం కనిపించే మొదటి ఐటెమ్ యొక్క ఇండెక్స్‌కు కర్సర్‌ను నిరంతరం అప్‌డేట్ చేయాల్సి ఉంటుంది. స్క్రోలింగ్ యానిమేషన్ పూర్తి కాకముందే, తదుపరి కర్సర్ రెండరింగ్ డేటా అరేలో ఉందో లేదో మనం తనిఖీ చేయాలి. కారుసెల్ విండో పరిమాణం మరియు కార్డ్ పరిమాణం ఆధారంగా, డిస్‌ప్లే విండోలో ఎన్ని కనిపించే అంశాలు సరిపోతాయో మనం సులభంగా చెప్పగలము. ఆ తర్వాత, ప్రస్తుత విండో మరియు తదుపరి విండోలోని అంశాలు రెండరింగ్ డేటా అర్రే పరిధిలో ఉన్నాయని మనం నిర్ధారించుకోవాలి. అలా కాకపోతే, ఖాళీ జాబితాను పూరించడానికి మనం రా డేటా నుండి అంశాలను తీసుకుంటాము, అదే సమయంలో కర్సర్ స్థానం ముందు ఉన్న డేటాను కూడా తొలగిస్తాము. వినియోగదారులు కుడి లేదా ఎడమ వైపుకు స్క్రోల్ చేసినప్పుడు ఇది వర్తిస్తుంది. వినియోగదారులు కుడి వైపుకు స్క్రోల్ చేసినప్పుడు, బ్యాక్‌గ్రౌండ్‌లో మరింత డేటాను పొందడం ద్వారా, కొత్త డేటా అందిన ప్రతిసారీ మనం రా డేటాను పూరిస్తాము. అయితే, రా డేటా పేజ్ రెండరింగ్‌లో భాగంగా ఉండదు.

మెమరీ ప్రొఫైల్

మనం మళ్ళీ Chrome డెవలపర్ టూల్స్‌ను చూద్దాం. మునుపటిలాగే, మొదటి స్నాప్‌షాట్ ఇనిషియలైజ్ చేసిన సమయంలో తీసుకోబడుతుంది మరియు రెండవది 12 సార్లు కుడివైపు స్క్రోల్ చేసిన తర్వాత తీసుకోబడుతుంది. ఇప్పుడు, 100+ ఐటమ్స్‌ను లోడ్ చేయడానికి కేవలం 0.3MB మెమరీ పెరుగుదల మాత్రమే పడుతుంది, మునుపటి 9.7MBతో పోలిస్తే.

తరువాత ఏమిటి?

పెద్ద డేటా విండోలను నిర్వహించడానికి క్యారస్‌ెల్ కాంపోనెంట్‌ను మెరుగుపరచడంతో పాటు, మనం ఒక ఫీచర్/పేజీని రీఫ్యాక్టర్ చేసినప్పుడు, పనితీరు సమాచారాన్ని సేకరించడానికి మనం మరిన్ని బెంచ్‌మార్క్‌లను జోడించాలి.

ఆధునిక వెబ్ అప్లికేషన్ స్టాక్ ఫ్రంట్ ఎండ్‌ వైపు మళ్లుతున్నప్పటికీ, ఫ్రంట్-ఎండ్ టెలిమెట్రీని సంగ్రహించడం మరియు మెరుగుపరచడం అనేది సాంప్రదాయ బ్యాక్-ఎండ్ టెలిమెట్రీ అంత ముఖ్యమైనది.