వెబ్‌సైట్‌లో కొంత జావాస్క్రిప్ట్ కోడ్‌ని ఉపయోగించడం కంటే (పన్ ఉద్దేశించినది) వేగాన్ని తగ్గించడానికి వేగవంతమైన మార్గం లేదు. జావాస్క్రిప్ట్‌ని ఉపయోగిస్తున్నప్పుడు, మీరు నాలుగు సార్లు కంటే తక్కువ కాకుండా ప్రాజెక్ట్‌ల పనితీరుతో దాని కోసం చెల్లించాలి. సైట్ యొక్క JavaScript కోడ్ వినియోగదారుల సిస్టమ్‌లను ఎలా లోడ్ చేస్తుందో ఇక్కడ ఉంది:
- నెట్‌వర్క్ ద్వారా ఫైల్‌ను డౌన్‌లోడ్ చేస్తోంది.
- డౌన్‌లోడ్ చేసిన తర్వాత అన్‌ప్యాక్ చేయబడిన సోర్స్ కోడ్‌ను అన్వయించడం మరియు కంపైల్ చేయడం.
- జావాస్క్రిప్ట్ కోడ్ అమలు.
- మెమరీ వినియోగం.
ఈ కలయిక మారుతుంది .
మరియు మేము మా ప్రాజెక్ట్‌లలో మరింత ఎక్కువ JS కోడ్‌ని చేర్చుతాము. సంస్థలు ఫ్రేమ్‌వర్క్‌లు మరియు రియాక్ట్, వ్యూ మరియు ఇతర లైబ్రరీల ద్వారా ఆధారితమైన సైట్‌ల వైపు వెళుతున్నందున, మేము సైట్‌ల యొక్క ప్రధాన కార్యాచరణను జావాస్క్రిప్ట్‌పై ఎక్కువగా ఆధారపడేలా చేస్తున్నాము.
నేను జావాస్క్రిప్ట్ ఫ్రేమ్‌వర్క్‌లను ఉపయోగించి చాలా భారీ సైట్‌లను చూశాను. కానీ సమస్యపై నా దృష్టి చాలా పక్షపాతంగా ఉంది. వాస్తవం ఏమిటంటే, నేను పనిచేసే కంపెనీలు సైట్ పనితీరు రంగంలో సంక్లిష్ట సమస్యలను ఎదుర్కొంటున్నందున ఖచ్చితంగా నా వైపు మొగ్గు చూపుతాయి. ఫలితంగా, ఈ సమస్య ఎంత సాధారణం అనే దాని గురించి మరియు మేము ఒక నిర్దిష్ట సైట్‌కు ఆధారంగా ఒకటి లేదా మరొక ఫ్రేమ్‌వర్క్‌ని ఎంచుకున్నప్పుడు మనం ఎలాంటి "పెనాల్టీలు" చెల్లిస్తాము అనే దాని గురించి నేను ఆసక్తిగా ఉన్నాను.
దీన్ని గుర్తించడంలో ప్రాజెక్ట్ నాకు సహాయపడింది. .
డేటా
HTTP ఆర్కైవ్ ప్రాజెక్ట్ సాధారణ డెస్క్‌టాప్ సైట్‌లకు మొత్తం 4308655 లింక్‌లను మరియు మొబైల్ సైట్‌లకు 5484239 లింక్‌లను ట్రాక్ చేస్తుంది. ఈ లింక్‌లతో అనుబంధించబడిన అనేక కొలమానాలలో సంబంధిత సైట్‌లలో కనుగొనబడిన సాంకేతికతల జాబితా ఉంది. దీనర్థం మేము వివిధ ఫ్రేమ్‌వర్క్‌లు మరియు లైబ్రరీలను ఉపయోగించే వేలాది సైట్‌లను శాంపిల్ చేయవచ్చు మరియు అవి క్లయింట్‌లకు ఎంత కోడ్‌ను పంపుతాయి మరియు వినియోగదారుల సిస్టమ్‌లపై ఈ కోడ్ ఎంత లోడ్‌ని సృష్టిస్తుంది అనే దాని గురించి తెలుసుకోవచ్చు.
నేను మార్చి 2020 డేటాను సేకరించాను, ఇది నాకు యాక్సెస్ ఉన్న అత్యంత ఇటీవలి డేటా.
నేను ఇతర సోర్స్ మెటీరియల్‌ని కూడా ఉపయోగించాలని భావించినప్పటికీ, రియాక్ట్, వ్యూ మరియు యాంగ్యులర్ ఉపయోగించి కనుగొనబడిన సైట్‌ల డేటాతో అన్ని సైట్‌లలోని సమగ్ర HTTP ఆర్కైవ్ డేటాను సరిపోల్చాలని నిర్ణయించుకున్నాను.
దీన్ని మరింత ఆసక్తికరంగా చేయడానికి, నేను సోర్స్ డేటా సెట్‌కు j క్వెరీని ఉపయోగించే సైట్‌లను కూడా జోడించాను. ఈ లైబ్రరీ ఇప్పటికీ చాలా ప్రజాదరణ పొందింది. ఇది రియాక్ట్, వ్యూ మరియు యాంగ్యులర్ అందించే సింగిల్ పేజ్ అప్లికేషన్ (SPA) మోడల్ కంటే వెబ్ డెవలప్‌మెంట్‌కు భిన్నమైన విధానాన్ని కూడా పరిచయం చేస్తుంది.
HTTP ఆర్కైవ్‌లోని లింక్‌లు ఆసక్తికర సాంకేతికతలను ఉపయోగిస్తున్నట్లు గుర్తించబడిన సైట్‌లను సూచిస్తాయి
ఫ్రేమ్‌వర్క్ లేదా లైబ్రరీ
మొబైల్ సైట్‌లకు లింక్‌లు
సాధారణ సైట్‌లకు లింక్‌లు
j క్వెరీ
4615474
3714643
స్పందించలేదు
489827
241023
వ్యూ
85649
43691
కోణీయ
19423
18088
ఆశలు మరియు కలలు
మేము డేటా విశ్లేషణకు వెళ్లే ముందు, నేను ఏమి ఆశించాలనుకుంటున్నాను అనే దాని గురించి మాట్లాడాలనుకుంటున్నాను.
ఆదర్శవంతమైన ప్రపంచంలో, ఫ్రేమ్‌వర్క్‌లు డెవలపర్‌ల అవసరాలకు మించి ఉండాలని మరియు మా సైట్‌లతో పనిచేసే సగటు వినియోగదారుకు కొంత నిర్దిష్ట ప్రయోజనాన్ని అందించాలని నేను నమ్ముతున్నాను. పనితీరు ఆ ప్రయోజనాలలో ఒకటి. ఇక్కడే ప్రాప్యత మరియు భద్రత అమలులోకి వస్తాయి. కానీ ఇది అతి ముఖ్యమైనది మాత్రమే.
కాబట్టి, ఆదర్శవంతమైన ప్రపంచంలో, ఒక రకమైన ఫ్రేమ్‌వర్క్ అధిక-పనితీరు గల సైట్‌ను సృష్టించడాన్ని సులభతరం చేస్తుంది. ఫ్రేమ్‌వర్క్ డెవలపర్‌కు ప్రాజెక్ట్‌ను నిర్మించడానికి తగిన ఆధారాన్ని అందించడం వల్ల లేదా అభివృద్ధిపై పరిమితులను విధించడం వల్ల, దాని కోసం అవసరాలను ముందుకు తెచ్చడం వల్ల ఏదైనా అభివృద్ధిని క్లిష్టతరం చేస్తుంది. నెమ్మదిగా ఉండాలి.
ఉత్తమ ఫ్రేమ్‌వర్క్‌లు రెండింటినీ చేయాలి: మంచి ఆధారాన్ని ఇవ్వండి మరియు పనిపై పరిమితులను విధించండి, మీరు మంచి ఫలితాన్ని సాధించడానికి అనుమతిస్తుంది.
డేటా యొక్క మధ్యస్థ విలువలను విశ్లేషించడం వల్ల మనకు అవసరమైన సమాచారం అందించబడదు. మరియు, వాస్తవానికి, ఈ విధానం మన దృష్టిని వదిలివేస్తుంది . బదులుగా, నేను నా వద్ద ఉన్న డేటా నుండి శాతాన్ని పొందాను. ఇవి 10, 25, 50 (మధ్యస్థ), 75, 90 శాతాలు.
నాకు ముఖ్యంగా 10వ మరియు 90వ పర్సంటైల్‌లపై ఆసక్తి ఉంది. 10వ పర్సంటైల్ నిర్దిష్ట ఫ్రేమ్‌వర్క్ కోసం చాలా ఉత్తమ పనితీరును సూచిస్తుంది (లేదా ఉత్తమమైన వాటికి కనీసం ఎక్కువ లేదా తక్కువ దగ్గరగా ఉంటుంది). మరో మాటలో చెప్పాలంటే, నిర్దిష్ట ఫ్రేమ్‌వర్క్‌ను ఉపయోగించే సైట్‌లలో కేవలం 10% మాత్రమే ఈ స్థాయికి లేదా అంతకంటే ఎక్కువ స్థాయికి చేరుకుంటాయి. 90వ పర్సంటైల్, మరోవైపు, నాణెం యొక్క మరొక వైపు - ఇది చెడు విషయాలు ఎలా పొందవచ్చో చూపిస్తుంది. 90వ పర్సంటైల్ అనేది వెనుకబడి ఉన్న సైట్లు-అత్యధిక JS కోడ్ లేదా ప్రధాన థ్రెడ్‌లో తమ కోడ్‌ను ప్రాసెస్ చేయడానికి ఎక్కువ సమయం ఉన్న సైట్‌లలో దిగువ 10%.
జావాస్క్రిప్ట్ కోడ్ వాల్యూమ్‌లు
ప్రారంభించడానికి, నెట్‌వర్క్‌లో వివిధ సైట్‌ల ద్వారా ప్రసారం చేయబడిన జావాస్క్రిప్ట్ కోడ్ పరిమాణాన్ని విశ్లేషించడం అర్ధమే.
మొబైల్ పరికరాలకు బదిలీ చేయబడిన JavaScript కోడ్ (Kb) మొత్తం
శాతాలు
10
25
50
75
90
అన్ని సైట్లు
93.4
196.6
413.5
746.8
1201.6
j క్వెరీ సైట్లు
110.3
219.8
430.4
748.6
1162.3
Vue సైట్లు
244.7
409.3
692.1
1065.5
1570.7
కోణీయ సైట్లు
445.1
675.6
1066.4
1761.5
2893.2
రియాక్ట్ సైట్లు
345.8
441.6
690.3
1238.5
1893.6
మొబైల్ పరికరాలకు పంపబడిన JavaScript కోడ్ మొత్తం
JavaScript కోడ్ (Kb) మొత్తం డెస్క్‌టాప్ పరికరాలకు బదిలీ చేయబడింది
శాతాలు
10
25
50
75
90
అన్ని సైట్లు
105.5
226.6
450.4
808.8
1267.3
j క్వెరీ సైట్లు
121.7
242.2
458.3
803.4
1235.3
Vue సైట్లు
248.0
420.1
718.0
1122.5
1643.1
కోణీయ సైట్లు
468.8
716.9
1144.2
1930.0
3283.1
రియాక్ట్ సైట్లు
308.6
469.0
841.9
1472.2
2197.8
డెస్క్‌టాప్ పరికరాలకు పంపబడిన JavaScript కోడ్ మొత్తం
మేము సైట్లు పరికరాలకు పంపే JS కోడ్ పరిమాణం గురించి మాత్రమే మాట్లాడినట్లయితే, మీరు ఊహించిన విధంగా ప్రతిదీ కనిపిస్తుంది. అవి, ఫ్రేమ్‌వర్క్‌లలో ఒకదానిని ఉపయోగించినట్లయితే, ఆదర్శవంతమైన పరిస్థితిలో కూడా, సైట్ యొక్క జావాస్క్రిప్ట్ కోడ్ వాల్యూమ్ పెరుగుతుంది. ఇది ఆశ్చర్యం కలిగించదు - మీరు జావాస్క్రిప్ట్ ఫ్రేమ్‌వర్క్‌ను సైట్‌కు ఆధారం చేయలేరు మరియు ప్రాజెక్ట్ యొక్క JS కోడ్ వాల్యూమ్ చాలా తక్కువగా ఉంటుందని ఆశించవచ్చు.
ఈ డేటా గురించి చెప్పుకోదగ్గ విషయం ఏమిటంటే, కొన్ని ఫ్రేమ్‌వర్క్‌లు మరియు లైబ్రరీలు ఇతర వాటి కంటే ప్రాజెక్ట్‌కి మంచి ప్రారంభ స్థానంగా పరిగణించబడతాయి. j క్వెరీ ఉన్న సైట్లు ఉత్తమంగా కనిపిస్తాయి. సైట్‌ల డెస్క్‌టాప్ వెర్షన్‌లలో, అవి అన్ని సైట్‌ల కంటే 15% ఎక్కువ జావాస్క్రిప్ట్‌ను కలిగి ఉంటాయి మరియు మొబైల్‌లో 18% ఎక్కువ కలిగి ఉంటాయి. (అంగీకరిస్తున్నాము, ఇక్కడ కొంత డేటా అవినీతి ఉంది. వాస్తవం ఏమిటంటే j క్వెరీ చాలా సైట్‌లలో ఉంది, కాబట్టి మొత్తం సైట్‌ల సంఖ్యతో అలాంటి సైట్లు ఇతరులకన్నా ఎక్కువ దగ్గరి అనుబంధాన్ని కలిగి ఉండటం సహజం. అయితే, ఇది ఎంత పచ్చిగా ప్రభావితం చేయదు ప్రతి ఫ్రేమ్‌వర్క్ కోసం డేటా అవుట్‌పుట్.)
కోడ్ వాల్యూమ్‌లో 15-18% పెరుగుదల గుర్తించదగిన వ్యక్తి అయితే, దీనిని ఇతర ఫ్రేమ్‌వర్క్‌లు మరియు లైబ్రరీలతో పోల్చి చూస్తే, j క్వెరీ విధించిన “పన్ను” చాలా తక్కువగా ఉందని నిర్ధారించవచ్చు. 10వ పర్సంటైల్‌లోని కోణీయ సైట్లు అన్ని సైట్‌ల కంటే 344% ఎక్కువ డేటాను డెస్క్‌టాప్‌కు పంపుతాయి మరియు మొబైల్‌కి 377% ఎక్కువ డేటాను పంపుతాయి. రియాక్ట్ సైట్లు అన్ని సైట్‌ల కంటే డెస్క్‌టాప్‌కి 193% ఎక్కువ కోడ్‌ని మరియు మొబైల్‌కి 270% ఎక్కువ కోడ్‌ని పంపడం ద్వారా తదుపరి అత్యంత భారీవి.
ఇంతకుముందు, ఫ్రేమ్‌వర్క్‌ను ఉపయోగించడం అంటే ప్రాజెక్ట్‌లో నిర్దిష్ట మొత్తంలో కోడ్ చేర్చబడుతుందని నేను పేర్కొన్నాను, దానిపై పని ప్రారంభంలోనే, ఫ్రేమ్‌వర్క్ డెవలపర్‌ను ఏదో ఒకవిధంగా పరిమితం చేయగలదని నేను ఆశిస్తున్నాను. ప్రత్యేకించి, మేము గరిష్ట కోడ్ మొత్తాన్ని పరిమితం చేయడం గురించి మాట్లాడుతున్నాము.
ఆసక్తికరంగా, j క్వెరీ సైట్లు ఈ ఆలోచనను అనుసరిస్తాయి. అవి 10వ శాతం (15-18%) వద్ద ఉన్న అన్ని సైట్‌ల కంటే కొంచెం బరువుగా ఉన్నప్పటికీ, డెస్క్‌టాప్ మరియు మొబైల్ రెండింటిలో 90% వద్ద 3వ శాతం వద్ద కొంచెం తేలికగా ఉంటాయి. ఇది చాలా ముఖ్యమైన ప్రయోజనం అని చెప్పలేము, కానీ j క్వెరీ సైట్లు, కనీసం, వాటి అతిపెద్ద సంస్కరణల్లో కూడా భారీ JavaScript కోడ్ పరిమాణాలను కలిగి ఉండవని చెప్పవచ్చు.
కానీ ఇతర ఫ్రేమ్‌వర్క్‌ల గురించి కూడా చెప్పలేము.
10వ పర్సంటైల్ విషయంలో మాదిరిగానే, యాంగ్యులర్ మరియు రియాక్ట్‌లోని 90వ పర్సంటైల్ సైట్లు ఇతర సైట్‌ల నుండి భిన్నంగా ఉంటాయి, కానీ దురదృష్టవశాత్తూ, అధ్వాన్నంగా ఉంటాయి.
90వ శాతం వద్ద, కోణీయ సైట్లు అన్ని సైట్‌ల కంటే మొబైల్‌కు 141% ఎక్కువ డేటాను మరియు డెస్క్‌టాప్‌కు 159% ఎక్కువ డేటాను పంపుతాయి. రియాక్ట్ సైట్లు అన్ని సైట్‌ల కంటే డెస్క్‌టాప్‌కి 73% ఎక్కువ పంపుతాయి మరియు మొబైల్‌కి 58% ఎక్కువ పంపుతాయి. 90వ శాతం వద్ద రియాక్ట్ సైట్‌ల కోడ్ పరిమాణం 2197.8 KB. దీనర్థం అటువంటి సైట్లు Vue ఆధారంగా వారి సమీప పోటీదారుల కంటే మొబైల్ పరికరాలకు 322.9 KB ఎక్కువ డేటాను పంపుతాయి. కోణీయ మరియు రియాక్ట్ మరియు ఇతర సైట్‌ల ఆధారంగా డెస్క్‌టాప్ సైట్‌ల మధ్య అంతరం మరింత పెద్దది. ఉదాహరణకు, డెస్క్‌టాప్ రియాక్ట్ సైట్లు సారూప్య Vue సైట్‌ల కంటే పరికరాలకు 554.7 KB ఎక్కువ JS కోడ్‌ను పంపుతాయి.
ప్రధాన థ్రెడ్‌లో జావాస్క్రిప్ట్ కోడ్‌ని ప్రాసెస్ చేయడానికి పట్టే సమయం
అధ్యయనంలో ఉన్న ఫ్రేమ్‌వర్క్‌లు మరియు లైబ్రరీలను ఉపయోగించే సైట్లు పెద్ద మొత్తంలో JavaScript కోడ్‌ని కలిగి ఉన్నాయని పై డేటా స్పష్టంగా సూచిస్తుంది. అయితే, ఇది మా సమీకరణంలో ఒక భాగం మాత్రమే.
బ్రౌజర్‌లో జావాస్క్రిప్ట్ కోడ్ వచ్చిన తర్వాత, దానిని పని చేయగల స్థితికి తీసుకురావాలి. ప్రధాన బ్రౌజర్ థ్రెడ్‌లోని కోడ్‌తో నిర్వహించాల్సిన చర్యల వల్ల ముఖ్యంగా చాలా సమస్యలు తలెత్తుతాయి. వినియోగదారు చర్యలను ప్రాసెస్ చేయడానికి, శైలులను లెక్కించడానికి, పేజీ లేఅవుట్‌ను రూపొందించడానికి మరియు ప్రదర్శించడానికి ప్రధాన థ్రెడ్ బాధ్యత వహిస్తుంది. మీరు జావాస్క్రిప్ట్ టాస్క్‌లతో ప్రధాన థ్రెడ్‌ను అధిగమించినట్లయితే, మిగిలిన టాస్క్‌లను సకాలంలో పూర్తి చేయడానికి దానికి అవకాశం ఉండదు. ఇది పేజీల పనిలో ఆలస్యం మరియు "బ్రేకులు" దారితీస్తుంది.
HTTP ఆర్కైవ్ డేటాబేస్ V8 ఇంజిన్ యొక్క ప్రధాన థ్రెడ్‌లో జావాస్క్రిప్ట్ కోడ్‌ను ప్రాసెస్ చేయడానికి ఎంత సమయం పడుతుంది అనే దాని గురించి సమాచారాన్ని కలిగి ఉంది. దీని అర్థం మనం ఈ డేటాను సేకరించి, వివిధ సైట్‌ల జావాస్క్రిప్ట్‌ను ప్రాసెస్ చేయడానికి ప్రధాన థ్రెడ్ ఎంత సమయం తీసుకుంటుందో తెలుసుకోవచ్చు.
మొబైల్ పరికరాలలో స్క్రిప్ట్ ప్రాసెసింగ్‌కు సంబంధించిన ప్రాసెసర్ సమయం (మిల్లీసెకన్లలో).
శాతాలు
10
25
50
75
90
అన్ని సైట్లు
356.4
959.7
2372.1
5367.3
10485.8
j క్వెరీ సైట్లు
575.3
1147.4
2555.9
5511.0
10349.4
Vue సైట్లు
1130.0
2087.9
4100.4
7676.1
12849.4
కోణీయ సైట్లు
1471.3
2380.1
4118.6
7450.8
13296.4
రియాక్ట్ సైట్లు
2700.1
5090.3
9287.6
14509.6
20813.3
మొబైల్ పరికరాలలో స్క్రిప్ట్ ప్రాసెసింగ్‌కు సంబంధించిన ప్రాసెసర్ సమయం
డెస్క్‌టాప్ పరికరాలలో స్క్రిప్ట్ ప్రాసెసింగ్‌కు సంబంధించిన CPU సమయం (మిల్లీసెకన్లలో).
శాతాలు
10
25
50
75
90
అన్ని సైట్లు
146.0
351.8
831.0
1739.8
3236.8
j క్వెరీ సైట్లు
199.6
399.2
877.5
1779.9
3215.5
Vue సైట్లు
350.4
650.8
1280.7
2388.5
4010.8
కోణీయ సైట్లు
482.2
777.9
1365.5
2400.6
4171.8
రియాక్ట్ సైట్లు
508.0
1045.6
2121.1
4235.1
7444.3
డెస్క్‌టాప్ పరికరాలలో స్క్రిప్ట్ ప్రాసెసింగ్‌కు సంబంధించిన ప్రాసెసర్ సమయం
ఇక్కడ మీకు బాగా తెలిసిన విషయాన్ని చూడవచ్చు.
స్టార్టర్స్ కోసం, j క్వెరీ ఉన్న సైట్లు ఇతర సైట్‌ల కంటే మెయిన్ థ్రెడ్‌లో జావాస్క్రిప్ట్ ప్రాసెసింగ్‌లో చాలా తక్కువ ఖర్చు చేస్తాయి. 10వ శాతం వద్ద, అన్ని సైట్‌లతో పోలిస్తే, మొబైల్‌లోని j క్వెరీ సైట్లు ప్రధాన థ్రెడ్‌లో JS కోడ్‌ని ప్రాసెస్ చేయడానికి 61% ఎక్కువ సమయాన్ని వెచ్చిస్తాయి. డెస్క్‌టాప్ j క్వెరీ సైట్‌ల విషయంలో, ప్రాసెసింగ్ సమయం 37% పెరుగుతుంది. 90వ శాతం వద్ద, j క్వెరీ సైట్లు మొత్తం స్కోర్‌లకు చాలా దగ్గరగా స్కోర్ చేస్తాయి. ప్రత్యేకించి, మొబైల్ పరికరాల్లోని j క్వెరీ సైట్లు అన్ని సైట్‌ల కంటే మెయిన్ థ్రెడ్‌లో 1.3% తక్కువ సమయాన్ని వెచ్చిస్తాయి మరియు డెస్క్‌టాప్ పరికరాలలో 0.7% తక్కువ సమయాన్ని వెచ్చిస్తాయి.
మా రేటింగ్ యొక్క మరొక వైపు ప్రధాన థ్రెడ్‌లో అత్యధిక లోడ్‌తో వర్గీకరించబడిన ఫ్రేమ్‌వర్క్‌లు ఉన్నాయి. ఇది మళ్లీ కోణీయ మరియు ప్రతిచర్య. రెండింటి మధ్య ఉన్న ఏకైక తేడా ఏమిటంటే, యాంగ్యులర్ సైట్లు రియాక్ట్ సైట్‌ల కంటే బ్రౌజర్‌లకు ఎక్కువ కోడ్‌ను పంపుతుండగా, కోణీయ సైట్లు కోడ్‌ను ప్రాసెస్ చేయడానికి తక్కువ CPU సమయం తీసుకుంటాయి. చాలా తక్కువ.
10వ శాతం వద్ద, డెస్క్‌టాప్ కోణీయ సైట్లు అన్ని సైట్‌ల కంటే ప్రధాన థ్రెడ్ ప్రాసెసింగ్ JS కోడ్‌లో 230% ఎక్కువ సమయాన్ని వెచ్చిస్తాయి. మొబైల్ సైట్‌ల కోసం, ఈ సంఖ్య 313%. రియాక్ట్ సైట్లు చెత్త పనితీరును ప్రదర్శించేవి. డెస్క్‌టాప్‌లో, వారు అన్ని సైట్‌ల కంటే 248% ఎక్కువ ప్రాసెసింగ్ కోడ్‌ను మరియు మొబైల్‌లో 658% ఎక్కువ సమయాన్ని వెచ్చిస్తారు. 658% అక్షర దోషం కాదు. 10వ శాతం వద్ద, రియాక్ట్ సైట్లు తమ కోడ్‌ని ప్రాసెస్ చేయడానికి 2.7 సెకన్ల ప్రధాన థ్రెడ్ సమయాన్ని వెచ్చిస్తాయి.
90వ శాతం, ఈ భారీ సంఖ్యలతో పోల్చినప్పుడు, కనీసం కొంచెం మెరుగ్గా కనిపిస్తోంది. అన్ని సైట్‌లతో పోలిస్తే, కోణీయ ప్రాజెక్ట్‌లు ప్రధాన థ్రెడ్‌లోని డెస్క్‌టాప్ పరికరాలపై 29% ఎక్కువ సమయం మరియు మొబైల్ పరికరాలలో 27% ఎక్కువ సమయాన్ని వెచ్చిస్తాయి. రియాక్ట్ సైట్‌ల విషయంలో, అదే గణాంకాలు వరుసగా 130% మరియు 98% లాగా కనిపిస్తాయి.
90వ పర్సంటైల్‌కి సారూప్య విలువల కంటే 10వ పర్సంటైల్ శాతం విచలనాలు మెరుగ్గా కనిపిస్తాయి. కానీ ఇక్కడ సమయాన్ని సూచించే సంఖ్యలు చాలా భయానకంగా ఉన్నాయని గుర్తుంచుకోవడం విలువ. రియాక్ట్‌తో రూపొందించబడిన వెబ్‌సైట్ కోసం ప్రధాన మొబైల్ థ్రెడ్‌లో 20.8 సెకన్లు అని చెప్పండి. (ఈ సమయంలో అసలు ఏమి జరుగుతుందో కథ ప్రత్యేక కథనానికి అర్హమైనదిగా నేను భావిస్తున్నాను).
ఇక్కడ ఒక సంభావ్య సంక్లిష్టత ఉంది (ధన్యవాదాలు ఈ ఫీచర్‌పై నా దృష్టిని ఆకర్షించినందుకు మరియు ఈ దృక్కోణం నుండి డేటాను జాగ్రత్తగా పరిశీలించినందుకు). వాస్తవం ఏమిటంటే అనేక సైట్లు అనేక ఫ్రంట్-ఎండ్ సాధనాలను ఉపయోగిస్తాయి. ప్రత్యేకించి, రియాక్ట్ లేదా వ్యూతో పాటుగా j క్వెరీని ఉపయోగించడాన్ని నేను చాలా సైట్‌లను చూశాను, ఎందుకంటే ఆ సైట్లు j క్వెరీ నుండి ఇతర ఫ్రేమ్‌వర్క్‌లు లేదా లైబ్రరీలకు మారుతున్నాయి. ఫలితంగా, నేను మళ్లీ డేటాబేస్‌ని కొట్టాను, ఈసారి కేవలం రియాక్ట్, j క్వెరీ, యాంగ్యులర్ లేదా వ్యూని ఉపయోగించే సైట్‌లకు సంబంధించిన లింక్‌లను మాత్రమే ఎంచుకుంటున్నాను, కానీ వాటి కలయిక కాదు. ఇక్కడ నేను పొందాను.
సైట్లు ఒకే ఫ్రేమ్‌వర్క్ లేదా ఒకే లైబ్రరీని ఉపయోగించే పరిస్థితిలో మొబైల్ పరికరాలలో స్క్రిప్ట్‌లను ప్రాసెస్ చేయడానికి సంబంధించిన ప్రాసెసర్ సమయం (మిల్లీసెకన్లలో)
శాతాలు
10
25
50
75
90
j క్వెరీని మాత్రమే ఉపయోగించే సైట్లు
542.9
1062.2
2297.4
4769.7
8718.2
Vueని మాత్రమే ఉపయోగించే సైట్లు
944.0
1716.3
3194.7
5959.6
9843.8
కోణీయతను మాత్రమే ఉపయోగించే సైట్లు
1328.9
2151.9
3695.3
6629.3
11607.7
రియాక్ట్‌ని మాత్రమే ఉపయోగించే సైట్లు
2443.2
4620.5
10061.4
17074.3
24956.3
సైట్లు ఒకే ఫ్రేమ్‌వర్క్‌ను లేదా ఒక లైబ్రరీని మాత్రమే ఉపయోగించే పరిస్థితిలో మొబైల్ పరికరాలలో స్క్రిప్ట్‌లను ప్రాసెస్ చేయడానికి సంబంధించిన ప్రాసెసర్ సమయం
మొదటిది, ఆశ్చర్యం కలిగించనిది: ఒక సైట్ ఒక ఫ్రేమ్‌వర్క్ లేదా ఒక లైబ్రరీని మాత్రమే ఉపయోగించినప్పుడు, అటువంటి సైట్ యొక్క పనితీరు చాలా తరచుగా మెరుగుపడుతుంది. ప్రతి పరికరం 10వ మరియు 25వ శాతాల వద్ద మెరుగ్గా పని చేస్తుంది. ఇది అర్ధమే. రెండు లేదా అంతకంటే ఎక్కువ ఫ్రేమ్‌వర్క్‌లు లేదా లైబ్రరీలను ఉపయోగించి రూపొందించిన సైట్ కంటే ఒక ఫ్రేమ్‌వర్క్‌ని ఉపయోగించి రూపొందించబడిన సైట్ మెరుగ్గా పని చేస్తుంది.
వాస్తవానికి, అధ్యయనం చేసిన ప్రతి ఫ్రంట్-ఎండ్ సాధనం యొక్క పనితీరు ఒక ఆసక్తికరమైన మినహాయింపు మినహా అన్ని సందర్భాల్లో మెరుగ్గా కనిపిస్తుంది. నన్ను ఆశ్చర్యపరిచిన విషయం ఏమిటంటే, 50వ పర్సంటైల్ మరియు అంతకంటే ఎక్కువ, రియాక్ట్‌ని ఉపయోగించే సైట్లు వారు ఉపయోగించే ఏకైక లైబ్రరీ అయినప్పుడు మరింత అధ్వాన్నంగా పనిచేస్తాయి. ఇది, మార్గం ద్వారా, నేను ఈ డేటాను ఇక్కడ అందించడానికి కారణం.
ఇది కొంచెం వింతగా ఉంది, కానీ నేను ఇప్పటికీ ఈ వింతకు వివరణ కోసం ప్రయత్నిస్తాను.
ఒక ప్రాజెక్ట్ రియాక్ట్ మరియు j క్వెరీ రెండింటినీ ఉపయోగిస్తుంటే, ఆ ప్రాజెక్ట్ j క్వెరీ నుండి రియాక్ట్‌కి మారే సమయంలో ఎక్కడో ఒక చోట ఉండవచ్చు. బహుశా దీనికి ఈ లైబ్రరీలు కలిపిన కోడ్‌బేస్ ఉండవచ్చు. రియాక్ట్ సైట్‌ల కంటే j క్వెరీ సైట్లు మెయిన్ థ్రెడ్‌లో తక్కువ సమయాన్ని వెచ్చిస్తున్నాయని మేము ఇప్పటికే చూసినందున, j క్వెరీలో కొంత కార్యాచరణను అమలు చేయడం సైట్ కొంచెం మెరుగ్గా పని చేయడంలో సహాయపడుతుందని ఇది మాకు తెలియజేయవచ్చు.
కానీ ప్రాజెక్ట్ j క్వెరీ నుండి రియాక్ట్‌కి మారినప్పుడు మరియు రియాక్ట్‌పై ఎక్కువగా ఆధారపడినప్పుడు, విషయాలు మారుతున్నాయి. సైట్ నిజంగా అధిక నాణ్యత కలిగి ఉంటే మరియు సైట్ డెవలపర్లు రియాక్ట్‌ని జాగ్రత్తగా ఉపయోగిస్తే, అటువంటి సైట్‌తో ప్రతిదీ బాగానే ఉంటుంది. కానీ సగటు రియాక్ట్ సైట్ కోసం, రియాక్ట్‌ను విస్తృతంగా ఉపయోగించడం అంటే ప్రధాన థ్రెడ్ భారీ లోడ్‌లో ఉందని అర్థం.
మొబైల్ మరియు డెస్క్‌టాప్ పరికరాల మధ్య అంతరం
మొబైల్ మరియు డెస్క్‌టాప్ పరికరాలలో సైట్‌లతో పని చేయడం మధ్య ఎంత పెద్ద అంతరం ఉందో అధ్యయనం చేయడం అనేది నేను పరిశోధించిన డేటాను పరిశీలించిన మరొక కోణం. మేము జావాస్క్రిప్ట్ కోడ్ యొక్క వాల్యూమ్లను పోల్చడం గురించి మాట్లాడినట్లయితే, అటువంటి పోలిక భయంకరమైన ఏదైనా బహిర్గతం చేయదు. అయితే, డౌన్‌లోడ్ చేయదగిన కోడ్‌ని చిన్న మొత్తంలో చూడటం మంచిది, కానీ మొబైల్ మరియు డెస్క్‌టాప్ కోడ్ మొత్తంలో చాలా తేడా లేదు.
కానీ మేము కోడ్‌ను ప్రాసెస్ చేయడానికి అవసరమైన సమయాన్ని విశ్లేషిస్తే, మొబైల్ మరియు డెస్క్‌టాప్ పరికరాల మధ్య చాలా పెద్ద గ్యాప్ గమనించవచ్చు.
డెస్క్‌టాప్‌తో పోలిస్తే మొబైల్ పరికరాల్లో ప్రాసెసింగ్ స్క్రిప్ట్‌లకు సంబంధించిన సమయం (శాతం) పెరుగుదల
శాతాలు
10
25
50
75
90
అన్ని సైట్లు
144.1
172.8
185.5
208.5
224.0
j క్వెరీ సైట్లు
188.2
187.4
191.3
209.6
221.9
Vue సైట్లు
222.5
220.8
220.2
221.4
220.4
కోణీయ సైట్లు
205.1
206.0
201.6
210.4
218.7
రియాక్ట్ సైట్లు
431.5
386.8
337.9
242.6
179.6
ఫోన్ మరియు ల్యాప్‌టాప్ మధ్య కోడ్ ప్రాసెసింగ్ వేగంలో కొంత వ్యత్యాసాన్ని అంచనా వేయవలసి ఉన్నప్పటికీ, ఆధునిక ఫ్రేమ్‌వర్క్‌లు తక్కువ శక్తితో పనిచేసే పరికరాలను తగినంతగా లక్ష్యంగా చేసుకోలేదని మరియు వారు కనుగొన్న అంతరాన్ని మూసివేయడానికి ప్రయత్నిస్తున్నాయని అలాంటి పెద్ద సంఖ్యలు నాకు చెబుతున్నాయి. 10వ పర్సంటైల్ వద్ద కూడా, డెస్క్‌టాప్ మెయిన్ థ్రెడ్ కంటే మొబైల్ మెయిన్ థ్రెడ్‌లో రియాక్ట్ సైట్లు 431.5% ఎక్కువ సమయాన్ని వెచ్చిస్తాయి. j క్వెరీకి అతి చిన్న గ్యాప్ ఉంది, కానీ ఇక్కడ కూడా సంబంధిత సంఖ్య 188.2%. వెబ్‌సైట్ డెవలపర్లు వారి ప్రాసెసింగ్‌కు ఎక్కువ ప్రాసెసర్ సమయం అవసరమయ్యే విధంగా వారి ప్రాజెక్ట్‌లను రూపొందించినప్పుడు (మరియు ఇది జరుగుతుంది మరియు ఇది కాలక్రమేణా మరింత దిగజారుతుంది), తక్కువ శక్తితో పనిచేసే పరికరాల యజమానులు దాని కోసం చెల్లించాలి.
ఫలితాలు
మంచి ఫ్రేమ్‌వర్క్‌లు డెవలపర్‌లకు వెబ్ ప్రాజెక్ట్‌లను (భద్రత, ప్రాప్యత, పనితీరు పరంగా) నిర్మించడానికి మంచి పునాదిని అందించాలి లేదా ఆ పరిమితులను ఉల్లంఘించే వాటిని నిర్మించడం కష్టతరం చేసే అంతర్నిర్మిత పరిమితులను కలిగి ఉండాలి.
ఇది వెబ్ ప్రాజెక్ట్‌ల పనితీరుకు వర్తించదు (మరియు బహుశా వాటికి కాదు ).
రియాక్ట్ లేదా కోణీయ సైట్లు ఇతర వాటి కంటే కోడ్‌ని సిద్ధం చేయడానికి ఎక్కువ CPU సమయాన్ని వెచ్చించినందున రియాక్ట్ సైట్లు రన్ అవుతున్నప్పుడు Vue సైట్‌ల కంటే ఎక్కువ CPU ఇంటెన్సివ్‌గా ఉన్నాయని అర్థం కాదు. వాస్తవానికి, మేము సమీక్షించిన డేటా ఫ్రేమ్‌వర్క్‌లు మరియు లైబ్రరీల కార్యాచరణ పనితీరు గురించి చాలా తక్కువగా చెబుతుంది. స్పృహతో ఉన్నా లేకున్నా, ఈ ఫ్రేమ్‌వర్క్‌లు ప్రోగ్రామర్‌లను నెట్టగల అభివృద్ధి విధానాల గురించి వారు మరింత మాట్లాడతారు. మేము ఫ్రేమ్‌వర్క్‌ల కోసం డాక్యుమెంటేషన్ గురించి, వాటి పర్యావరణ వ్యవస్థ గురించి, సాధారణ అభివృద్ధి పద్ధతుల గురించి మాట్లాడుతున్నాము.
సైట్ యొక్క పేజీల మధ్య నావిగేట్ చేస్తున్నప్పుడు పరికరం జావాస్క్రిప్ట్ కోడ్‌ని అమలు చేయడానికి ఎంత సమయం వెచ్చిస్తుంది అనే విషయాన్ని మేము ఇక్కడ విశ్లేషించని విషయాన్ని కూడా పేర్కొనడం విలువ. SPAకి అనుకూలంగా ఉన్న వాదన ఏమిటంటే, సింగిల్ పేజీ అప్లికేషన్‌ను బ్రౌజర్‌లోకి లోడ్ చేసిన తర్వాత, వినియోగదారు సైద్ధాంతికంగా సైట్ యొక్క పేజీలను వేగంగా తెరవగలుగుతారు. ఇది వాస్తవానికి దూరంగా ఉందని నా స్వంత అనుభవం నాకు చెబుతుంది. కానీ ఈ సమస్యను స్పష్టం చేయడానికి మా వద్ద డేటా లేదు.
స్పష్టమైన విషయం ఏమిటంటే, మీరు వెబ్‌సైట్‌ను రూపొందించడానికి ఫ్రేమ్‌వర్క్ లేదా లైబ్రరీని ఉపయోగిస్తుంటే, ప్రాజెక్ట్‌ను మొదట్లో లోడ్ చేయడం మరియు దాన్ని సిద్ధంగా ఉంచుకోవడంలో మీరు రాజీ పడుతున్నారు. ఇది చాలా సానుకూల దృశ్యాలకు కూడా వర్తిస్తుంది.
తగిన పరిస్థితుల్లో కొన్ని రాజీలు చేయడం ఖచ్చితంగా సాధ్యమే, అయితే డెవలపర్లు అలాంటి రాజీలను స్పృహతో చేయడం ముఖ్యం.
కానీ మనకు ఆశావాదానికి కారణం కూడా ఉంది. ఆ సాధనాల పనితీరును మెరుగుపరచడంలో సహాయపడే ప్రయత్నంలో మేము సమీక్షించిన కొన్ని ఫ్రంట్-ఎండ్ సాధనాల డెవలపర్‌లతో Chrome డెవలపర్లు ఎంత సన్నిహితంగా పని చేస్తున్నారో చూడడానికి నేను సంతోషిస్తున్నాను.
అయితే, నేను ఆచరణాత్మక వ్యక్తిని. కొత్త ఆర్కిటెక్చర్‌లు పనితీరు సమస్యలను తరచుగా పరిష్కరిస్తాయి. మరియు బగ్‌లను పరిష్కరించడానికి సమయం పడుతుంది. మనం ఊహించనట్లే అన్ని పనితీరు సమస్యలను పరిష్కరిస్తుంది, మీరు దీన్ని మా ఇష్టమైన ఫ్రేమ్‌వర్క్‌ల యొక్క కొత్త వెర్షన్‌ల నుండి ఆశించకూడదు.
మీరు ఈ ఆర్టికల్‌లో చర్చించిన ఫ్రంట్-ఎండ్ టూల్స్‌లో ఒకదానిని ఉపయోగించాలనుకుంటే, ఈ సమయంలో మీ ప్రాజెక్ట్ పనితీరుకు హాని కలిగించకుండా ఉండటానికి మీరు అదనపు ప్రయత్నం చేయాల్సి ఉంటుందని అర్థం. కొత్త ఫ్రేమ్‌వర్క్‌ను ప్రారంభించే ముందు పరిగణించవలసిన కొన్ని పరిగణనలు ఇక్కడ ఉన్నాయి:
- ఇంగితజ్ఞానంతో మిమ్మల్ని మీరు పరీక్షించుకోండి. మీరు ఎంచుకున్న ఫ్రేమ్‌వర్క్‌ని నిజంగా ఉపయోగించాల్సిన అవసరం ఉందా? స్వచ్ఛమైన జావాస్క్రిప్ట్ నేడు చాలా సామర్థ్యం కలిగి ఉంది.
- ఈ ఫ్రేమ్‌వర్క్ యొక్క 90% సామర్థ్యాలను మీకు అందించగల ఎంపిక ఫ్రేమ్‌వర్క్‌కు (ప్రీయాక్ట్, స్వెల్ట్ లేదా మరేదైనా) తేలికైన ప్రత్యామ్నాయం ఉందా?
- మీరు ఇప్పటికే ఫ్రేమ్‌వర్క్‌ని ఉపయోగిస్తుంటే, మెరుగైన, మరింత సాంప్రదాయికమైన, ప్రామాణికమైన ఎంపికలను అందించే ఏదైనా ఉంటే పరిగణించండి (ఉదా. Vueకి బదులుగా Nuxt.js, Reactకి బదులుగా Next.js మొదలైనవి).
- మీ ఏమి అవుతుంది జావాస్క్రిప్ట్ పనితీరు?
- మీరు ఎలా చేయగలరు ఖచ్చితంగా అవసరమైన దానికంటే ఎక్కువ జావాస్క్రిప్ట్ కోడ్‌ని ప్రాజెక్ట్‌లోకి ఇంజెక్ట్ చేయడం కష్టతరం చేసే అభివృద్ధి ప్రక్రియ?
- మీరు అభివృద్ధి సౌలభ్యం కోసం ఫ్రేమ్‌వర్క్‌ను ఉపయోగిస్తుంటే, పరిగణించండి క్లయింట్‌లకు ఫ్రేమ్‌వర్క్ కోడ్‌ని పంపండి. బహుశా మీరు సర్వర్‌లోని అన్ని సమస్యలను పరిష్కరించగలరా?
మీరు ఫ్రంట్ ఎండ్ డెవలప్‌మెంట్ కోసం సరిగ్గా ఎంచుకున్న దానితో సంబంధం లేకుండా సాధారణంగా ఈ ఆలోచనలు చూడటం విలువైనవి. కానీ మీరు మొదటి నుండి పనితీరు లేని ప్రాజెక్ట్‌లో పని చేస్తున్నప్పుడు అవి చాలా ముఖ్యమైనవి.
ప్రియమైన పాఠకులారా! మీరు ఆదర్శ జావాస్క్రిప్ట్ ఫ్రేమ్‌వర్క్‌ను ఎలా చూస్తారు?
మూలం: www.habr.com